al-ice.ai

The Trust Policy Outlived the Platform: Qubole Cross-Account Roles Abused to Raid Customer AWS

Agent & Supply Chain Security by al-ice.ai Editorial

On 9 November 2026, Wiz published “Trusted by Default: Qubole Cross-Account Access Abused in the Wild,” disclosing a supply-chain campaign in which a threat actor used IAM credentials from Qubole’s AWS account (805246085872) to assume integration roles inside customer environments between 14 and 26 October 2026. Once inside, the actor enumerated broadly, harvested credentials from Lambda, Secrets Manager, and SSM Parameter Store, validated them with TruffleHog — including Microsoft Entra ID and Okta credentials — and exfiltrated S3 data. The investigation began when AI data security company Sentra flagged suspicious activity across several of its customer environments, recognized it as a broad supply-chain attack, and brought in Wiz, which worked with Google’s Mandiant incident responders. The uncomfortable core of the story is not a novel exploit: in most victim environments, the actor’s requests were the only AssumeRole traffic from the vendor account in October, because customers had deprecated the platform but left the trust policies in place.

How the vendor-account path works

Qubole is a cloud data-processing platform that operates inside customer AWS accounts through cross-account IAM roles: during onboarding, the customer creates a role trusting the vendor’s AWS account — typically gated by an External ID — and the vendor calls sts:AssumeRole to get temporary credentials scoped to that role. Wiz CIRT observed the first malicious use on 14 October, when a Mullvad VPN address (45.83.220.211) called AssumeRole against integration roles from Qubole’s account using IAM user AIDA3W7DIFLYOLTK63SFS — a principal Wiz says it has never observed in any activity other than the threat actor’s. From 15 October most traffic shifted to an OVH-hosted VPS (57.129.54.120); on 18 October a second IAM user from the same account (AIDAJYRRH5Y3A7AAJM2HW, which also carries legitimate Qubole platform traffic) and a second Mullvad exit (185.209.199.73) joined in. Every attributed AssumeRole call included an External ID, and every one succeeded — the trust policies were still there to honor them. Role session names followed a consistent quiam- prefix (quiam-enum, quiam-scope-full), a small operational signature defenders can hunt.

Enumerate everything, validate with TruffleHog, download the buckets

Inside each environment the actor enumerated storage and data (ListBuckets, ListObjects, GetDatabases, ListTables, DescribeClusters), compute (DescribeInstances, DescribeImages, DescribeSecurityGroups, DescribeVpcs), databases (DescribeDBInstances, DescribeDBSnapshots), and identity material (ListRoles, ListKeys, ListAliases, DescribeKey, GetKeyPolicy) — then went after the places credentials actually live: GetFunctionConfiguration on every Lambda function (which returns environment variables), ListSecrets plus GetSecretValue, and DescribeParameters plus GetParameter. The validation step is notable: the actor used TruffleHog to test what it found — GetCallerIdentity against discovered AWS keys (a permissionless call that confirms a key is live), Entra ID sign-ins as service principals with discovered client secrets, and OAuth token requests with discovered Okta client credentials. S3 theft followed a fixed sequence — ListBuckets, ListObjects, HeadObject, then GetObject — and was opportunistic rather than targeted, in some cases entire buckets in a single session. Wiz flags a logging gap that matters for scoping: CloudTrail management events record the role assumption and bucket listing, but not the object reads — without S3 data events or server access logs, the exfiltration itself is invisible.

The ISO, the second campaign, and what is not claimed

Two things in the disclosure deserve careful handling. First, Wiz Research found an ISO (sso_agent.iso, SHA-256 65f061281c9a712e9502793dc4c5035cae490b84da05f7d4223cefa65ad396e4) hosted on the OVH address: a bootable Linux image that starts a 90-minute clock, uploads interface and disk inventories, polls the attacker IP over TCP 23458 for shell input, then hard-reboots to erase itself — with an ntfs3 driver suggesting Windows targets. Wiz states plainly it has not identified any deployments and cannot confirm use. Second, a separate 8–11 October cluster abused customer-owned AWS keys believed created for Qubole integrations (all tested within one hour on 8 October, a small number leading to compromise) — which Wiz cannot definitively link to the main campaign. Attribution is explicitly withheld: the targeting looks opportunistic and does not match typical state-backed priorities, but Wiz says it has no direct insight into motive or use of the stolen data. The Register, which covered the disclosure on 9 November, reports Wiz calling it a “broad, opportunistic supply chain campaign” across “multiple” environments while declining a count, and that Qubole did not respond to inquiries — both carried here as reported.

What to actually do

  1. Inventory every role that trusts an external account — then delete the ones whose platform you already left: the victims here were breached through trust policies for a deprecated integration, and dormant trust is attacker infrastructure.
  2. Hunt CloudTrail from 1 October onward in every account holding a Qubole-era integration role: AssumeRole calls with userIdentity.accountId 805246085872 from non-AWS source addresses, either named principal ID, any IOC IP, and GetCallerIdentity with a TruffleHog user agent paired with those addresses — plus IdP sign-in logs for the same user agent.
  3. Rotate everything the role could read, then revoke the sessions: every secret, parameter, and Lambda environment variable reachable by an assumed role — remembering that rotating a credential does not end temporary sessions already issued.
  4. Shrink the trust primitive itself: replace account-:root principals with the vendor’s specific IAM principal where supported, and add aws:SourceIp or aws:SourceVpce conditions limited to documented vendor ranges — an External ID alone did not stop this actor.
  5. Enable S3 data events for sensitive buckets now: management events will show you the role assumption but never the GetObject calls, so scope of data theft cannot be reconstructed after the fact without them.

Read with the Fireworks second breach, disclosed the same day, the pattern hardens: the blast radius of an AI-adjacent platform incident now runs through provider accounts, eval jobs, and integration roles rather than model endpoints. And as the PingCAP TiDB Cloud breach showed last month, stolen service-account credentials plus a month of quiet access is all it takes to turn control-plane adjacency into a data breach.

Our verification was read-only. We read the Wiz blog “Trusted by Default: Qubole Cross-Account Access Abused in the Wild” (Zack Morrow, Sean Johnstone, Benjamin Read, 9 November 2026) first-hand in full: Sentra detection and Mandiant collaboration; 14–26 October window; account 805246085872; both IAM user IDs and their traffic profiles; Mullvad and OVH infrastructure; External-ID-bearing successful AssumeRole calls; quiam- session names; full enumeration, credential-harvesting, TruffleHog-validation (AWS, Entra ID, Okta), and S3-exfiltration sequences; the CloudTrail object-read logging gap; the sso_agent.iso hash, behavior, and no-deployment caveat; the unlinked 8–11 October customer-key cluster; withheld attribution; and the full hunting and hardening guidance. The Register’s 9 November report (Jessica Lyons, 19:59 UTC) is carried as reported for Wiz’s “broad, opportunistic” characterization, the declined victim count, and Qubole’s non-response; THN, CSO Online, and GBHackers accounts were used only as cross-checks. We assumed no roles, ran no scans, touched no AWS infrastructure, and contacted no vendor. Brave Search was used for discovery only.

Sources: