How ShinyHunters turned a single SaaS breach into access to dozens of enterprise Snowflake environments — and what it reveals about the trust architecture every modern SaaS stack depends on.
In early April 2026, the ShinyHunters extortion group breached Anodot, an AI-powered anomaly detection platform, and extracted the persistent authentication tokens it uses to connect to customer cloud data warehouses. Those tokens gave ShinyHunters direct access to Snowflake environments belonging to Anodot’s customers — no Snowflake vulnerability required.
Snowflake confirmed on April 9 that Anodot was the compromised third party. ShinyHunters has since claimed data from 26 organizations, publicly named Rockstar Games as a victim with an April 14 ransom deadline, and reported attempting access to over 400 Salesforce-connected entities.
The breach didn’t exploit a bug in Snowflake. It exploited a design pattern — one that virtually every enterprise SaaS stack depends on.
The Architecture of the Attack
Anodot connects to cloud data warehouses using persistent access tokens. These tokens authenticate its connections to customer Snowflake environments so it can monitor business metrics in real time. The tokens are long-lived, broadly scoped, and function as trusted credentials between services.
When ShinyHunters compromised Anodot, they didn’t need to crack passwords or bypass multi-factor authentication. They extracted tokens that were already authorized to access customer data. From Snowflake’s perspective, the queries looked identical to normal Anodot activity — automated reads from expected tables at expected intervals.
The attackers performed standard database operations to query and exfiltrate data. No exploitation of Snowflake infrastructure was necessary. The tokens did exactly what they were designed to do. They just did it for the wrong people.
By the time Anodot’s status page showed all connectors down across every geographic region, the data was already gone.
Why This Keeps Happening
This attack follows a pattern that is becoming the dominant breach vector for enterprises: compromise the integration, not the target.
ShinyHunters has been refining this approach throughout 2025 and 2026. The group was behind the Salesloft/Drift breach that cascaded into over 760 companies via stolen OAuth tokens, the TELUS Digital breach where 1 petabyte of data was exfiltrated using credentials from a separate compromise, and attacks on the Infinite Campus student platform and the European Commission’s cloud environment.
The strategy is consistent: find the smaller SaaS tool that connects to the well-defended platform. Breach the smaller tool. Use its credentials to access the larger platform as a trusted service.
Three architectural patterns make this attack repeatable and reliable:
Persistent tokens replace session-based trust. Modern SaaS integrations rely on long-lived tokens that authenticate service-to-service connections. These tokens don’t expire on logout. They don’t rotate automatically. They persist until someone manually revokes them — which in many organizations means they persist indefinitely. A single breach provides access that can last weeks or months.
Integration permissions are chronically over-scoped. An analytics tool needs read access to specific tables. In practice, integration tokens are often granted broad read access to entire data warehouses because it’s easier to set up and nobody wants to debug permission errors during onboarding. The convenience of broad scopes becomes the blast radius of a breach.
Compromised token activity is indistinguishable from legitimate use. When a stolen integration token queries your data warehouse, it looks exactly like the integration doing its job. The queries originate from the SaaS vendor’s infrastructure, hit expected endpoints, and follow expected patterns. There’s nothing anomalous to detect until the data is already gone.
What Traditional Security Tools Miss
This is what makes the Anodot breach particularly instructive for companies that believe they have strong security postures.
Vulnerability scanners found nothing because there was no vulnerability in Snowflake to find. The tokens were working as designed. The authorization was technically valid. The problem was architectural — who held the tokens and what happened when their environment was compromised.
Network security was irrelevant. The data exfiltration happened through legitimate API calls over encrypted connections. No firewall rule or WAF signature would flag a properly authenticated API request returning query results.
Identity and access management was configured correctly. The tokens had the permissions they were assigned. The IAM policies were technically sound. The gap wasn’t in how permissions were configured — it was in the assumption that the entity holding those permissions would never be compromised.
The failure is in the trust model, not in the tooling. And trust model failures don’t show up in scan results.
The Acquisition Factor
Glassbox acquired Anodot in November 2025. The breach occurred roughly four months later. While there’s no confirmed link between the acquisition and the compromise, the pattern is worth noting for any security team managing vendor risk.
Acquisitions introduce security risk in predictable ways: systems are migrated, teams are reorganized, security processes are consolidated or deprioritized during integration, and the acquiring company may not fully understand the security posture of what they just bought. If a critical vendor in your stack has recently changed ownership, that’s a signal to reassess — not assume continuity.
What This Means for B2B SaaS Companies
Every B2B SaaS company is both a potential target and a potential attack vector. If you integrate with customer environments using persistent tokens, you are holding the keys to their data. If a third-party tool integrates with yours, you’re trusting their security posture as if it were your own.
The uncomfortable question: how many SaaS integrations currently hold persistent tokens to your most sensitive systems? Most security teams can’t answer confidently. Procurement approved the tool. Engineering set up the integration. The token was generated and forgotten. Nobody audited the scope. Nobody set up rotation. Nobody asked what happens when that vendor gets breached.
This is the architectural gap that traditional security tooling cannot close. Authorization logic failures — the kind where every individual component works as designed but the system-level trust model is broken — don’t get caught by scanners, SAST tools, or penetration testing focused on individual applications. They get caught by testing how applications interact, how trust flows between services, and what assumptions break when one link in the chain is compromised.
What to Do Now
Inventory every integration that holds credentials to your systems. Not just the ones security approved — the ones engineering set up during a sprint and never documented.
Scope tokens to minimum necessary permissions. If an analytics tool needs to read three tables, it shouldn’t have access to your entire warehouse. The configuration work is cheaper than the breach.
Implement automated token rotation. Persistent tokens should have expiration dates measured in days or weeks, not “never.” Automated rotation eliminates the window between a compromise and access.
Monitor for anomalous query patterns. If your analytics integration suddenly starts querying tables it’s never touched before, or exporting volumes it’s never exported, that should trigger an alert — even if the credentials are valid.
Treat every vendor with integration access as a critical dependency. Not a convenience feature. Not a nice-to-have analytics layer. A critical dependency with direct access to your most sensitive data. Evaluate them accordingly.
The Anodot breach isn’t a story about Snowflake getting hacked. Snowflake’s systems were never compromised. It’s a story about the trust architecture that connects modern SaaS stacks being fundamentally fragile — and about attackers who have figured out exactly where the weakest links are.
The companies that recognize this and test their trust boundaries will be the ones that don’t end up on ShinyHunters’ next list.