Supply chain attack via stolen Qubole credentials hit more than a dozen customers

What happened

Security firm Sentra has disclosed a supply chain attack in which an attacker obtained credentials belonging to Qubole, a big-data platform, and then used the access that Qubole's customers had already granted the vendor to quietly read their data. According to Sentra's write-up, more than a dozen organizations were hit, and none of them were breached directly — the intruder reached each one through a shared, trusted vendor.

Sentra reported the campaign to Wiz, which investigated it together with Sentra and Mandiant and published the findings under the title "Trusted by Default: Qubole Cross-Account Access Abused in the Wild."

The speed of the access was notable. Sentra says assuming each Qubole-trusted role took roughly one second, letting the attacker move between victim organizations almost instantly. In one seven-minute window the attacker read about 100 passwords and keys from three different storage locations, plus thousands of credential records contained inside downloaded files. Across the whole campaign the attacker performed zero write operations: nothing was modified or deleted, only copied, which made the intrusion far harder to notice.

Dormant trust and valid credentials

The doors the attacker used were old ones. Sentra reports that Qubole's roles had been dormant since spring, and that some victims had stopped using Qubole entirely while the cross-account roles — still able to reach sensitive data — remained in place. Sentra adds that it had flagged one of those roles before the attack as unused for months yet still able to reach sensitive data.

The victims had configured their integrations the way AWS recommends, including an ExternalId — a code the vendor must present before assuming a role. Every Qubole role had one, and the attacker supplied the correct value each time, so to AWS the sessions looked like Qubole itself. But none of the activity originated from Qubole's network: it came from a rented OVH server and the Mullvad VPN service, and there was no legitimate Qubole activity at all during that window.

How the attack unfolded

The attacker began cautiously. Sentra describes an initial test of the stolen credentials against a single low-value role, a quiet reconnaissance pass, and a first theft of thousands of customer-profile files. The pace then changed: within minutes the attacker assumed every Qubole-trusted role and launched bulk downloads that ran in the background over the following days. A final sweep, launched from a different VPN address, pulled production database backups. The activity then stopped, but the trusts remained in place, so the attacker went quiet without losing access.

Credential harvesting ran alongside the data theft. According to Sentra, the techniques included:

• Bulk extraction from AWS Secrets Manager, capturing source-control, identity-provider, CI and database credentials, along with the vendor's own tokens and ExternalIds.
• Reading decrypted values from SSM Parameter Store, including keys for monitoring and scanner agents.
• Harvesting Lambda environment variables, switching to a second route when the first was blocked.
• Scraping EC2 user data, the startup scripts where tokens and passwords are often stored.

Tracing and proving the theft

Sentra identified the origin of leaked samples by matching file contents — not file names, which are trivial to change — against data it had already scanned, narrowing the sources to a handful of S3 buckets. Each bucket was reachable by hundreds of identities, so the team filtered down to external identities such as vendors, tools and partners, then asked which of those could read most of the source buckets. One stood out: Qubole. Capability alone is not proof, so the team then compared each external identity's activity against its own historical baseline — when it was used, how often, from which IP addresses, and what it did. Every vendor looked normal except one.

Proving exactly what was taken was a separate problem, because most cloud storage does not record every file read by default. Sentra pieced the picture together from three places. Encryption unlock logs record the file name each time an encrypted object is downloaded, and matching those records to the attacker's sessions showed which files left. The secrets access records produced an exact list of credentials needing rotation. And file access logs, where they were enabled, recorded every downloaded file; across one victim's accounts that came to millions of files, and on encrypted buckets those logs matched the encryption records exactly. Files protected only by default encryption leave no such trail, so the real totals are likely higher.

Why it matters

The uncomfortable lesson is that correct configuration did not help here. The victims followed AWS guidance, yet the attacker's access was genuinely valid and looked legitimate in every log. Sentra argues only two things meaningfully limit this kind of breach: restricting each vendor integration to the minimum data it actually needs, so a stolen key opens as little as possible, and behavioral monitoring of how every identity uses data, so a trusted one that starts behaving like an attacker gets flagged.

The incident also underlines the risk of forgotten vendor trust: every integration a company has ever connected to its cloud can leave standing access behind, often reaching its most sensitive data, and dormant roles are rarely reviewed. With breach notification deadlines as short as 72 hours, organizations that already know which of their stores hold personal, financial and credential data — as Sentra, which sells a data security platform, notes it did for its customers — can answer what was taken far faster than those starting from scratch.