Attackers Abuse Qubole’s Trusted AWS Access to Steal Secrets and Data from Customer Accounts

An unknown attacker used credentials tied to Qubole’s AWS account to break into the AWS environments of multiple Qubole customers between October 14 and October 26, 2026, stealing stored secrets and copying data out of S3 buckets.

Cloud security firm Wiz disclosed the campaign on November 9 in a detailed technical write-up, prepared with data security company Sentra and Google’s Mandiant. Qubole is a data lake and big data processing platform owned by Idera. Qubole and Idera had not issued any public statement at time of publication.

How a trusted vendor role became the way in

Qubole works inside customer AWS accounts through cross-account IAM roles. During setup, a customer creates a role whose trust policy lets Qubole’s AWS account assume it, usually gated by an External ID that the vendor must present.

According to Wiz, the attacker called AssumeRole from AWS account 805246085872, which Qubole’s platform uses to reach customer environments. The first activity came on October 14 from a Mullvad VPN address using IAM user AIDA3W7DIFLYOLTK63SFS. From October 15, most of the activity came from a VPS hosted by OVH. On October 18, the attacker also began using a second IAM user, AIDAJYRRH5Y3A7AAJM2HW, which also carries legitimate Qubole traffic.

Every role assumption tied to the attacker included a valid External ID, and every one succeeded. How the attacker obtained the credentials has not been disclosed.

Most of the roles the attacker used were dormant. In the majority of environments Wiz reviewed, the attacker’s requests were the only role assumptions from the vendor account in October. Sentra said one affected customer had stopped using Qubole a while ago, but the old roles were still in place and could read nearly all of its source buckets.

Secrets harvested, then tested with TruffleHog

Once inside, the attacker enumerated storage, compute, databases, IAM roles and KMS keys, then went after common credential stores:

• Lambda: function environment variables through GetFunctionConfiguration
• Secrets Manager: ListSecrets followed by GetSecretValue
• SSM Parameter Store: DescribeParameters and GetParameter

The attacker then ran the stolen credentials through TruffleHog to check which ones worked. Wiz said these were the victims’ own AWS access keys, Microsoft Entra ID client secrets and Okta client credentials, not the vendor’s.

In its own account of the investigation, Sentra said the attacker got into more than a dozen Qubole-trusted accounts at one customer in about 3 minutes and read about 100 passwords and keys in 7 minutes. Those included source control, identity provider, CI and database credentials. Sentra said the attacker made no write actions, which made the activity harder to spot.

Whole S3 buckets copied

Wiz described the data theft as opportunistic. The attacker listed whatever buckets each role could reach and downloaded their contents, in some cases taking an entire bucket in a single session. At the customer Sentra investigated, the attacker first took thousands of customer profile files, then started bulk downloads across every Qubole-trusted role and, in a final pass, pulled production database backups. Sentra said file access logs at that customer recorded millions of downloaded files.

Wiz has not said how many organizations were hit. It has not tied the campaign to any known group and said the targeting does not match typical state-backed priorities.

Wiz also found a bootable Linux image, sso_agent.iso, hosted on the attacker’s OVH server. It says the image is built to be booted remotely on a victim machine, collect system details and run shell commands for 90 minutes before forcing a reboot. Wiz has not seen it deployed.

A second, separate wave in early October

Wiz also tracked a different actor that, from October 8 to October 11, tested customer-owned AWS access keys believed to have been created for Qubole integrations. All of those keys were tested within a single hour on October 8, and a small number of victims were then compromised. Wiz has not linked this activity to the role assumption campaign.

What Qubole customers should check

Wiz advises any organization that has ever connected Qubole to AWS, including those that no longer use it, to review CloudTrail from October 1, 2026 onward in every account that holds a Qubole role. Key signs include:

• AssumeRole events where userIdentity.accountId is 805246085872 and the source IP is not an AWS address
• Any activity from principal ID AIDA3W7DIFLYOLTK63SFS, and activity from AIDAJYRRH5Y3A7AAJM2HW that comes from outside AWS
• Role session names starting with quiam-, such as quiam-enum
• Traffic from 57.129.54[.]120 (OVH) or the Mullvad VPN addresses 45.83.220[.]211, 185.209.199[.]73 and 89.37.63[.]175, which other VPN users also share
• GetCallerIdentity calls with a TruffleHog user agent, plus the same user agent in identity provider sign-in logs

If a Qubole role was assumed, Wiz recommends rotating every secret, parameter and Lambda environment variable that role could read and revoking the role’s active sessions, since rotation alone does not end sessions already issued. It also recommends removing Qubole roles that are no longer needed, trusting a specific vendor principal instead of the whole account, and adding aws:SourceIp or aws:SourceVpce conditions. Wiz said a source IP condition alone would have blocked every role assumption it observed.

Teams working through a cleanup can follow the BreachNews guide on how to rotate leaked API keys after a platform breach. The campaign is the latest in a run of attacks that abuse trusted third parties, after the Klue supply chain breach and the Chainstack breach through a third-party component.