An attacker gained access to multiple customer AWS accounts by abusing Qubole's trusted cross-account IAM roles between October 14 and October 26, according to researchers at Wiz. The intrusion allowed the threat actor to read stored secrets and exfiltrate data from environments belonging to organizations that had integrated the Qubole data lake platform, now owned by Idera.
Qubole operates inside customer AWS accounts after customers create an IAM role whose trust policy permits Qubole's account (805246085872) to assume it using a matching External ID. The attacker leveraged valid credentials for this account to issue successful AssumeRole requests against both active and unused roles that still trusted Qubole.
Why the Roles Let the Attacker In
Every malicious AssumeRole call included a valid External ID, which AWS accepts from the trusted account without treating the value as a secret. Wiz noted that most targeted roles were dormant yet remained configured to trust Qubole's account, enabling the abuse.
Attacker Activity Observed
Once inside victim accounts the actor searched for credentials by inspecting Lambda environment variables, Secrets Manager secrets and SSM Parameter Store values. Stolen credentials were validated using TruffleHog and included AWS access keys, Entra ID client secrets and Okta client credentials. The attacker also copied entire S3 buckets when broad read permissions existed.
How to Check Your Accounts
Wiz recommends reviewing CloudTrail logs from October 1 onward in every account containing a Qubole role. Key indicators include AssumeRole requests from account 805246085872 originating outside AWS, activity by IAM principal IDs AIDA3W7DIFLYOLTK63SFS and AIDAJYRRH5Y3A7AAJM2HW from non-AWS IPs, and sessions beginning with "quiam-". Additional indicators are the IPs 57.129.54.120, 2001:41d0:70d:7800::, 45.83.220.211, 185.209.199.73 and 89.37.63.175 together with the user agent "TruffleHog".
Recommended Remediation Steps
- Rotate all secrets accessible to any assumed Qubole role and revoke active sessions.
- Remove unused Qubole roles or replace the :root principal with the specific IAM principal used by Qubole.
- Add aws:SourceIp or aws:SourceVpce conditions restricting AssumeRole calls to Qubole's documented ranges.
- Replace the External ID with a new value after any suspected compromise.
- Enable organization trails and S3 data events for sensitive buckets.
