
Attackers Exploit Qubole Trusted AWS Access to Breach Customer Accounts and Steal Data
Attackers used Qubole's trusted AWS account to assume customer IAM roles between Oct 14 and Oct 26, stealing secrets and data from S3, Secrets Manager and Lambda environments, according to cloud security firm Wiz.
Attackers leveraged Qubole's trusted AWS account to assume customer IAM roles between October 14 and October 26 and stole credentials and data from multiple cloud services.
Attack Details
The intrusion used the Qubole platform account identifier 805246085872. Each AssumeRole request included a valid external ID, which AWS treats as non-secret and is visible in CloudTrail logs. The attacker accessed Lambda environment variables, Secrets Manager, and SSM Parameter Store, then tested harvested keys with TruffleHog. Data was copied from any S3 bucket the assumed role could read, sometimes downloading entire buckets in a single session. A separate campaign from October 8 to October 11 used customers' own AWS access keys that had been configured for Qubole, compromising a few environments.
Detection Guidance
Organizations should search CloudTrail management events from October 1 onward for AssumeRole calls where the requesting account ID is 805246085872 and the source IP address is not an AWS address. Key indicators include IAM principal IDs AIDA3W7DIFLYOLTK63SFS and AIDAJYRRH5Y3A7AAJM2HW when the source is external, IP addresses 57.129.54.120, 2001:41d0:70d:7800::, 45.83.220.211, 185.209.199.73, 89.37.63.175, session names starting with quiam-, and the user agent TruffleHog on GetCallerIdentity calls. Review all actions taken after any suspicious session, especially in Secrets Manager, SSM Parameter Store, Lambda, and S3. Enable S3 data events or server access logs to capture object-level reads.
Mitigation Steps
If a Qubole role was assumed, rotate all secrets, parameters, and Lambda environment variables that the role could reach and revoke active sessions. Remove unused Qubole roles or delete Qubole's account from the role trust policy. Where possible, replace the account-wide root principal in the trust policy with the specific IAM principal Qubole uses and add an aws:SourceIp or aws:SourceVpce condition limiting AssumeRole to Qubole's documented network ranges. Change external IDs after an incident and use a unique value per role. Audit the permissions granted to vendor roles, which often include broad S3 read, Lambda, Secrets Manager, and SSM access. Set alerts for AssumeRole requests arriving from VPN or hosting providers not used by the vendor, and ensure organization-wide CloudTrail logging with S3 data events for sensitive buckets.
Sources: The Hacker News · The Register
SiTech — AI-powered web development
We build fast, modern websites and bring AI into real business workflows. Have a project or a question? We'd love to help.