Qubole Breach Turned Vendor AWS Trust Into a Skeleton Key

Someone walked into dozens of customer AWS accounts between October 14 and October 26 carrying Qubole's own keys. Not stolen passwords to customer accounts — the vendor's credentials, the ones its cloud data platform legitimately uses to assume IAM roles customers had created for it. Once inside, the attacker enumerated resources, emptied secrets stores, tested harvested credentials with TruffleHog, and in some cases downloaded entire S3 buckets, according to research from The Hacker News and CSO Online.

The campaign was flagged by AI data security company Sentra, investigated by Google's Wiz — whose CIRT analysts Zack Morrow, Sean Johnstone and Benjamin Read published the technical breakdown — with Mandiant incident responders in the loop, per The Register. It hasn't been attributed to any group, the targeting looks opportunistic rather than espionage-shaped, and one detail should annoy every security architect reading this: many of the compromised roles belonged to organizations that had stopped using Qubole. The trust outlived the contract.

The primitive: a trust policy that outlived the vendor

Quick mechanics, because the whole attack is just one API call with a borrowed identity. Qubole — a data lake platform owned by Idera — operates inside customer AWS accounts to manage compute and touch storage without customers handing over long-lived access keys. The standard pattern: the customer creates an IAM role, and the role's trust policy lets Qubole's AWS account (805246085872) call sts:AssumeRole on it. An External ID is supposed to act as a shared-knowledge check against confused-deputy abuse.

Here's the catch that makes this a vendor-compromise story rather than a customer-misconfig story: the External ID isn't treated as a secret. Per AWS's own external ID guidance, anyone who can view the role can see it. The attacker had credentials for Qubole's AWS account — how they got them has not been disclosed — and every malicious AssumeRole request Wiz observed carried the correct External ID and succeeded. The lock worked exactly as designed. The attacker had the key.

It's the classic ladder mechanic from any stealth game: the guard's uniform gets you past every checkpoint until someone revokes the uniform. Nobody here revoked it. Wiz found that many targeted roles had seen zero legitimate Qubole activity during October — the platform relationship was dead — but the trust policy was still live, and that's all AssumeRole checks.

October 8–11: the warmup act nobody can quite connect

During its investigation, Wiz spotted a separate campaign running October 8 through 11 that abused a different integration method: Qubole also lets customers connect with their own AWS access keys instead of roles, and an attacker used customer-owned keys believed to have been set up for Qubole to compromise what The Register describes as a small number of victim environments. Wiz says it can't definitively link this to the main event. Treat it as an open question — but it suggests whoever was behind this had been poking at Qubole's integration surface for at least a week before the AssumeRole campaign kicked off.

October 14–15: first blood via Mullvad

The first confirmed malicious activity landed on October 14. An IP address associated with Mullvad VPN attempted to assume customer integration roles from Qubole's account using an IAM user identified as AIDA3W7DIFLYOLTK63SFS. Wiz's CIRT team made a pointed observation about this principal, quoted in The Register's coverage:

Across the affected environments, Wiz CIRT has not observed this IAM user in any activity other than that associated with this threat actor.

That makes AIDA3W7DIFLYOLTK63SFS a gold-standard IOC: any appearance of it in your CloudTrail is malicious by definition. The activity continued on October 15, and on October 18 the attacker began using a second IAM user from the same Qubole account — AIDAJYRRH5Y3A7AAJM2HW — alongside another Mullvad address. This one requires care: Qubole's legitimate traffic also uses that identity, so it's only an IOC when the source address is outside AWS. Wiz says Qubole's real traffic comes only from AWS infrastructure, which gives defenders a clean discriminator.

Most of the later activity originated from an OVH-hosted VPS, 57.129.54[.]120 (with IPv6 sibling 2001:41d0:70d[:]7800::). The Mullvad addresses — 45.83.220[.]211, 185.209.199[.]73, 89.37.63[.]175 — are shared VPN egress, so a match alone isn't proof. The attacker also ran role sessions starting with quiam-, like quiam-enum, which is a lovely little hunting hook.

Inside the accounts: a secrets store speedrun

Post-assumption, the tradecraft was pure enumeration-and-harvest, and honestly it reads like a CTF privilege-escalation checklist executed at production scale. The attacker mapped S3 buckets, databases, EC2 instances, security groups and IAM identities, then went straight for the places AWS customers keep their crown jewels: Secrets Manager, Systems Manager Parameter Store and Lambda environment variables. Sentra reported more than 100 passwords and keys read within minutes, plus thousands of additional credential records inside downloaded files.

Then the interesting move: the attacker ran harvested credentials through TruffleHog — yes, the open-source secrets scanner — to validate what worked. Confirmed tested-and-live loot included victims' own AWS access keys, Microsoft Entra ID service principal credentials and Okta OAuth client credentials. Wiz's guidance explicitly tells defenders to check identity provider sign-in logs for the TruffleHog user agent on GetCallerIdentity calls. That's the blast-radius concern: this wasn't just an AWS breach, it was a credential broker for everything else those environments touched. We've seen what live token exposure does to incident scope before — the Chainalysis breach that exposed live tokens for every user turned a single compromise into a per-customer rotation marathon, and the same math applies here.

On S3, the behavior was grab-everything: enumerate accessible buckets and objects, pull the contents, sometimes an entire bucket in a single session. That opportunism is why Wiz says the targeting doesn't match state-backed playbooks — no selection, no staging, just mass collection. Sentra noted the attacker performed no write operations in observed environments, consistent with a theft operation rather than pre-positioning for destruction or ransomware.

The ISO that (probably) never fired

One find deserves precision about what's confirmed versus theoretical. On the attacker's OVH infrastructure, Wiz discovered a bootable Linux ISO named sso_agent.iso. It collects system information, talks to the server over TCP port 23458, and executes remotely supplied shell commands; its configuration suggests Windows systems may have been the intended target. But Wiz found no deployments of the image and cannot confirm it was ever used against victims. So: capability observed, exploitation not observed. File it under 'what they were building next,' not 'what happened.'

The logging gap that hurts the most

Here's the part that should sting. CloudTrail management events capture each AssumeRole call and bucket listing — so we know the attacker was in the S3 pantry. But they don't record which objects were read. That requires S3 data events or server access logs, and several victims lacked them, leaving responders unable to determine what was actually taken. You cannot scope a breach you cannot observe, and 'we don't know what was stolen' is the worst possible answer to give your legal team. If this incident does one thing for your org, let it be a data-events audit.

What to hunt and what to fix

Wiz's hunting guidance targets CloudTrail from October 1 onward in every AWS account holding a Qubole role. The core query logic:

eventName = "AssumeRole"
AND userIdentity.accountId = "805246085872"
AND sourceIPAddress NOT AWS-owned   -- Qubole's legit traffic is AWS-internal
-- High-fidelity indicators:
-- userIdentity.principalId = "AIDA3W7DIFLYOLTK63SFS"   (always malicious)
-- principalId = "AIDAJYRRH5Y3A7AAJM2HW" from non-AWS IP (malicious only off-AWS)
-- roleSessionName starts with "quiam-"
-- sourceIPAddress in 57.129.54.120, 2001:41d0:70d:7800::/64 (OVH)
-- userAgent contains "TruffleHog" on GetCallerIdentity

For every suspicious session, trace everything it did afterward — Secrets Manager, Parameter Store, Lambda, S3. And mind the trap The Register flagged: rotating a credential does not terminate temporary sessions already issued. If a role was assumed, you're doing full rotation of every reachable secret, not just the integration credential. That includes the Entra ID secrets and Okta client credentials, because the attacker validated those too.

On the structural side, Wiz's recommendations read like an audit template for every SaaS vendor grant you have, not just Qubole's:

• Kill stale trust. If you deprecated a vendor, delete the role. A trust policy with no legitimate traffic is a loaded door nobody watches.
• Scope the principal. Trust specific vendor IAM principals, not an entire external AWS account. Account-wide trust is what made Qubole's compromise automatically your compromise.
• Pin the network path. Add aws:SourceIp or VPC endpoint conditions matching documented vendor ranges. This attacker operated from Mullvad and OVH — a source-IP condition would have stopped every observed request cold.
• Stop treating External IDs as secrets. They're viewable by anyone with role access. They're a confused-deputy check, not authentication.
• Enable S3 data events. Several victims can't say what was taken. Don't be several victims.

Neither Qubole nor Idera had published a statement when The Hacker News checked, and Qubole didn't respond to The Register's inquiries. It's also unknown whether the compromised credentials have been disabled or the activity has stopped. So the vendor-trust question stands on its own: the integration model isn't broken — least-privilege roles beat long-lived keys every time — but it shifts risk onto the vendor's credential hygiene, and this month that risk was realized across dozens of environments whose owners, in many cases, had forgotten the door existed.