Intruders stole data from over a dozen organizations through Qubole’s AWS access

A threat actor used stolen IAM credentials tied to Qubole’s AWS account to take data from more than a dozen organizations between Oct. 14 and Oct. 26, 2026.

The intruders assumed cross-account IAM roles that organizations had created for Qubole’s AWS account so Qubole could access customer environments. Qubole, a data lake platform owned by Idera, operates inside customer AWS accounts through roles built during onboarding. The attacker used credentials from AWS account 805246085872 to call AssumeRole. AWS approves an AssumeRole request when it comes from the trusted account and carries the correct External ID, and AWS treats that External ID as a nonsecret identifier logged in plain text in CloudTrail.

The attacker possessed the relevant External IDs along with vendor-side credentials, and every malicious role-assumption request included the required External ID and succeeded.

Sentra first spotted suspicious activity in multiple customer environments and notified Wiz, and the campaign ran from Oct. 14 to Oct. 26, 2026. Initial suspicious activity appeared on Oct. 14 from a Mullvad VPN IP address attempting to assume customer integration roles. The requests used IAM user AIDA3W7DIFLYOLTK63SFS, and later activity came from an OVH-hosted VPS at 57.129.54[.]120. On Oct. 18, a second IAM identity, AIDAJYRRH5Y3A7AAJM2HW, appeared alongside another Mullvad VPN address, though Qubole’s normal traffic also uses it.

Qubole roles had been dormant since the spring before being used in the attack, and numerous targeted roles showed no genuine Qubole activity in October even though their permissions stayed active. Sentra said, “The doors the attacker used were old ones.” Role sessions carried names beginning with quiam-, such as quiam-enum and quiam-scope-full. In more than half of affected environments, attacker role assumptions from Qubole’s account were the only ones recorded that month.

The intruder listed cloud resources including IAM identities, security groups, EC2 instances, databases and S3 buckets, then accessed AWS Secrets Manager, Systems Manager Parameter Store and Lambda function configurations to retrieve credentials. The attacker accessed secrets including source-control, identity-provider, CI and database credentials, vendor tokens and ExternalIds from Secrets Manager, read decrypted entries from SSM Parameter Store such as monitoring and scanner agent keys, and harvested Lambda environment variables, switching routes when blocked.

The attacker downloaded data from Amazon S3, sometimes taking whole buckets within a single session. Sentra said the intruder downloaded millions of files across the accounts of one company, and reported that the attacker read more than 100 passwords and keys within minutes. The first theft included thousands of customer-profile files, and a last sweep from another VPN address collected production database backups.

Tested credentials included AWS access keys, Microsoft Entra ID service principal secrets and Okta OAuth client credentials. The attacker tested discovered credentials using TruffleHog. Files downloaded from victims’ environments contained thousands of credential records. The attacker scraped EC2 user data, which are startup scripts that frequently contain tokens and passwords.

The attacker moved from one company to the next almost instantly, taking about a second to assume each role. The intruder performed no write operations; nothing changed or was deleted, only stolen. Wiz characterized the activity as opportunistic, reading whatever each role could reach rather than seeking specific data. No known threat group has been linked to this campaign.

Wiz found no connection between this campaign and activity reported publicly before, and said it does not fit usual state-backed priorities. A separate campaign active from Oct. 8 to Oct. 11 tested customer-owned AWS access keys against victim environments, and in some cases used them for compromise. That activity involved a few compromised environments and is not linked to the AssumeRole abuse.

The attacks came from rented OVH servers and Mullvad VPN, with no activity originating from Qubole’s network. wiz.io said, “Shared VPN addresses alone do not prove compromise.” Shared VPN exit IP is insufficient evidence on its own. Most later activity originated from an OVH-hosted VPS at 57.129.54[.]120.

Wiz found a bootable Linux ISO file called sso_agent.iso on the attacker’s OVH infrastructure, but researchers found no evidence anyone deployed the ISO in any victim environment. The ISO could collect system information, communicate over TCP port 23458 and execute remotely supplied shell commands.

Investigators from Wiz, Sentra and Mandiant collaborated to investigate the activity. Investigators need S3 data events or S3 server access logs to determine which S3 objects were read; CloudTrail management events alone do not record object reads. Some victims did not have the needed logs, leaving responders unable to identify which objects the intruder read.

AWS and Qubole did not respond to inquiries about the attack. When checked, Qubole and Idera had not published any notice about the attack on their sites. How many companies experienced the intrusion, how much data the intruder took, who the attackers are and where the credential compromise began are still unknown.

Wiz recommends organizations review AWS CloudTrail logs from Oct. 1, 2026 onward for suspicious AssumeRole activity from account 805246085872. User agent TruffleHog on GetCallerIdentity calls from suspicious IPs is an indicator to look for in identity provider sign-in logs. Organizations should set alerts for AssumeRole requests from vendor accounts arriving through VPN or hosting companies the vendor has not used before.

Wiz recommends removing unused Qubole roles or removing Qubole’s account from trust policies, adding aws:SourceIp or aws:SourceVpce conditions limiting AssumeRole requests to vendor documented network ranges, and limiting trust policies to particular vendor IAM principals instead of permitting a whole external AWS account. Wiz researchers said, “a source IP condition alone would have blocked every role assumption we observed.” If unauthorized role assumption is confirmed, Wiz recommends rotating every secret the role could read and revoking active role sessions, though rotating credentials can leave temporary sessions that were already issued still active.

Qubole roles accessed almost all the data the intruder targeted. Limiting role assumptions to the vendor’s network ranges by source IP would have stopped all observed assumptions. Some affected companies had stopped using Qubole but left its trusted cloud roles active.

Investigators need to record every account and region using an organization trail, and turn on S3 data events or server access logging for buckets holding sensitive data. Logs record encrypted downloads with file names; default-encryption files leave no trail, so the real number the intruder took is likely higher. Where organizations turned on file access logs, they recorded every file downloaded with IP and session. Stopping use of a service does not by itself delete IAM roles or their trust policies, and giving permissions to a whole external AWS account adds needless risk.

Teams need to evaluate the trust policy security and the credentials behind it as separate items. A hacked tech vendor can act as a doorway into the cloud systems of many customers even if each customer keeps a separate account. Sentra gave each affected customer five actions: remove Qubole from trusting roles, rotate read secrets, block attacker IPs, preserve logs and notify Qubole. Breach notification deadlines sometimes run as briefly as 72 hours.