A breach of Anodot — an AI-powered analytics and anomaly detection platform that integrates with Snowflake cloud data warehouses — has resulted in data theft from over a dozen Snowflake customer environments. The ShinyHunters group, which claimed responsibility, obtained authentication tokens stored within Anodot’s infrastructure and used them to access downstream customer data warehouses directly. Snowflake confirmed the incident, characterising it as a third-party issue affecting a limited number of customers.
How the Attack Chain Worked
The breach follows a pattern that is becoming increasingly common in cloud security incidents: rather than attacking the target data warehouse (Snowflake) directly, attackers compromised the integration layer that connects to it.
Anodot provides real-time anomaly detection and business analytics, pulling data from Snowflake into its platform to analyse revenue, transactions, and system performance metrics. To do this, Anodot holds authentication tokens — essentially long-lived credentials — that allow it to read from customer Snowflake environments. When ShinyHunters breached Anodot’s systems, they did not just compromise Anodot’s own data: they obtained the keys that unlocked each connected customer’s Snowflake warehouse.
With those tokens, the attackers were able to authenticate to Snowflake as Anodot — a legitimately trusted source — and exfiltrate data directly. There was no vulnerability in Snowflake itself, and no compromise of the victim organisations’ own networks. The attack succeeded entirely because of credentials held by a third party.
ShinyHunters confirmed they also attempted to breach Salesforce using a similar approach, though that attempt failed. The group has a documented history of large-scale data theft operations involving SaaS platform credential abuse.
The Fourth-Party Risk Problem
This incident is a clear example of fourth-party risk — the risk that your organisation’s data is exposed not through your own systems or even your direct suppliers, but through the suppliers of your suppliers.
Organisations running Snowflake as their data warehouse almost certainly use multiple integration tools that hold persistent Snowflake credentials: ETL platforms, analytics tools, business intelligence connectors, monitoring agents. Each of those platforms is a potential entry point for attackers who want access to the underlying data. Yet most third-party risk programmes focus on direct suppliers and rarely audit the security posture of tools that connect to their data infrastructure.
The data accessible to Anodot was the data accessible to any attacker who compromised Anodot. For organisations using Anodot for business analytics, that could include revenue data, transaction records, customer metrics, and operational telemetry — whatever was in the Snowflake environment Anodot was authorised to read.
Recommended Actions
- Audit all third-party integrations with access to your Snowflake environment immediately. Use Snowflake’s
SHOW INTEGRATIONS,SHOW CONNECTIONS, and access history tables to identify every external service holding active credentials. Revoke tokens for any integration you cannot verify as unaffected. - Rotate Snowflake credentials used by Anodot. If you are an Anodot customer with a Snowflake integration, treat your Anodot-associated Snowflake tokens as compromised. Issue new credentials and audit access history for the affected period.
- Apply least privilege to integration credentials. Integration platforms should hold read-only credentials scoped to the specific schemas they need, not broad warehouse-level access. A token that can only read one schema limits the blast radius of a third-party breach.
- Review your third-party risk assessment process for SaaS integrations. Integration platforms that hold credentials to your data infrastructure should be subject to the same vendor security reviews as direct data processors. Request SOC 2 Type II reports, ask about credential storage practices, and understand how tokens can be revoked.
- Implement Snowflake network policies. Snowflake allows network policies that restrict which IP addresses can use credentials. Locking Anodot’s credentials to Anodot’s known IP ranges would have limited the attacker’s ability to use the stolen tokens from their own infrastructure.