Stolen IAM credentials at Qubole opened the AWS environments of customers who forgot to revoke their trust

November 9, 2026. Researchers at Wiz published an investigation that should make any cloud team sit up straight: an attacker used compromised IAM credentials from the AWS account of Qubole, a data-processing platform, to assume the cross-account roles that customers had granted the vendor. Between October 14 and 26, 2026, the attacker enumerated resources, harvested secrets from Secrets Manager, SSM Parameter Store and Lambda, then drained S3 data. The uncomfortable part: most of the assumed roles were no longer in use, but their trust policies were still active.

What happened: a vendor, cross-account roles, and dormant trust

Qubole runs on a pattern that has become standard across the AWS ecosystem. Instead of asking for long-lived access keys, the customer creates an IAM role in their own account whose trust policy lets the vendor’s account assume it, usually gated by an External ID. When the platform needs to act, an identity in Qubole’s account calls sts:AssumeRole and receives temporary credentials scoped to that role.

That model moves the risk. Security no longer depends on a key you rotate, but on a trust relationship that, once set up, tends to stay in place — even after the customer stops using the service. That is precisely the crack this campaign walked through. Wiz put it plainly: “many organizations left trust policies active even after deprecating the platform.” The attacker did not have to break anything — the doors were simply still open.

Wiz, alerted by the data-security firm Sentra and then backed by Mandiant, traced the activity to October 14, 2026. That day, an IP address belonging to the Mullvad VPN (45.83.220.211) called AssumeRole against integration roles, from AWS account 805246085872 and using the IAM user AIDA3W7DIFLYOLTK63SFS. The researchers saw that user in no activity other than the attacker’s. From October 15, most traffic shifted to an OVH VPS (57.129.54.120); on October 18, a second IAM user in the same account (AIDAJYRRH5Y3A7AAJM2HW) joined in. Every AssumeRole attributed to the attacker carried an External ID, and every one succeeded.

What the attacker did, step by step

Once inside, the intruder worked methodically and opportunistically. Session names followed a constant prefix, quiam- — quiam-enum, quiam-scope-full — which, in hindsight, made the retrospective hunt easier.

First came enumeration, broad and untargeted: ListBuckets, ListObjects, GetDatabases, ListTables, DescribeClusters, DescribeInstances, DescribeSecurityGroups, DescribeVpcs, DescribeDBInstances, ListRoles, ListKeys, GetKeyPolicy. The attacker was mapping what each role let them reach.

Then secret harvesting, focused on the three places where AWS stores credentials by default: the environment variables of Lambda functions (via GetFunctionConfiguration), secrets in Secrets Manager (ListSecrets then GetSecretValue), and parameters in SSM Parameter Store (DescribeParameters then GetParameter).

Then validation, using TruffleHog. The tool tested the AWS keys it found (a GetCallerIdentity call, which needs no permission), signed in as Microsoft Entra ID service principals using stolen client secrets, and requested OAuth tokens from Okta with recovered client credentials. That detail is what turns an AWS intrusion into a multi-cloud identity compromise: the attacker never stopped at the edge of the breached account.

Finally, exfiltration, with an identical sequence everywhere: assume a role, list reachable buckets, enumerate objects, download them. The researchers describe an opportunistic actor who “read from whatever buckets each role could reach,” at times downloading entire buckets in a single session, with no apparent interest in any specific type of data.

The detail that makes it worse: a bootable evidence-wiper

Wiz’s report also surfaced an unusual artifact. Hosted on the OVH server the attacker controlled was an ISO image named sso_agent.iso (SHA-256 65f061281c9a712e9502793dc4c5035cae490b84da05f7d4223cefa65ad396e4). It is a bootable Linux image designed to be launched remotely on a victim machine: it starts a 90-minute countdown, gathers system information, uploads interface and partition lists, then polls an address on TCP port 23458 and runs whatever script it receives. The loading of the ntfs3 driver points to a Windows target. When the timer runs out, a hard reboot erases any trace. Wiz found no deployment of the image — but its existence signals an actor already preparing the next phase.

A second, unlinked front

The researchers also spotted a separate campaign, from October 8 to 11, 2026, that this time used customer-owned AWS access keys created for Qubole integrations. On October 8, the actor tested every one of those keys within a single hour; in a small number of cases, they went on to compromise the cloud environment. Wiz says it cannot definitively connect the two sets of activity — which suggests the Qubole account compromise is only one brick in a larger picture.

What to do: the hunt and the cleanup

Wiz provides a concrete detection plan, portable to any vendor. Any organization that has integrated Qubole should review CloudTrail from October 1, 2026 in every account holding an integration role, looking for three signals: AssumeRole events whose userIdentity.accountId is 805246085872 with a non-AWS source IP (all legitimate traffic observed came from AWS infrastructure); events whose principalId is AIDA3W7DIFLYOLTK63SFS; and events from AIDAJYRRH5Y3A7AAJM2HW filtered on the non-AWS source. A GetCallerIdentity carrying a TruffleHog user-agent alongside a known IP betrays the credential-validation phase.

For every role session found, rotate every secret, parameter and environment variable the role could read, and revoke the active sessions. The detail that trips everyone: rotating a credential does not end temporary sessions that were already issued.

Two preventive measures stand out from the report. The first is to inventory third-party trust relationships — list every role whose trust policy allows an external account, along with the permissions and data it can reach. The second is to enable S3 data events or server access logs on sensitive buckets: CloudTrail management events record the role assumption and the listing, but not the object reads that make up the exfiltration itself.

Verdict

This campaign exploited no software flaw. It exploited configuration debt: cross-account trust relationships set up at onboarding and never revoked when the vendor was dropped. The vendor’s AWS account became a bridge into dozens of customer environments, and nobody was watching the bridge.

If you have integrated Qubole, run the CloudTrail hunt above today, then rotate every exposed secret — that part is non-negotiable. If you consume any SaaS provider that operates through cross-account roles, do the inventory exercise even without any sign of compromise: for each external trust role, ask whether it is still needed, what it can read, and who is watching its AssumeRole calls. If you provide this kind of integration, an External ID is not enough: you need to monitor assumptions from unexpected sources. The rule to remember: a cloud trust relationship is a standing access right, not a one-time configuration — it must be inventoried, monitored and revoked like any privileged account.

References

• Wiz — “Trusted by Default: Qubole Cross-Account Access Abused in the Wild” (November 9, 2026)
• The Register — “Attackers backdoor trusted AWS integrations to steal secrets” (November 9, 2026)
• The Hacker News — “Hackers Exploit Qubole’s Trusted AWS Access to Breach Customer Accounts and Steal Data” (November 9, 2026)