NEWS

Hackers Abuse Trusted Qubole AWS Access to Breach Multiple Cloud Environments

Attackers used compromised Qubole IAM credentials to assume cross-account roles and steal data from dozens of customers' AWS environments in October.

Dylan H.

News Desk

November 10, 2026
2 min read
Hackers Abuse Trusted Qubole AWS Access to Breach Multiple Cloud Environments

Overview

A threat actor used compromised IAM credentials belonging to Qubole, an enterprise big data and analytics platform, to access and exfiltrate data from multiple customers' AWS environments. The campaign ran from October 14 to 26, 2026 and affected tens of companies whose AWS IAM roles were configured to trust Qubole's AWS account. BleepingComputer reported the findings on 2026-11-10.

Wiz began investigating after Sentra reported suspicious activity in customer environments, and Mandiant also took part. BleepingComputer found no public statement from Qubole. How the Qubole credentials were first compromised has not been disclosed.

Attack Chain

  1. Compromise two Qubole IAM users.
  2. Assume unused cross-account roles in customer AWS accounts that trusted Qubole.
  3. Survey cloud resources and pull secrets from AWS Secrets Manager, SSM Parameter Store and Lambda environment variables.
  4. Validate discovered AWS keys, Microsoft Entra ID client secrets and Okta credentials with TruffleHog.
  5. Download data from accessible S3 buckets, opportunistically rather than against specific targets.

Impact

  • Sentra confirmed dozens of victims and millions of files stolen from one customer.
  • The attacker collected about 100 passwords and keys in seven minutes.
  • Secrets for Entra ID and Okta raise the risk of follow-on identity compromise beyond AWS.

Recommendations

  1. Review CloudTrail logs from October 1 onward for access originating from Qubole's AWS account.
  2. Investigate related Secrets Manager, SSM and S3 access.
  3. Rotate exposed credentials and revoke active role sessions.
  4. Remove unused third-party integrations. For those you keep, restrict role permissions, trusted principals and permitted source networks, and require an ExternalId condition.
  5. Move secrets out of Lambda environment variables where possible.

Why It Matters

This is a classic third-party trust problem: the customers' own controls were not breached. Cross-account roles that nobody used still worked, which is why periodic review of IAM trust policies matters.

Sources