Weaponizing SaaS Trust: How Attackers Abused Qubole's AWS Infrastructure to Drain Enterprise Secrets

Between October 14 and October 26, threat actors systematically leveraged compromised credentials from data lake vendor Qubole to breach customer cloud environments. By abusing AWS cross-account trust relationships, the adversary pivoted from Qubole’s core infrastructure directly into downstream enterprise accounts [0].

The intrusion targeted the core architectural pattern used by managed data platforms: the AWS Security Token Service (sts:AssumeRole) mechanism [0]. Rather than exploiting zero-day vulnerabilities in underlying operating systems, the threat actor exploited persistent, standing privileges left open in both active and abandoned enterprise deployments [0].

Cross-Account Attack Chain via Compromised Vendor Infrastructure

Step-by-step lateral progression from vendor account to downstream secret exfiltration

01 · Step 01

Vendor Credential Compromise

Adversary obtains valid credentials for Qubole platform account 805246085872.

02 · Step 02

Cross-Account AssumeRole

Actor executes sts:AssumeRole against customer roles using known External IDs.

03 · Step 03

Local Secret Harvesting

Adversary scrapes Lambda variables, Secrets Manager, and SSM Parameter Store.

04 · Step 04

Automated Credential Triage

TruffleHog validates harvested Okta tokens, Entra ID secrets, and AWS keys.

05 · Step 05

Unlogged Bulk S3 Exfiltration

Adversary drains entire S3 buckets where object-level logging was disabled.

Anatomy of the Cross-Account Trust Compromise

Cloud data platforms like Qubole require operational access to enterprise storage and compute resources [0]. Under the standard AWS multi-tenant delegated administration model, the customer provisions an IAM role containing specific resource permissions [0]. The role attaches a trust policy allowing Qubole’s primary AWS account (805246085872) to assume the identity via the sts:AssumeRole API [0].

Security researchers from Wiz and Sentra discovered that attackers obtained valid credentials belonging to this central Qubole account [0]. Armed with these credentials, the adversary systematically sent AssumeRole requests to downstream customer tenants [0]. Every targeted IAM role required a shared identifier known as an ExternalId to prevent the Confused Deputy problem [0].

Because the AWS ExternalId functions as a shared correlation string rather than a cryptographically protected secret, possession of vendor credentials nullified its defensive value [0]. Anyone with access to the role’s trust policy or deployment templates can inspect the identifier [0]. AWS accepts the AssumeRole call whenever the origin account matches the trust policy and supplies the expected string [0]. Because enterprises rarely revoke vendor roles after retiring SaaS software, the attacker assumed roles that had sat dormant for years [0].

Credential Harvesting and the TruffleHog Pipeline

Once inside a victim’s AWS account, the adversary avoided noisy compute provisioning or cryptomining. Telemetry indicates the attacker systematically inventoried centralized secrets engines and runtime configuration stores [0]. The operators focused on three primary targets:

• AWS Lambda: Reading plain-text environment variables embedded within serverless functions [0].
• AWS Secrets Manager: Extracting stored API keys, database connection strings, and partner credentials [0].
• AWS Systems Manager (SSM) Parameter Store: Pulling encrypted parameters and plaintext configurations [0].

The threat actors piped these recovered strings directly into TruffleHog, an open-source secret scanning engine [0]. This automated step rapidly separated valid, high-privilege tokens from stale strings [0]. Verified credentials included corporate AWS IAM access keys, Microsoft Entra ID application client secrets, and Okta tenant admin credentials [0].

By validating third-party identity credentials, the attacker established lateral footholds outside the targeted AWS perimeter [0]. A secondary wave of intrusions detected between October 8 and October 11 revealed direct usage of customer-generated static AWS access keys originally created for Qubole [0]. That separate campaign targeted environments that avoided IAM roles in favor of long-lived API keys [0].

Vector Characteristic	Static AWS Access Keys (Oct 8–11)	Cross-Account IAM Role (Oct 14–26)	Hardened Role with Conditional IP Binding
Authentication Credential	Long-lived AKIA... Key Pair	Temporary STS Session Token	Temporary Token with Source IP Check
Target Mechanism	Direct IAM User Authentication	sts:AssumeRole with External ID	sts:AssumeRole with aws:SourceIp check
Revocation Friction	Manual Key Rotation / Deletion	Trust Policy Deprecation	Centralized CIDR Restriction Block
Detection Signature	Anomaly in User Agent / Location	Call to 805246085872 outside AWS	Failed sts:AssumeRole (AccessDenied)
Average Blast Radius	Single Account / Assigned Rights	Entire Trust Scope + Lateral Stores	Bounded to Authorized Vendor Gateways

S3 Data Exfiltration and the Logging Deficit

Following the credential sweep, the adversary targeted enterprise Amazon S3 storage [0]. Rather than conducting refined, selective queries against specific analytical partitions, the attacker issued bulk listing calls (s3:ListBucket) followed by unconstrained recursive downloads [0]. In multiple confirmed compromises, entire operational S3 buckets were downloaded in a single session [0].

This phase exposed a critical logging deficit in enterprise environments [0]. AWS CloudTrail logs management events by default, which captures control-plane actions such as sts:AssumeRole, s3:CreateBucket, and s3:ListBuckets [0]. CloudTrail does not log data-plane actions—such as s3:GetObject—unless an organization explicitly configures S3 Data Events or enables S3 Server Access Logging [0].

AWS CloudTrail Management Events vs S3 Data Events

Forensic visibility divergence during unauthorized data exfiltration

Forensically Blind

CloudTrail Management Events (Default)

• • Logs sts:AssumeRole invocation and session parameters
• • Records s3:ListBucket execution across accounts
• • Misses s3:GetObject read operations
• • Leaves incident responders unable to determine breached records

Full Non-Repudiation

S3 Data Events & Server Access Logs (Opt-In)

• • Captures individual object keys during s3:GetObject calls
• • Records byte size, source IP, and IAM ARN per file
• • Enables precise data breach blast-radius scoping
• • Adds $0.10 per 100,000 recorded events to CloudTrail billing

Verdict ·Without data-plane logging, legal teams must treat every object in an accessed bucket as fully compromised.

Multiple compromised organizations could confirm that an attacker assumed their Qubole role and listed storage resources [0]. They could not determine which specific database dumps, analytical tables, or compliance archives the attacker downloaded [0]. From a regulatory perspective under GDPR, HIPAA, and SEC reporting mandates, the absence of negative evidence forces incident response teams to presume total exfiltration for all accessible buckets.

Architectural Tradeoffs in SaaS Vendor Integration

Enterprise teams routinely trade security boundaries for deployment velocity. Granting a managed SaaS data platform access via cross-account IAM roles avoids the operational overhead of running dedicated infrastructure inside customer VPCs. This pattern creates architectural single points of failure.

When organizations integrate third-party data processing engines, they face distinct isolation models:

Managed Cross-Account SaaS vs Dedicated Customer VPC Deployment

Evaluating attack surface expansion against ongoing operational burden

Managed Cross-Account (Qubole Pattern)

• + Zero underlying compute or cluster lifecycle management
• + Rapid onboarding via standardized CloudFormation role templates
• + Centralized platform upgrades managed entirely by the vendor

Blast Radius & Supply Chain Exposure

• – Vendor account compromise exposes all downstream customer roles
• – Static External IDs provide no identity protection once vendor keys leak
• – Stale, forgotten roles remain fully exploitable indefinitely

The Qubole breach demonstrates that cross-account role assumption without continuous network restriction creates an unmonitored back door [0]. While IAM roles eliminate the risk of leaking static secret keys from local hard drives, they concentrate trust into the vendor’s hosting account [0]. Once the vendor’s control tier is compromised, the attacker inherits identical permissions across hundreds of enterprise tenants simultaneously [0].

Immediate Remediation Protocols and Long-Term Role Hardening

Security and infrastructure teams must audit all current and historical third-party IAM trust configurations. Organizations that evaluated or utilized Qubole must execute immediate containment steps.

Immediate Incident Containment and Threat Hunting Sequence

Structured investigation path for AWS environments holding vendor trust relationships

01 · Step 01

1. Audit CloudTrail Logs

Query from Oct 1 onward for sts:AssumeRole calls originating from account 805246085872.

02 · Step 02

2. Sever Trust Relationships

Delete or strip trust policies from all IAM roles mapped to Qubole platform accounts.

03 · Step 03

3. Revoke Active STS Sessions

Attach an explicit inline deny policy with aws:TokenIssueTime conditions to kill active sessions.

04 · Step 04

4. Rotate Downstream Secrets

Invalidate Okta, Entra ID, and AWS keys stored in Lambda, SSM, or Secrets Manager.

Containment and Triage Sequence

1. Query CloudTrail for Adversary Sessions: Execute an Athena or CloudWatch Insights query across all regional trails from October 1 onward. Filter for eventName = "AssumeRole" where userIdentity.accountId = "805246085872" and the source IP address originates outside documented AWS data center ranges [0].
2. Immediate Trust Deprecation: Delete all IAM roles associated with Qubole. If workloads are actively running, modify the trust policy to remove account 805246085872 or insert a deny condition immediately [0].
3. Invalidate Active STS Sessions: Deleting an IAM role does not revoke previously issued short-lived tokens. Administrators must apply an inline policy to the role prior to deletion containing an explicit deny with an aws:TokenIssueTime condition older than the current timestamp.
4. Credential Rotation across Identity Providers: Assume all secrets stored within SSM Parameter Store, Secrets Manager, and Lambda environment variables accessible by the Qubole role are compromised [0]. Rotate all Okta API tokens, Microsoft Entra ID client credentials, and operational database strings immediately [0].

Long-Term Defensive Architecture

To prevent supply chain trust abuse across other SaaS integrations, platform engineering teams must enforce three guardrails:

• Enforce IP Restrictive Trust Conditions: Standardize on IAM policies that combine sts:AssumeRole trust with strict IP filtering. By adding an aws:SourceIp condition to the trust policy, the role can only be assumed when the call originates from known, static NAT gateways operated by the vendor.
• Implement Automated Dormancy Pruning: Deploy automated monitors that evaluate LastAccessedTime on all IAM roles containing external account IDs in their principal field. Any cross-account role with zero invocations over a 30-day window must be automatically disabled.
• Mandate S3 Data-Plane Logging on Sensitive Buckets: Enable CloudTrail S3 Data Events or S3 Server Access Logs for every bucket holding production data, proprietary analytics, or compliance records. Without granular GetObject logging, forensic teams cannot defend against breach notifications or limit liability during supply chain failures [0].