Qubole: attacker used vendor AWS credentials to assume customer roles and exfiltrate S3 data
Severity: high · Patch status: no-fix-needed · Since 2026-11-09
Wiz CIRT, working with Sentra and Mandiant, reports that between 14 and 26 October 2026 a threat actor used IAM credentials from an AWS account that Qubole's platform uses (805246085872) to assume integration roles that customers had created to trust Qubole, presenting valid External IDs. Every role assumption the post attributes to the actor succeeded, and in most affected environments it was the only vendor-account activity that month, so the trust policies were simply still in place. Inside the customer accounts the actor enumerated storage, compute, databases, roles and KMS keys, read Lambda environment variables, Secrets Manager and SSM Parameter Store, checked harvested AWS, Entra ID and Okta credentials with TruffleHog, and downloaded S3 objects, in some cases whole buckets. The post names no vendor fix; the remediation it describes is customer-side: remove or narrow unused trust (a specific principal plus source-IP conditions), rotate External IDs and every credential the roles could read, revoke sessions already issued, and enable S3 data events. The post does not say how many customers were affected, only that there were multiple victim environments.
What to do
- Audit CloudTrail from 1 October 2026 for sts:AssumeRole where the caller account is 805246085872 and the source IP is not an AWS address; also review AssumeRole calls by IAM users AIDA3W7DIFLYOLTK63SFS and AIDAJYRRH5Y3A7AAJM2HW that come from non-AWS addresses, IPs 45.83.220.211, 185.209.199.73, 57.129.54.120 and 89.37.63.175, and session names prefixed quiam-
- Rotate all credentials found in Lambda env vars, Secrets Manager and SSM Parameter Store, and validate Entra ID/Okta service principal secrets
- Review S3 data events logs for GetObject/ListObjects exfiltration from integration roles
- Remove unused third-party cross-account trust roles; where one is kept, narrow the trusted principal, add aws:SourceIp or aws:SourceVpce conditions, and rotate the External ID per role
- Enable S3 server access logs/CloudTrail data events for sensitive buckets, and revoke active sessions for any integration role the actor assumed (rotating a credential does not end sessions already issued)
Sources
All live incidents on Threat Watch
