Summary
- Unknown attackers used compromised IAM credentials from Qubole's AWS account to assume cross-account integration roles in customer environments, beginning 14 October.
- Stolen data includes secrets from Lambda, Secrets Manager, SSM Parameter Store, and S3 buckets, with TruffleHog used to validate credentials.
- Attackers also uncovered Microsoft Entra ID secrets and Okta OAuth client credentials while moving through affected environments.
- Many organisations remained exposed because they left trust policies active after stopping use of the Qubole platform.
- Wiz, working with Mandiant, describes the campaign as broad and opportunistic; attribution has not been established.
What happened
Attackers obtained IAM credentials associated with Qubole's AWS account and used them to call the sts:AssumeRole API, gaining temporary credentials for integration roles managed by Qubole's customers. Qubole is a cloud data processing platform that uses cross-account IAM roles to operate inside customer AWS environments, removing the need for customers to supply long-lived access keys directly. The malicious activity was first observed on 14 October, originating from Qubole AWS account 805246085872 and an IAM user ID that Wiz analysts confirmed has not appeared in any legitimate activity. A second IAM user from the same account joined the operation on 18 October.
Scope of the intrusion
Once inside customer environments, the attackers enumerated a wide range of AWS services and extracted credentials, keys, and other sensitive material stored in Lambda environment variables, Secrets Manager, and SSM Parameter Store. They used TruffleHog — an open-source credential scanning tool — to test the validity of harvested AWS keys, and also uncovered Microsoft Entra ID secrets and Okta client credentials that could be used to request OAuth tokens. Data was taken from S3 storage in what researchers characterised as opportunistic behaviour, with some cases involving the download of entire buckets rather than targeted extraction.
A separate but related activity cluster
Wiz investigators also identified an earlier cluster of activity between 8 and 11 October that used customer-owned AWS access keys for Qubole integrations. A small number of those incidents resulted in full environment compromise. Wiz says it cannot definitively connect this earlier cluster to the main campaign, and no attribution has been made to any known threat group. How the stolen data is being used is also unknown.
The trust relationship problem
The incident illustrates a risk that persists long after a vendor relationship ends. Wiz noted that many organisations had deprecated their use of the Qubole platform but left the associated IAM trust policies in place. That residual access gave the attackers a valid, if stale, pathway into live production environments. The supply chain angle here is not a software compromise — it is the abuse of a legitimate, standing trust relationship that organisations had simply forgotten to revoke.
Discovery and investigation
AI data security company Sentra flagged suspicious activity that led to the broader investigation. Wiz's Cloud Incident Response Team worked alongside Google's Mandiant to trace and scope the campaign. The findings were published in a blog by Wiz analysts Zack Morrow, Sean Johnstone, and Benjamin Read. Neither AWS nor Qubole responded to media inquiries at the time of reporting.
Why it matters
This incident is a practical demonstration of third-party cloud trust risk at scale. CISOs often focus on direct credential exposure or software supply chain attacks, but cross-account IAM trust relationships represent a quieter, persistent attack surface. When a SaaS or data platform holds the right to assume roles inside your AWS environment, a compromise of that platform becomes a compromise of your environment — regardless of whether you are still using the product. The Qubole campaign shows that attackers are actively surveying this surface, and that inactive integrations are not safe integrations. The breadth of downstream credential exposure — spanning AWS native secrets, identity provider credentials, and OAuth tokens — means a single assumed role can cascade into enterprise-wide access across cloud and identity infrastructure.
What to do now
- Review all IAM trust policies and cross-account roles, paying particular attention to vendors or platforms that are no longer in active use, and revoke any that are not currently required.
- Search CloudTrail logs from 1 October onward for AssumeRole events where userIdentity.accountId is 805246085872, especially those originating from non-AWS IP addresses.
- For any role sessions identified in CloudTrail, review all subsequent activity from those sessions, focusing on Secrets Manager, SSM Parameter Store, Lambda, and S3.
- If a Qubole integration role was assumed by the threat actor, rotate every secret, parameter, and Lambda environment variable accessible to that role, and revoke any active sessions associated with the role.
- Rotate all Qubole-associated credentials, noting that rotating a credential does not invalidate temporary sessions that were already issued before rotation.
- Audit for exposure of downstream identity credentials, including Microsoft Entra ID secrets and Okta client credentials, that may have been accessible to any compromised role.
