Attacker Used Qubole's AWS Access to Raid Customer Accounts

An attacker broke into AWS accounts belonging to several customers of Qubole, a data lake platform, between October 14 and October 26 and took stored secrets and data, according to cloud security company Wiz, which worked with Sentra and Mandiant. The attacker did not need to attack each customer separately. They used credentials for an AWS account that Qubole’s platform uses to reach customer environments, and AWS accepted those requests because each customer had created a role that trusts that account. How the attacker got the credentials has not been disclosed.

The way Qubole connects is common to many SaaS tools: a customer creates an AWS IAM role whose trust policy lets the vendor’s account assume it, gated by an “External ID”. Wiz says every request it attributed to the attacker carried a valid External ID and succeeded, and that most of the roles involved were not otherwise in use. In the accounts it examined, the attacker listed resources, read Lambda environment variables, Secrets Manager entries and SSM Parameter Store values, tested the credentials it found with the TruffleHog tool (victims’ own AWS keys, Entra ID client secrets and Okta client credentials), and copied data out of S3, sometimes a whole bucket at once. Wiz has not tied the campaign to any known group and says the targeting looks opportunistic. The Hacker News reported that neither Qubole nor its owner Idera had posted a statement when it checked, and that the researchers did not say whether the credentials have been disabled. Wiz also saw a separate, unlinked burst on October 8 to 11 in which an actor used customers’ own AWS access keys, believed to have been created for Qubole integrations.

How to check if you’re affected

Affected products are any AWS account that has a Qubole integration role, including accounts that no longer use Qubole, because the unused roles still trusted Qubole’s account. Wiz advises reviewing CloudTrail logs from October 1, 2026 onward in every account that holds such a role, looking for:

• AssumeRole events where userIdentity.accountId is 805246085872 and the source IP address is not an AWS address. Wiz saw Qubole’s legitimate traffic come only from AWS.
• AssumeRole events from IAM principal ID AIDA3W7DIFLYOLTK63SFS. In the environments Wiz examined, only the attacker used it.
• Events from principal ID AIDAJYRRH5Y3A7AAJM2HW when the source address is outside AWS. This user also carries legitimate Qubole traffic, so the source address is what separates the two.
• Source IPs 57.129.54[.]120 and 2001:41d0:70d[:]7800:: (OVH-hosted), and 45.83.220[.]211, 185.209.199[.]73 and 89.37.63[.]175 (Mullvad VPN addresses that other people also use, so a match alone is not proof).
• Role session names beginning with quiam- (for example quiam-enum), and the TruffleHog user agent on GetCallerIdentity calls from those addresses, also in your identity provider’s sign-in logs.

For any suspicious session, review what it did afterward, especially in Secrets Manager, SSM Parameter Store, Lambda and S3. Wiz notes that without S3 data events or server access logs, responders could not see which objects were read in several victims. For the longer-term fix, Wiz recommends removing trust for integrations you no longer use, narrowing the trusted principal, adding an aws:SourceIp or aws:SourceVpce condition (it says a source-IP condition alone would have blocked every role assumption it saw), and treating the External ID as non-secret.

Sources

• Wiz: Trusted by Default: Qubole Cross-Account Access Abused in the Wild
• The Hacker News: Hackers Exploit Qubole’s Trusted AWS Access to Breach Customer Accounts and Steal Data
• AWS: Access to AWS accounts owned by third parties (linked from The Hacker News as AWS’s External ID guidance)