Qubole Trusted AWS Access Breach: A Vendor Role That Spied on Every Customer

An attacker broke into AWS accounts belonging to multiple Qubole customers between October 14 and 26 and stole stored secrets and data, according to cloud security firm Wiz's technical analysis.

The attacker used credentials for an AWS account that Qubole's platform uses to reach those customers. How the credentials were obtained has not been disclosed.

How Vendor Roles Work

Qubole, a data lake platform owned by Idera, operates inside its customers' AWS accounts. To let it in, a customer creates an IAM role — an AWS identity with its own set of permissions. The role's trust policy allows Qubole's AWS account to assume the role, granting those permissions. Each such request, called AssumeRole, must include a matching code from Qubole known as an External ID.

Apart from the attack, most roles the attacker assumed were unused — but each still trusted Qubole's account, so the attacker's requests worked.

What the Attacker Did Inside

In the examined accounts, the attacker hunted for stored credentials: it read Lambda environment variables, pulled secrets from Secrets Manager, and read values from the SSM Parameter Store. It then ran found credentials through TruffleHog — victims' own AWS access keys, Entra ID client secrets, and Okta client credentials.

It also copied data out of S3. Rather than searching for specific data, it retrieved whatever a role could access, and sometimes downloaded an entire bucket in a single session.

Qubole also lets customers connect with AWS access keys instead of a role. Between October 8 and 11, a separate attacker used customers' own keys believed to have been set up for Qubole, and compromised a few victims' cloud environments. The researchers have not linked the two activities.

The External ID Problem

The uncomfortable lesson is that the External ID is not a secret. Every attacker AssumeRole request carried one and was accepted. AWS's own External ID guidance says the code is visible to anyone with access to the role. It is logged in plain text in CloudTrail, and vendors and IaC files often store it.

One quoted sensor explains: the researchers said a source IP condition alone would have blocked every role assumption observed. The fix is mechanical — constrain by aws:SourceIp or aws:SourceVpce where the vendor supports it.

How to Check Your Accounts

Wiz's hunting guidance covers CloudTrail logs from October 1 in every AWS account holding a Qubole role:

• Account: AssumeRole requests where userIdentity.accountId is 805246085872 and sourceIPAddress is not an AWS address — Qubole's real traffic came only from AWS.
• Principal ID: AIDA3W7DIFLYOLTK63SFS — used only by the attacker in examined accounts.
• Principal ID: AIDAJYRRH5Y3A7AAJM2HW from a non-AWS source — the attacker used it from October 18, but Qubole's normal traffic also uses it.
• IPs: 57.129.54[.]120, 2001:41d0:70d[:]7800:: (OVH), and Mullvad VPN exits — a match alone is not proof.
• Session names starting with quiam-, such as quiam-enum.
• User agent: TruffleHog on GetCallerIdentity calls from those IPs.

CloudTrail management events log each AssumeRole and bucket listing, but not which S3 objects were read. That requires S3 data events or server access logs — several victims lacked them, so responders could not tell which objects were read.

How to Close the Route

1. Rotate every secret, parameter, and Lambda environment variable the compromised role could reach — and revoke the role's active sessions. Rotating a credential does not end already-issued sessions.
2. Remove unused Qubole roles, or take Qubole's account out of the trust policy entirely.
3. Where Qubole supports it, replace account-wide :root principals with the specific IAM principal.
4. Add aws:SourceIp / aws:SourceVpce conditions limiting AssumeRole to the vendor's documented ranges.
5. Change the External ID per role; treat it as an identifier, not a control.
6. Review what vendor roles can reach — Qubole's own setup guide ships a sample S3 policy granting read on every bucket in the account.
7. Alert on vendor-account AssumeRole requests arriving through VPNs or unfamiliar hosting.
8. Keep an organization-wide CloudTrail and enable S3 data events for sensitive buckets.

Sources

• The Hacker News coverage
• Wiz technical analysis
• AWS External ID guidance
• Qubole IAM roles setup guide