What Happened
Wiz researchers describe a Qubole AWS breach affecting multiple customers, The Hacker News reports. Between October 14 and October 26, an attacker used credentials for Qubole’s own AWS account to assume IAM roles inside customer accounts. Qubole is a data lake platform owned by Idera. It runs inside customer environments through those roles, and each request carried the required External ID.
The attacker searched Lambda environment variables, Secrets Manager, and SSM Parameter Store for credentials. Stolen keys went through TruffleHog. They included AWS access keys, Entra ID client secrets, and Okta client credentials. The attacker also copied S3 data, sometimes a full bucket in one session. A separate campaign from October 8 to 11 used customer AWS keys set up for Qubole. Neither Qubole nor Idera has made a public statement, and the source of the credentials is unknown.
Why This Matters for Canadian Organizations
Canadian banks, insurers, retailers, and public bodies run data platforms inside their own AWS accounts and grant vendors standing access. Most of the abused roles sat unused, yet they still trusted Qubole’s account. One vendor compromise became a path into many customer environments.
The loot matters more than the S3 data. Stolen Entra ID and Okta secrets reach beyond AWS into identity systems. Under PIPEDA, an incident with real risk of significant harm triggers breach reporting. OSFI Guideline B-13 expects federally regulated institutions to manage third-party technology risk.
What to Do
List every IAM role in your AWS accounts with a trust policy naming an outside account. Delete roles you no longer use. Scope the rest to the narrowest permissions and add conditions. Search CloudTrail from October 1 for AssumeRole calls from account 805246085872. Rotate any secrets stored in Lambda variables, Secrets Manager, or Parameter Store if a Qubole role had read access. Review Entra ID and Okta sign-in logs for new use of those credentials. Read more TechTalk coverage and our latest news.
