As reported by BleepingComputer, attackers compromised IAM credentials belonging to the Qubole big data platform and used them to assume cross-account roles across dozens of customer AWS environments — exfiltrating millions of files and hundreds of secrets in a matter of days. The campaign, active from October 14–26, 2026, was investigated jointly by Wiz, Sentra, and Mandiant.

Cloud Security Alert: As reported by BleepingComputer, attackers compromised IAM credentials belonging to the Qubole big data platform and used them to assume cross-account roles across dozens of customer AWS environments — exfiltrating millions of files and hundreds of secrets in a matter of days.

This incident is a textbook example of what cloud security practitioners have warned about for years: third-party trust relationships are unmonitored blast radius multipliers. When you grant a cross-account IAM role to a SaaS provider, you are effectively extending your security perimeter to include that vendor's identity hygiene. If their IAM users are compromised, the attacker inherits every permission you delegated — and in most environments, that delegation was configured years ago and never revisited.

Why This Attack Pattern Is Dangerous

The attacker didn't need a zero-day. They didn't need malware. They needed one compromised IAM user in a trusted third-party account — and from there, AWS's own sts:AssumeRole API did the rest. The trust chain is the exploit.

What makes this particularly insidious is the invisibility of the exposure. Most organizations have no inventory of which external AWS accounts they trust via cross-account roles. These roles are typically created during initial SaaS onboarding, granted broad permissions to "make integration easier," and then forgotten. There is rarely a revocation review process. The roles sit dormant — exactly as observed in this attack, where the attacker specifically targeted unused roles that still carried their original broad permissions.

The attacker harvested secrets at a rate of 100 passwords and keys in seven minutes across one victim environment. That speed tells us the permissions were dangerously broad and completely unmonitored.

The Lateral Movement Playbook

The attack sequence Wiz described is now a standard cloud compromise playbook:

Why This Attack Pattern Is Dangerous
Assume role via pre-existing cross-account trust — no exploitation needed
Enumerate with ListBuckets, ListObjects, HeadObject — native AWS APIs, no detection by most SIEMs
Harvest secrets from Secrets Manager, SSM Parameter Store, and Lambda environment variables
Validate credentials with TruffleHog — automating discovery of AWS keys, Entra ID client secrets, and Okta credentials
Exfiltrate opportunistically from every accessible S3 bucket

Every step uses legitimate AWS API calls. Without dedicated cloud detection engineering, this traffic pattern blends into normal activity — especially when the assumed role hasn't been used recently, so there's no baseline to compare against.

Who Is Most at Risk

Any organization using third-party SaaS platforms that require cross-account AWS IAM roles is exposed. The highest-risk profiles include:

  • Data analytics and ML platforms (Qubole, Databricks, Snowflake partnerships) — these typically require broad S3 and compute permissions
  • Organizations with dormant cross-account roles — roles created for a pilot or evaluation that was never decommissioned
  • Environments without cloud security posture management (CSPM) — no visibility into trust policies or permission drift
  • Companies storing secrets in Lambda env vars or SSM Parameter Store without encryption access logging

Shield53 Recommendations

Immediate Actions (This Week)

  • Audit all cross-account trust relationships. Run aws iam list-roles across all accounts and inspect every TrustPolicy for Principal: AWS entries referencing external account IDs. Inventory every third-party trust relationship and validate it is still in active use.
  • Remove or restrict dormant roles. If a cross-account role hasn't been assumed in 90+ days (check CloudTrail AssumeRole events), revoke it. If the vendor relationship has ended, delete the role entirely.
  • Apply least-privilege to remaining trust roles. Replace broad s3:* or *:* permissions with explicit resource ARNs and read-only actions where possible. Use condition keys like aws:SourceAccount and sts:ExternalId to constrain role assumption.
  • Enable CloudTrail lake queries for AssumeRole events from external accounts and set alerts for any role assumption from account IDs not in your approved vendor list.

Strategic Actions (Next 30 Days)

  • Implement ExternalId enforcement. Every cross-account role should require a unique ExternalId that the third party must provide. This prevents confused-deputy attacks even if the vendor's IAM credentials are compromised.
  • Deploy secret scanning and rotation. Lambda environment variables should not contain long-lived credentials. Rotate any secrets exposed in Secrets Manager or Parameter Store and enforce automatic rotation policies.
  • Build detection rules for the observed TTPs: alert on ListBuckets followed by bulk GetObject calls from a single role session, TruffleHog user-agent patterns in VPC Flow Logs if egressing through a NAT gateway, and anomalous GetSecretValue volume from a single session.
  • Establish a quarterly third-party trust review process. Treat cross-account IAM roles like privileged access — require justification, owner assignment, and expiration dates.

The fundamental lesson here is not about Qubole specifically — it's about the systemic blind spot in how organizations manage third-party cloud trust. Every cross-account role is a door into your environment that you've handed the key to someone else. If you can't list every door, who holds the keys, and when they were last used, you are operating with an incomplete threat model. Fix the inventory first. Everything else follows.