Qubole AWS Breach Explained: Trusted Access Abused to Raid Customer Cloud Accounts

Illustrative image: server racks in a data centre. Qubole's breach involved no product photo — the attack abused trusted cloud access, not a device. Image: Wikimedia Commons / Ana Las Heras, CC BY-SA 4.0

TL;DR — The Answer: The Qubole AWS breach explained in one line: attackers got hold of credentials from Qubole's own AWS account and used them to walk into multiple customers' AWS environments through the trusted access those customers had granted Qubole, stealing secrets and copying data from storage buckets. Wiz, which disclosed the campaign on 9 November 2026, says the activity ran from 14 to 26 October — and any organisation that ever connected Qubole to AWS should check its logs from 1 October.

📌 Key Highlights

• Disclosed 9 November 2026: cloud security firm Wiz, working with Sentra and Mandiant, reported that an attacker used IAM credentials from Qubole's AWS account (805246085872) to assume customer integration roles.
• Activity ran 14–26 October 2026: the first role assumptions came from a Mullvad VPN address; most later activity came from an OVH-hosted server.
• Secrets and data stolen: the attacker harvested credentials from Lambda, Secrets Manager and SSM Parameter Store, tested them with TruffleHog, and copied data from S3 buckets — sometimes entire buckets in a single session.
• No CVE involved: this was abuse of a trusted cross-account relationship, not a software flaw. How the attacker obtained Qubole's credentials has not been disclosed.
• Check now: review CloudTrail from 1 October 2026 for AssumeRole calls from account 805246085872 coming from addresses outside AWS — and delete integration roles you no longer use.

What happened?

Wiz published its report, "Trusted by Default: Qubole Cross-Account Access Abused in the Wild", on 9 November 2026. AI data security company Sentra spotted suspicious activity across several of its customer environments, recognised it as a broad supply-chain attack, and shared what it found with Wiz; Google's Mandiant incident responders joined the investigation.

Qubole is a data lake and cloud data-processing platform owned by Idera. It works inside its customers' AWS accounts: during onboarding, a customer creates a cross-account IAM role whose trust policy allows Qubole's AWS account to assume it, usually gated by a code known as an External ID. When Qubole needs to act in the customer's environment, an identity in Qubole's account calls the AssumeRole API with the role name and the External ID, and receives temporary credentials scoped to the customer's role.

The attacker obtained credentials tied to Qubole's own AWS account and made those same AssumeRole calls. Because the customers' roles trusted Qubole's account — and every request the attacker made carried a valid External ID — every request succeeded. Wiz says the attacker broke into "multiple" customer AWS environments. No victim names and no victim count have been released, and neither Qubole, Idera nor AWS had posted a statement about the attack when The Hacker News and The Register checked on 9 November.

Qubole AWS breach explained: how trusted access works

Think of a cross-account IAM role as a guest list for a building. The customer writes the list: "Qubole's AWS account may enter, with these permissions." The External ID is a code word the guest is supposed to say at the door. The problem is that AWS does not treat the External ID as a secret — it is logged in plaintext in CloudTrail, and it is often stored by the vendor and in infrastructure code. It was never meant to be the only lock on the door.

Once the attacker held credentials for Qubole's account, the guest list did the rest. The customers' own trust policies said Qubole's account may enter, so AWS let the attacker in — with whatever permissions each customer's role carried. Many of those roles were dormant: in most of the environments Wiz observed, the attacker's requests were the only AssumeRole activity from the vendor account in the whole of October. The trust policies were still in place, so the requests succeeded. That is the sharpest lesson here: trust you forgot you granted is still trust, and an attacker only needs one forgotten role.

Illustrative image: rows of servers in a data centre hall. The Qubole attack happened entirely in the cloud — no device was involved. Image: Wikimedia Commons / Ana Las Heras, CC BY-SA 4.0

What the attackers took

Once inside an environment, the attacker worked through a consistent routine. Role session names followed a pattern — the prefix "quiam-" followed by a description of the action, such as "quiam-enum" and "quiam-scope-full". It enumerated broadly: storage and data, compute, databases, identity and keys. Then it went after the places AWS customers store credentials: Lambda function environment variables, Secrets Manager entries and SSM Parameter Store values. It used the open-source tool TruffleHog to test what it found — the victims' own AWS access keys, Microsoft Entra ID client secrets and Okta client credentials — and then pulled data from S3, reading whatever buckets each role could reach, in some cases downloading entire buckets in a single session. The targeting looks opportunistic rather than selective: the attacker took what the role could reach, not specific files it had come for.

When	What happened
8–11 October 2026	Separate, unlinked activity: an actor tested customer-owned AWS access keys believed to have been created for Qubole integrations — all of them within a single hour on 8 October — and went on to compromise a small number of environments. Wiz has not linked this to the main campaign.
14 October 2026	First observed role assumptions in the main campaign, from Mullvad VPN address 45.83.220.211, using IAM user AIDA3W7DIFLYOLTK63SFS.
15 October 2026	Most activity moves to an OVH-hosted server, 57.129.54.120.
18 October 2026	A second IAM user from the same account, AIDAJYRRH5Y3A7AAJM2HW, begins use; a second Mullvad address sweeps integration roles across multiple environments in quick succession.
14–26 October 2026	Main campaign window: enumeration, secret harvesting, credential validation with TruffleHog, and S3 data copying.
9 November 2026	Wiz discloses the campaign publicly.

Two things Wiz is careful about. First, it also found a bootable Linux image, sso_agent.iso, hosted on the attacker's OVH address — designed, it believes, to be remotely booted on a victim machine, gather system information, and run shell scripts sent from that address, before rebooting after 90 minutes to erase evidence. But Wiz has identified no deployments of this image and cannot confirm if or how it was used, so it should not be reported as part of the attack. Second, Wiz has found no ties between this campaign and any other publicly reported activity. The targeting and data theft look opportunistic and do not match typical state-backed priorities — but Wiz says it has no direct insight into the attacker's motivation or how the stolen data may be used.

How to check if your AWS account was affected

Wiz's advice is specific and cheap to follow. Any organisation that has integrated with Qubole — including one that no longer uses it — should review CloudTrail from 1 October 2026 onward, in every account that holds an integration role:

Signal	What to look for	What it means
AssumeRole from Qubole's account	userIdentity.accountId is 805246085872 and sourceIPAddress is not an AWS address	All legitimate platform traffic Wiz observed came from AWS infrastructure — anything else is suspect
Attacker-only IAM user	userIdentity.principalId is AIDA3W7DIFLYOLTK63SFS	In the environments observed, only the threat actor used this IAM user — any activity warrants investigation
Second IAM user	userIdentity.principalId is AIDAJYRRH5Y3A7AAJM2HW and sourceIPAddress is not an AWS address	This user also carries legitimate platform traffic, so filter on the source address to separate the two
TruffleHog validation	GetCallerIdentity calls with a TruffleHog user agent, paired with any attacker IP address	Shows which stolen credentials the attacker tried to validate — check identity-provider sign-in logs too
Role session names	Sessions starting with "quiam-", such as quiam-enum or quiam-scope-full	The attacker's consistent naming pattern

For every role session you find, review everything that session did afterwards — especially Secrets Manager, SSM Parameter Store, Lambda and S3. If the attacker assumed an integration role, rotate every secret, parameter and Lambda environment variable the role could read, and revoke the role's active sessions: rotating a credential does not end temporary sessions that were already issued. And make sure your logs actually cover the ground — in several affected environments, missing logs meant responders could not see which S3 objects the attacker read, because CloudTrail management events record the role assumption and the bucket listing, but not the object reads themselves. S3 data events or server access logs are what close that gap.

What to fix now

The fixes Wiz recommends are mostly about removing trust you no longer need and tightening the trust you keep. Inventory every IAM role whose trust policy allows an external account, and delete the integration roles for vendors you no longer use. Where the vendor supports it, narrow the trusted principal from the whole vendor account down to the specific IAM principal the vendor uses, and add a source-IP or source-VPC condition limiting role assumption to the vendor's documented network ranges — Wiz says a source-IP condition alone would have blocked every role assumption it observed in this campaign. Treat the External ID as non-secret, rotate it in coordination with the vendor, and use a distinct value per role where supported. Apply least privilege to vendor roles: access to Lambda configuration, Secrets Manager, SSM parameters and broad S3 reads is often granted for convenience, not need. Finally, alert on third-party role assumption from new networks — vendor traffic usually comes from a known set of cloud networks, so an AssumeRole from a vendor account through a VPN or hosting provider the vendor has never used is a high-signal detection.

Why it matters for India readers

No Indian victims have been named, and no India-specific impact has been reported — this is a global cloud story, not an India breach. But the pattern lands directly on Indian teams: startups, SaaS firms and enterprises across India run on AWS and grant the same kind of cross-account trust to data platforms, analytics tools, backup vendors and deployment services. Every one of those integrations is a guest list like Qubole's, and most teams have never audited theirs. The same week brought the same lesson from other directions — CERT-In's Crafty Falcon advisory warned that AI tools are hacking Indian banks at machine speed, and Microsoft's Storm-3358 report showed the same AI tooling turned on financial firms. The common thread is trusted access: the front door is no longer a password to crack, it is a permission granted long ago and never reviewed. Indian organisations that report incidents to CERT-In within six hours of detection — the rule for reportable incidents — will want this audit done before an incident, not during one. And the patching discipline matters in parallel: the SonicWall SSL-VPN flaw that bypasses SAML and MFA is another actively exploited weakness in the wild right now, with a 20 November remediation date.

Should you care?

✅ Yes, if your organisation uses AWS and any third-party integration — run the CloudTrail check from 1 October for account 805246085872, and delete integration roles you no longer use; a source-IP condition on the roles you keep would have stopped this attack cold. ⏳ Ordinary readers should not panic — no consumer impact has been reported and no personal data breach was named. But if a service you use runs on AWS, its vendors' hygiene is your data's hygiene, so the check matters even if you cannot run it yourself.

FAQs

What is the Qubole AWS breach?
Wiz disclosed on 9 November 2026 that an attacker used credentials from Qubole's own AWS account to assume customer IAM integration roles between 14 and 26 October, stealing secrets and copying data from S3 buckets in multiple customer environments. No software flaw or CVE is involved — the attack abused a trusted cross-account relationship.

How do I check if my AWS account was affected by the Qubole breach?
Review CloudTrail from 1 October 2026 in every account that holds a Qubole integration role. Look for AssumeRole calls where the account ID is 805246085872 and the source IP is not an AWS address, or any activity from IAM user AIDA3W7DIFLYOLTK63SFS. If you find a session, review everything it did, rotate every secret it could read, and revoke the role's active sessions.

What is a cross-account IAM role, and why is it risky?
It is an AWS identity a customer creates so a vendor's account can act inside the customer's environment — the trust policy is the guest list, and the External ID is a code word. It is risky because the trust often outlives the relationship: roles for vendors you stopped using still accept the vendor's credentials, and the External ID is logged in plaintext, so it is not a real secret.

Was my personal data stolen in the Qubole breach?
No victim names, no victim count and no consumer impact have been disclosed. The victims are organisations' AWS environments, and Wiz has not said what data sat in the S3 buckets that were copied. If a service you use announces it was affected, follow that service's guidance.

Takeaway

The Qubole breach needed no exploit and no zero-day — just credentials for a trusted vendor account and guest lists nobody had reviewed. The fix is an audit, not a patch: find every external account your AWS roles trust, delete the ones you no longer use, and pin the rest to the vendor's real networks.

If you run AWS, run the CloudTrail check today — it takes minutes, and the account ID to search for is 805246085872. For the wider pattern of trusted access being turned against its owners, read our Storm-3358 ARTEX explainer on AI agents attacking financial firms.

Sources

• Wiz — Trusted by Default: Qubole Cross-Account Access Abused in the Wild (9 November 2026)
• The Hacker News — Hackers Exploit Qubole's Trusted AWS Access to Breach Customer Accounts and Steal Data (9 November 2026)
• The Register — Attackers backdoor trusted AWS integrations to steal secrets (9 November 2026)
• AWS Documentation — How to use an external ID when granting access to your AWS resources to a third party
• Threadlinqs Intelligence — Qubole AWS Role Assumption Campaign: Detection & IOCs (TL-2026-5571, 9 November 2026)