Hackers used a stolen Qubole AWS key to raid customer cloud accounts

The attacker did not need any of the victims' own credentials to get in. For about 12 days in October, an attacker moved through the AWS accounts of Qubole customers using credentials that belonged to Qubole itself, and entered through roles the customers had built so that Qubole could get in.

Cloud security firm Wiz disclosed the campaign on November 9. Sentra, a data security company, spotted it first and reported it to Wiz, which investigated with Sentra and Mandiant. Wiz observed a threat actor using IAM credentials from an AWS account associated with Qubole between October 14 and October 26, 2026, to assume IAM roles that customers had created to trust Qubole's account.

Qubole, a data lake platform owned by Idera, operates within its customers' AWS accounts. To let it in, a customer creates an IAM role, an AWS identity with its own set of permissions. The role's trust policy allows Qubole's AWS account to assume the role and take on those permissions. Every one of those requests (AWS calls it AssumeRole) has to include a code supplied by Qubole, known as an External ID.

The check that never fired

Qubole's External ID did nothing to stop this attacker. "Every AssumeRole request we attributed to the threat actor included an External ID, and every one succeeded," Wiz wrote. That is consistent with what the control was built for. The External ID exists to solve the "confused deputy" problem, where one customer tricks a vendor into acting on another customer's account, and was never designed to resist someone holding the vendor's own keys. The Hacker News noted that the code is not treated as a secret, and anyone with access to the role can view it, according to AWS's external ID guidance. Wiz also pointed out that the ID is logged in plain text in CloudTrail and is often stored by vendors and in infrastructure-as-code files.

Sentra argues the victims did nothing wrong in their setup. They configured their Qubole integrations the way AWS recommends, ExternalId check included. Every Qubole role had it, and the attacker presented the right code every time. As far as AWS could tell, the attacker was Qubole.

All of the calls came from AWS account 805246085872, which Wiz says Qubole's platform uses to reach customers, and according to The Register they used IAM user ID AIDA3W7DIFLYOLTK63SFS. The first sign of the attacker, Wiz said, came on October 14, when an IP address belonging to Mullvad VPN (45.83.220[.]211) called AssumeRole against integration roles in customer environments. Wiz has not said how the attacker got Qubole's credentials. The DEV Community summary of the research notes that Wiz did not say whether the credentials have been disabled or whether the activity has stopped.

Roles nobody was using

Old access that nobody had removed was the weakest point. Apart from the attack, most of the roles the attacker assumed were unused, according to Wiz's researchers, but each still trusted Qubole's account, so the attacker's requests worked. In a majority of the environments Wiz CIRT observed, the threat actor's requests were the only AssumeRole activity from the vendor account in October.

Sentra's account is blunter. In one customer it examined, Qubole's roles had been dormant since the spring. Another customer had stopped using Qubole a while ago, yet its Qubole roles were still in place and could read nearly all of the source buckets. Sentra says it took the attacker about a second to assume each Qubole-trusted role. After testing the credentials on a low-value role, the attacker entered every Qubole-trusted role within minutes and started bulk downloads that ran in the background over the following days.

Once inside, the attacker went looking for keys, harvesting secrets from Lambda, Secrets Manager and SSM Parameter Store, testing them with TruffleHog and downloading S3 data, sometimes whole buckets. BigGo, summarizing the research, reported that the haul included victims' own AWS access keys, Microsoft Entra ID client secrets and Okta client credentials, which were used to request OAuth tokens. Those identity-provider secrets can reach well beyond AWS, into the SaaS applications a company signs into through Entra ID or Okta.

Some victims may not be able to work out what was taken. CloudTrail management events record each AssumeRole request and bucket listing but not which S3 objects were read. That requires S3 data events or server access logs, and several victims lacked the necessary logging.

There was also a second cluster of activity. "From October 8 to October 11, an actor used customer-owned AWS access keys that we believe were created for Qubole integrations," Wiz said. Mallory.ai, summarizing the report, says that actor compromised a small number of customer environments. Wiz did not establish a link to the cross-account campaign.

What nobody has said yet

How many victims there are is unclear. Wiz declined to tell The Register how many organizations were affected, but called it a "broad, opportunistic supply chain campaign" that hit "multiple" customer environments. Sentra's post gives two figures: more than a dozen organizations hacked in a single attack, and a campaign impacting dozens of Qubole customers. No victims have been named, and no attacker has been identified.

Nothing has come from the vendor. Neither Qubole nor Idera had posted a statement about the attack on their websites when The Hacker News checked on November 9, and neither AWS nor Qubole responded to The Register's inquiries. Whether Qubole has contained the compromise or will notify customers is unknown, as is whether any stolen data has been published or sold.

Any organization that has connected Qubole to AWS, including one that has since stopped using it, should check its CloudTrail logs from October 1 onward. The sign to look for is an AssumeRole request from the account Qubole's platform uses, 805246085872, that came from an address outside AWS. "All legitimate platform traffic we observed came from AWS infrastructure," Wiz said. Search for the principal AIDA3W7DIFLYOLTK63SFS, which Wiz has seen only in attacker activity. The second principal, AIDAJYRRH5Y3A7AAJM2HW, is also worth checking: the attacker used it from October 18, but Qubole's normal traffic uses it too, so it only matters when the request came from outside AWS. A match on the Mullvad addresses proves nothing by itself, because they are shared VPN exit nodes.

If you find a hit, 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. Even if you find nothing, list every IAM role that trusts an outside account and delete the ones nobody can vouch for. Wiz also suggests 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.

According to the researchers, that last setting alone would have been enough: "A source IP condition alone would have blocked every role assumption we observed."

Sources

• Wiz: Trusted by Default: Qubole Cross-Account Access Abused in the Wild
• The Hacker News: Hackers Exploit Qubole's Trusted AWS Access to Breach Customer Accounts and Steal Data
• Sentra: Inside the Qubole Supply Chain Attack
• The Register: Attackers backdoor trusted AWS integrations to steal secrets
• Runtime Wire: Sentra and Wiz trace AWS data theft to customer roles that trusted Qubole
• WindowsForum: Qubole AWS Credential Attack Exposes Dormant IAM Roles and Entra ID Secrets
• BigGo Finance: Attackers Hijack Qubole's AWS Trust to Raid Customer Cloud Accounts
• Mallory.ai: Attackers Abuse Qubole's AWS Trust Relationships to Steal Customer Secrets and S3 Data
• MLQ.ai: Wiz finds attackers used Qubole's trusted AWS access to steal secrets and data
• DEV Community: Attacker Rides Qubole's Trusted AWS Account Into Customer Environments