Another round of data theft tied to Snowflake environments is making headlines.
This time, the entry point wasn’t a compromised user or exposed credentials. A SaaS integration provider was breached, authentication tokens were taken, and those tokens were then used to access data across multiple customer environments.
From the outside, nothing appears broken. The systems involved behaved as expected. Access was granted through valid mechanisms, and activity flowed through legitimate channels.
That is why this kind of incident keeps repeating without triggering the response it should.
This isn’t about Snowflake
If you look back at the 2024 incident, the pattern is already familiar. Attackers used stolen credentials to access Snowflake instances and move directly to data.
What changed here is not the outcome, but the path.
In the earlier incident, attackers used credentials to get in and tokens to stay. In this case, they started with tokens.
Direct access has been replaced by indirect access through integrations. The attacker no longer needs to interact with the environment in a way that generates obvious signals.
The platform becomes the last step in the chain, not where the problem starts.
This is consistent with what we’ve already seen across recent supply chain incidents, where the initial compromise matters far less than how access is used afterward.
Framing this as a Snowflake issue misses the underlying shift. The same pattern is showing up across SaaS, cloud storage, and data platforms. The common factor is not the vendor. It is the way access is granted and reused across systems.
The supply chain is now operational access
Integrations used to be treated as plumbing. They move data, automate workflows, and connect systems that would otherwise remain isolated.
In practice, they now function as distributed access layers.
A single integration can hold long-lived tokens, operate across multiple environments, and execute actions on behalf of users or services. When that integration is compromised, the attacker does not need to establish a foothold. They inherit one that already exists and is already trusted.
We’ve seen a similar pattern play out in supply chain compromises where execution inside a trusted environment immediately translates into usable access, which is then reused across systems.
That access often spans:
- data platforms
- storage systems
- SaaS applications
Movement across these systems does not require new techniques. It follows the same paths used by the business every day.
At that point, lateral movement is no longer something the attacker needs to do. The architecture does it for them.
Tokens quietly removed the last layer of friction
The shift from credentials to tokens is subtle, but it changes how access behaves.
Tokens are designed for persistence and automation. They are issued once and reused without requiring repeated authentication. They operate through APIs, often without user interaction, and they tend to outlive password rotations or session resets.
In many environments, they are also poorly tracked. Login events are monitored closely. Token usage is often treated as background activity.
During the 2024 Snowflake-related intrusions, one of the attackers described the situation in a way that is difficult to ignore:
I can still run commands because I have the ‘masterToken’ for every account 🤣
Ellyel8
The important part is not the quote itself. It’s how that access was maintained. By reading publicly available documentation, the attacker understood how tokens behaved and used them to persist even after accounts were secured.
Removing the attacker did not remove the access.
That creates a situation where access can continue even after remediation steps are taken. The user account may be secured, while the token tied to an integration remains active and continues to provide the same level of access.
From an attacker’s perspective, this is a cleaner and more reliable form of persistence than anything involving malware.
Why this activity blends in
From a detection standpoint, there is very little here that resembles a traditional intrusion.
What the environment shows is consistent with normal operations:
- authentication events are valid
- API calls follow expected patterns
- integrations behave within their intended scope
What is missing is the context that connects those actions across systems.
Data access that looks reasonable in isolation can become suspicious when viewed alongside activity in another platform. A token used by an integration may appear benign until it starts accessing data in a way that does not match historical behavior.
Most tools are not built to assemble that picture across systems. They operate within a single domain, which means they validate individual actions but rarely question how those actions relate to each other.
That gap is where this type of attack operates.
A recurring pattern, not a one-off incident
The activity has been linked to the ShinyHunters extortion group, which has a history of targeting SaaS platforms and monetizing access at scale. The specific actor matters less than the consistency of the technique.
There is nothing unique about what was done here, which is exactly why it matters.
Any group with access to tokens from a widely used integration platform can reproduce the same outcome. As more organizations rely on interconnected SaaS services, the number of indirect access paths continues to grow.
We are also seeing how this kind of access reuse can evolve into something more automated and self-propagating, where compromised trust relationships are used to extend reach without direct interaction.
At the same time, attackers are shifting toward methods that require less effort and produce fewer signals. Compromising a third-party provider or harvesting tokens at scale offers a higher return than attempting to break into individual environments.
This is why supply chain-driven incidents are becoming more frequent. They provide reach, consistency, and a level of stealth that aligns with how modern environments are built.
The attack isn’t hidden. It’s fragmented.
Security teams are not blind to this activity. They see parts of it every day:
- An identity platform logs a successful authentication.
- A SaaS application records valid API usage.
- A data platform shows expected queries and exports.
Each system validates what it observes. None of them connect those actions.
That is where this model starts to break.
The attacker does not need to evade detection across every control. They only need each control to validate its own piece of the activity. Tokens make that easier. Integrations extend it across systems. By the time the pattern forms, it exists across domains that are rarely analyzed together.
This is why incidents like this feel contained while data is still leaving the environment.
The gap is not visibility in a single system. It is the lack of visibility across them.
If detection is still anchored on isolated signals, it will continue to confirm that everything is working as expected, while missing how access is being misused across identity, SaaS, and data platforms.
That is the shift these incidents are forcing.
Not more alerts. Not more controls.
A different way of seeing the attack while it is still in progress.