Last month, the ShinyHunters hacker group breached Anodot, a SaaS analytics integrator, and stole authentication tokens that connected to customers’ Snowflake environments. Using those tokens, they accessed at least a dozen Snowflake accounts and began exfiltrating data. Rockstar Games, Cisco, and Telus Digital are among the companies named so far. The attacks were timed over the Easter/Passover holiday weekend, and because the access came through legitimate integrator tokens, it looked like normal inter-service traffic.
Snowflake’s own infrastructure wasn’t compromised. The vulnerability was in how a third-party integrator’s credentials provided a direct path to customer data and nothing was there to stop the attackers once they were inside.
If that sounds familiar, it’s because we saw the same problem play out less than two years ago.
This already happened once
In mid-2024, attackers compromised roughly 165 organizations through their Snowflake instances. The method was even simpler: stolen usernames and passwords, harvested by malware from employee and contractor machines. Some of those credentials were years old and had never been rotated. None of the affected accounts had MFA enabled. Over 500 million records were stolen from Ticketmaster alone. AT&T lost call and text metadata for nearly 110 million customers. Santander, Advance Auto Parts, Neiman Marcus, and LendingTree were also hit.
Snowflake responded with meaningful changes: MFA became mandatory for new accounts, admins got org-wide enforcement tools, and single-factor authentication is being phased out entirely. These were real improvements. None of them would have prevented what happened last week. Stolen tokens bypass MFA entirely. Traffic from an allowlisted integrator sails past network policies.
How is this different from 2024?
| 2024 | 2026 |
|---|---|---|
Entry point | Stolen passwords (pre-authentication) | Stolen OAuth tokens (post-authentication) |
Source of compromise | Customer Snowflake users | Third-party infrastructure |
MFA would have helped? | Yes, it was opt-in and nobody had it on | No, tokens bypass password-based MFA entirely |
The fixes from 2024 addressed password-based attacks against customer accounts. In 2026, the compromise originated in third-party infrastructure and used tokens that bypass password-based MFA entirely. Different attack surface, different credential type. In both cases, once the attacker was authenticated, there was nothing between them and the data.
The structural problem
It’s natural to look at each breach and identify the specific control that was missing. Those controls do matter: MFA should be on, network policies should be configured, and tokens should be scoped and rotated, but treating each incident as a standalone failure ignores the deeper issue.
Authentication mechanisms will be bypassed. The specific method changes: stolen passwords yesterday, hijacked tokens today, perhaps an AI-identified vulnerability tomorrow (Anthropic’s Mythos is a preview of where this is heading). The question worth building around isn’t how do we make the perimeter unbreakable? It’s what happens when it breaks?
Think about how we secure physical spaces. You don’t secure a building by just locking the front door. You install cameras, alarms, and a safe for the things that matter most. Yet people still think about data security by just locking the front door, and the response to breaches like these is to try to build a better lock. For many organizations, including those targeted in 2024 and 2026, security didn’t extend much further than the door. Once the locks were picked, there was nothing stopping the attackers once inside the building. No cameras, no alarm, and no safe.
Building below the perimeter
Let’s address this upfront: ALTR is a third-party service that integrates with Snowflake with a service user. We leverage secure key-pair authentication which addresses the breach vector that affected so many companies in 2024. The private key is generated in ALTR‘s infrastructure and is never exposed publicly. It doesn’t live in a browser, isn’t exposed in our UI or API, and never leaves our environment.
Secure authentication alone doesn’t mean ALTR is secure and we actively work to prevent the kind of breach that affected Anodot. We undergo regular security audits and continuously scan our software for vulnerabilities. We recommend customers leverage network policies to ensure that ALTR‘s service users only originate from ALTR. We enable customers to bring their own encryption keys to ensure sovereignty and control over their data. We are also SOC 2 Type 2 certified, ensuring that our security controls are effective. You can learn more at trust.altr.com.
ALTR helps companies secure more than just the front door. We’re the cameras, alarms, and safes. We empower companies with a variety of tools to ensure that, even if attackers get into their systems, additional security measures protect their sensitive data.
The most immediate layer is access controls. Masking policies, row-level security, and table-level restrictions ensure that a valid session doesn’t automatically translate to full data access. If an attacker compromises a credential and that role is governed by masking policies, they get masked values, not raw sensitive data. The blast radius shrinks from “everything that user could query” to what the policy actually allows. For the most sensitive data, tokenization and format-preserving encryption can replace real values entirely with non-sensitive substitutes that carry no intrinsic meaning.
These policies are informed by automated classification of sensitive content across your data sources (PII, PHI, PCI, and custom patterns), so protection is anchored to what’s actually sensitive rather than relying on guesswork.
On the monitoring side, Database Activity Monitoring provides query-level visibility into what’s happening in your Snowflake environment. The exfiltration pattern in both breaches (bulk queries against unfamiliar tables, at unusual volume, during unusual hours) is exactly the kind of activity that monitoring surfaces. Without it, there’s no signal that anything is wrong.
Looking forward
The Snowflake breach pattern is not a one-time event. Two incidents, two years apart, with fundamentally different attack vectors had the same outcome. The vulnerabilities from 2024 were addressed, but attackers found new ones for 2026. Inevitably, new ones will be found.
The organizations that weather these events don’t treat authentication as the only answer. Visibility into how data is accessed, controls that limit what a single credential can reach, and protection on the data itself ensure that even a successful extraction doesn’t compromise your business. New exploits will be found. New breaches will happen. The companies that weather these storms are the ones that secure more than the front door.