Attackers Abuse Qubole's AWS Role Trust to Access Customer Accounts and Steal Data

Wiz said the attacker used credentials for an AWS account that Qubole's platform uses to reach customers' AWS environments. How the attacker obtained those credentials has not been disclosed. Most of the IAM roles the attacker assumed were unused, but each still trusted Qubole's account, so the AssumeRole requests were accepted. Sentra alerted the researchers after spotting the activity in several of its customers' environments.

In the accounts the researchers examined, the attacker read environment variables for Lambda functions, pulled secrets from Secrets Manager, read values from the SSM Parameter Store and tested the credentials found with TruffleHog. The attacker also copied data from S3 buckets that a role could access. The researchers said the targeting does not match what state-backed groups usually pursue and have not linked the campaign to other publicly reported activity. Neither Qubole nor Idera had posted a statement about the attack when The Hacker News checked.

The researchers recommend that organizations review CloudTrail logs from 1 October onward for AssumeRole requests from Qubole's account, 805246085872, that come from an address outside AWS. They also advise rotating secrets reachable by any affected role, revoking active sessions, removing unneeded Qubole roles, restricting trust policies with source IP conditions, and reviewing what each vendor role can reach.

Why it matters Any organization that connected Qubole to AWS, including one that no longer uses it, may hold a role that still trusts Qubole's account and can be assumed by an attacker. Because the External ID is not a secret and can be seen in CloudTrail, it does not protect a role on its own. Investigators should check CloudTrail for the listed indicators, review every session that followed, and treat secrets reachable by affected roles as exposed until they are rotated.