Qubole Supply Chain Attack: Stolen Vendor Keys Abused Trusted AWS Roles

Between October 14 and October 26, 2026, a threat actor used IAM credentials tied to Qubole's vendor AWS account to AssumeRole into customer environments and steal secrets and S3 data, according to Wiz and Sentra. Qubole is a big-data platform that connects through cross-account IAM roles customers configure once and often forget. Sentra saw suspicious dormant vendor roles wake up across customers, reported the campaign, and worked with Wiz and Mandiant on investigation. If you ever integrated Qubole — even years ago — inventory vendor trust roles, hunt CloudTrail, and rotate secrets those roles could read.

This is not a novel malware family; it is trusted integration abuse after vendor credential theft. ExternalId conditions still passed because the attacker presented legitimate vendor-side keys.

TL;DR

Background: cross-account vendor trust

Many SaaS platforms — including data processors like Qubole — ask customers to create an IAM role their AWS account may assume. A typical trust policy allows the vendor account root with an ExternalId condition. When the vendor needs access, an identity in the vendor account calls AssumeRole and receives temporary credentials scoped to the customer role.

Security teams usually picture this as safe when ExternalId is unique and least privilege is tight. The Qubole campaign shows the remaining risk: compromise of the vendor's IAM users turns every still-trusted role into a customer breach pretext.

Attack chain, step by step

Synthesized from Wiz and Sentra primary posts:

1. Vendor credential theft (undisclosed vector). Wiz states the actor used IAM users in Qubole-associated account 805246085872, including AIDA3W7DIFLYOLTK63SFS and later AIDAJYRRH5Y3A7AAJM2HW. How those credentials were obtained is not publicly disclosed.
2. AssumeRole from non-Qubole infrastructure. First observed October 14 from Mullvad VPN IP 45.83.220.211, then predominantly from OVH VPS 57.129.54.120 and a second Mullvad address 185.209.199.73. Sentra notes no normal Qubole network footprint in the window — behavior, not Identity alone, exposed the actor.
3. Rapid lateral movement across customers. Sentra reports more than a dozen organizations impacted through the same vendor key, with about a second per AssumeRole enabling sweeps. Many targets still had dormant Qubole roles from integrations that had ended in spring 2026.
4. Discovery and enumeration. Session names used prefix quiam- (for example quiam-enum, quiam-scope-full). APIs touched include S3 listing, RDS snapshots, EC2 describes, KMS metadata, and more — classic cloud cartography.
5. Credential harvesting. Lambda GetFunctionConfiguration for environment variables, Secrets Manager GetSecretValue, SSM GetParameter. Sentra cites ~100 passwords and keys read in seven minutes across three storage types in one environment narrative.
6. Validation with TruffleHog. Discovered AWS keys, Entra ID client secrets, and Okta credentials were tested — confirming downstream identity exposure beyond AWS alone.
7. S3 exfiltration. ListBuckets → ListObjects → GetObject, often opportunistic across everything the role could read. CloudTrail management events do not log object bodies; Wiz stresses S3 data events or server access logs for detection.
8. Quiet persistence without writes. Sentra reports zero write actions — theft only — which avoids destructive signals many SOCs monitor.

Wiz additionally describes a sso_agent.iso hosted on the attacker VPS with speculative remote-boot behavior; no deployment confirmed.

Timeline

Who is affected

Review if:

• Your AWS organization created Qubole integration roles, even if Qubole was decommissioned
• CloudTrail shows AssumeRole from account 805246085872 in October 2026
• Session names begin with quiam- from vendor principals
• S3 data events show unusual GetObject volume through Qubole-trusted roles

Hunt queries (conceptual):

• Filter AssumeRole where userIdentity.accountId is the vendor account and source IPs are not Qubole-published ranges
• Correlate Secrets Manager GetSecretValue and lambda:GetFunctionConfiguration immediately after those assumptions
• Compare against baselines: Sentra notes in many environments these were the only October AssumeRole calls from the vendor account

What this means if you run AI coding agents

Coding agents rarely call Qubole APIs directly, but they consume the credentials this actor stole:

• Lambda environment variables often hold API keys agents use for OpenAI-compatible endpoints, vector DBs, and webhooks
• Secrets Manager entries feed CI jobs that agents trigger
• S3 buckets may store training sets, prompt logs, or MCP server bundles agents fetch at runtime

After vendor-trust incidents, assume anything the integration role could read was exfiltrated — rotate before agents resume unattended runs. Our first 24 hours after a vendor breach runbook applies once you confirm exposure.

For supply-chain incidents that started as jokes versus confirmed attacks, contrast TypeSafe AI's October stunt with this confirmed vendor-path theft. The November attacks timeline will reference dedicated breakdown posts as they ship.

Five actions Sentra gave customers

Sentra's field teams reported delivering evidence-backed actions the same day they attributed sources:

1. Remove Qubole from every role that still trusts it
2. Rotate every secret that was read (names and log locations without viewing secret values)
3. Block attacker IPs documented by Wiz
4. Preserve CloudTrail and S3 logs before retention expiry
5. Notify Qubole

Use Wiz's post for IOC detail and Mandiant coordination context.

Wiz defender recommendations (summary)

Wiz's detection and hunting section stresses behavior on top of valid trust:

• Inventory every cross-account vendor role, not only active SaaS contracts. Qubole roles that sat unused since spring still worked in October.
• Restrict vendor principals to documented network sources where AWS conditions allow — Sentra argues a network restriction alone would have blocked the Mullvad and OVH sessions Wiz lists.
• Enable S3 data events on buckets holding credentials, customer exports, or model artifacts. Management-event CloudTrail shows ListBuckets; it does not prove which objects left.
• Alert on AssumeRole from vendor accounts when session names match patterns like quiam-* or when the source IP is a consumer VPN/VPS rather than the vendor's published ranges.
• Rotate secrets reachable from any role the vendor could assume, not only secrets labeled "Qubole," because the actor harvested broadly inside each environment.

Wiz's Recommendations for Defenders section adds operational hygiene beyond IoCs: inventory every IAM role that trusts an external AWS account, correlate each with the vendor's current contract status, and use data-detection signals (unusual read volume, new session names, geography shifts) because valid ExternalId plus valid vendor keys will always look correct in identity-only logs.

Wiz also documents identity IOCs defenders can wire into SIEM rules:

User-agent strings (Boto3 and aws-cli versions Wiz lists) are weak signals alone — Wiz warns they appear in benign tooling too. Pair them with account, principal, or IP evidence.

Network restrictions and zero trust on vendor roles

Sentra's post argues the permissions exfiltrated were broader than Qubole documentation required, and that dormant privileged external roles should be removed, not merely monitored. That matches Wiz's recommendation to shrink cross-account trust to the minimum data each vendor needs today.

For organizations experimenting with agents that provision cloud resources, this incident is a reminder that vendor IAM roles are machine identities with the same lifecycle needs as human SSO accounts: owners, expiry, and periodic access reviews. An agent prompt that says "create an IAM role for vendor X" should not outlive the vendor contract without an automated teardown job.

ISO artifact note

Wiz researchers found sso_agent.iso (SHA-256 65f061281c9a712e9502793dc4c5035cae490b84da05f7d4223cefa65ad396e4) hosted on the attacker VPS, describing a time-limited remote boot image that phones home on TCP 23458. No in-the-wild deployment is confirmed. Include the hash in threat-intel feeds, but prioritize AssumeRole + secret access hunts first — those are confirmed across customer environments.

What developers are saying

The Hacker News thread on Sentra's write-up is mostly reaction, not reproduction. reshasentra (Sentra) commented that the scale was "Wow! Unbelivable!" drc500free said long posts read like AI-generated prose and are hard to finish — for defenders, the actionable content is in Wiz's hunt section, not comment threads. No HN commenter claimed independent reproduction of AssumeRole in a lab as of this publication.

What Beam can and cannot do here

Beam does not monitor AWS CloudTrail or vendor IAM. It helps on developer machines where agents store cloud keys:

• Redaction before local event storage limits how often secrets appear in agent history you review later
• PreToolUse deny can block obvious aws secretsmanager get-secret-value patterns in Claude Code or Codex when policy is in enforce mode — not comprehensive for every AWS CLI invocation
• Skill/MCP scanning catches some credential-harvesting patterns in configs agents load

Treat Beam as session observability, not cloud DDR. Sentra and Wiz describe the data detection and response layer that flagged dormant vendor roles waking up — orthogonal to hook-based agent tooling.

Related reading

• TypeSafe AI joke vs real October attacks
• Black October Wiz roundup on AI developer platforms
• Storm-0940 ARTEX and ConnectWise supply chain
• Zeabur breach and environment variable exposure
• Wiz: Trusted by Default Qubole post
• Sentra: Inside the Qubole supply chain attack

Frequently asked questions

When did the Qubole supply chain activity run?

Wiz CIRT observed activity between October 14 and October 26, 2026, using IAM credentials from AWS account 805246085872 associated with Qubole cross-account integrations.

How did attackers enter customer accounts?

They called sts:AssumeRole on customer-created integration roles that trust the Qubole vendor account, presenting valid ExternalIds. Roles were often dormant but still trusted, so calls succeeded.

What did they steal?

Per Wiz and Sentra, secrets from Secrets Manager and SSM Parameter Store, Lambda environment variables, S3 objects from reachable buckets, and additional credentials validated with TruffleHog including AWS keys, Entra ID, and Okta client secrets.

Did AWS ExternalId fail?

No. Every attributed AssumeRole included an ExternalId and succeeded because the attacker held Qubole vendor IAM credentials, not because customers misconfigured the condition.

What should teams do first?

Remove or restrict unused Qubole trust roles, review CloudTrail AssumeRole from account 805246085872 since October 1, enable S3 data events on sensitive buckets, and rotate secrets reachable from compromised roles.

Does this affect AI coding agents directly?

Agents and CI jobs often read the same cloud secrets the actor harvested from Lambda env vars and Secrets Manager. Compromise of those materials lets attackers impersonate automation that agents use.

IOC accounts, IPs, and timelines reflect Wiz and Sentra publications as of 2026-11-09.