AWS cloud breach investigations have uncovered how attackers exploited trusted access granted to the cloud analytics provider Qubole, compromising multiple customer environments without exploiting a vulnerability in Amazon Web Services itself. Between October 14 and 26, 2026, attackers used compromised IAM credentials associated with Qubole to access sensitive information, retrieve cloud secrets, and download stored data. The incident highlights why organizations need stronger identity controls alongside dark web monitoring and external threat intelligence.
The findings, investigated by Wiz, Sentra, and Mandiant, expose a critical weakness in third-party cloud relationships: access granted to a legitimate provider can become a security liability when its credentials are compromised.
For CISOs, SOC teams, and cloud security professionals, understanding this attack offers practical lessons in identity governance, credential exposure, and incident response.
What Happened in the AWS Cloud Breach Involving Qubole?
Qubole is a cloud-based data processing and analytics platform that helps organizations manage large datasets and computational workloads.
Its integrations allow the platform to access selected resources inside customer AWS environments through predefined identity and access management (IAM) roles.
Researchers discovered that attackers obtained access to IAM identities associated with Qubole’s AWS account and used those identities to assume trusted roles across multiple customer environments.
Once authenticated, they could explore cloud infrastructure, retrieve secrets, and download data from accessible Amazon S3 buckets.
The investigation established several important findings:
- Malicious activity occurred between October 14 and 26, 2026.
- Multiple customer AWS environments were accessed.
- Attackers retrieved secrets from AWS Secrets Manager and Systems Manager Parameter Store.
- AWS Lambda environment variables were examined for sensitive information.
- Discovered AWS, Microsoft Entra ID, and Okta credentials were tested.
- Data was downloaded from accessible Amazon S3 buckets.
Sentra reported dozens of affected organizations and millions of files stolen from one customer environment.
However, the exact total number of victims and the original method used to obtain Qubole-associated credentials have not been publicly established.
How Attackers Exploited Trusted AWS IAM Access
The campaign relied on existing cross-account permissions rather than exploiting a software vulnerability.
AWS allows organizations to authorize external accounts to access specific resources through IAM roles.
This functionality is essential for many legitimate SaaS integrations, but it requires careful configuration and ongoing oversight.
1. Compromised third-party credentials
The attackers used IAM credentials belonging to an AWS account associated with Qubole.
These identities could request temporary access to customer environments that had previously established trust relationships with the provider.
Researchers identified suspicious authentication activity originating from external VPN and hosting infrastructure.
The initial credential compromise remains unexplained.
2. Abuse of cross-account IAM roles
The attackers invoked AWS Security Token Service using the AssumeRole operation.
Because customer trust policies permitted the Qubole-associated AWS account to assume designated roles, the requests were accepted.
The attackers also supplied valid external identifiers required by the integrations.
Some organizations had retained these permissions even after they stopped actively using Qubole.
This allowed obsolete trust relationships to remain exploitable.
3. Cloud infrastructure reconnaissance
After assuming customer roles, the attackers enumerated resources to understand which services and information were accessible.
Their activity involved examining storage buckets, secrets, application configurations, and other cloud resources.
The available permissions determined how far each intrusion could progress.
4. Credential harvesting and data exfiltration
The attackers retrieved secrets and examined configuration information that could contain additional credentials.
Researchers also observed the use of TruffleHog to validate discovered authentication material.
The activity included testing AWS keys, Microsoft Entra ID application credentials, and Okta client secrets.
Finally, the attackers downloaded files from accessible Amazon S3 buckets, sometimes extracting large volumes of information during individual sessions.
Why Trusted Cloud Integrations Create Security Risks
One of the most important lessons from this incident is that organizations can experience security breaches without their own credentials being compromised initially.
A trusted vendor may already possess sufficient authorization to reach sensitive systems.
If attackers compromise the vendor’s identity, they may inherit that access.
This creates several risks.
Excessive permissions: Third-party integrations may retain access to resources beyond their operational requirements.
Inactive integrations: Organizations sometimes stop using software without removing associated IAM roles.
Shared exposure: A single compromised provider account can potentially affect multiple customers.
Limited visibility: Security teams may overlook external authentication activity when concentrating on internal users.
This incident also demonstrates why an external identifier is not a replacement for strong identity security.
External IDs help prevent certain unauthorized role-assumption scenarios, but they cannot independently stop an attacker who has compromised an authorized identity and obtained the required identifier.
Organizations must evaluate cloud trust relationships as part of their wider attack surface.
DarknetSearch explores related identity risks in its article on cloud identity attacks and how compromised accounts lead to breaches.
What Information Was Exposed?
The attackers accessed several AWS services commonly used to store application secrets and business information.
| Cloud resource | Potential exposure |
|---|---|
| AWS Secrets Manager | Application passwords, API keys, and authentication secrets |
| SSM Parameter Store | Configuration data and stored credentials |
| AWS Lambda | Environment variables containing sensitive values |
| Microsoft Entra ID | Application identity credentials |
| Okta | OAuth client credentials |
| Amazon S3 | Business files and other stored data |
The actual impact depended on the permissions attached to each compromised role.
Access to a secret does not automatically demonstrate that attackers successfully used it to compromise another system.
Nevertheless, potentially exposed credentials should be investigated and rotated when necessary.
How External Threat Intelligence Supports Cloud Breach Investigations
Cloud attacks require visibility across internal infrastructure, identity systems, and external sources of compromised information.
When credentials are exposed, security teams need to understand whether those credentials have appeared in publicly accessible repositories, leaked datasets, or monitored criminal sources.
Investigating exposed credentials
DarknetSearch provides credential and stealer log monitoring capabilities that help organizations investigate potentially compromised authentication information.
External exposure monitoring can complement internal cloud security tools by identifying credentials associated with corporate domains or accounts.
However, investigators have not established that the credentials initially used in the Qubole attack originated from the dark web.
Monitoring cannot replace AWS CloudTrail analysis, IAM governance, or cloud-native threat detection.
Strengthening employee security practices
Cloud identities can also become exposed through phishing, malicious software, accidental publication, or poor credential-handling practices.
Targeted security awareness training helps employees recognize suspicious authentication requests, protect credentials, and report security concerns.
These measures complement technical restrictions on privileged access.
How to Detect Suspicious AWS Access
Organizations with current or historical Qubole integrations should review relevant AWS logs.
In the original Wiz investigation of the Qubole cross-account compromise, researchers recommend examining CloudTrail activity beginning October 1, 2026.
Particular attention should be given to:
AssumeRoleevents originating from AWS account805246085872.- Requests involving IAM user identifier
AIDA3W7DIFLYOLTK63SFS. - Role assumptions from unexpected VPN or hosting-provider addresses.
- Unusual access to Secrets Manager and Parameter Store.
- Unexpected Lambda configuration queries.
- Large or unexplained S3 object downloads.
- Credential-validation activity from unfamiliar infrastructure.
CloudTrail management events alone do not necessarily record individual S3 object downloads.
Organizations should enable appropriate S3 data events or server access logging for sensitive storage.
Investigation teams must also correlate suspicious indicators with legitimate provider activity before determining whether a specific event represents compromise.
How Organizations Can Prevent Similar Attacks
Defending against trusted-access abuse requires more than rotating passwords.
Organizations should strengthen the governance of third-party integrations.
Review external IAM trust relationships
Identify which external AWS accounts can assume roles within your environment.
Remove obsolete integrations and investigate roles that have remained inactive for extended periods.
Apply least-privilege permissions
Limit each external role to the resources required for its intended function.
Avoid unnecessary access to secrets, configuration stores, and entire S3 buckets.
Restrict trusted identities and networks
Where supported, limit role assumption to specific provider identities and approved source networks.
Use temporary workload credentials instead of long-lived access keys.
Improve cloud activity monitoring
Alert on unusual role assumptions, unexpected authentication sources, bulk secrets retrieval, and abnormal storage access.
Maintain sufficient logging to reconstruct potential data exfiltration.
Establish third-party risk reviews
Include integration permissions in vendor security assessments.
Ensure that access is reviewed whenever a contract, service configuration, or business relationship changes.
What Should Affected Organizations Do?
If suspicious activity is identified, incident responders should prioritize containment and evidence preservation.
- Identify affected integrations. Review roles trusting Qubole-associated identities and determine whether unauthorized sessions occurred.
- Analyze CloudTrail records. Reconstruct role assumptions and subsequent activity across affected accounts.
- Revoke unauthorized access. Remove unnecessary trust relationships and invalidate compromised sessions.
- Rotate potentially exposed secrets. Prioritize credentials accessed through Secrets Manager, Lambda, and Parameter Store.
- Investigate data access. Examine S3 logs to determine which files may have been downloaded.
- Monitor for further activity. Review other cloud services and identity providers for unauthorized access.
Incident-response teams should also determine whether notification obligations apply to any confirmed exposure of regulated information.
Frequently Asked Questions
What caused the AWS cloud breach involving Qubole?
Attackers used compromised IAM credentials associated with Qubole to assume customer-created AWS roles.
Those roles trusted Qubole’s AWS account and granted access to designated cloud resources.
The initial method used to compromise the provider-associated credentials has not been publicly confirmed.
Was Amazon Web Services itself compromised?
No vulnerability or compromise of AWS infrastructure was established in this incident.
AWS stated that its services operated as designed.
The attackers exploited trusted identity relationships configured between a third-party provider and customer AWS accounts.
Which organizations were affected?
The campaign affected multiple organizations that maintained AWS integrations trusting Qubole-associated identities.
Sentra reported dozens of victims.
However, the complete number of affected companies has not been publicly established, and an existing Qubole integration does not automatically mean an organization was compromised.
Can dark web monitoring prevent cloud credential theft?
Dark web monitoring cannot directly prevent unauthorized IAM role assumptions.
It can help investigate credentials or information that appear in monitored external sources.
Preventing similar intrusions requires identity governance, restricted access, cloud logging, credential security, and effective incident-response procedures.
Strengthen Visibility Into Exposed Credentials and Cloud Risks
The Qubole incident demonstrates how a single compromised third-party identity can expose multiple cloud environments.
Organizations need stronger control over trusted integrations, privileged credentials, and sensitive data access. External threat intelligence can complement those safeguards by identifying potential exposures beyond corporate infrastructure.
DarknetSearch helps security teams investigate compromised credentials, monitor leaked information, and improve external threat visibility.
Explore its capabilities and request a DarknetSearch free trial to assess how continuous monitoring can strengthen your existing security operations.
