Unknown attackers used compromised identity and access management (IAM) credentials associated with Qubole’s AWS account to access customer AWS environments, stealing secrets and other sensitive data from S3 buckets.
Qubole is a cloud data processing platform that uses cross-account IAM roles to manage compute and access storage in customers’ AWS environments without requiring customers to provide long-lived AWS access keys. The supply-chain attack abused this third-party, cross-account trust relationship.
Google’s cloud-security shop Wiz declined to tell us how many organizations were affected, but called it a “broad, opportunistic supply chain campaign” that hit “multiple” customer environments.
“Because many organizations left trust policies active even after deprecating the platform, the attacker was able to successfully assume integration roles, enumerate cloud resources, harvest secrets, and siphon data,” the researchers told The Register in an emailed response to questions.
Neither AWS nor Qubole responded to The Register‘s inquiries.
Wiz, working with Google’s Mandiant incident responders after AI data security company Sentra flagged suspicious activity, traced the malicious activity back to October 14, when credentials associated with Qubole’s AWS account were used to call the sts:AssumeRole API to obtain temporary credentials for customer-managed integration roles.
The calls originated from Qubole AWS account 805246085872, and used IAM user ID AIDA3W7DIFLYOLTK63SFS, Wiz analysts Zack Morrow, Sean Johnstone, and Benjamin Read said in a Monday blog about the supply chain attack. “Across the affected environments, Wiz CIRT has not observed this IAM user in any activity other than that associated with this threat actor,” the trio wrote.
This activity continued on October 15, and on October 18, the digital intruders began using a second IAM user from the same account.
Once inside customers’ environments, the crooks began probing a ton of AWS services and stealing credentials, keys, and other secrets stored across Lambda, Secrets Manager, and SSM Parameter Store.
The miscreants also used TruffleHog to test AWS credentials belonging to victim organizations, discover their Microsoft Entra ID secrets, and request OAuth tokens using Okta client credentials also uncovered while snooping around the AWS environments.
Abusing the integration roles also allowed the criminals to steal data from customers’ S3 storage, although it seems they were largely opportunistic attackers, in some cases downloading entire buckets, as opposed to state-sponsored spies looking for specific data.
The threat hunters haven’t attributed the supply chain attack to any particular group, and say they don’t have any insight into how the miscreants are using the stolen data.
While investigating this incident, Wiz spotted a separate campaign between October 8 and October 11 that also used customer-owned AWS access keys for Qubole integrations. While a “small number” of these also resulted in the intruders compromising victim organizations’ AWS environments, Wiz said it can’t definitively connect the two sets of malicious activity.
Organizations that have integrated with Qubole should rotate credentials – although rotating a credential does not end temporary sessions that were already issued.
Customers should also review CloudTrail from October 1 onward, looking for AssumeRole events where userIdentity.accountId matches Qubole’s AWS account ID, 805246085872, particularly those originating from non-AWS IP addresses.
“For every role session you find, review all subsequent activity from that session, especially Secrets Manager, SSM Parameter Store, Lambda and S3,” the researchers wrote. “If the threat actor assumed an integration role, rotate every secret, parameter and Lambda environment variable the role could read, and revoke active sessions for the role.”®
