Qubole AWS account 805246085872 abused: check CloudTrail for stolen roles

Attackers used credentials from an AWS account associated with the data platform Qubole (account ID 805246085872) to assume roles in customers' AWS environments and steal secrets and S3 data, security firm Wiz reported on 9 November 2026. Wiz, working with Sentra and Mandiant, saw the activity between 14 and 26 October. It matters well beyond Qubole's customers: the method abused a trust setting that AWS customers routinely grant to SaaS vendors, and the roles that were hit were mostly ones nobody was using any more.

Key points

• Wiz says a threat actor used IAM credentials from AWS account 805246085872, associated with Qubole, to call sts:AssumeRole on customer integration roles between 14 and 26 October 2026.
• Most roles the attacker assumed had no legitimate vendor traffic, but their trust policies still accepted Qubole's account, and every request carried an accepted External ID.
• Inside victim accounts the attacker read secrets from Lambda, Secrets Manager and SSM Parameter Store, tested stolen keys with TruffleHog, and in some cases downloaded whole S3 buckets.
• Wiz says it does not know how many organisations were hit or how the credentials were obtained, and its post contains no statement from Qubole.
• Wiz says an aws:SourceIp condition in the trust policy alone would have blocked every role assumption it observed.

What to do

Who is affected: any AWS account that has an IAM role trusting Qubole's account 805246085872, which includes integration roles created long ago and since forgotten.

1. Look in CloudTrail from 1 October 2026 onward, in every account that holds a Qubole integration role. Wiz lists these checks: AssumeRole events where userIdentity.accountId is 805246085872 and sourceIPAddress is not an AWS address; any AssumeRole by principal ID AIDA3W7DIFLYOLTK63SFS (Wiz saw only the attacker use it); AssumeRole by AIDAJYRRH5Y3A7AAJM2HW from a non-AWS address (that user also appears in legitimate platform traffic); and any activity from the indicator addresses listed below.
2. Look for session names that start with quiam- (for example quiam-enum). Wiz saw the attacker use that prefix.
3. If a role was assumed, rotate every secret, SSM parameter and Lambda environment variable that role could read, and revoke the role's active sessions. Wiz stresses that rotating a credential does not end sessions that were already issued.
4. Remove trust you do not use. Delete Qubole integration roles you no longer need, or take the vendor account out of their trust policies.
5. Tighten what remains. Replace the account-wide :root principal with the specific IAM principal the vendor uses, and add an aws:SourceIp or aws:SourceVpce condition limited to the vendor's documented ranges.
6. Check your logging. CloudTrail management events show the role assumption and the bucket listing but not individual object reads. Without S3 data events or server access logs you cannot tell which objects were taken. Wiz notes that several victims lacked those logs.

What happened

Qubole sells a data-lake platform that runs inside customers' own AWS accounts. The Hacker News describes the company as owned by Idera. To work, it asks customers to create IAM roles whose trust policy names Qubole's AWS account as allowed to assume them. Instead of handing over long-lived access keys, the customer lets the vendor's account request short-lived credentials through the AWS Security Token Service.

According to Wiz, a threat actor got hold of IAM credentials belonging to a Qubole-associated account and began calling AssumeRole against those customer roles on 14 October. Wiz does not say how the credentials were obtained, and The Hacker News reports that neither Qubole nor Idera had published a statement when it wrote. The Register says AWS and Qubole did not respond to its questions.

The first observed call came on 14 October from a Mullvad VPN address, using the IAM user with ID AIDA3W7DIFLYOLTK63SFS. From 15 October most activity moved to an OVH-hosted server at 57.129.54[.]120. On 18 October the actor began using a second IAM user from the same account, AIDAJYRRH5Y3A7AAJM2HW, and swept through integration roles across several environments in quick succession. Wiz saw TruffleHog activity from 16 to 19 October, the aws-cli user agent from 21 to 26 October, and a role assumption from another Mullvad address on 25 October. The last activity it saw was on 26 October.

In a majority of the environments Wiz examined, the attacker's requests were the only AssumeRole calls from the vendor account during October. Many of the roles had no legitimate vendor traffic at all, yet their trust policies were still active, so the requests succeeded.

Inside the victim accounts

Wiz describes a consistent sequence. The attacker assumed a role, then listed storage (buckets and objects, databases, tables and clusters), compute (instances, images, security groups, VPCs), databases and snapshots, and identity and key information. It then harvested credentials: it listed Lambda functions and called GetFunctionConfiguration, which returns environment variables; it listed and read Secrets Manager secrets; and it read SSM Parameter Store parameters.

What it found, it tested. Using TruffleHog, the actor ran GetCallerIdentity against discovered AWS access keys in bursts lasting seconds, signed in to Microsoft Entra ID as service principals using client secrets, and requested OAuth tokens from Okta with client credentials. Wiz says the actor was opportunistic in what it took from S3, in some cases downloading an entire bucket in one session.

A separate, earlier campaign

Wiz also describes activity from 8 to 11 October that it has not linked to the role-assumption campaign. In that case a different actor used customer-owned AWS access keys believed to have been created for Qubole integrations. On 8 October all of those keys were tested within one hour, and in a small number of cases the victim's cloud environment was compromised. Wiz says it cannot tie the two together.

The bootable ISO

Wiz Research also found a file called sso_agent.iso on the same OVH server, using the Validin threat-intelligence service. It is a bootable Linux image that, according to Wiz, gathers system information, uploads network and disk details to the server, polls the server on TCP port 23458 and runs whatever shell script it receives, then hard-reboots after 90 minutes, which would erase evidence. It loads the ntfs3 driver at boot, which suggests Windows machines were the intended target. Wiz has not identified any deployments and cannot confirm the file was used in this campaign. Its SHA-256 hash is 65f061281c9a712e9502793dc4c5035cae490b84da05f7d4223cefa65ad396e4.

Background: why a trusted vendor account is a master key

The cross-account role pattern is the standard AWS-recommended alternative to sharing access keys, and it is widely used by monitoring, data, security and cost tools. The risk is structural. A trust policy that names a vendor's account as a principal says "anything in that account that is allowed to call sts:AssumeRole may try", and the only extra check is usually the External ID.

The External ID was designed to stop the "confused deputy" problem, where one customer tricks a vendor into acting on another customer's account. It is not a secret. Wiz points out that it is logged in plaintext in CloudTrail and often stored by vendors and in infrastructure-as-code. An attacker who controls the vendor's credentials can read or guess it, and in this campaign every AssumeRole call carried an External ID the target accepted.

That is why the abandoned roles matter. Integrations get set up for a proof of concept, a migration or a departed team, and the role outlives its purpose. It carries no traffic, so nobody watches it, but its trust policy keeps working.

The numbers

Indicator	Detail
Vendor-associated AWS account	805246085872
Attacker IAM users	2 (AIDA3W7DIFLYOLTK63SFS, then also AIDAJYRRH5Y3A7AAJM2HW from 18 October)
First and last observed activity	14 October and 26 October 2026
Days of observed activity	13 (inclusive)
Source servers and VPN exits in Wiz's list	5 addresses

Wiz does not publish a victim count. Its post says "multiple" environments, and Sentra reported suspicious activity across "several" of its customers' environments. We are not estimating one.

Indicators of compromise

These are from Wiz's post. The three Mullvad addresses are shared VPN exit nodes, so a match alone is not proof of the attacker.

• OVH GmbH: 57.129.54[.]120 (15 to 26 October) and 2001:41d0:70d[:]7800:: (16 to 24 October)
• 31173 Services AB (Mullvad): 45.83.220[.]211 (14 to 15 October) and 185.209.199[.]73 (18 to 21 October)
• Datacamp Limited (Mullvad VPN AB): 89.37.63[.]175 (25 October)
• Session-name prefix quiam-
• Most common user agent: a Boto3 1.37.9 client on Linux with Python 3.13.5 (15 to 26 October). Wiz says no user agent is suspicious alone; treat it as one only alongside another indicator.

What it means

For security teams the lesson is an inventory task. Every role in every account whose trust policy names an external account is an inbound door, and the vendor's own security becomes yours. Wiz's practical advice is to list those roles, delete the dead ones, pin the rest to a named principal and the vendor's published source ranges, and alert on a vendor account calling AssumeRole from a VPN or hosting provider the vendor has never used. It also recommends a distinct External ID per role where supported, and not treating it as the only control.

For SaaS providers, Wiz recommends assuming customer roles from workload roles with short-lived credentials instead of long-lived IAM user keys, restricting those principals by aws:SourceIp or aws:SourceVpc, publishing egress ranges so customers can pin their trust policies, and monitoring their own CloudTrail for calls into customer accounts from unexpected networks.

Wiz describes the targeting as opportunistic and not matching typical state-backed priorities, and it has found no ties to other public reporting.

What we don't know yet

• How many organisations were affected. Wiz does not say.
• How the attacker got the Qubole-associated credentials, and whether they have been disabled. The Hacker News notes the researchers did not say whether the activity has stopped.
• What Qubole and Idera will say. Wiz's post contains no statement from Qubole, and AWS and Qubole did not respond to The Register.
• Whether the October 8 to 11 access-key campaign is connected.
• Whether the ISO was ever used against anyone.
• What was done with the stolen data. Wiz says it has no insight into how it is being used.

What to watch next

Watch for a statement or advisory from Qubole or Idera that confirms the account's status and publishes the vendor's source IP ranges, since those are what customers need to write a tight trust policy. Watch Wiz's post for updates to the indicator list, and your own identity provider's sign-in logs for the user agents and addresses above.

Sources

• Wiz: Trusted by Default: Qubole Cross-Account Access Abused in the Wild (primary)
• The Register: Attackers backdoor trusted AWS integrations to steal secrets
• The Hacker News: Hackers Exploit Qubole's Trusted AWS Access to Breach Customer Accounts and Steal Data