Wiz: attacker used Qubole's AWS account to assume customer IAM roles and steal secrets and S3 data

What happened

Security firm Wiz disclosed on November 9 that an attacker spent twelve days, from October 14 to October 26, operating inside the AWS environments of multiple Qubole customers without ever touching a customer credential. According to a RedEye Threat Intelligence analysis republished on dev.to, the intruder held credentials for AWS account 805246085872 — the account Qubole's data lake platform uses to reach customer environments — and used them to assume the IAM roles customers had created to admit the vendor.

Sentra first noticed the activity across several of its own customers' environments and alerted Wiz. Neither Qubole nor its owner Idera had published a statement when The Hacker News checked on publication day, and Wiz has not said how the credentials were obtained, whether they have been disabled, or whether the activity has stopped.

Why the trust relationship was the vulnerability

Qubole operates inside customer AWS accounts, so each customer creates an IAM role whose trust policy names Qubole's account, and every AssumeRole call must carry a matching External ID supplied by Qubole. The attacker's requests all included the correct External ID and were accepted — the mechanism working exactly as designed. AWS's own guidance treats the External ID as a non-secret: it is visible to anyone who can read the role, appears in plain text in CloudTrail logs, and is routinely stored by vendors and in infrastructure-as-code repositories. Once the attacker controlled the trusted account, the check offered no real resistance.

Wiz also found that most of the roles the attacker assumed were dormant. Former customers who had stopped using Qubole never removed the role or its trust relationship, leaving the vendor account with standing access to their environments.

What the attacker did inside

Credentials came first, data second. In the accounts Wiz examined, the attacker read Lambda environment variables, pulled secrets from AWS Secrets Manager, read SSM Parameter Store values, and ran the harvested material through TruffleHog to confirm which credentials actually worked — including victims' own AWS access keys, Entra ID client secrets and Okta client credentials. The attacker then copied S3 data from any bucket the role could reach, in some cases downloading an entire bucket in a single session, without apparent targeting.

Wiz has not connected the campaign to any other publicly reported activity and notes the indiscriminate collection does not match typical state-backed targeting. The validated Entra ID and Okta secrets matter beyond AWS: they extend the blast radius into the victims' identity providers and every SaaS application those identities can reach.

A second, separate campaign ran from October 8 to October 11, in which an attacker used customers' own static AWS access keys — keys Wiz believes were created for Qubole's alternative connection method — to compromise a few environments. Wiz has not linked the two campaigns, though both hit the same customer base through the same vendor integration.

Detection guidance and a logging gap

Wiz's hunting guidance covers CloudTrail from October 1 onward in every account that holds a Qubole role. Because legitimate Qubole traffic originated only from AWS address space, source address is the strongest single signal. Indicators include AssumeRole calls from account 805246085872 arriving from non-AWS addresses, two suspect IAM principals, OVH-hosted and Mullvad VPN source IPs, role session names beginning with quiam-, and the TruffleHog user agent on GetCallerIdentity calls.

One gap limits incident response: CloudTrail management events record each AssumeRole call and bucket listing, but not which S3 objects were read. That requires S3 data events or S3 server access logs, which several victims had not enabled, leaving responders unable to determine exactly what was taken.

Wiz's remediation advice

Wiz treats any assumed Qubole role as a full credential compromise: rotate every secret, parameter and Lambda environment variable the role could reach, and revoke the role's active sessions, since rotation alone does not end sessions already issued. Longer term, Wiz recommends removing Qubole roles that are no longer needed, replacing account-wide root principals in trust policies with Qubole's specific IAM principal where supported, adding SourceIp or SourceVpce conditions tied to the vendor's documented network ranges, rotating the External ID after an incident, using distinct values per role, and alerting on vendor-account AssumeRole traffic that arrives through VPN infrastructure. Wiz states that a source IP condition by itself would have blocked every role assumption it observed.

Wiz also points to overbroad vendor permissions as a root cause: Qubole's own setup guide includes a sample S3 policy granting read access to every bucket in the account, and vendor roles commonly receive Lambda configuration, Secrets Manager, SSM and wide S3 read rights for convenience.

Why it matters

This is a supply-chain compromise without a poisoned package: the trusted artifact was a cross-account trust policy, often left in place by organizations that had long since stopped using the product, and the External ID — widely treated as a security boundary — functioned as little more than a routing label. Any SaaS platform holding standing AssumeRole access into customer clouds is a template for the same attack, and the same gaps will determine the next victim's impact: dormant vendor roles, root-level trust principals, no network conditions, broad S3 and secrets permissions, and missing S3 data event logging. Until Qubole or Idera explains how the account was compromised and confirms containment, any organization with a Qubole trust relationship should treat its exposure as unresolved.