Attackers Used Qubole's Trusted AWS Account to Walk Into Customer Clouds and Download Whole S3 Buckets

Someone got hold of the keys a vendor uses to reach its customers, and used them on all of those customers at once. Between October 14 and October 26, an attacker used credentials from an AWS account belonging to Qubole, a data lake platform owned by Idera, to assume IAM roles inside customer AWS environments, steal stored secrets and copy data out of S3.

Sentra spotted the activity across several of its own customers and alerted Wiz, which investigated with Google's Mandiant. Sentra says there are dozens of victims, with millions of files taken from one customer alone. How the attacker obtained Qubole's credentials has not been disclosed, and Qubole had posted no statement when the research came out.

Old integrations, still open

Qubole works inside its customers' AWS accounts. During setup, each customer creates a role that trusts Qubole's account, protected by an External ID. Every request the attacker made carried a valid External ID, and every one succeeded.

The worst part is that most of those roles were idle. In a majority of the environments Wiz examined, the attacker's requests were the only role assumptions from Qubole's account in October. Companies that had stopped using the platform had never removed the trust, so the door was still unlocked.

The attacker came in through Mullvad VPN and an OVH server, using two IAM users from Qubole's account. One of them also carries legitimate Qubole traffic, which makes the bad sessions easy to miss.

Secrets first, then the data

Once inside, the attacker went straight for credentials. It read Lambda environment variables, pulled values from Secrets Manager and SSM Parameter Store, then ran what it found through TruffleHog to check which AWS keys, Entra ID client secrets and Okta credentials still worked. Sentra clocked it collecting about 100 passwords and keys in seven minutes.

Then it took whatever the role could reach. There was no sign of a targeted hunt: the attacker listed buckets and downloaded their contents, sometimes an entire bucket in a single session. Several victims had no S3 data event logging, so responders could not tell which files were read.

Wiz also found a separate wave from October 8 to 11, in which someone tested customer owned AWS access keys that appear to have been created for Qubole and broke into a few environments. It has not tied the two campaigns together.

What to check

Any company that ever connected Qubole to AWS should review CloudTrail from October 1 onward:

• Look for AssumeRole calls from account 805246085872 that come from an address outside AWS, and any activity from the IAM user AIDA3W7DIFLYOLTK63SFS.
• Search for role sessions named quiam-, such as quiam-enum.
• If a role was assumed, rotate every secret, parameter and Lambda variable it could read, and revoke its active sessions. Rotation alone does not end sessions already issued.
• Delete vendor roles you no longer use, and add an aws:SourceIp condition to the ones you keep. Wiz says that one condition would have blocked every role assumption it saw.

Stored secrets were the prize in the Northflank breach too, and cloud attackers keep going after them first.

Some offers on this page may be paid placements or contain affiliate links.