Somebody got into dozens of Qubole customer environments through a supply chain attack and walked off with data. The speed is what should scare you. The attacker hopped from company to company using stolen credentials, and in seven minutes pulled over 100 passwords and keys from three separate places.
If you run data pipelines on Qubole, or any setup where Qubole has trusted IAM roles, this one is yours. The attacker tested stolen creds on one low-value role first, then went wide, entering every Qubole-trusted role and kicking off bulk downloads. Lambda environment variables and EC2 user data were harvested too, which means secrets you thought were tucked away weren't. Qubole's own network didn't catch any of it.
The numbers: thousands of credential records and files downloaded, zero write actions, and access routed through a rented OVH server and Mullvad VPN. Sentra traced the leaked samples back to a handful of S3 buckets by matching them against data it had already scanned. One external identity, Qubole, could read most of those source buckets. Proving what was taken was the hard part, since most cloud storage doesn't log every file read by default.
Attackers used stolen credentials tied to Qubole's own AWS account to walk into customer environments and steal data. Entire S3 buckets, plus secrets from Lambda, Secrets Manager, and SSM Parameter Store, are gone. This is a supply-chain hit, and it's not a fluke.
If you use Qubole, you're exposed through a cross-account IAM role that Qubole uses to manage compute and reach your storage. The attacker didn't need to touch your account directly. They rode the trust relationship you already set up. Any secret that role could read should be treated as burned.
The timeline starts October 14, when sts:AssumeRole calls came from Qubole account 805246085872. Activity continued on October 15 and 18. Wiz also saw a separate campaign from October 8 to 11 that used customer AWS keys for Qubole integrations, though it isn't confirmed as the same actor. The attackers ran TruffleHog against victim credentials and requested Okta OAuth tokens. Wiz hasn't attributed the campaign to a group or seen what happens to the stolen data. Let's dive deeper…
In today's ContentBuffer update: