A coordinated cloud supply chain intrusion has compromised the cloud environments of dozens of enterprise organizations through trusted identity relationships established with big-data analytics vendor Qubole. The campaign, active between October 14 and October 26, 2026, saw an unidentified threat actor leverage stolen long-term Identity and Access Management (IAM) credentials belonging to Qubole’s primary Amazon Web Services (AWS) account (805246085872).
By exploiting these legitimate vendor credentials, the adversary systematically executed cross-account sts:AssumeRole API calls into customer environments that had provisioned integration roles for the platform. The intrusion bypassed customary perimeter defenses by traveling along authorized cloud control plane trust corridors.
The incident came to light following joint technical disclosures published by cloud security provider Wiz, data security posture management firm Sentra, and Google Cloud’s Mandiant. Their investigations revealed that the attacker abused these cross-account roles to harvest stored secrets, access keys, configuration parameters, and exfiltrate entire Amazon Simple Storage Service (S3) buckets.
The speed and automation of the compromise were severe: in one monitored customer account, the attacker extracted more than 100 enterprise passwords and authentication keys in seven minutes. In another, millions of analytical and proprietary files were siphoned out across a single continuous session.
What makes this campaign particularly dangerous is its reliance on historical, forgotten cloud architecture. Researchers confirmed that many of the victimized enterprises had discontinued their use of Qubole months or even years earlier. While business relationships had lapsed and operational software had been decommissioned, the underlying AWS IAM cross-account trust policies remained active inside client cloud estates. The threat actor uncovered these dormant paths and used them to bypass traditional identity verification.
The disclosure of the Qubole AWS security breach highlights a critical systemic vulnerability in modern cloud-native enterprises: the unmanaged lifecycle and excessive privilege of third-party software-as-a-service (SaaS) integration roles. As organizations scramble to audit their cloud environments, this event forces a fundamental reassessment of how cross-account trust is negotiated, monitored, and revoked across multi-tenant cloud ecosystems.
The Mechanics of the Qubole AWS Security Breach
To understand how an external adversary compromised internal enterprise environments without exploiting software vulnerabilities in customer workloads, one must examine the architecture of SaaS cross-account access within AWS.
+--------------------------------------------------------------------------------------------------+
| ATTACK EXECUTION TIMELINE |
+--------------------------------------------------------------------------------------------------+
| |
| [Attacker Infrastructure] |
| OVH VPS (57.129.54.120) & Mullvad VPN (185.209.199.73) |
| | |
| | 1. Authenticates with stolen Qubole IAM credentials |
| v |
| [Compromised Qubole AWS Account (805246085872)] |
| Principals: AIDA3W7DIFLYOLTK63SFS & AIDAJYRRH5Y3A7AAJM2HW |
| | |
| | 2. sts:AssumeRole (Supplying Role ARN + Valid External ID) |
| v |
| [Customer AWS Account - Cross-Account Role] |
| Trust Policy validates Account ID & External ID -> Returns Temporary STS Tokens |
| | |
| | 3. Session Name: quiam-enum / quiam-scope-full |
| v |
| [Automated Privilege Escalation & Lateral Data Extraction] |
| * AWS Secrets Manager & SSM Parameter Store |
| * AWS Lambda (Environment Variables) |
| * TruffleHog (Real-time key & OAuth validation) |
| * Mass S3 Bucket Exfiltration -> Egress to Attacker Storage |
+--------------------------------------------------------------------------------------------------+Big-data processing engines and cloud data lake management platforms require direct, low-latency access to customer compute clusters (such as Amazon Elastic MapReduce) and storage layers (such as Amazon S3). Rather than requiring customers to generate long-lived static API access keys—a practice discouraged by security benchmarks—SaaS providers instruct customers to create an IAM role within their own AWS account.
This role contains a Trust Policy (defining who can assume the role) and Permission Policies (defining what actions the role can perform once assumed).
When the vendor platform needs to execute an operational task—such as spinning up an Apache Spark cluster or querying an analytics bucket—it calls the AWS Security Token Service (STS) AssumeRole API. AWS STS validates that the caller matches the principal specified in the customer's trust policy, issues short-lived temporary security credentials (consisting of an Access Key ID, a Secret Access Key, and a Session Token), and allows the platform to act inside the customer's account within the scope of the assigned permissions.
The Illusion of Protection: Why External IDs Failed
In standard cross-account designs, AWS recommends incorporating an ExternalId condition into the trust policy. The external ID is designed specifically to solve the "confused deputy" problem—a scenario where an attacker tricks a third-party vendor into using its legitimate permissions to access another customer’s resources. The external ID functions as a shared secret between the customer and the SaaS platform.
During this campaign, the attacker did not trick Qubole's automated software; rather, the attacker held the vendor's internal IAM credentials directly.
The threat actor compromised two distinct IAM user identities operating within Qubole’s AWS account (805246085872):
- AIDA3W7DIFLYOLTK63SFS: An identity that, according to forensic telemetry, was used exclusively by the adversary and showed no legitimate platform activity.
- AIDAJYRRH5Y3A7AAJM2HW: An identity introduced into the campaign on October 18, which commingled malicious operations with legitimate Qubole production traffic originated from inside AWS infrastructure.
Because the adversary possessed internal access to Qubole's environment or its deployment databases, they obtained both the customer-assigned role Amazon Resource Names (ARNs) and their corresponding ExternalId strings.
When the threat actor initiated an sts:AssumeRole request from their external command infrastructure, AWS STS evaluated two conditions:
- Did the request originate from the trusted account (805246085872)? Yes.
- Did the request supply the matching ExternalId? Yes.
Every single assumption request evaluated as cryptographically valid. The security control specifically designated to protect cross-account access offered zero resistance because the trusted identity itself was compromised.
Attacker Tradecraft, Infrastructure, and Tooling
Forensic analysis conducted across victim environments revealed a consistent, automated operational playbook. The attacker operated strictly from outside AWS infrastructure, routing commands through a dedicated Virtual Private Server (VPS) hosted by OVH in Europe (57.129.54.120) and exit nodes provided by the commercial VPN service Mullvad (including 185.209.199.73).
+--------------------------------------------------------------------------------------------------+
| ATTACKER TOOLING & OPERATIONAL FINGERPRINT |
+--------------------------------------------------------------------------------------------------+
| Threat Actor Primary Infrastructure : OVH SAS VPS (57.129.54.120) & Mullvad VPN Exit Nodes |
| Compromised Qubole AWS Account ID : 805246085872 |
| Malicious IAM Principal 1 : AIDA3W7DIFLYOLTK63SFS (Dedicated attacker user) |
| Malicious IAM Principal 2 : AIDAJYRRH5Y3A7AAJM2HW (Blended with legitimate traffic) |
| STS Role Session Names Observed : quiam-enum, quiam-scope-full |
| Secret Validation Engine : TruffleHog (Automated secret scanning and API verification)|
| Stored Forensic Artifacts : Bootable custom ISO image configured for data collection |
+--------------------------------------------------------------------------------------------------+When calling AssumeRole, the threat actor applied explicit session tags that revealed an organized, scripted reconnaissance methodology. The sessions utilized the naming convention quiam-
- quiam-enum: Dedicated to rapid enumeration of cloud storage, serverless functions, and secret stores.
- quiam-scope-full: Employed during deep exfiltration phases where broad reading rights were exercised.
Once temporary credentials were generated, the adversary avoided noisy compute deployment, avoiding launching EC2 instances or manipulating container clusters. Instead, they focused entirely on high-value identity discovery and bulk data extraction.
To maximize the utility of stolen configurations, the adversary ran automated discovery scripts that piped retrieved environmental parameters directly into TruffleHog, an open-source secret scanning tool. This enabled the attacker to validate stolen credentials immediately against external target APIs, confirming within seconds whether harvested tokens granted active administrative reach into secondary cloud providers or enterprise identity portals.
Investigators also observed a custom ISO file hosted on the attacker's OVH server. While researchers found no evidence that this bootable image was successfully mounted or booted within victim virtual machines, its presence suggests the adversary maintained contingency tooling intended to establish persistent out-of-band compute footholds in environments where virtual machine management permissions were accessible.
Architectural and Governance Breakdowns: What Went Wrong
The severity of the Qubole AWS security breach was magnified by multiple overlapping structural failures in how enterprises design, provision, and decommission cloud integrations. The adversary exploited gaps in access control that had accumulated across years of enterprise cloud operations.
1. The Zombie Role Phenomenon and Offboarding Lapses
The most alarming finding documented by Sentra and Wiz was that the vast majority of compromised roles were completely dormant prior to October 14. Multiple victim enterprises had ended their commercial subscriptions with Qubole years before the attack occurred.
In modern enterprise IT, procurement and vendor offboarding procedures frequently focus on contract termination, billing cessation, single sign-on (SSO) revocation, and user deprovisioning from third-party dashboards.
However, cloud control plane configurations are frequently neglected:
- Infrastructure as Code (IaC) repositories (such as Terraform or AWS CloudFormation) often separate third-party role definitions from dynamic application workloads.
- When a SaaS platform is decommissioned, teams rarely run formal cleanup routines to delete the historical cross-account IAM role from their AWS accounts.
- Because an idle IAM role incurs zero direct financial cost on an AWS monthly bill, it does not trigger cost-optimization alarms or FinOps cleanup workflows.
As a result, these integration roles remain intact indefinitely. The trust relationship remains active on the AWS control plane, quietly waiting for an authentication request from the vendor's account. The adversary did not need to break into active, heavily monitored software stacks; they simply walked through doors left unlocked by former customers years in the past.
+--------------------------------------------------------------------------------------------------+
| THE ZOMBIE ROLE DECOMMISSIONING GAP |
+--------------------------------------------------------------------------------------------------+
| |
| ENTERPRISE OFFBOARDING WORKFLOW (TYPICAL) |
| [ Terminate Contract ] ---> [ Disable SSO / User Logins ] ---> [ Cease Monthly Billing ] |
| | |
| X (MISSED STEP) |
| v |
| [ Delete AWS Cross-Account IAM Role ] |
| |
| RESULT: The cross-account trust policy remains fully active in the AWS control plane. |
| The vendor's AWS Account ID retains permanent AssumeRole rights into the cloud perimeter. |
+--------------------------------------------------------------------------------------------------+2. Excessive Permissions Provisioned to Analytics Integrations
Cloud big-data engines frequently present complex deployment documentation that recommends broad permissions during onboarding. To minimize deployment friction and avoid broken analytics pipelines caused by missing granular rights, DevOps and platform teams routinely grant extensive access to vendor integration roles.
Rather than scoping access down to specific operational data subsets, integration roles frequently contain wildcard permissions across multiple core AWS services:
- s3: or s3:GetObject across all bucket resources, enabling universal data exfiltration.
- secretsmanager:GetSecretValue, allowing the role to inspect all stored operational credentials.
- ssm:GetParameter, providing plaintext access to configuration databases.
- lambda:GetFunctionConfiguration, allowing external roles to read environment variables embedded in serverless microservices.
This excessive entitlement profile enabled a single role assumption event to convert a data lake integration into a complete administrative reconnaissance vehicle. The attacker did not need to perform complex local privilege escalation; the compromised role already possessed the rights needed to compromise the organization's wider infrastructure.
3. Structural Deficiencies in Standard IAM Trust Policies
A standard IAM trust policy template distributed by SaaS vendors typically mirrors the following structure:
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::805246085872:root"
},
"Action": "sts:AssumeRole",
"Condition": {
"StringEquals": {
"sts:ExternalId": "CUSTOMER_DEFINED_SHARED_SECRET"
}
}
}
]
}This configuration contains an inherent architectural vulnerability: delegation to account root.
When a customer specifies "AWS": "arn:aws:iam::805246085872:root", the customer delegates authorization authority to the administrator of that external AWS account. The customer's trust boundary ends at the account border. Any IAM user, role, or automated workload inside the 805246085872 account that possesses the sts:AssumeRole permission can assume the customer's role, provided they pass the sts:ExternalId string.
Crucially, standard vendor trust policies omit network boundary conditions.
AWS IAM supports global condition keys, such as aws:SourceIp and aws:SourceVpce, which can restrict the execution of sts:AssumeRole to specific, documented vendor egress IP addresses or private VPC endpoints.
Because these conditions were absent from victim policies, the attacker was able to assume these roles from commercial hosting providers (OVH) and consumer privacy VPNs (Mullvad) without triggering an immediate IAM policy denial.
4. Breakdown of the Shared Responsibility Model for SaaS
The incident reveals a blind spot in how security responsibilities are handled between cloud service providers (CSPs), third-party SaaS vendors, and enterprise customers.
+--------------------------------------------------------------------------------------------------+
| SHARED RESPONSIBILITY BREAKDOWN IN SAAS INTEGRATIONS |
+--------------------------------------------------------------------------------------------------+
| AWS Responsibility : Protect the underlying physical STS and IAM authorization plane. |
| STATUS: Operating as designed. (Cryptographic validation succeeded). |
| |
| SaaS Responsibility : Secure internal credentials, rotate keys, restrict internal egress. |
| (Qubole / Idera) STATUS: FAILED. Internal IAM user keys leaked to external adversaries. |
| |
| Customer : Maintain least privilege, prune stale roles, apply network conditions. |
| Responsibility STATUS: FAILED. Left zombie roles active; omitted source IP conditions. |
+--------------------------------------------------------------------------------------------------+Under the AWS Shared Responsibility Model, AWS guarantees the integrity of the underlying STS infrastructure and ensures that access policies are enforced as written. AWS executed its function correctly: the credentials matched, the account matched, and the external ID matched.
The failure occurred in the interaction between the SaaS provider and its enterprise clients:
- Vendor Level (Qubole / Idera): The vendor failed to protect long-term access keys associated with identity AIDA3W7DIFLYOLTK63SFS. Furthermore, internal monitoring failed to detect that its internal credentials were being leveraged from foreign network infrastructure (OVH/Mullvad) to initiate external role assumptions against clients.
- Customer Level: Enterprise security teams failed to treat third-party trust relationships as dynamic attack surfaces. Security operations centers (SOCs) actively monitor user logins and anomalous employee behavior, but rarely inspect cross-account STS assume role activity initiated by established vendor accounts.
Blast Radius: What the Attackers Took and Why It Matters
The consequences of unauthorized access through these trusted roles extended far beyond the boundaries of Qubole's analytics workflows. By targeting cloud configuration repositories and identity stores, the attacker turned access to a single analytics role into an enterprise-wide data collection campaign.
Systematic Harvesting of Secrets and Infrastructure Configurations
Once inside an account, the threat actor did not spend time attempting to deploy cryptominers or modify infrastructure. Their focus was intelligence gathering.
+--------------------------------------------------------------------------------------------------+
| HARVESTED ASSET INVENTORY |
+--------------------------------------------------------------------------------------------------+
| Resource Target | Specific Assets Extracted |
+---------------------------+----------------------------------------------------------------------+
| AWS Lambda Configurations | Plaintext DB strings, external API tokens, private signing keys. |
| AWS Secrets Manager | Database master passwords, third-party integration secrets. |
| SSM Parameter Store | Microservice configurations, internal application endpoints. |
| Cloud Storage (S3) | Entire buckets: analytical logs, customer PII, raw business records. |
| Identity & Access Tokens | Microsoft Entra ID client secrets, Okta OAuth service credentials. |
+---------------------------+----------------------------------------------------------------------+AWS Lambda Environment Variables
Modern cloud applications frequently pass operational configurations to serverless functions via environment variables. By invoking lambda:GetFunctionConfiguration, the threat actor extracted database connection strings, third-party API tokens (such as payment gateways and communication webhooks), and encryption keys embedded in serverless application environments.
AWS Secrets Manager and SSM Parameter Store
The threat actor called secretsmanager:GetSecretValue and ssm:GetParameters across all available resource regions. The data extracted included master database passwords, operational API keys, internal service account tokens, and application configurations.
Direct Cross-Identity Spillover
Most critically, the harvested secrets included authentication credentials for external Identity Providers (IdPs). Researchers confirmed that the attacker extracted Microsoft Entra ID (formerly Azure AD) client secrets and Okta OAuth client credentials.
This allowed the attacker to move laterally across identity perimeters: a breach originating inside an AWS third-party data platform role expanded directly into corporate identity directories, granting access to internal applications, software repositories, and Azure cloud environments.
Automated Validation via TruffleHog
The threat actor recognized that raw credential collection often results in unmanageable volumes of expired or non-functional tokens. To streamline exploitation, the adversary integrated the open-source scanner TruffleHog into their automation pipeline.
As strings were pulled from Secrets Manager, SSM, and Lambda, TruffleHog automatically tested each token against its corresponding service endpoint:
- AWS access keys were validated via sts:GetCallerIdentity.
- Entra ID credentials were submitted to Microsoft identity endpoints to verify tenant access.
- Okta client credentials were tested to establish whether administrative API scopes could be accessed.
This automated validation loop allowed the adversary to triage stolen data rapidly. Within minutes of initial cross-account role assumption, the attacker possessed a validated list of active credentials for further lateral expansion.
+--------------------------------------------------------------------------------------------------+
| AUTOMATED EXFILTRATION & VALIDATION PIPELINE |
+--------------------------------------------------------------------------------------------------+
| |
| [sts:AssumeRole via Qubole Credentials] |
| | |
| v |
| [Extract Raw Secrets & Configs] |
| (Secrets Manager, SSM Parameter Store, Lambda Environment Variables) |
| | |
| v |
| [Real-Time TruffleHog Ingestion Engine] |
| | |
| +---------+---------+---------+ |
| | | | |
| v v v |
| [AWS API] [Entra ID] [Okta API] |
| (sts:GetCallerIdentity) (OAuth Token) (Client Auth) |
| | | | |
| +---------+---------+---------+ |
| | |
| v |
| [Confirmed High-Privilege Target Tokens Flagged for Immediate Exploitation] |
+--------------------------------------------------------------------------------------------------+Indiscriminate Data Lake Draining
Unlike targeted advanced persistent threats (APTs) that search for specific corporate intellectual property, this adversary’s exfiltration strategy was opportunistic and exhaustive.
Wiz researchers noted that the threat actor made no effort to parse or selectively filter S3 bucket contents. Once permissions were confirmed via s3:ListBuckets, the automation issued bulk download requests, reading from every storage bucket within the role's scope.
In multiple cases, the attacker downloaded the entire contents of multi-terabyte data lake repositories across a single session, exfiltrating financial logs, raw analytics datasets, and personally identifiable information (PII) directly to foreign infrastructure.
Detection and Threat Hunting: Investigating the Compromise
Because the intrusion relied entirely on legitimate AWS control plane APIs, conventional endpoint detection and response (EDR) platforms deployed on virtual machines were completely blind to the intrusion. Detection depends entirely on analyzing AWS CloudTrail event logs.
Every security operations team that has ever utilized Qubole—regardless of current contract status—must review CloudTrail logs beginning from October 1, 2026.
+--------------------------------------------------------------------------------------------------+
| HUNTING & FORENSIC CHECKS |
+--------------------------------------------------------------------------------------------------+
| Priority 1: External Account Calls |
| Identify all sts:AssumeRole API events where the calling account ID matches |
| 805246085872. |
| |
| Priority 2: Non-AWS Source IP Addresses |
| Flag any connection from 805246085872 originating from commercial hosting or VPNs |
| (e.g., OVH, Mullvad) rather than verified AWS infrastructure. |
| |
| Priority 3: Known Malicious Principals |
| Search specifically for identity AIDA3W7DIFLYOLTK63SFS. |
| |
| Priority 4: Anomalous Session Names |
| Search for roleSessionName values utilizing the quiam-* naming structure. |
| |
| Priority 5: Downstream Discovery & Access |
| Correlate flagged sessions against Secrets Manager, SSM Parameter Store, Lambda, |
| and S3 data-plane events. |
+--------------------------------------------------------------------------------------------------+Key Indicators of Compromise (IoCs)
When triaging CloudTrail event records, security analysts should flag events that match these indicators:
- Caller Account ID: 805246085872 (Qubole platform account).
- Dedicated Attacker Principal: AIDA3W7DIFLYOLTK63SFS.
- Shared / Compromised Principal: AIDAJYRRH5Y3A7AAJM2HW (especially when originating from non-AWS IPs).
- Role Session Names: quiam-enum, quiam-scope-full, or any string beginning with the quiam- prefix.
- Known Malicious IP Nodes:
57.129.54.120 (OVH Hosting)
185.209.199.73 (Mullvad VPN)
Amazon Athena CloudTrail Forensic Queries
Security teams using Amazon Athena to query CloudTrail logs stored in S3 can run the following SQL queries to identify unauthorized role assumptions and trace downstream attacker activity.
Query 1: Detect Suspicious Qubole Cross-Account Role Assumptions
This query inspects all AssumeRole events initiated by the Qubole AWS account, isolating requests that originated outside of AWS infrastructure or matched the attacker's operational naming conventions:
SELECT
eventtime,
useridentity.accountid AS calling_account_id,
useridentity.principalid AS calling_principal_id,
useridentity.arn AS calling_arn,
sourceipaddress,
useragent,
requestparameters,
responseelements,
resources[1].arn AS assumed_role_arn
FROM cloudtrail_logs
WHERE eventsource = 'sts.amazonaws.com'
AND eventname = 'AssumeRole'
AND useridentity.accountid = '805246085872'
AND (
-- Detect dedicated malicious principal
useridentity.principalid LIKE '%AIDA3W7DIFLYOLTK63SFS%'
-- Detect attacker session naming structure
OR json_extract_scalar(requestparameters, '$.roleSessionName') LIKE 'quiam-%'
-- Detect calls originating outside known AWS infrastructure
OR sourceipaddress NOT LIKE '%.amazonaws.com'
)
ORDER BY eventtime DESC;Query 2: Trace Downstream Secrets Harvesting and Exfiltration
Once a suspicious session is identified, copy the generated accessKeyId from the responseElements of the AssumeRole record and run this query to map every API operation executed by that session:
SELECT
eventtime,
eventname,
eventsource,
sourceipaddress,
useridentity.sessioncontext.sessionissuer.username AS assumed_role_name,
useridentity.sessioncontext.sessionissuer.arn AS assumed_role_arn,
requestparameters,
errorcode,
errormessage
FROM cloudtrail_logs
WHERE useridentity.accesskeyid = 'ASIATEMPORARYKEYIDHERE'
AND eventtime >= '2026-10-01T00:00:00Z'
ORDER BY eventtime ASC;Look specifically for clusters of high-risk enumeration and read operations occurring within short time windows:
- GetSecretValue (AWS Secrets Manager)
- GetParameters / GetParameter / DescribeParameters (SSM Parameter Store)
- GetFunctionConfiguration / ListFunctions (AWS Lambda)
- ListBuckets / GetObject / GetBucketLocation (Amazon S3)
Remediation and Hardening: The Problem-Solution Blueprint
Containing and resolving this threat requires a structured approach. Remediating a cloud control plane breach differs fundamentally from isolating an on-premises host: simply rotating static credentials does not immediately terminate active, authenticated cloud sessions.
+--------------------------------------------------------------------------------------------------+
| REMEDIATION WORKFLOW PHASES |
+--------------------------------------------------------------------------------------------------+
| |
| PHASE 1: IMMEDIATE CONTAINMENT (T + 0 Hours) |
| + Terminate Active STS Sessions via AWSRevokeOlderSessions Inline Policy |
| + Delete Dormant and Unused Qubole IAM Roles and Trust Policies |
| + Block Account ID 805246085872 via Service Control Policies (SCPs) |
| |
| PHASE 2: CREDENTIAL ROTATION MATRIX (T + 24 Hours) |
| + Rotate All AWS Secrets Manager and SSM Parameter Store Values Accessible by Role |
| + Invalidate and Reissue Lambda Environment Variables |
| + Cycle External Identity Secrets (Entra ID Client Secrets, Okta OAuth Keys) |
| |
| PHASE 3: ARCHITECTURAL HARDENING (T + 7 Days) |
| + Implement aws:SourceIp and aws:SourceVpce Conditions on All Third-Party Roles |
| + Restrict Account Root Trust (:root) to Explicit Vendor IAM Principals |
| + Deploy Automated Stale Role Reaping via CIEM / Identity Analytics Tools |
+--------------------------------------------------------------------------------------------------+Phase 1: Immediate Containment and Session Revocation
Step 1: Invalidate All Active Assumed Role Sessions Immediately
When an IAM role is assumed via STS, AWS generates temporary credentials valid for between 15 minutes and 12 hours (depending on the role's MaxSessionDuration setting). Deleting or modifying the role does not automatically invalidate temporary tokens that have already been issued.
To terminate ongoing malicious sessions instantly, administrators must attach an explicit revocation policy to the role. This can be accomplished via the AWS Management Console (Role -> Revoke Sessions) or by applying the standard AWS revocation inline policy:
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Deny",
"Action": "*",
"Resource": "*",
"Condition": {
"DateLessThan": {
"aws:TokenIssueTime": "2026-11-10T00:00:00Z"
}
}
}
]
}This condition forces AWS STS to reject any API call made with a token issued prior to the specified timestamp, severing the attacker’s active access.
Step 2: Delete Stale Roles and Decommission Access
If the enterprise no longer actively uses Qubole, delete the IAM role entirely. In accounts where legacy integration models used static IAM user access keys rather than roles, identify and delete all associated IAM access keys immediately.
Step 3: Enforce Account-Wide Ingress Restrictions via Service Control Policies (SCPs)
Organizations using AWS Organizations should implement a Service Control Policy (SCP) at the root or organizational unit (OU) level to prevent any identity within the enterprise from creating or assuming roles involving the compromised Qubole account ID, providing an immediate safety net across all managed child accounts:
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "BlockCompromisedVendorAccount",
"Effect": "Deny",
"Action": "sts:AssumeRole",
"Resource": "*",
"Condition": {
"StringEquals": {
"aws:PrincipalAccount": "805246085872"
}
}
}
]
}Phase 2: Credential Rotation Across All Affected Services
Because the adversary systematically tested credentials using TruffleHog, security teams must assume that any secret accessible to the compromised role has been compromised.
+--------------------------------------------------------------------------------------------------+
| CREDENTIAL ROTATION MATRIX |
+--------------------------------------------------------------------------------------------------+
| Affected Layer | Action Required |
+----------------------+---------------------------------------------------------------------------+
| Secrets Manager | Rotate all secrets read by the role; update downstream database users. |
| SSM Parameter Store | Re-encrypt and reissue parameters; terminate existing application pools. |
| AWS Lambda | Invalidate tokens stored in environment variables; redeploy functions. |
| Microsoft Entra ID | Delete compromised client secrets; generate new cryptographic keys. |
| Okta Authentication | Revoke exposed OAuth service app credentials; audit user session logs. |
+----------------------+---------------------------------------------------------------------------+- AWS Secrets Manager & SSM: Identify all secrets readable by the role’s permission policy. Rotate those secrets immediately, including underlying database passwords, administrative tokens, and application credentials.
- Lambda Microservices: Review all Lambda functions evaluated by the threat actor. Invalidate API keys and configurations exposed in environment variables, redeploy functions with refreshed configurations, and move sensitive parameters to encrypted Secrets Manager stores using AWS Key Management Service (KMS) customer-managed keys.
- Cross-Cloud Identity Providers: Coordinate with identity administration teams to audit Microsoft Entra ID and Okta logs for authentication events originating from OVH, Mullvad, or unrecognized IP addresses. Revoke and cycle all exposed client secrets and application certificates.
Phase 3: Architectural Redesign for Third-Party Cloud Integrations
Organizations actively maintaining third-party SaaS cross-account integrations must redesign their trust policies to prevent single-point-of-compromise vulnerabilities.
Hardening Trust Policies with Explicit Network Boundaries
Never grant cross-account role assumption rights without constraining the network paths through which the request may arrive. Demand that SaaS vendors provide documented, static public IP egress ranges or dedicated VPC endpoints. Incorporate these boundaries directly into the trust policy using the aws:SourceIp condition key:
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "NetworkHardenedSaaSTrustPolicy",
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::805246085872:root"
},
"Action": "sts:AssumeRole",
"Condition": {
"StringEquals": {
"sts:ExternalId": "USE_CRYPTOGRAPHICALLY_RANDOM_UUID_HERE"
},
"IpAddress": {
"aws:SourceIp": [
"VENDOR_DOCUMENTED_CIDR_BLOCK_1/32",
"VENDOR_DOCUMENTED_CIDR_BLOCK_2/28"
]
}
}
}
]
}If this policy had been in place across victim accounts, the attacker's requests from OVH (57.129.54.120) and Mullvad (185.209.199.73) would have been denied immediately by the AWS IAM evaluation engine.
Eliminating Account-Level Root Delegation
Where technical architecture permits, move away from trusting arn:aws:iam::
Implementing Cloud Infrastructure Entitlement Management (CIEM)
Enterprises must transition from passive access control to automated identity lifecycle management. Deploy CIEM tools or custom automated auditing scripts that scan AWS IAM Access Advisor data across all corporate accounts weekly.
Establish an automated policy enforcement rule:
- If an external cross-account role exhibits zero API calls over a trailing 30-day window, the role must be disabled automatically by attaching an explicit Deny All inline policy.
- If inactivity extends to 60 days, the role must be queued for administrative review and automated deletion.
+--------------------------------------------------------------------------------------------------+
| AUTOMATED CIEM ACCESS REAPING PIPELINE |
+--------------------------------------------------------------------------------------------------+
| |
| [AWS IAM Access Advisor Daily Scan] |
| | |
| v |
| [Evaluate Third-Party Cross-Account Roles] |
| | |
| +---------+---------+ |
| | | |
| (Activity < 30 Days) (Zero Activity >= 30 Days) |
| | | |
| v v |
| [Keep Active] [Attach Explicit Inline Deny Policy] |
| | |
| v |
| (Zero Activity >= 60 Days) |
| | |
| v |
| [Notify Security Operations & Automatically Delete Role] |
+--------------------------------------------------------------------------------------------------+Supply Chain Realities: What Happens Next
The exploitation of trusted vendor roles in the Qubole AWS security breach represents a critical inflection point for cloud supply chain security. The incident exposes a core limitation of modern enterprise defense: a company can invest heavily in hardening its own applications and endpoint fleets, yet remain vulnerable to complete data compromises through forgotten identity trust policies configured years prior.
+--------------------------------------------------------------------------------------------------+
| COMPARATIVE SUMMARY: TRADITIONAL VS. REALITY |
+--------------------------------------------------------------------------------------------------+
| Traditional Security Focus | Attack Reality in Qubole Campaign |
+---------------------------------------+----------------------------------------------------------+
| Patching vulnerable software code | Exploit valid, authorized cloud control plane APIs |
| Monitoring active user credentials | Exploited forgotten, unmonitored vendor IAM roles |
| Enforcing network perimeter firewalls | Breached environment entirely via cloud STS trust |
| Endpoint Detection & Response (EDR) | Zero on-host footprint; executed purely via APIs |
| Relying on external ID as a secret | External IDs bypassed when vendor account is hijacked|
+---------------------------------------+----------------------------------------------------------+This campaign demonstrates that the cloud control plane has become a primary target for supply chain attacks. Threat actors recognize that breaking into a single vendor's AWS account can provide immediate access to hundreds of enterprise targets, bypassing corporate firewalls, identity providers, and perimeter logging tools.
In the wake of this disclosure, regulatory and compliance scrutiny will inevitably increase. Under evolving cybersecurity disclosure mandates—including the U.S. Securities and Exchange Commission (SEC) cyber incident reporting rules and the European Union’s NIS2 directive—organizations that sustained bulk S3 exfiltration or exposure of customer PII face mandatory reporting timelines.
Enterprise risk assessments will no longer be able to treat vendor security questionnaires as sufficient verification: security teams will be required to demonstrate continuous, cryptographically bound, and network-restricted control over every external entity integrated into their cloud estate.
For cloud architecture and security leadership, the operational imperative is clear. The era of granting broad, permanent account-to-account trust relationships is over.
Organizations must immediately audit their environments for legacy integration roles, eliminate dormant trust relationships, enforce strict network conditions, and replace long-lived trust configurations with dynamic, ephemeral access architectures. As cloud environments become more interconnected, the boundaries of an organization's cloud perimeter are only as secure as the weakest vendor holding an assumed role in its environment.
Reference:
- https://www.securityweek.com/over-a-dozen-organizations-hit-in-qubole-supply-chain-attack/
- https://www.bleepingcomputer.com/news/security/hackers-exploit-trusted-aws-access-to-breach-multiple-cloud-environments/
- https://aviatrix.ai/threat-research-center/hackers-exploit-quboles-trusted-aws-access-breach-customer-accounts-steal-data/
- https://mlq.ai/news/wiz-finds-attackers-used-quboles-trusted-aws-access-to-steal-secrets-and-data-from-customer-clouds/
- https://www.scworld.com/brief/qubole-customers-targeted-in-aws-cross-account-access-attack
- https://www.reddit.com/r/SecOpsDaily/comments/1xrvjxc/trusted_by_default_qubole_crossaccount_access/
- https://daily.dev/posts/qubole-supply-chain-attack-exposed-aws-entra-id-and-okta-credentials-qnnrnrzix
- https://thehackernews.com/2026/11/hackers-exploit-quboles-trusted-aws.html
- https://brandefense.io/security-news/qubole-aws-access-breach/
- https://www.wiz.io/blog/qubole-cross-account-access-abused-in-the-wild
