Qubole Third-Party AWS Breach: Detecting and Remediating Trusted Cross-Account Access Abuse

Between October 14 and October 26, 2026, an attacker breached AWS accounts belonging to multiple customers of Qubole, the Idera-owned data lake platform, and exfiltrated stored secrets and data. According to cloud security firm Wiz, the attacker did not phish individual customers or exploit a flaw in AWS itself — they used credentials for the AWS account that Qubole's platform uses to reach into customer environments. How the attacker initially obtained those credentials has not been publicly disclosed, but the outcome is unambiguous: a single compromised vendor identity became a skeleton key into multiple downstream customer tenants.

This is the supply-chain pattern that keeps materializing in cloud environments, and it should be treated as an active incident-response trigger, not a news item to file away. If your organization runs Qubole — or any SaaS data platform that operates cross-account IAM roles, assumed roles, or static access keys inside your AWS accounts — you need to assume your trust relationships are being enumerated by adversaries right now and validate them accordingly.

Technical Analysis

What Happened

Based on the Wiz disclosure and reporting, the attack chain breaks down as follows:

Initial access (undisclosed): The attacker obtained credentials belonging to an AWS account operated by Qubole. This account holds trust relationships — almost certainly cross-account IAM roles or long-lived access keys — into customer AWS accounts, which is standard architecture for data lake platforms that must read from customer S3 buckets, write query results, and manage compute.
Pivot into customer accounts: Using Qubole's legitimate trusted access, the attacker assumed roles or used standing credentials in customer accounts. From CloudTrail's perspective, much of this activity can look like normal vendor automation unless you are explicitly baselining it.
Collection and exfiltration: The attacker harvested stored secrets — which in AWS environments typically means Secrets Manager (GetSecretValue), SSM Parameter Store (GetParameter/GetParameters), IAM access key enumeration (ListAccessKeys, CreateAccessKey), and environment variables from Lambda/ECS — and stole data from customer storage, most plausibly S3 (GetObject, ListBuckets, ListObjectsV2).

Why This Technique Is Dangerous

Third-party cross-account access defeats the most common cloud detections because:

The principal is expected. An assumed role from a known vendor account ID does not trip "anomalous principal" analytics unless you baseline behavior, not just identity.
Static vendor credentials often lack IP/session context. If Qubole's platform uses IAM user access keys rather than role assumption with session tags, activity can originate from anywhere without raising impossible-travel or ASN anomalies.
Secrets access is quiet. GetSecretValue calls are data events that many organizations never enabled in CloudTrail. Twelve days of dwell time (Oct 14–26) strongly suggests detection gaps in customer environments, not just in Qubole's.

Affected Parties

Qubole customers whose AWS accounts were connected to the Qubole platform via IAM roles or access keys during the October 14–26, 2026 window.
Any downstream systems whose credentials were stored in the breached accounts (database credentials, API keys, other SaaS tokens) — these must be treated as compromised and rotated.

Exploitation Status

Confirmed active exploitation in the wild. This is not theoretical. Multiple customer accounts were breached and data was stolen. No CVE applies — this is a credential-abuse and trust-relationship compromise, not a software vulnerability. The MITRE ATT&CK mapping is straightforward: T1078.004 (Valid Accounts: Cloud Accounts), T1552.004/T1552.005 (Credentials from Cloud Stores), T1530 (Data from Cloud Storage).

Detection & Response

The detections below target the observable behaviors of this campaign: cross-account role assumption from unexpected contexts, bulk secrets retrieval, access key manipulation, and data staging from S3. They are tuned to fire on deviations from vendor baselines, not on every legitimate vendor call.

Sigma Rules

YAML

---
title: AWS IAM Access Key Creation by Cross-Account or Assumed-Role Principal
id: 3c8e1a47-2b6d-4f59-a1c7-9d0e5b2f8a31
status: experimental
description: Detects creation of new IAM access keys by an assumed-role session or federated principal, consistent with persistence established after third-party credential abuse as seen in the Qubole AWS breach.
references:
  - https://thehackernews.com/2026/11/hackers-exploit-quboles-trusted-aws.html
  - https://attack.mitre.org/techniques/T1098/001/
author: Security Arsenal
date: 2026/11/12
tags:
  - attack.persistence
  - attack.t1098.001
  - attack.t1078.004
logsource:
  product: aws
  service: cloudtrail
detection:
  selection:
    eventSource: iam.amazonaws.com
    eventName:
      - CreateAccessKey
      - CreateLoginProfile
      - UpdateAccessKey
  filter_console_self:
    userIdentity.type: IAMUser
    sourceIPAddress|endswith: '.amazonaws.com'
  condition: selection and not filter_console_self
falsepositives:
  - Legitimate admin key rotation via assumed role; baseline expected operators and suppress known ARNs
level: high
---
title: AWS Bulk Secrets Retrieval from Secrets Manager or SSM Parameter Store
id: 6f2d9b15-8e4a-4c37-b920-1a5f7c3d6e94
status: experimental
description: Detects high-volume reads of stored secrets via Secrets Manager or SSM Parameter Store, matching the stored-secrets theft behavior reported in the Qubole customer account breaches. Tune the threshold to your environment baseline.
references:
  - https://thehackernews.com/2026/11/hackers-exploit-quboles-trusted-aws.html
  - https://attack.mitre.org/techniques/T1552/004/
  - https://attack.mitre.org/techniques/T1552/005/
author: Security Arsenal
date: 2026/11/12
tags:
  - attack.credential_access
  - attack.t1552.004
  - attack.t1552.005
logsource:
  product: aws
  service: cloudtrail
detection:
  selection:
    eventSource:
      - secretsmanager.amazonaws.com
      - ssm.amazonaws.com
    eventName:
      - GetSecretValue
      - BatchGetSecretValue
      - GetParameters
      - GetParametersByPath
  condition: selection
falsepositives:
  - Application bootstrap and CI/CD pipelines legitimately read secrets at deploy time; alert on burst volume, off-hours timing, or principals with no prior secrets-read history
level: medium
---
title: AWS AssumeRole from Unexpected External Account or Unusual Source
id: 91a4c6e2-5d7f-48b3-a206-4e8b1f9c3d57
status: experimental
description: Detects cross-account AssumeRole events where the calling account differs from the role-owning account. Review against an allowlist of approved vendor account IDs (e.g., Qubole platform accounts) to surface hijacked or rogue trust relationships.
references:
  - https://thehackernews.com/2026/11/hackers-exploit-quboles-trusted-aws.html
  - https://attack.mitre.org/techniques/T1078/004/
author: Security Arsenal
date: 2026/11/12
tags:
  - attack.initial_access
  - attack.t1078.004
logsource:
  product: aws
  service: cloudtrail
detection:
  selection:
    eventSource: sts.amazonaws.com
    eventName: AssumeRole
  filter_approved_vendors:
    userIdentity.accountId:
      - 'REPLACE_WITH_APPROVED_VENDOR_ACCOUNT_ID'
  condition: selection and not filter_approved_vendors
falsepositives:
  - Partner integrations and MSP tooling; maintain and version-control the approved external account ID list
level: high

KQL — Microsoft Sentinel (AWS CloudTrail via CommonSecurityLog / Syslog ingestion)

This hunt surfaces secrets-access bursts and IAM key manipulation grouped by caller identity — the two highest-fidelity behaviors from this breach. Adjust the threshold after 24 hours of baselining against your legitimate Qubole integration traffic.

KQL — Microsoft Sentinel / Defender

let lookback = 14d;
let SecretsEvents = CommonSecurityLog
| where TimeGenerated > ago(lookback)
| where DeviceVendor == "Amazon" or DeviceProduct has "CloudTrail"
| where Activity in ("GetSecretValue", "BatchGetSecretValue", "GetParameters", "GetParametersByPath", "CreateAccessKey", "ListAccessKeys")
| extend CallerIdentity = tostring(parse_json(AdditionalExtensions).userIdentity_arn);
SecretsEvents
| summarize EventCount = count(), DistinctTargets = dcount(DestinationHostName), FirstSeen = min(TimeGenerated), LastSeen = max(TimeGenerated)
    by CallerIdentity, SourceIP, Activity
| where EventCount > 25 or Activity in ("CreateAccessKey")
| sort by EventCount desc;
// Companion hunt: cross-account AssumeRole from non-baselined source IPs
CommonSecurityLog
| where TimeGenerated > ago(lookback)
| where Activity == "AssumeRole"
| extend SrcASN = tostring(parse_json(AdditionalExtensions).sourceIPAddress)
| summarize Assumptions = count(), DistinctIPs = dcount(SourceIP) by SourceUserName, SrcASN
| where DistinctIPs > 3
| sort by Assumptions desc

Velociraptor VQL — Hunt for Exposed Cloud Credentials on Endpoints

Qubole's platform credentials were stolen from somewhere — endpoints, build servers, or a vault with weak access controls. This artifact hunts for AWS credential material and recent CLI usage on Windows endpoints to find where long-lived cloud keys are sitting unprotected in your environment.

VQL — Velociraptor

-- Locate AWS credential files and recent AWS CLI secrets-access usage on endpoints
SELECT FullPath, Size, Mtime,
       parse_pe(file=FullPath) AS FileMeta
FROM glob(globs=[
  'C:/Users/*/.aws/credentials',
  'C:/Users/*/.aws/config',
  'C:/ProgramData/*/.aws/credentials'
])
WHERE Size > 0
UNION ALL
SELECT Exe AS FullPath, NULL AS Size, CreateTime AS Mtime, NULL AS FileMeta
FROM pslist()
WHERE CommandLine =~ 'aws (secretsmanager|ssm|iam) (get|create|list)'
   OR CommandLine =~ 'aws s3 (cp|sync)'

Remediation & Verification Script (Bash / AWS CLI)

Run this against every AWS account that had (or has) a Qubole trust relationship. It inventories cross-account trust policies, finds access keys older than 90 days, and flags principals that read secrets during the incident window.

Bash / Shell

#!/bin/bash
# Qubole third-party trust audit — run per AWS account, per region as needed
set -euo pipefail
ACCOUNT_ID=$(aws sts get-caller-identity --query Account --output text)
echo "[*] Auditing account ${ACCOUNT_ID}"

# 1. List all IAM roles with cross-account trust policies (external account IDs in Principal)
echo "[*] Roles trustable by EXTERNAL AWS accounts:"
aws iam list-roles --query 'Roles[].RoleName' --output text | tr '\t' '\n' | while read -r ROLE; do
  TRUST=$(aws iam get-role --role-name "$ROLE" --query 'Role.AssumeRolePolicyDocument' --output json)
  if echo "$TRUST" | grep -q "\"AWS\"" && ! echo "$TRUST" | grep -q "${ACCOUNT_ID}"; then
    echo "  !! $ROLE"
    echo "$TRUST" | grep -o 'arn:aws:iam::[0-9]*:[^"]*' | sort -u
  fi
done

# 2. Find IAM users with access keys older than 90 days (static vendor credentials)
echo "[*] Access keys older than 90 days:"
aws iam list-users --query 'Users[].UserName' --output text | tr '\t' '\n' | while read -r USER; do
  aws iam list-access-keys --user-name "$USER" \
    --query "AccessKeyMetadata[?Status=='Active'].[AccessKeyId,CreateDate]" --output text \
  | while read -r KEY CREATED; do
      AGE=$(( ( $(date +%s) - $(date -d "$CREATED" +%s) ) / 86400 ))
      [ "$AGE" -gt 90 ] && echo "  !! $USER  $KEY  age=${AGE}d — ROTATE NOW"
    done
done

# 3. Audit CloudTrail for secrets access and key creation in the incident window
echo "[*] CloudTrail lookup: secrets reads and key creation Oct 14-26 2026:"
aws cloudtrail lookup-events \
  --start-time 2026-10-14T00:00:00Z --end-time 2026-10-27T00:00:00Z \
  --lookup-attributes AttributeKey=EventName,AttributeValue=GetSecretValue \
  --max-results 50 --query 'Events[].{User:Username,Time:EventTime}' --output table
aws cloudtrail lookup-events \
  --start-time 2026-10-14T00:00:00Z --end-time 2026-10-27T00:00:00Z \
  --lookup-attributes AttributeKey=EventName,AttributeValue=CreateAccessKey \
  --query 'Events[].{User:Username,Time:EventTime}' --output table

Remediation

There is no patch for this breach — remediation is architectural and procedural. Prioritize in this order:

Immediately engage Qubole/Idera and Wiz guidance. Confirm whether your account is among those breached. Idera should provide affected-customer notification; demand the specific role ARNs, access key IDs, and source IPs involved. Monitor https://www.qubole.com and Idera security advisories for official guidance.
Rotate everything the trusted role could touch. Any secret readable by Qubole's role — Secrets Manager entries, SSM parameters, database credentials, S3-accessible key material — must be treated as compromised and rotated. Do not selectively rotate; the attacker had twelve days.
Replace static vendor credentials with scoped role assumption. If Qubole (or any vendor) connects via long-lived IAM user access keys, migrate to cross-account IAM role assumption with: an ExternalId (prevents confused-deputy abuse), session duration ≤ 1 hour, and a deny-by-default permission policy limited to the exact buckets and actions the platform needs.
Enforce source-IP and service conditions on vendor trust policies. Where the vendor publishes egress IP ranges, add aws:SourceIp conditions to the trust policy. Where they assume via their own AWS account, add aws:PrincipalAccount and aws:PrincipalArn conditions.
Enable CloudTrail data events for secrets and S3. Management events alone will not show GetSecretValue or GetObject in all configurations. Enable data events for Secrets Manager, SSM, and your sensitive S3 buckets, and ship them to a tamper-evident, separate logging account.
Alert on vendor behavior deviation, not vendor identity. Baseline your Qubole role's normal call volume, source ASNs, and API mix. A vendor principal suddenly calling ListBuckets, GetSecretValue, or CreateAccessKey outside its normal pattern is a page-worthy event.
Audit all third-party trust relationships — not just Qubole. Every SaaS platform with standing access into your AWS accounts is this same blast radius. Inventory them, apply least privilege, and require vendors to document their own credential security.

The uncomfortable lesson of this breach is that your cloud perimeter is only as strong as your least-secure trusted vendor. The attackers didn't break AWS — they walked through a door your organization legitimately opened. Close it, narrow it, and watch it.

Related Resources

Security Arsenal Penetration Testing Services AlertMonitor Platform Book a SOC Assessment vulnerability-management Intel Hub