Incident sheet · SIG-7123 · /security
- Signal
- SIG-7123
- System
- SEC · Security & Risk
- Filed
- Read
- 3 min · 506 words
- Severity
- Routine
Qubole AWS credential breach hit tens of cloud customers
Attackers compromised two Qubole IAM users, entered customer AWS accounts through trusted roles and stole millions of files from one victim; Sentra confirmed dozens of victims.
Event log
- The attack ran from October 14 to October 26 and affected tens of companies.
- Attackers compromised two Qubole IAM users and assumed trusted customer AWS roles.
- Sentra confirmed dozens of victims and millions of files stolen from one customer.
- The attacker collected 100 passwords and keys in seven minutes.
- Administrators should review CloudTrail from October 1 and revoke active role sessions.
By Amara Osei
Sentra confirmed dozens of victims and millions of files stolen from one customer after attackers compromised Qubole's AWS credentials between October 14 and 26. The wider campaign reached tens of companies whose AWS environments trusted an account associated with Qubole.
How did a trusted integration become an entry point?
Qubole provides an enterprise cloud data processing and analytics platform. Its service helps companies manage large datasets, run machine-learning workloads and manage computing resources through AWS integration.
The attack exploited that integration. Customer administrators create cross-account IAM roles so external providers can reach approved AWS resources. Trust policies specify which external AWS accounts may assume a role, while permissions define which resources and actions the role can use.
External providers use the AWS STS AssumeRole API to obtain temporary credentials. Attackers compromised two Qubole IAM users and used that position to assume otherwise unused roles in customer AWS accounts already configured to trust Qubole's account. Access stayed within the permissions assigned to each role.
The basic problem was simple: a legitimate provider trust relationship became an unauthorized access route.
What did the attackers collect?
Wiz began investigating after Sentra, a data security and governance company, reported suspicious activity in some of its customers' environments. Mandiant, a cybersecurity company, joined the investigation.
Once inside, the attacker surveyed cloud resources, retrieved secrets from AWS Secrets Manager and SSM Parameter Store, and read Lambda environment variables. The attacker also used the TruffleHog tool to validate discovered AWS keys, Microsoft Entra ID client secrets and Okta client credentials.
Wiz researchers explained: “The sequence was consistent across environments: assume a role, call ListBuckets to see what the role could reach, call ListObjects and HeadObject to enumerate and inspect the contents, then call GetObject to download them.”
That access enabled bulk downloads from every accessible S3 bucket rather than a narrow selection of named files. The report describes the approach as opportunistic rather than carefully targeting specific data.
Sentra reported that the attacker collected 100 passwords and keys in seven minutes. That works out to an average of about 14 credentials a minute, or roughly one every four seconds. Millions of files came from one customer alone.
The report does not specify the exact method used to compromise the Qubole accounts or the number of downstream victims.
The scale remains clear despite those gaps: the attack collected broadly available secrets and data rather than pursuing one named target.
What should administrators do now?
BleepingComputer reported that it had found no public announcement from Qubole. The publication had emailed the company for more information and was awaiting a response.
Potentially affected administrators should take four steps:
- Review AWS CloudTrail logs from October 1 onward for suspicious access from Qubole's AWS account, then investigate subsequent secret retrieval and S3 access.
- Rotate exposed credentials and revoke active role sessions.
- Remove unused integrations.
- Restrict permissions, trusted identities and permitted source networks on remaining roles.
The priority is simple: close unused trust paths, cut live sessions and replace exposed credentials.
via bleepingcomputer.com (Source)
More from Amara Osei
Show full bio
Correspondent covering regulation, policy and their impact on enterprise information technology and the leaders who run at CIO Monitor.
122 articles
The newsroom digest
One email a day with the stories that matter. No noise.