Qubole Supply Chain Attack: Over a Dozen Organizations Hit via Compromised IAM Credentials — Detection and Remediation Guide | Security Arsenal

In early 2026, threat actors leveraged compromised IAM credentials associated with Qubole — a cloud-native data pipeline and analytics platform — to gain unauthorized access to customer environments and exfiltrate sensitive data including secrets, API keys, environment variables, and credentials. More than a dozen organizations have been confirmed as victims, and the full scope of the compromise is still being investigated.

This is not a theoretical threat. This is an active, in-the-wild supply chain compromise targeting organizations that rely on Qubole for data pipeline orchestration and analytics. If your organization uses Qubole — or any similar cloud data platform with IAM integration — the blast radius of this attack should be a wake-up call. Stolen environment variables and service account credentials can serve as initial access vectors for lateral movement, privilege escalation, and long-term persistence across your cloud infrastructure.

The attack underscores a fundamental challenge in modern cloud security: your security posture is only as strong as the weakest link in your software supply chain. When a third-party SaaS provider's IAM credentials are compromised, every customer that has integrated that platform into their environment inherits the risk.

Technical Analysis: How the Attack Works

Attack Chain Overview

Based on the available reporting, the attack unfolded through the following sequence:

Initial Compromise: Threat actors obtained IAM credentials associated with Qubole's infrastructure. The exact method of credential compromise has not been fully disclosed, but supply chain attacks of this nature typically involve phishing, insider threats, compromised CI/CD pipelines, or exploitation of exposed secrets in public repositories.
Lateral Access via Trusted Integration: Using the compromised Qubole IAM credentials, attackers accessed customer environments that had granted Qubole platform access to their cloud resources. Qubole's architecture requires customers to configure IAM roles, access keys, and trust relationships to enable data pipeline orchestration — effectively creating a bridge between the Qubole control plane and the customer's cloud environment.
Data Exfiltration: With access established, the attackers systematically harvested:
- Secrets and API keys stored in environment variables used by Qubole-managed data pipelines
- Service account credentials used for data source authentication
- Configuration files containing database connection strings, storage bucket access keys, and third-party API tokens
- Customer files stored in cloud storage buckets accessible via the Qubole-configured IAM roles
Downstream Exploitation: The stolen credentials and secrets provide attackers with persistent access vectors that can be used for further compromise even after the initial Qubole breach is detected and remediated.

Why This Attack Is Particularly Dangerous

The Qubole compromise illustrates several critical risks inherent to SaaS data platforms:

Overprivileged IAM Roles: Many organizations configure Qubole IAM roles with broad permissions (e.g., s3:*, secretsmanager:GetSecretValue, sts:AssumeRole) to avoid pipeline failures. This creates a large attack surface when those roles are compromised.
Environment Variable Exposure: Data pipeline platforms frequently pass credentials, connection strings, and API keys as environment variables to job execution containers. An attacker with access to the control plane can read these variables without ever touching the underlying host.
Trust Relationship Abuse: Customers establish trust policies that allow Qubole's service accounts to assume roles in their AWS/Azure/GCP environments. If Qubole's side of the trust is compromised, that trust relationship becomes an attacker's highway into your cloud.
Cascading Credential Compromise: The secrets stolen from Qubole environments can be used to pivot to databases, storage accounts, CI/CD systems, and other SaaS platforms — far beyond the initial blast radius.

Affected Organizations

At least a dozen organizations have been confirmed as victims. The identities of all affected organizations have not been publicly disclosed, but the impact spans multiple industries that rely on Qubole for data engineering and analytics workloads. Any organization that has integrated Qubole into their cloud data infrastructure should assume potential exposure and initiate an incident response assessment.

Exploitation Status

This is confirmed active exploitation in the wild. This is not a proof-of-concept or theoretical vulnerability — attackers have successfully compromised IAM credentials and used them to access and steal customer data across multiple organizations. There is no CVE associated with this incident as it represents a credential compromise and trust abuse scenario rather than a software vulnerability.

Detection and Response

If your organization uses Qubole, you need to hunt for indicators of compromise across your cloud environment, your identity provider logs, and your network telemetry. The following detections target the specific behaviors associated with this attack: unauthorized use of IAM credentials, anomalous API calls to secrets management services, and bulk data access patterns consistent with exfiltration.

SIGMA Rules

YAML

---
title: Anomalous IAM Role Assumption from External Service
description: Detects AssumeRole API calls from external IP addresses or unusual user agents that could indicate compromised third-party service credentials being used from attacker infrastructure.
references:
  - https://www.securityweek.com/over-a-dozen-organizations-hit-in-qubole-supply-chain-attack/
  - https://attack.mitre.org/techniques/T1550/
  - https://attack.mitre.org/techniques/T1078.004/
author: Security Arsenal
date: 2026/04/06
status: experimental
id: 8f2a1b3c-4d5e-6f7a-8b9c-0d1e2f3a4b5c
tags:
  - attack.credential_access
  - attack.t1550
  - attack.t1078.004
  - attack.initial_access
logsource:
  product: aws
  service: cloudtrail
detection:
  selection:
    eventName: AssumeRole
  filter_known_ips:
    sourceIPAddress:
      - '*.qubole.com'
      - 'internal_known_ranges'
  condition: selection and not filter_known_ips
falsepositives:
  - Legitimate cross-account role assumptions from new IP ranges
  - Qubole infrastructure changes (verify with vendor before alerting)
level: high
---
title: Bulk Secrets Manager Access via Assumed Role
description: Detects high-volume GetSecretValue or ListSecrets API calls via an assumed IAM role, indicating potential mass secrets harvesting consistent with supply chain credential theft.
references:
  - https://www.securityweek.com/over-a-dozen-organizations-hit-in-qubole-supply-chain-attack/
  - https://attack.mitre.org/techniques/T1552/
author: Security Arsenal
date: 2026/04/06
status: experimental
id: 2b3c4d5e-6f7a-8b9c-0d1e-2f3a4b5c6d7e
tags:
  - attack.credential_access
  - attack.t1552.001
  - attack.t1552.004
logsource:
  product: aws
  service: cloudtrail
detection:
  selection:
    eventName:
      - GetSecretValue
      - ListSecrets
      - DescribeSecret
      - BatchGetSecretValue
  filter_service_roles:
    userIdentity.type: AssumedRole
    userIdentity.arn|contains:
      - 'qubole'
      - 'Qubole'
      - 'data-pipeline'
  condition: selection and filter_service_roles
falsepositives:
  - Normal data pipeline secret retrieval during job execution
  - Baseline the expected call volume per role before enabling alerting
level: high
---
title: Suspicious S3 Bulk Download via Third-Party IAM Role
description: Detects mass S3 GetObject calls via assumed roles associated with third-party data platforms, potentially indicating data exfiltration through compromised SaaS credentials.
references:
  - https://www.securityweek.com/over-a-dozen-organizations-hit-in-qubole-supply-chain-attack/
  - https://attack.mitre.org/techniques/T1567/
  - https://attack.mitre.org/techniques/T1530/
author: Security Arsenal
date: 2026/04/06
status: experimental
id: 3c4d5e6f-7a8b-9c0d-1e2f-3a4b5c6d7e8f
tags:
  - attack.exfiltration
  - attack.t1567
  - attack.collection
  - attack.t1530
logsource:
  product: aws
  service: cloudtrail
detection:
  selection:
    eventName: GetObject
    userIdentity.type: AssumedRole
    userIdentity.sessionContext.sessionIssuer.type: Role
  filter_qubole_arn:
    userIdentity.arn|contains:
      - 'qubole'
      - 'Qubole'
  condition: selection and filter_qubole_arn
falsepositives:
  - Normal data pipeline read operations
  - Correlate with baseline data transfer volumes per IAM role
level: medium

KQL Hunt Query — Microsoft Sentinel / Defender

KQL — Microsoft Sentinel / Defender

// Hunt for anomalous IAM credential usage and secrets access patterns
// consistent with the Qubole supply chain compromise.
// Requires CloudTrail logs ingested into Sentinel via AWS connector or CEF.

let lookback = 14d;
let knownQuboleIPs = dynamic(["203.0.113.0/24", "198.51.100.0/24"]); // Replace with actual Qubole egress IPs from vendor documentation

// Part 1: Detect AssumeRole calls from unusual source IPs
AWSCloudTrail
| where TimeGenerated > ago(lookback)
| where EventName == "AssumeRole"
| where UserIdentityArn contains "qubole" or SessionMfaAuthenticated == false
| extend SourceIP = tostring(SourceIpAddress)
| where SourceIP !startswith "10." and SourceIP !startswith "172." and SourceIP !startswith "192.168."
| project TimeGenerated, EventName, UserIdentityArn, SourceIpAddress, UserAgent, RoleSessionName = tostring(parse_json(RequestParameters).roleSessionName)
| summarize AssumeRoleCount = count(), DistinctIPs = dcount(SourceIpAddress) by UserIdentityArn, SourceIpAddress, bin(TimeGenerated, 1h)
| where DistinctIPs > 2 or AssumeRoleCount > 50
| sort by TimeGenerated desc;

// Part 2: Detect mass secrets retrieval via assumed roles
AWSCloudTrail
| where TimeGenerated > ago(lookback)
| where EventName in ("GetSecretValue", "ListSecrets", "BatchGetSecretValue", "DescribeSecret")
| where UserIdentityType == "AssumedRole"
| summarize SecretsAccessCount = count(), DistinctSecrets = dcount(tostring(parse_json(RequestParameters).secretId)) by UserIdentityArn, SourceIpAddress, bin(TimeGenerated, 1h)
| where SecretsAccessCount > 20 or DistinctSecrets > 10
| sort by SecretsAccessCount desc;

// Part 3: Detect bulk S3 GetObject calls from assumed roles (exfil pattern)
AWSCloudTrail
| where TimeGenerated > ago(lookback)
| where EventName == "GetObject"
| where UserIdentityType == "AssumedRole"
| extend BucketName = tostring(parse_json(RequestParameters).bucketName)
| summarize ObjectDownloads = count(), DistinctObjects = dcount(tostring(parse_json(RequestParameters).key)) by UserIdentityArn, BucketName, SourceIpAddress, bin(TimeGenerated, 1h)
| where ObjectDownloads > 100
| sort by ObjectDownloads desc;

Velociraptor VQL — Endpoint Hunt for Stolen Credential Artifacts

VQL — Velociraptor

-- Hunt for evidence of environment variable harvesting or credential file access
-- on hosts running Qubole agents or data pipeline execution environments
-- Deploy as a hunt across Linux-based data pipeline worker nodes

SELECT 
    Pid,
    Name,
    CommandLine,
    Exe,
    Username,
    CreateTime,
    Environ
FROM pslist()
WHERE CommandLine =~ '(?i)(qubole|data.?pipeline|spark|hadoop)'
   OR Name =~ '(?i)(qds|qubole)'

-- Hunt for suspicious reads of credential files
SELECT 
    FullPath,
    Size,
    Mtime,
    Atime,
    Mode
FROM glob(globs=[
    '/home/*/.aws/credentials',
    '/home/*/.aws/config',
    '/root/.aws/credentials',
    '/opt/qubole/**/*credential*',
    '/opt/qubole/**/*secret*',
    '/etc/qubole/**/*.conf',
    '/tmp/*env*',
    '/proc/*/environ'
])
ORDER BY Atime DESC

-- Check for unexpected network connections from pipeline processes
SELECT 
    Pid,
    Name,
    LocalAddr,
    LocalPort,
    RemoteAddr,
    RemotePort,
    Status,
    Family
FROM netstat()
WHERE Name =~ '(?i)(qds|qubole|spark|java)'
  AND Status == 'ESTABLISHED'
  AND RemoteAddr !~ '^(10\.|172\.(1[6-9]|2[0-9]|3[01])\.|192\.168\.)'

Remediation and Hardening Script

Bash / Shell

#!/bin/bash
# Qubole Supply Chain Compromise - Emergency Response Script
# Run this on your cloud management workstation with appropriate IAM permissions
# This script helps you audit, rotate, and harden credentials associated with Qubole

set -euo pipefail

echo "=========================================="
echo " Qubole Supply Chain Attack - IR Script"
echo " $(date -u '+%Y-%m-%d %H:%M:%S UTC')"
echo "=========================================="

# --- STEP 1: Identify all IAM roles with Qubole trust relationships ---
echo ""
echo "[STEP 1] Identifying IAM roles with Qubole-related trust policies..."
aws iam list-roles --query 'Roles[?contains(AssumeRolePolicyDocument, `qubole`) || contains(AssumeRolePolicyDocument, `Qubole`)].{RoleName:RoleName,Arn:Arn,CreateDate:CreateDate}' --output table 2>/dev/null || echo "  [!] No Qubole-related roles found by name. Checking all trust policies..."

# Broader search - list all roles and check trust policies for external account IDs
aws iam list-roles --query 'Roles[].RoleName' --output text | tr '\t' '\n' | while read -r role; do
    trust_policy=$(aws iam get-role --role-name "$role" --query 'Role.AssumeRolePolicyDocument' --output json 2>/dev/null)
    if echo "$trust_policy" | grep -qi "external\|qubole\|Qubole\|052366595310"; then
        echo "  [FOUND] Role: $role"
        echo "$trust_policy" | python3 -m json.tool 2>/dev/null || echo "$trust_policy"
        echo "---"
    fi
done

# --- STEP 2: List all access keys for Qubole-related IAM users ---
echo ""
echo "[STEP 2] Listing access keys for potential Qubole-related IAM users..."
aws iam list-users --query 'Users[?contains(UserName, `qubole`) || contains(UserName, `Qubole`) || contains(UserName, `data-pipeline`)].{UserName:UserName,CreateDate:CreateDate}' --output table

aws iam list-users --query 'Users[?contains(UserName, `qubole`) || contains(UserName, `Qubole`)].UserName' --output text | tr '\t' '\n' | while read -r user; do
    echo "  Access keys for $user:"
    aws iam list-access-keys --user-name "$user" --query 'AccessKeyMetadata[].{AccessKeyId:AccessKeyId,Status:Status,CreateDate:CreateDate}' --output table
done

# --- STEP 3: Check CloudTrail for suspicious API calls ---
echo ""
echo "[STEP 3] Checking CloudTrail for suspicious AssumeRole activity (last 14 days)..."
aws cloudtrail lookup-events \
    --lookup-attributes AttributeKey=EventName,AttributeValue=AssumeRole \
    --start-time "$(date -u -d '14 days ago' +%Y-%m-%dT%H:%M:%S)" \
    --end-time "$(date -u +%Y-%m-%dT%H:%M:%S)" \
    --max-results 50 \
    --query 'Events[].{Time:EventTime,User:Username,Resource:Resources[0].ResourceName}' \
    --output table 2>/dev/null || echo "  [!] CloudTrail lookup requires appropriate permissions"

# --- STEP 4: Audit Secrets Manager access patterns ---
echo ""
echo "[STEP 4] Checking Secrets Manager access events (last 14 days)..."
aws cloudtrail lookup-events \
    --lookup-attributes AttributeKey=EventName,AttributeValue=GetSecretValue \
    --start-time "$(date -u -d '14 days ago' +%Y-%m-%dT%H:%M:%S)" \
    --max-results 50 \
    --query 'Events[].{Time:EventTime,User:Username}' \
    --output table 2>/dev/null || echo "  [!] CloudTrail lookup requires appropriate permissions"

# --- STEP 5: Deactivate compromised access keys ---
echo ""
echo "[STEP 5] IMPORTANT: Rotate all credentials associated with Qubole"
echo "  The following actions should be performed manually after verification:"
echo ""
echo "  a) Deactivate and delete old access keys:"
echo "     aws iam update-access-key --access-key-id <KEY_ID> --status Inactive --user-name <USER>"
echo "     aws iam delete-access-key --access-key-id <KEY_ID> --user-name <USER>"
echo ""
echo "  b) Create new access keys:"
echo "     aws iam create-access-key --user-name <USER>"
echo ""
echo "  c) Update Qubole platform configuration with new credentials"
echo ""
echo "  d) Rotate all secrets stored in Secrets Manager that were accessible via Qubole roles:"
echo "     aws secretsmanager list-secrets --query 'SecretList[].Name' --output text"
echo "     aws secretsmanager rotate-secret --secret-id <SECRET_NAME>"
echo ""

# --- STEP 6: Apply least-privilege policy recommendations ---
echo ""
echo "[STEP 6] Hardening Recommendations:"
echo ""
echo "  1. Add External ID condition to all Qubole trust policies:"
echo '     "Condition": {"StringEquals": {"sts:ExternalId": "your-unique-external-id"}}'
echo ""
echo "  2. Restrict source IP in trust policies:"
echo '     "Condition": {"IpAddress": {"aws:SourceIp": ["QUBOLE_IP_RANGES"]}}'
echo ""
echo "  3. Scope IAM policies to minimum required actions (remove wildcards)"
echo ""
echo "  4. Enable CloudTrail data events for S3 and Secrets Manager"
echo ""
echo "  5. Set up AWS Config rules for IAM policy compliance monitoring"
echo ""
echo "  6. Rotate ALL environment variables and credentials used in Qubole pipelines"
echo ""

echo "=========================================="
echo " Script complete. Review output and take"
echo " manual remediation actions as directed."
echo "=========================================="

Remediation: What You Must Do Now

If your organization uses Qubole, treat this as an active incident until you can prove otherwise. The following steps should be executed immediately and in order.

Immediate Actions (Within 24 Hours)

Inventory All Qubole Integrations: Identify every IAM role, service account, access key, and trust relationship associated with Qubole across all cloud providers (AWS, Azure, GCP). Do not assume you know where they all are — check every account, every subscription, every project.
Rotate All Credentials: Rotate every IAM access key, API key, service account credential, and secret that was accessible through or stored within Qubole-managed pipelines. This includes:
- AWS access keys assigned to Qubole-configured IAM users
- Secrets stored in AWS Secrets Manager, Azure Key Vault, or GCP Secret Manager that were retrieved by Qubole pipelines
- Database connection strings and credentials passed as environment variables
- Third-party API keys configured in Qubole cluster or pipeline settings
Review Trust Policies: Audit all IAM trust policies that allow Qubole to assume roles in your environment. Add ExternalId conditions if not already present. Restrict source IP ranges to known Qubole egress IPs if feasible.
Check CloudTrail / Audit Logs: Review the last 30 days of cloud audit logs for anomalous activity from Qubole-associated IAM roles. Look for AssumeRole calls from unexpected source IPs, bulk GetSecretValue calls, mass S3 GetObject operations, and any API calls outside normal business hours.

Short-Term Actions (Within 7 Days)

Apply Least Privilege: Review and reduce the permissions granted to Qubole IAM roles. Remove wildcard permissions (s3:*, secretsmanager:*). Scope policies to specific buckets, specific secrets, and specific actions only.
Enable Data Event Logging: If not already enabled, turn on CloudTrail data events for S3 (object-level logging) and Secrets Manager. Without data events, you cannot see which specific secrets were read or which objects were downloaded.
Implement Secrets Manager Alternatives: Stop passing credentials as environment variables in data pipelines. Migrate to runtime secrets retrieval using AWS IAM Roles for Service Accounts (IRSA), Azure Managed Identities, or GCP Workload Identity Federation so that credentials are never stored in pipeline configurations.
Contact Qubole Support: Engage with Qubole (now part of a larger organization) to determine whether your organization was affected by this specific compromise. Request a formal incident notification if applicable.

Long-Term Hardening (Within 30 Days)

Supply Chain Risk Assessment: Conduct a formal review of all third-party SaaS platforms that have IAM trust relationships or credential access to your cloud environment. Qubole is the target today — tomorrow it could be any other vendor with similar access patterns.
Implement Cloud Security Posture Management (CSPM): Deploy CSPM tooling to continuously monitor IAM trust policies, detect overprivileged roles, and alert on credential access anomalies.
Establish Secrets Rotation Automation: Implement automated secrets rotation using AWS Secrets Manager rotation, HashiCorp Vault, or equivalent tooling. Manual rotation is error-prone and too slow for supply chain incident response.
Network Segmentation: Ensure that data pipeline execution environments are network-segmented from production systems. An attacker using compromised pipeline credentials should not be able to reach your production databases or internal services directly.

The Broader Lesson: Third-Party IAM Is Your IAM

The Qubole supply chain attack is not an isolated incident — it is a pattern. Attackers increasingly target the connective tissue between organizations: the IAM trust relationships, API integrations, and credential sharing arrangements that make modern cloud architectures work. When a SaaS provider's credentials are compromised, every customer that has granted that provider access inherits the breach.

The uncomfortable truth is that most organizations grant third-party data platforms far more access than they need. Broad IAM roles, long-lived access keys, and environment variables stuffed with plaintext credentials are the norm, not the exception. Every one of those trust relationships is a potential attack vector.

If this incident does not prompt a comprehensive review of your third-party IAM integrations, the next one will.

Related Resources

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

Qubole Supply Chain Attack: Over a Dozen Organizations Hit via Compromised IAM Credentials — Detection and Remediation Guide