Attacker used Qubole's AWS account to reach customer data, Wiz says

Attacker used Qubole's AWS account to reach customer data, Wiz says

10 November 2026: An attacker used IAM credentials from an AWS account linked to the Qubole data platform to enter multiple customer AWS environments between 14 and 26 October, collecting secrets and downloading S3 data, according to Wiz. Any organisation that ever connected Qubole should search its CloudTrail logs from 1 October, because in most victim accounts the integration was no longer in use.

Not yet independently verified. This account comes from Wiz, which says it worked with Sentra and Mandiant. We found no statement from Qubole or its owner Idera on either company's site when this was published. We will update this when it can be confirmed, and remove this note.

A vendor trust nobody had switched off

Qubole, like many SaaS data platforms, works through a cross-account IAM role that the customer creates and that trusts the vendor's AWS account. Wiz observed role assumptions from account 805246085872, first through a Mullvad VPN address and from 15 October mostly through a VPS at OVH. Every request it attributed to the attacker carried an External ID, and every one succeeded.

The detail that should worry security teams is how dormant these links were. In the majority of environments Wiz examined, the attacker's requests were the only AssumeRole activity from the vendor account in October. The trust policies had simply been left in place.

Sentra first spotted the activity across several of its customers and passed it to Wiz. Mandiant also worked on the case, and Wiz says it has found no tie to other publicly reported campaigns.

From configuration data to whole buckets

Once inside, the attacker listed storage, compute, databases, roles and keys, then went to the usual hiding places for credentials: Lambda environment variables, Secrets Manager and SSM Parameter Store. TruffleHog was used to test what turned up, including AWS access keys, Entra ID client secrets and Okta client credentials belonging to the victims.

Data theft looked opportunistic, with some sessions downloading entire buckets. Wiz warns that CloudTrail management events record the role assumption and the listing but not the object reads, so S3 data events must have been switched on for those downloads to show.

A separate burst of activity from 8 to 11 October used customer-owned AWS access keys that Wiz believes were created for Qubole integrations. It could not link that to the main campaign.

Where to look in CloudTrail

Wiz suggests these searches from 1 October in every account holding an integration role:

• AssumeRole events where userIdentity.accountId is 805246085872 and sourceIPAddress is not an AWS address
• any activity from principal AIDA3W7DIFLYOLTK63SFS, which in the environments observed only the attacker used
• principal AIDAJYRRH5Y3A7AAJM2HW from a non-AWS address, since this one also carries real Qubole traffic
• role session names beginning quiam-, and GetCallerIdentity calls with a TruffleHog user agent

Rotating secrets is only half of it

If a role was assumed, Wiz says to rotate every secret, parameter and Lambda variable it could read and to revoke the role's active sessions, because rotation does not end temporary sessions already issued. Unused integration roles should go, and a source IP or VPC endpoint condition on those that stay would, by Wiz's account, have blocked every assumption it saw. It also calls the External ID non-secret, since CloudTrail logs it in plain text.

We list Qubole among 15 ETL software products and Idera as a company.

Sources

• Wiz: Trusted by Default: Qubole Cross-Account Access Abused in the Wild, 9 November 2026