Qubole AWS credentials abused to assume customer roles and steal data

What happened

A threat actor hijacked credentials from Qubole's AWS account to access multiple customer environments. By providing the required External ID, the attacker successfully assumed IAM roles that customers had established to grant Qubole access.

Once inside, the attacker used session names starting with quiam- to enumerate resources and exfiltrate data from S3 buckets. They also targeted Lambda environment variables, AWS Secrets Manager, and the SSM Parameter Store to harvest credentials. The attacker used TruffleHog to validate stolen AWS access keys, Entra ID client secrets, and Okta client credentials. This activity involved OVH-hosted IPs 57.129.54[.]120 and Mullvad VPN addresses 45.83.220[.]211 and 185.209.199[.]73.

A separate, unlinked activity involving Qubole AWS access keys was observed between October 8 and October 11.

Why it matters

This is a significant supply chain compromise that exploits the inherent trust in third-party cross-account integrations. Because the attacker used legitimate External IDs, standard role assumptions appeared valid. The attacker's behavior was opportunistic, downloading entire S3 buckets rather than targeting specific files. For defenders, this highlights the danger of overly permissive vendor roles and the necessity of restricting access by source IP or VPC endpoint rather than relying solely on an External ID.

Who is affected

• Organizations with IAM roles trusting Qubole's AWS account: 805246085872
• Organizations using Qubole via AWS access keys

What to do now

1. Check CloudTrail logs from October 1 onward for AssumeRole requests where userIdentity.accountId is 805246085872 and sourceIPAddress is not an AWS address.
2. Rotate all secrets, parameters, and Lambda environment variables that the assumed roles had access to, and revoke all active sessions.
3. Update IAM trust policies to include an aws:SourceIp or aws:SourceVpce condition to restrict requests to Qubole's documented network ranges.
4. Replace the account-wide :root principal in trust policies with the specific IAM principal used by Qubole.
5. Remove any unused Qubole roles.
6. Enable S3 data events or S3 server access logs to monitor for object-level access and exfiltration.

What we don't know yet

• How the attacker initially obtained the credentials for Qubole's AWS account.
• Whether the credentials used by the attacker have since been disabled.
• The specific motivation of the threat actor.
• Whether the sso_agent.iso file was successfully deployed against any victims.