Inside the Qubole Supply Chain Attack: How Sentra Found It

How a third-party compromise created a path into multiple organizations, and how Sentra uncovered it in less than 24 hours.

Co-authored with Sagy Drucker, Asaf Rozali and Riva Kranz

Sentra recently uncovered a very wide supply chain attack that moved through organization after organization. Dozens of Qubole customers were impacted. An attacker got hold of credentials belonging to Qubole, a big-data platform, and used the access that company after company had once granted Qubole to quietly pull their data. Nobody broke into these companies directly. The attacker came in through a vendor they all trusted.

This kind of risk is easy to miss. Your cloud is full of identities that aren’t people: vendor integrations, automation and AI agents, each holding standing access to your data. Most days they do the same thing, from the same place, on the same schedule. The danger is the day one of them starts doing something else, and very few teams are watching for it.

The riskiest of these are the ones you forgot. Every vendor you have ever connected to your cloud left a door behind. Most of those doors are still there, trusted, rarely watched, and often able to reach your most sensitive data.

Sentra spotted the campaign and reported it to Wiz, which investigated it together with Sentra and Mandiant. Wiz has published the full research: Trusted by Default: Qubole Cross-Account Access Abused in the Wild.

This post isn’t the story of one company. It’s what we saw across the attacks: how the attacker got in, how they moved, what they went after, and what finally gave them away.

The attack at a glance

• More than a dozen organizations hacked in a single attack, all through access they had once granted Qubole.
• About a second to assume each Qubole-trusted role, so the attacker could move from one company to the next almost instantly.
• About 100 passwords and keys read in 7 minutes, from three different places they were stored, plus thousands of credential records inside the files the attacker downloaded.
• 0 write actions. Nothing was changed or deleted, only stolen, which made it harder to notice.

Forgotten vendor trust

The doors the attacker used were old ones. Qubole roles were still in place long after companies had stopped using Qubole, and those roles could read nearly all of the data the attacker went after.

Qubole’s roles had been dormant since the spring. Then they came back to life. Sentra had seen this risk coming. Before the attack, it had already flagged one of Qubole’s roles as unused for months yet still able to reach sensitive data.

Valid credentials, wrong network

The organizations hit by this attack weren’t careless. They set up their Qubole integrations the way AWS recommends, including an additional check called an ExternalId, a code the vendor must present before it can get in. Every Qubole role had it, and the attacker presented the right code every time. As far as AWS could tell, the attacker was Qubole.

None of the activity came from Qubole’s own network. It all came from a rented OVH server and the Mullvad VPN, and there was no normal Qubole activity at all in that window. Every session was the attacker.

That’s what makes supply chain attacks so dangerous. When a trusted vendor is compromised, following best practice isn’t enough, because the attacker’s access is real and looks legitimate in every log. Only two things stop it. Zero trust limits each vendor to the data it truly needs, so a stolen key opens as little as possible. And data detection and response (DDR) watches how every identity actually uses data, flagging the moment a trusted one starts behaving like an attacker. In this attack, the access looked valid. The behavior didn’t.

Test quietly, then sweep

The attacker started slowly. They tested the stolen credentials on one low-value Qubole role, took a quiet look around, and made a first theft of thousands of customer-profile files. Then they moved fast. Within minutes they entered every Qubole-trusted role and started bulk downloads that ran in the background over the following days. A final pass, from a different VPN address, pulled production database backups.

Then the activity stopped. The trusts were still in place, so the attacker went quiet without ever losing access.

How the attacker stole credentials

Stealing data wasn’t enough. We saw the attacker use several different techniques to steal credentials that could open even more doors:

• Pulling secrets in bulk from Secrets Manager: source-control, identity-provider, CI and database credentials, and even the vendor’s own tokens and ExternalIds.
• Reading decrypted parameters from SSM Parameter Store, including monitoring and scanner agent keys.
• Harvesting Lambda environment variables, switching to a second route when the first one was blocked.
• Scraping EC2 user data, the startup scripts where tokens and passwords often hide.

How we traced it

The first job was matching the leaked samples to data Sentra had already scanned. We compared what was inside the files, not just their names, because names are easy to change and content isn’t.

Within a few hours we had it down to a handful of S3 buckets. Those were the sources, and the question became much narrower: who could read them?

Each source bucket could be reached by hundreds of identities: service roles, admins, single sign-on users and automation. Chasing every one of them in a day wasn’t realistic. So we narrowed to external identities, the accounts outside a company’s environment that are still trusted to get in, such as vendors, tools and partners. Then we checked which of them could read most of the source buckets. One stood out: Qubole.

Being able to reach data doesn’t mean someone did. So for every external identity, we compared its activity to its own history: when it was used, how often, from which IP addresses, and what it did. Every vendor looked normal except one.

A small team split the work, each using AI to move faster, and we held every finding to one rule: it was either proven or assumed. That rule saved us more than once. One early lead looked strong on paper, but the activity logs showed the identity had never been used, so we dropped it.

Proving what was taken

Knowing the attacker could reach the data wasn’t enough. Each affected company needed to know what was actually taken, and that’s harder to prove than it sounds, because most cloud storage doesn’t record every file read by default. So we pieced the picture together from three places.

The first was encryption. Every time an encrypted file is downloaded, the cloud has to unlock it, and each unlock is logged with the file’s name. By matching those records to the attacker’s sessions, we could see which files left. Files that only use default encryption leave no such trail, so the real number is likely higher.

The second was the secrets themselves. Every password and key the attacker read left its own record, which gave an exact list of what to change.

The third was file access logs. Where they were turned on, they recorded every file the attacker downloaded, with the IP and session. Across one company’s accounts that came to millions of files, and on encrypted buckets the logs matched the encryption records exactly.

This is where having an agentic Data Security Platform makes the difference. Sentra continuously discovers and classifies sensitive data across cloud, SaaS, data warehouses, on-premises environments and AI systems. It also maps every employee, service account and AI agent to the data each one can reach. After a breach, the clock is running: breach notification deadlines can be as short as 72 hours, and every hour spent working out what was taken is an hour that can’t be spent containing it. Logs can show which files were touched, but not what was inside them. Because Sentra had already discovered and classified our customers’ data, we knew which locations held personal, financial and credential data before the investigation even began. That turned “what did we lose?” from a question that can take weeks into one we answered the same day.

Five actions, same day

By the end of the day, we could give each affected customer five clear actions, each backed by evidence:

1. Remove Qubole from every role that trusts it.
2. Rotate every secret that was read. We shared each secret’s name and where to find it in their logs, without ever seeing the values themselves.
3. Block the attacker’s IP addresses.
4. Preserve the logs before they expire.
5. Let Qubole know.

One vendor, many targets

What we saw wasn’t unique to one company. The attacker held Qubole’s credentials, and those credentials opened a door at every organization that still trusted Qubole. This was a broad campaign that moved through company after company, impacting dozens of Qubole customers.

Because Sentra can see which organizations trust the same vendor, we checked every Sentra customer with a Qubole connection within about an hour. The same activity showed up across customer environments, a long-unused Qubole role suddenly waking up in the same window, and we warned each affected customer directly.

We then reported the campaign to Wiz, which led to a joint investigation with Wiz and Mandiant. Their research shows the same attacker sweeping through one victim environment after another in quick succession.

Close the doors you forgot

Some vendors can reach far more sensitive data than others, and those are the ones an attacker wants. Compromise one of them, and everything it can access goes with it. Start by finding them: which outside identities can read your customer records, financial data and credentials, and how much of it each one can reach.

Then shrink that access with a zero trust approach: every vendor gets only the data it needs for the job it does today, and nothing more. Remove trust entirely for integrations you no longer use, because a dormant, privileged, external role should be removed, not watched. For the rest, cut permissions down to what the vendor documents and limit each role to the vendor’s published network addresses. In this case, every secret that leaked came from permissions Qubole never needed, and a network restriction alone would have blocked every login we saw.

That’s exactly what Sentra does. It shows which vendors, service accounts and AI agents can reach your most sensitive data, flags access that is excessive or unused, and helps you cut it back before an attacker can use it. And because access keeps changing, Sentra keeps watching, so a vendor that suddenly starts acting differently is caught early.

How Sentra turned a month into a day

We didn’t start from zero, and that’s why the investigation took a day instead of a month. Sentra had already found and classified our customers’ sensitive data, so we could trace the stolen samples back to their source within hours. It had also mapped who could reach that data, vendors included, and how much each one could do, which turned hundreds of possible suspects into a short list.

Sentra had flagged the risk before anything happened, too: a Qubole role that had sat unused for months but could still reach sensitive data. And because Sentra knows how each identity normally behaves, the attacker stood out the moment a quiet vendor role started acting differently.

Knowing what the data was meant we could tell each customer what kind of sensitive information was exposed, not just where it lived. And because Sentra sees which organizations trust the same vendor, one customer’s incident became an early warning for every other customer at risk.

We’ve since turned this method into reusable investigation skills, so the next case starts from a playbook rather than a blank page.

Actionable controls to prevent and mitigate supply chain breaches

• Continuous sensitive data discovery: Automatically locate and classify sensitive data across all cloud, SaaS, data warehouse, and AI environments.
• Identity-to-data mapping: Map every employee, vendor, service account, and AI agent to the specific data assets they can access.
• Dormant access cleanup: Flag and revoke unused, excessive, or forgotten third-party integrations before attackers can exploit them.
• Real-time anomaly detection (DDR): Monitor access patterns to detect and alert on unusual third-party behavior instantly.
• Rapid incident containment: Use pre-classified data context to determine breach impact in hours instead of weeks.

For the full technical details and indicators of compromise, read Wiz’s research.

Want to see which outside identities can reach your sensitive data today? Book a demo today.