What We Know So Far about the Snowflake “Breach”

What we Know So Far

While further details, and the additional impact from this incident and more incidents may still unfold beyond what is laid out above, the release of the report from Mandiant has provided significant more detail beyond what was disclosed previously.  

Snowflake and Snowflake Customers are being Targeted 

Currently three Snowflake Customers have confirmed breaches. Cybercriminals have claimed to breach an additional 7. Snowflake has confirmed that some access to their systems was also obtained. Mandiant has indicated 165 potentially exposed organizations have been notified by Mandiant and Snowflake. 

The common thread is obvious – Snowflake, but really this is all about data and the attractiveness of that to cybercriminals and other threat actors. With a market share estimated at around 20% of all Data Warehouses, and recently being recognized as #1 on the Fortune Future 50 List, it should not be surprising that Snowflake is a target. 

However we should not naively presume that because Snowflake is a target that these breaches stem from a failure by Snowflake. To be clear, this relationship is as yet – a correlation, not yet confirmed as a causal relationship. Snowflake’s Chief Information Security Officer, Brad Jones maintains that the company and their forensic partners found no evidence of vulnerabilities or breaches within Snowflake’s platform itself. 

A Single Snowflake Account Confirmed as Compromised

Snowflake has confirmed that a threat actor obtained credentials of a single former employee and accessed demo accounts they had access to. Snowflake asserts these accounts contained no “sensitive” data and were isolated from production and corporate systems. However, unlike Snowflake’s core systems, which are protected by Okta and Multi-Factor Authentication (MFA), these dormant demo accounts lacked such safeguards. 

What We Don’t know

• The threat actor claimed that they were also able to log into Snowflake’s ServiceNow using this employee’s credentials. This has not been confirmed by Snowflake or explicitly refuted to our knowledge.
• Whether any other snowflake employee’s have been obtained by similar methods?
• What definition of “sensitive” data was used to determine whether the demo accounts contained “sensitive” data?

Attack Path = Infostealer Malware > Credentials > Snowflake customer deployments

Until the release of the Mandiant report, It was almost certain, but not conclusive, that the initial access point for the attackers in these breaches was compromised credentials used by administrative users at the breached organizations. The latest update from Snowflake indicated that the compromised credentials used were “credentials previously purchased or obtained through infostealing malware”, and that no compromised credentials of current or former Snowflake personnel have been determined yet to be complicit in this. The Mandiant report explicitly states how this was determined, removing any ambiguity – “every incident Mandiant responded to associated with this campaign was traced back to compromised customer credentials.”

The density of attacks on Snowflake customers is increased by the ease of identification of Snowflake users in infostealer marketplaces and logs, as all Snowflake users can log in via a common Snowflake domain (e.g., https://<account_identifier>.snowflakecomputing.com).

Separate investigations into the breach of the former employee account confirm that a Snowflake employee’s device was infected with infostealer malware that logs keystrokes and other activities. This malware would have allowed the threat actors to obtain the employee’s credentials. This is corroborated by the now-deleted Hudson Rock blog indicating that an infostealer malware dubbed Lumma Stealer was used to steal Snowflake credentials of an employee. The Mandiant report further indicates that the compromised credentials was not a single malware, but several infostealer malware variants, including; VIDAR, RISEPRO, REDLINE, RACOON STEALER, LUMMA and METASTEALER.

Notoriety keeps Test Environments in the Crosshairs

Demo accounts, like the one the former Snowflake employee’s used for demonstration purposes, are ignored as potential security risks. Despite assurances that these accounts don’t contain sensitive data, they remain attractive and easier targets for cybercriminals. The allure lies in the perception: to the average person, a compromise of a demo account can appear indistinguishable from a full-scale breach of production systems. This perception is amplified when companies use realistic, production-like test data in their demos, a common practice to provide an authentic user experience. Cybercriminals exploit this perception gap and lack of security in comparison to heavily fortified production environments. , knowing that a claimed breach of a high-profile company like Snowflake can generate significant media attention, even if the actual impact is limited. 

What We Still Don’t know

• Whether the demo accounts compromised have any correlation to the customers compromised? 

Organization wide MFA is a necessity, but remains challenging

To mitigate further customers being impacted by attacks, Snowflake has urged all customers to enforce multi-factor authentication (MFA) on all accounts and restrict traffic to authorized users or locations. This reinforces Symmetry’s 2024 State of Data+AI Security Report finding that all organizations have at least one human identity without MFA enabled. Mandiant has confirmed that “affected customer instances did not require multi-factor authentication”.

In this instance, the inability to enforce MFA organization-wide by Snowflake has contributed to the number of organization’s at risk. While Snowflake supports both native MFA (via Duo) and integration into an organization’s IDP (such as Okta) – ensuring that MFA is enabled org-wide isn’t just one click away. 

For organizations that need to use Snowflake’s native MFA : Each user must manually log in and enable MFA themselves, and there’s no policy to block or restrict access for users who haven’t enabled MFA, creating a significant reliance on users to do the right thing.

For organizations with integrated into their iDP: Existing MFA policies will be enforced – however if a user (such as admin) was created or logged in before this integration was enabled, then extra steps need to be taken to ensure that they are restricted from logging in directly using solely username and password.

What We Still Don’t know

• Whether the organizations that have been breached had integrated into their own IDP’s? Reporting from Techcrunch indicates this may be the case. This is significant, as this integration would have enforced existing MFA policies, but extra steps would have been needed to ensure existing credentials for users like admins were removed after enabling the IDP. 
• How many remaining Snowflake customer environments still have admin accounts without MFA enforced?

Snowflake Steadfast in Shared Responsibility Model

Despite the high-profile nature of the breaches and the potential reputational risk, Snowflake has not deviated from the shared responsibility model. They provide comprehensive, proactive guidance covering Identification, Investigation, and Prevention, but consistently emphasize that customers are responsible for implementing these measures. For Identification, Snowflake offers SQL queries to detect logins from suspected IPs and suspicious client apps like “rapeflake.” However, it’s the customers who must run these queries and interpret the results. Similarly, in the Investigation phase, Snowflake provides the means for customers to review actions of identified users, check for external access attempts, and analyze client environments, but the execution of these steps lies with the customers. For Prevention, Snowflake guides customers in setting up network policies, reviewing account parameters, monitoring for unauthorized changes, and strengthening authentication (See Note 1), yet again underscoring that customers must apply these safeguards. 

Additional comprehensive guidance was included in the Mandiant report. 

Extortion inevitable after data exfiltration

Mandiant indicates that the intent of the attacker was data theft and extortion, and that cybercriminals are attempting to extort many of the victims, threatening to release or sell the data unless a ransom is paid. Unsurprisingly they are also actively attempting to sell data. This dual-pronged approach of both extortion and data sale maximizes the potential financial gain for the threat actor, while putting victims in an extremely difficult position. They must decide whether to pay the ransom with no guarantee the data won’t be sold anyway, or risk the data being publicly exposed or sold to other malicious actors.

What We Still Don’t know

• Whether the data being actively touted for sale are from organizations that have refused to bend to extortion claims?

What can we learn from this?

The recent series of events involving Snowflake and its customers serves as a stark reminder of the complexities and shared responsibilities in modern data security. While the full extent of the breaches is yet to be determined, it’s clear that a renewed focus on the fundamentals of data security is needed. Stay tuned for our upcoming blog, “Lessons Learned from the Snowflake Incident” where we’ll dive deeper into actionable strategies for preventing similar incidents in the future. We’ll explore Zero Trust for Data, the role of continuous monitoring, DSPM ,and DDR.

In an era where data is the lifeblood of business, the Snowflake incident is a clarion call for modern data security, starting with data security posture management. It’s not just about securing a platform; it’s about securing the entire data ecosystem. 

Notes:

Note 1: Companies impacted by the breach have been encouraged to reset their Snowflake login credentials immediately, with clear steps to ensure these actions are effective. For suspected compromised accounts, Snowflake recommends disabling the user accounts using the SQL command ALTER USER IDENTIFIER($user_name) SET DISABLED = TRUE. This action aborts all running queries, closes user sessions, and locks the user out of Snowflake. However, if the ALLOW_ID_TOKEN parameter is enabled, the account must remain disabled for at least 6 hours to fully invalidate any unauthorized access. Before restoring access, it’s crucial to reset user credentials by removing all delegated authorizations for various integrations, resetting passwords, and unsetting SSH keys if present. These steps, combined with implementing security hardening measures, can help prevent future unauthorized access and strengthen the overall security posture.