One Vendor Key. Every Customer’s Cloud.

An attacker broke into the Amazon Web Services accounts of multiple Qubole customers and stole stored secrets and data. The break-in ran October 14–26, according to cloud security company Wiz, which disclosed the campaign on Monday. The attacker did not break into Qubole itself. It used credentials for the AWS account Qubole’s platform uses to reach its customers — and the trust those customers had placed in Qubole did the rest.

Qubole, owned by Idera, operates inside its customers’ AWS accounts. To let it in, a customer creates an IAM role whose trust policy allows Qubole’s AWS account to assume that role. Each request to do so, called AssumeRole, must include a matching code from Qubole known as an External ID. The design lets the vendor work inside your cloud without holding your keys — until someone else holds the vendor’s keys.

Trust is the vulnerability

How the attacker got Qubole’s AWS credentials has not been disclosed. But once they had them, the doors opened on their own: AWS accepts an AssumeRole request from the trusted account with the correct External ID, and the External ID is not treated as a secret — anyone with role access can view it, and it is logged in plain text in CloudTrail.

Most of the roles the attacker assumed were unused, according to Wiz. That did not matter: each role still trusted Qubole’s account, so the requests worked anyway. Unused trust is still trust. Any organization that has connected Qubole to AWS, even one that no longer uses it, should check CloudTrail from October 1 onward for AssumeRole requests from Qubole’s platform account, 805246085872, coming from an address outside AWS — Wiz says Qubole’s real traffic comes only from AWS addresses.

Neither Qubole nor Idera had posted a statement when The Hacker News checked on Monday, and the researchers did not say whether the credentials have been disabled or the activity has stopped.

What the attacker took

Inside the compromised accounts, the attacker went straight for the secrets: Lambda environment variables, Secrets Manager, and SSM Parameter Store values. Then it ran the credentials it found through TruffleHog, a tool that tests whether leaked secrets still work. The haul: the victims’ own AWS access keys, Entra ID client secrets, and Okta client credentials — keys to their clouds and identity systems in one sweep.

The attacker also copied data out of S3 — any bucket a role could access, sometimes an entire bucket in one session. Several victims lacked the logging to determine which objects were read: CloudTrail records each AssumeRole request and bucket listing, but not which S3 objects were read; that needs S3 data events or server access logs.

Sentra spotted the activity in several customers’ environments and alerted Wiz. The campaign has not been linked to other publicly reported activity, and Wiz says the targeting does not match state-backed groups. A second, separate wave ran October 8–11, when an attacker used customers’ own AWS access keys believed set up for Qubole to compromise a few cloud environments; it has not been linked to the AssumeRole abuse.

How to check, and how to close the route

In CloudTrail, look for AssumeRole requests from account 805246085872 with a source address outside AWS. Two IAM principal IDs matter: AIDA3W7DIFLYOLTK63SFS, which only the attacker used, and AIDAJYRRH5Y3A7AAJM2HW, which the attacker used from October 18 but Qubole’s normal traffic also uses — investigate it only from outside AWS. The attacker also used OVH addresses 57.129.54.120 and 2001:41d0:70d:7800:: and Mullvad VPN addresses 45.83.220.211, 185.209.199.73, and 89.37.63.175, though other VPN users share those. Sessions starting with quiam- and TruffleHog user-agent strings on GetCallerIdentity calls are further markers. For every suspicious session, review everything it did afterward, especially in Secrets Manager, SSM Parameter Store, Lambda, and S3.

To close the route, Wiz recommends:

• Rotate everything the role could reach — all secrets, parameters, and Lambda environment variables — and revoke the role’s active sessions. Rotating a credential does not end sessions already issued.
• Remove roles you no longer need, or take Qubole’s account out of the trust policy.
• Narrow the trust policy. Swap the account-wide :root principal for the specific IAM principal Qubole uses, and add an aws:SourceIp or aws:SourceVpce condition limiting AssumeRole requests to the vendor’s documented ranges — Wiz says a source IP condition alone would have blocked every role assumption it observed.
• Stop treating the External ID as a secret. It is logged in plain text and often stored in infrastructure code — change it, use a different value per role, and never rely on it alone.
• Audit every vendor role. Qubole’s setup guide includes a sample S3 policy letting the role read every bucket in the account, and vendor roles are routinely granted broad access for convenience.

Supply-chain trust is transitive: when you trust a vendor’s account, you trust whoever holds that vendor’s credentials. The same pattern ran through the Chainalysis breach, where an AI agent’s access exposed every user’s credentials, and the Crédit Mutuel Arkéa heist, where an attacker moved $133 million through the bank’s own account. Audit your vendor roles the way you audit your own users — because to your cloud, there is no difference.