Attacker Rides Qubole's Trusted AWS Account Into Customer Environments, Steals Secrets and S3 Data

TL;DR

• what: An attacker used credentials for Qubole's own AWS account (805246085872) to assume vendor IAM roles in multiple customer AWS accounts from October 14 to October 26.
• impact: The attacker pulled secrets from Lambda environment variables, Secrets Manager and SSM Parameter Store, validated AWS, Entra ID and Okta credentials with TruffleHog, and copied S3 data, sometimes entire buckets.
• fix: Wiz advises rotating everything a compromised Qubole role could reach, revoking active sessions, removing unused Qubole roles, and restricting vendor trust policies by source IP or VPC endpoint; Qubole and its owner Idera had not published a statement at the time of writing.
• who: Any organization that has ever connected Qubole to AWS, including former customers whose Qubole IAM roles still trust the vendor account.

An attacker spent 12 days inside the AWS accounts of multiple Qubole customers, harvesting stored secrets and copying S3 data, without ever touching a customer credential to get in. Cloud security firm Wiz disclosed on November 9 that the attacker used credentials for AWS account 805246085872, the account Qubole's data lake platform uses to reach its customers, and assumed the IAM roles those customers had created to let Qubole in. The activity ran from October 14 to October 26. How the attacker obtained Qubole's credentials has not been disclosed, and Wiz did not say whether the credentials have been disabled or whether the activity has stopped.

Qubole, owned by Idera, had not posted a statement on the incident when The Hacker News checked on publication day. Sentra first spotted the activity across several of its own customers' environments and alerted Wiz.

Why the Roles Let the Attacker In

Qubole operates inside its customers' AWS accounts. To enable that, each customer creates an IAM role whose trust policy allows Qubole's AWS account to assume it. Every AssumeRole request must carry a matching External ID supplied by Qubole. Every request tied to the attacker included the correct External ID and was accepted.

That is the design working as intended. AWS's own guidance states the External ID is not a secret: anyone with access to the role can view it, it is logged in plain text in CloudTrail, and vendors and infrastructure-as-code repositories routinely store it. Once the attacker held credentials for the trusted account, the External ID check offered no real resistance.

⚠️ Unused roles were still open doors — Wiz found that most of the roles the attacker assumed were otherwise unused. Customers who had connected Qubole and moved on never removed the role or the trust relationship, so the vendor account kept standing access to their environments.

What the Attacker Did Inside

The objective was credentials first, data second. In the accounts Wiz examined, the attacker:

• Read environment variables from Lambda functions.
• Pulled secrets from AWS Secrets Manager.
• Read values from SSM Parameter Store.
• Ran the harvested material through TruffleHog to confirm which credentials worked, including the victims' own AWS access keys, Entra ID client secrets and Okta client credentials.
• Copied data out of S3 from any bucket the role could reach, without targeting specific data, in some cases downloading an entire bucket in one session.

The indiscriminate S3 collection points to opportunistic theft rather than an intelligence mission. Wiz has not linked the campaign to any other publicly reported activity and says the targeting does not match what state-backed groups usually pursue. The validated Entra ID and Okta secrets matter beyond AWS: they extend the blast radius into identity providers and every SaaS application those identities reach.

A Second, Separate Campaign

Qubole also lets customers connect using static AWS access keys instead of a role. From October 8 to October 11, an attacker used customers' own AWS access keys, which Wiz believes had been created for Qubole, and compromised a few of those cloud environments. Wiz has not linked this activity to the AssumeRole abuse, but it hits the same customer base through the same vendor integration.

Indicators Published by Wiz

Wiz's hunting guidance covers CloudTrail from October 1 onward in every AWS account that holds a Qubole role. Wiz observed legitimate Qubole traffic originating only from AWS address space, which makes source address the strongest single signal.

• Account: AssumeRole calls where userIdentity.accountId is 805246085872 and sourceIPAddress is not an AWS address.
• IAM principal AIDA3W7DIFLYOLTK63SFS: used only by the attacker in the accounts Wiz examined; any activity is suspect.
• IAM principal AIDAJYRRH5Y3A7AAJM2HW from a non-AWS address: attacker use began October 18, but Qubole's normal traffic also uses this principal.
• OVH-hosted attacker IPs: 57.129.54[.]120 and 2001:41d0:70d[:]7800::.
• Mullvad VPN IPs: 45.83.220[.]211, 185.209.199[.]73 and 89.37.63[.]175, shared with other VPN users, so a match alone is not proof.
• Role session names beginning with quiam-, such as quiam-enum.
• TruffleHog user agent on GetCallerIdentity calls from the IPs above, and the same user agent in identity provider sign-in logs.

The logging gap — CloudTrail management events record each AssumeRole and bucket listing, but not which S3 objects were read. That requires S3 data events or S3 server access logs. Several victims lacked them, so responders could not determine which objects the attacker had taken.

Researcher Mitigation Guidance

Wiz's recommendations center on treating any assumed Qubole role as a full credential compromise. Rotating a secret does not end sessions already issued, so Wiz pairs rotation of every secret, parameter and Lambda environment variable the role could reach with revocation of the role's active sessions. Beyond the incident, Wiz recommends removing Qubole roles that are no longer needed, replacing the account-wide :root principal in trust policies with Qubole's specific IAM principal where supported, and adding aws:SourceIp or aws:SourceVpce conditions tied to the vendor's documented network ranges. On that last point Wiz was blunt: "a source IP condition alone would have blocked every role assumption we observed."

Wiz also flags overbroad vendor permissions as a root cause. Qubole's own setup guide includes a sample S3 policy granting read access to every bucket in the account, and vendor roles commonly receive Lambda configuration, Secrets Manager, SSM and wide S3 read rights for convenience. Wiz further recommends rotating the External ID after an incident, using distinct values per role, and alerting on vendor-account AssumeRole requests that arrive through VPN infrastructure.

RedEye Assessment

This is a supply chain compromise without a poisoned package. The trusted artifact was a cross-account trust policy, and it was trusted by organizations that had long since stopped using the product. The External ID, widely treated as a security boundary, functioned as a routing label. Expect attackers to repeat this pattern against other SaaS platforms that hold standing AssumeRole access into customer clouds, and expect the same gaps to determine impact: dormant vendor roles, :root trust principals, no network conditions, broad S3 and secrets permissions, and missing S3 data event logging. Until Qubole or Idera explains how account 805246085872 was compromised and confirms containment, any organization with a Qubole trust relationship should treat its exposure as unresolved. RedEye can assess your third-party cloud trust relationships, review CloudTrail for these indicators, and scope what a compromised vendor role could have reached.

Originally published on RedEye Threat Intelligence.