Sentra Uncovers Qubole Supply Chain Attack in Under 24 Hours

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. An attacker got hold of credentials belonging to Qubole, a legacy 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 is the inside view from one of the affected organizations. All the customer had to start with was a handful of stolen files, and we had one day to answer two questions: where did this data come from, and how did the attacker get in?

The attack at a glance

• About 3 minutes to get into every account that trusted Qubole, more than a dozen in all.
• About 100 passwords and keys read in 7 minutes, from three different places the customer stored them, plus thousands of credential records inside the files they downloaded.
• 0 write actions. Nothing was changed or deleted, only stolen, which made it harder to notice.

Step 1: Trace the stolen data to its source

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?

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.

Step 2: Find who could reach it

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 the customer'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, a platform the customer had stopped using a while ago, still had roles in place, and those roles could read nearly all of the source buckets.

Step 3: Spot the identity acting out of character

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.

Qubole's roles had been dormant since the spring. Then they came back to life. 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.

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.

How the attack unfolded

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.

Along the way, they raided four credential stores:

• Secrets Manager: nearly every secret, including source-control, identity-provider, CI and database credentials, plus the vendor’s own tokens and ExternalIds.
• SSM Parameter Store: every parameter under one path, decrypted, including monitoring and scanner agent keys.
• Lambda: environment variables, pulled through a second route even where the first was blocked.
• EC2 user data: startup scripts from many instances, a common hiding place for tokens and passwords.

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

The access looked valid. The behavior didn't.

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.

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.

Proving what was taken

Knowing the attacker could reach the data wasn't enough. The customer 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 the customer 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 the customer'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 the customer can't spend containing it. Logs can show which files were touched, but not what was inside them. Because Sentra had already discovered and classified this customer's 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 the 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 happened to this customer wasn't unique to them. 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.

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 pattern 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 the customer's 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 meant we could tell the 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.

One stood out. Qubole, a platform the customer had stopped using a while ago, still had roles in place, and those roles could read nearly all of the source buckets.