Threat actor uses compromised Qubole credentials to breach multiple AWS customers

A threat actor used compromised Qubole IAM credentials to access and remove data from customers’ Amazon Web Services environments from Oct. 14 to Oct. 26, 2026.

Cloud security company Wiz reported the campaign following a tip from Sentra about suspicious activity in customer environments. Sentra alerted Wiz to the activity, triggering the joint investigation. Sentra said the campaign affected dozens of victims; one customer alone lost millions of files. The firm also said the attacker gathered secrets at a speed of 100 passwords and keys within seven minutes, describing the movement as fast.

Idera owns Qubole, a data lake platform that processes big data and runs machine learning workloads inside customer AWS accounts. To let Qubole in, customers build cross-account IAM roles whose trust policies permit Qubole’s AWS account to assume them; trust policies govern which external accounts can assume the role, and permissions define the allowed actions. The actor abused a cross-account IAM trust relationship rather than breaking into AWS itself, breaking into two Qubole IAM users and assuming unused roles in customer accounts set up to trust Qubole. Most assumed roles went unused but still trusted Qubole’s account, so the requests succeeded.

Because those roles continued to trust Qubole’s AWS account, AWS granted the attacker’s AssumeRole requests, with each request using the STS AssumeRole API for temporary credentials. Once inside, the intruder read Lambda environment variables, drew secrets from SSM Parameter Store and AWS Secrets Manager, and listed S3 buckets, surveying cloud resources after gaining role access. The actor used TruffleHog to validate credentials, including AWS access keys, Entra ID client secrets and Okta client credentials, and pulled data from every S3 bucket the role could reach instead of targeting specific information.

The exact method and total victim count were not specified. An AWS spokesperson stated AWS services worked as designed and were not compromised by the issue, noting customers set up roles trusting the third-party provider.

“AWS services were not compromised by this issue and operated as designed,” the spokesperson said. Mandiant joined Wiz in the investigation. Qubole and Idera had not posted statements about the attack on their websites as of Nov. 9, 2026.

Wiz tracked the campaign window across the affected customer environments. Qubole’s AWS account identifier is 805246085872. Investigators should examine IAM principal ID AIDA3W7DIFLYOLTK63SFS, which only the attacker used in the accounts reviewed. The attacker also used principal AIDAJYRRH5Y3A7AAJM2HW from Oct. 18, 2026, although Qubole’s normal traffic uses it too, so activity from this principal is suspicious only when the source address is outside AWS.

Attacker IP addresses included OVH-hosted 57.129.54.120 and 2001:41d0:70d:7800::, plus Mullvad VPN addresses 45.83.220.211, 185.209.199.73 and 89.37.63.175, though other VPN users share Mullvad addresses so a match alone is not proof. Session names starting with quiam-, such as quiam-enum, are an indicator of suspicious activity, as Wiz observed role sessions with this prefix tied to the attacker. A TruffleHog user agent on GetCallerIdentity calls from the listed IPs is also an indicator, and the same user agent may appear in identity provider sign-in logs.

CloudTrail management events record AssumeRole requests and bucket listings but not which S3 objects the attacker read; responders need S3 data events or server access logs. Some victims lacked those logs, so responders could not determine which objects the attacker accessed, leaving log gaps that limited the visibility of some investigations. Wiz recommends checking CloudTrail logs from Oct. 1, 2026 onward for AssumeRole requests from account 805246085872 that come from outside AWS, since Wiz observed real Qubole traffic only from AWS addresses.

Affected organizations should rotate all secrets, parameters and Lambda environment variables reachable by a compromised role and revoke active sessions, because rotating credentials does not end sessions that were already issued and active sessions must be revoked separately. Unused Qubole roles should be deleted, or Qubole’s account should be removed from their trust policies, even at organizations that no longer use Qubole.

Trust policies should name Qubole’s specific IAM principal rather than the account-wide root principal, narrowing the principal to reduce the blast radius of a compromised vendor account. Wiz researchers said each attacker AssumeRole request included an External ID, and AWS accepted it, with the External ID carried in every request to such a role.

Per AWS’s external ID guidance, the code is not treated as secret material, and role access permits viewing it. External IDs are logged in plain text in CloudTrail and often stored by vendors and infrastructure-as-code files, so they should not be the sole control; a unique value per role is recommended after an incident, with organizations changing the External ID for Qubole and using different values per role where possible.

“a source IP condition alone would have blocked every role assumption we observed,” Wiz researchers said, referring to a source IP condition limiting AssumeRole requests to Qubole’s documented network ranges. Organizations should set alerts for vendor AssumeRole requests arriving through unfamiliar VPNs or hosting providers to help detect abuse from networks the vendor has not used before.

AWS recommends reviewing cross-account IAM roles, removing unused integrations, granting the least privilege, and adding source IP restrictions to trust policies. Customers who suspect unauthorized activity should follow credential remediation guidance or contact AWS Support.