Attackers who got hold of credentials tied to Qubole's AWS account used them to walk into customers' AWS environments and steal secrets and data, according to research by Wiz reported by The Register on 9 November. Qubole, a cloud data processing platform, works through cross-account IAM roles that customers create so it can run compute and read storage without long-lived access keys. The attackers simply assumed those roles.
The lesson for anyone running workloads on AWS is uncomfortable: many of the victims had stopped using Qubole long ago but never removed the trust they had granted it. Those forgotten roles still had wide read access to sensitive data.
How the attack worked
Wiz traced the activity to 14 October, when credentials linked to Qubole's AWS account called the sts:AssumeRole API to get temporary credentials for customer-managed integration roles. It continued on 15 October, and from 18 October the attackers also used a second IAM user in the same account. Wiz investigated with Google's Mandiant after the data security company Sentra flagged suspicious activity.
Sentra says the affected customers had followed AWS guidance, including an ExternalId that a vendor must present before assuming a role. The attacker supplied the correct value every time, so to AWS the requests looked exactly like Qubole. None of the traffic came from Qubole's network, though: Sentra says it came from a rented OVH server and the Mullvad VPN.
Wiz has not said how many organizations were affected, describing a broad, opportunistic campaign across multiple environments. Sentra puts the number at more than a dozen and says the attacker could hop between roles in about a second each. While investigating, Wiz also found a separate campaign from 8 to 11 October that used customer-owned AWS access keys for Qubole integrations, but it cannot firmly link the two.
What was taken
Once inside, the attackers enumerated AWS services and harvested secrets from Lambda environment variables, Secrets Manager and SSM Parameter Store. Sentra adds that they also scraped EC2 user data, and that the secrets included source control, identity provider, CI and database credentials. According to Wiz, the attackers used TruffleHog to test stolen AWS credentials, found Microsoft Entra ID secrets, and requested OAuth tokens with Okta client credentials they came across.
They also pulled data from S3, in some cases downloading whole buckets, which Wiz reads as opportunistic theft rather than targeted espionage. Sentra says the attacker made no write actions at all, which made the activity harder to spot, and finished with a pass that took production database backups. When the activity stopped, the trust relationships were still in place, so the attacker went quiet without losing access.
Nobody has attributed the campaign, and Wiz says it does not know how the stolen data is being used. Neither AWS nor Qubole answered The Register's questions.
Forgotten trust is the weak point
The striking detail is that the Qubole roles had sat dormant since the spring, according to Sentra, before suddenly coming back to life. Wiz told The Register that many organizations left trust policies active after they stopped using the platform, which is what let the attacker in. Cross-account roles avoid handing vendors long-lived keys, but they only stay safe if someone removes them when the vendor relationship ends and limits each role to the data the vendor actually needs.
What to do
- If you ever integrated Qubole, review CloudTrail from 1 October for AssumeRole events from Qubole's AWS account 805246085872, especially from non-AWS IP addresses, and check everything each session did afterwards.
- If an integration role was assumed, rotate every secret, parameter and Lambda environment variable it could read, and revoke the role's active sessions, since rotation alone does not end issued sessions.
- Remove cross-account trust policies for vendors you no longer use.