Hackers Exploit Qubole’s Trusted AWS Access to Breach Customer Accounts and Steal Data

Swati KhandelwalNov 09, 2026Cloud Security / Data Breach

An attacker broke into AWS accounts belonging to multiple Qubole customers between October 14 and October 26 and stole stored secrets and data, cloud security company Wiz said today.

The attacker used credentials for an AWS account that Qubole’s platform uses to reach those customers. How the attacker got those credentials has not been disclosed.

Qubole, a data lake platform owned by Idera, operates within its customers’ AWS accounts. To let it in, a customer creates an IAM role, which is an AWS identity with its own set of permissions.

The role’s trust policy allows Qubole’s AWS account to assume the role, granting those permissions. Each request to do this, called AssumeRole, must include a matching code from Qubole known as an External ID.

Apart from the attack, most of the roles the attacker assumed were unused, according to Wiz’s researchers. But each role still trusted Qubole’s account, so the attacker’s requests worked.

Any organization that has connected Qubole to AWS, even one that no longer uses 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.

The researchers did not say whether the credentials have since been disabled or whether the activity has stopped. Neither Qubole nor Idera had posted a statement about the attack on their websites when The Hacker News checked today.

Why the Roles Let the Attacker In

Every AssumeRole request tied to the attacker carried an External ID and was accepted, the researchers said in their technical analysis.

AWS accepts an AssumeRole request for such a role when it comes from the trusted account and includes the correct External ID. 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.

Sentra spotted the activity in several of its customers’ environments and alerted the researchers.

In the accounts the researchers examined, the attacker looked for stored credentials. It read environment variables for Lambda functions, pulled secrets from Secrets Manager, and read values from the SSM Parameter Store.

It then ran the credentials it had found through TruffleHog to test whether they worked. These were the victims’ own AWS access keys, Entra ID client secrets, and Okta client credentials.

The attacker also copied data out of S3. It retrieved data from any bucket a role could access rather than searching for specific data, and sometimes downloaded an entire bucket in a single session.

The researchers have not linked this campaign to any other publicly reported activity, and say the targeting does not match what state-backed groups usually go after.

Qubole also lets customers connect with AWS access keys instead of a role. From October 8 to October 11, an attacker used customers’ own AWS access keys, which the researchers believe had been set up for Qubole.

That attacker then compromised a few of the victims’ cloud environments. This activity has not been linked to the AssumeRole abuse.

How to Check Your Accounts

Wiz’s hunting guidance covers CloudTrail logs from October 1 onward in every AWS account that holds a Qubole role. Look for:

• Account: AssumeRole requests where userIdentity.accountId is 805246085872 and sourceIPAddress is not an AWS address. The researchers saw Qubole’s real traffic come only from AWS.
• IAM principal ID: AIDA3W7DIFLYOLTK63SFS. Any activity from this IAM user should be investigated, because only the attacker used it in the accounts the researchers examined.
• IAM principal ID: AIDAJYRRH5Y3A7AAJM2HW, when the source address is outside AWS. The attacker used this IAM user from October 18, but Qubole’s normal traffic also uses it.
• IP: 57.129.54[.]120 and 2001:41d0:70d[:]7800::, OVH-hosted addresses that the attacker used.
• IP: 45.83.220[.]211, 185.209.199[.]73 and 89.37.63[.]175, which are Mullvad VPN addresses. Other VPN users share them, so a match alone is not proof.
• Session name: role sessions that start with quiam-, such as quiam-enum.
• User agent: TruffleHog on GetCallerIdentity calls from one of the IP addresses above. Look for the same user agent in your identity provider’s sign-in logs.

For every suspicious session, review everything it did afterward, especially in Secrets Manager, SSM Parameter Store, Lambda, and S3.

CloudTrail management events log each AssumeRole request and bucket listing, but not which S3 objects were read. That needs S3 data events or S3 server access logs. Several victims lacked the required logs, so responders could not determine which objects the attacker had read.

How to Close the Route

The researchers recommend these steps:

1. If the attacker assumed one of your Qubole roles, rotate all secrets, parameters, and Lambda environment variables that role had access to, and revoke the role’s active sessions. Rotating a credential does not end sessions that were already issued.
2. Remove any Qubole role you no longer need, or take Qubole’s account out of its trust policy.
3. Where Qubole supports it, swap the account-wide :root principal in the trust policy for the specific IAM principal that Qubole uses.
4. Add an aws:SourceIp or aws:SourceVpce condition that limits AssumeRole requests to the vendor’s documented network ranges. In this attack, the researchers said, “a source IP condition alone would have blocked every role assumption we observed.”
5. Assume others can see the External ID. It is logged in plain text in CloudTrail, and vendors and infrastructure-as-code files often store it, so do not use it as your only control. After an incident like this, change it to Qubole and use a different value for each role where possible.
6. Review what each vendor role can reach. Qubole’s setup guide includes a sample S3 policy that lets the role read every bucket in the account. Vendor roles are often granted access to Lambda settings, Secrets Manager, SSM parameters, and broad S3 read permissions for convenience, according to the researchers.
7. Set alerts for AssumeRole requests from a vendor account that arrive through a VPN or a hosting company the vendor has not used before.
8. Log every account and region with an organization trail, and enable S3 data events or server access logs for buckets that store sensitive data.