Postmortem on the Snowflake Data Breach
The recent cyberattack against cloud storage and data analytics giant, Snowflake is a fascinating case among the many high-profile data breaches this series explores. In many other breaches, internal data privacy vulnerabilities among the victim organization’s workforce/employees are the main driver of exposure. That is, threat actors leverage poor external data privacy to fashion social engineering attacks aimed at gaining unauthorized access to their target’s information systems. That one predominant risk – employee risk – leads to negative consequences correlated to internal processes. This breach, however, involves third-party vendor risk as the predominant factor. And because Snowflake is both a popular third-party vendor to many organizations – as well as a user of many third-party vendors, the cause and consequences of this attack provide a perfect case study on the risks of weak external data privacy among third-party vendors.
Part of Privacy Bee for Business’s white paper series of cyberattack postmortems, this document contains a profile on the victimized organization. It also offers analysis of key information about how the attacks were organized and how strong external data privacy practices might have prevented the incident.
Nearly all the enormous, costly data breaches and cyberattacks examined by this series share one glaring commonality. It is a consideration all too frequently overlooked by even the most sophisticated InfoSec programs and one which, even in the aftermath of a catastrophic security breach, is still often left inadequately addressed. The commonality threading through this and most other cybersecurity failures: inadequate External Data Privacy (EDP) Management.
THE VICTIM ORGANIZATION
With 2024 projected revenues of $2.08 billion and market capitalization of $43.23 billion, the Bozeman, Montana-based Snowflake, Inc. is a cloud data storage and analytics company trading on the NYSE under the ticker symbol (SNOW). Founded in 2012, the organization is credited with helping launch the mushrooming “data-as-a-service” industry segment, and its products/services are used by some of the world’s foremost brands – especially in the technology industry. With more than 9,000 customers and a 20%-plus share of the data warehousing market, Snowflake’s September 2020 IPO was one of the largest ever for a software company at that time.
A full 30% of the Fortune 500 uses Snowflake. The top three products and services engaged by customers using Snowflake for data management are Data Analytics (226), Cloud Services (211), Digital Transformation (186). This includes notable tech leaders like Google, SAP Business Warehouse, Oracle Data Warehouse, Apache Hive, IBM Data Warehouse and others. The following graphical representation of Snowflake services usage come from 6Sense, aB2B sales and marketing software provider.
However, Snowflake serves myriad other customers in a broad array of industries including household name brands such as Wells Fargo & Company, Mastercard and Capital One, Adobe, Albertsons Companies, AT&T, Be The Match, Deliveroo, Doordash, HP, Instacart, JetBlue, Kraft Heinz, Mastercard, McKesson, Micron, NBC Universal, Nielsen, Novartis, Okta, PepsiCo, Pitney Bowes, Siemens, University of Notre Dame, Uber, US Foods, Western Union, Yamaha, and many others.
Special Note: Privacy Bee has produced postmortems for Uber and Okta in the wake of their own data breaches. The fact that these two earlier, massive data breaches occurred at two Snowflake customers illustrates how the theft of data from one source can often be used to propagate attacks on other organizations. With the stolen data from these two earlier breaches being sold on the Dark Web, it is not inconceivable that these data may have somehow played a role in this case as well though finding evidence of such a link is difficult to achieve.
In any case, the sheer number and variety of the organizations exposed as a result of this breach underscores the extent to which vulnerabilities of a single organization can quickly transform into risks for their entire roster of clients. Given this victim’s function as a data warehousing service provider, this breach is particularly damaging as the organization is itself a wildly popular third-party vendor to hundreds of other data-rich organizations.
It is a veritable certainty that this breach of data among so many large enterprises will lead to additional incidents. Particularly for those organizations that do not assume firm control over their external data privacy and that of their third-party business partners/vendors.
Cut to the chase – Read all about Privacy Bee for Business solutions for Vendor Risk Management.
KNOWN FACTS OF THE ATTACKS
In mid- to late May 2024, cloud security firm Mitiga published a blog post revealing that a known threat actor – UNC5537 – had been “observed using stolen customer credentials to target organizations using Snowflake databases”. Moreover, the threat activity originated from commercial VPN IP addresses.
It was also noted that UNC5537 was using a custom, purpose-built attack tool they named “Rapeflake” to access Snowflake environments identified as lacking two-factor authentication. The name hackers gave to their tool plainly illustrates their malevolent intent.
The stolen credentials were used by this threat actor to conduct data theft for sale on the black market, and to extort money from Snowflake customers victimized in the breach. Extortion demands publicly pressured the exposed Snowflake customers by posting their stolen data for sale on the dark web and hacker forums. By mid-June 2024, Bloomberg reported that the UNC5537 hacker group had accessed the Snowflake accounts of around 165 customers and made off with volumes of valuable and sensitive data. Seeming to confirm this, Snowflake customers were reported to be receiving ransom payment demands of between $300,000 and $5 million.
Speaking to media outlet, TechTarget, Mitiga’s director of research (and co-author of the above-linked blog post) Mr. Or Aspir, told the editorial team that the suspicious activity was initially isolated after several customer inquiries and threat intelligence reports emerged regarding certain Snowflake environments. Aspir also said that although Mitiga did investigate and determine the “issue was far more extensive than initially thought, involving multiple organizations” they did not immediately contact Snowflake. This was because the Mitiga investigation found the threat campaign targeting Snowflake customers had begun in April. Even though no evidence yet pointed to Snowflake’s systems being directly breached, Mitiga assumed that Snowflake was at least aware of the activity.
For its part, and true to form for so many large organizations victimized by this type of attack, Snowflake initially revealed very little about the contours of the attack and how unauthorized access was achieved. They minimized the gravity of the breach, offering only that the threat actors had “not directly breached any information security protocols”.
However, this claim was quickly disproved according to Wired magazine quoting a hacker they’d spoken with who revealed the actual method by which the breach was achieved. At the same time, Mandiant, a Google-owned security firm engaged by Snowflake to investigate the breach disclosed in a published blog that the hackers had indeed obtained access through vulnerabilities in the security of third-party contractors of Snowflake. Mandiant did not name any particular third-party contractor. However, Wired magazine’s investigative team confirmed that one of the exploited third parties was publicly-traded engineering and digital services firm, EPAM Systems. EPAM systems is indeed a vendor serving Snowflake.
Unsurprisingly, Wired’s hacker source – part of a known hacker group called ShinyHunters – said a computer belonging to one of EPAM’s personnel in Ukraine was infected with info-stealer malware through a spear-phishing attack. And once inside the EPAM worker’s system, a remote-access Trojan was installed, rendering full access to everything on this worker’s machine.
In several Snowflake related investigations, Mandiant observed that the initial compromise of “infostealer” malware occurred on contractor computers that were also being used by EPAM employees for personal activities, including gaming and downloads of pirated software.
INITIAL CONSEQUENCES OF THE ATTACK
Typically, the consequences of a data breach or cyber attack can take many months to trickle out. This is often due to tight lipped responses from the breached organization. It’s also because it can take time for investigations to wend beyond the initial breach then follow all the sales/resales of stolen data to Data Brokers and other threat actors on the Dark Web, tracing subsequent breaches back to the original stolen data. In this case, the opposite seems to be the case. A mere six weeks have transpired since the initial attack was noted by Mitiga and the writing of this paper in late June 2024.
While Snowflake, for obvious reasons of reputation management and damage control did not reveal the names of any of its customers affected by the attack, evidence of it is being reported by dozens of organizations who were impacted. Whether they’ve received ransom demands, or simply found they were vulnerable during internal reviews following the revelation of Snowflake’s breach, organizations are sounding off.
Unprecedented Speed of Reported Breaches Following Snowflake Attack
Within weeks of the hack, Snowflake customers began reporting evidence of being breached and even being hit with ransom demands to keep their data from being sold. Here are five that were announced in the immediate wake.
Pure Storage disclosed breaches of their Snowflake workspaces. Through its cybersecurity contractor, Pure Storage reported telemetry information it uses to provide proactive customer support had been accessed without authorization from its Snowflake environment. The leaked info included customer email addresses, company names and LDAP usernames.
Advance Auto Parts is investigating Snowflake-related issues. In its quarterly 8K filing to the Securities and Exchange Commission, the auto parts chain said they had “identified unauthorized activity within a third-party cloud database environment containing company data and launched an investigation with industry-leading experts.”
Live Nation Entertainment/Ticketmaster reports unauthorized access to a third-party cloud database. While they didn’t name Snowflake directly, it is widely known that they are a client of Snowflake. They also disclosed that hackers had made off with data on 560 MILLION Ticketmaster customers!
Santander Bank warned that the information on nearly thirteen thousand of its employees had been breached in the Snowflake attack including employees’ PII from payroll such as names, Social Security numbers and bank account information.
Lending Tree subsidiary, QuoteWizard, a home mortgage application tool, did not respond to questions. However, it has been reported that a database including customer details, credit card info, insurance quotes and other highly sensitive information had been stolen by a hacker offering this data stolen from Snowflake for sale at the price of $2million.
The ferocity and speed of the consequences of this attack speak to the fact that as a target, Snowflake, is particularly situated as both a third-party vendor serving hundreds of enterprise clients as well as a user of multiple third parties to field its products. This makes them especially vulnerable from both ends of the spectrum.
ATTACK VECTORS AND EXTERNAL DATA PRIVACY MANAGEMENT
This attack path diagram from Mandiant (below) illustrates the nature of how the breach was engineered. From the standpoint of External Data Privacy management, the initial infection of malware at the very beginning of the attack path could only have been accomplished as a result of poor external data privacy at the EPAM contractor which enabled the threat actors to create and deploy a spear phishing scheme setting this breach in motion.
Had Snowflake been exerting strong control over its own external data privacy and requiring its roster of third-party vendors to achieve and maintain baseline levels of EDP compliance, it is far less likely that the EPAM employee would have fallen prey to the spear-phishing ruse that set this dramatic and damaging sequence of events in motion.
In its report Mandiant observed, “the initial compromise of infostealer malware occurred on contractor systems that were also used for personal activities, including gaming and downloads of pirated software.” This passage of the report was especially notable because of the overlap between external data privacy failures and more traditional info sec failures. That is, not only was compliance poorly enforced regarding personal use of business computers, but readily available data on the individual was easily gathered and leveraged by the threat actors to gain access to Snowflake credentials. So, while Snowflake’s internal production data was not technically accessed, its customer instances were nevertheless exposed.
The secondary vector discussion as it relates to this attack was the use of the “Rapeflake” hacker tool to target Snowflake environments that lacked two-factor authentication (2FA). Analysts have suggested that the absence of any multi-factor authentication on some of the Snowflake customer environments was partly to blame. Yet, the only benefit to threat actors in isolating targets without 2FA is but a small savings of time. 2FA would have only slowed this breach down by hours to days at the outside.
Typically, hackers pursue the path of least resistance when seeking victims. It is for this reason that the majority of breaches today no longer employ brute force attacks on encryption or other hardened network security. Instead, threat actors have turned to social engineering methods such as spear phishing, credential theft, email stuffing and others. This is because it is far simpler to sidestep a tall wall than to break through it.
“Two-factor authentication isn’t our savior. It won’t defend against phishing. It’s not going to prevent identity theft. It’s not going to secure online accounts from fraudulent transactions.” – Bruce Schneier
Bruce Schneier, a fellow and lecturer at Harvard’s Kennedy School, a board member of Electronic Frontier Foundation and technologist says, “Two-factor authentication isn’t our savior. It won’t defend against phishing. It’s not going to prevent identity theft. It’s not going to secure online accounts from fraudulent transactions.” The use of a purpose-built tool to find Snowflake accounts not protected by 2FA merely provided the path of least resistance for UNC5537 to gain access. In reality, the same social engineering efforts enabled by sloppy management of external data privacy would have been just as successful at circumventing 2FA. It just might have taken a few more hours or days.
This fact only underscores how important it is for any organization serious about security to develop, deploy, measure and enforce a strong, well-articulated external data privacy policy and practices across its entire organization as well as its whole supply chain and vendor ecosystem. This is something covered extensively in the Privacy Bee white paper, “Cyber Security Isn’t Enough – the Information Security Ecosystem Dies Without External Data Privacy”.
And for more information on precisely how to execute on this goal, we recommend reading Privacy Bee white paper “External Data Privacy Metrics and KPIs – A How-to Guide for Strong Compliance” which details how to begin to field such a protocol.
LONGER TERM CONSEQUENCES OF THE ATTACK
In today’s business environment, third-party partnerships are essential for many reasons. Not least of which is their role in helping stand up highly technical infrastructure capabilities by flattening the costs and labor challenges associated with engineering, development and implementation of increasingly complex technology stacks. Additionally, as business processes like HR/staffing, logistics, resource management, procurement and others are increasingly outsourced, businesses more routinely rely on information systems integrations with many third-party vendors and contractors.
This postmortem is being written less than two months since the inception of the attack which is not typically the case. Most of these documents are generated six to twelve months following the initial incident. During that time, the downstream consequences become more readily apparent. In this case, however, the consequences are already presenting themselves.
The five Snowflake customers highlighted in the “Initial Consequences” segment above are surely only the beginning of the inevitable flood of others. And because the list of organizations using Snowflake contains such a high concentration of top-tier targets – financial companies, travel, retail and others where large volumes of sensitive PII is at stake – it is an irresistible draw for hackers and threat actors all over the world.
Already hackers are selling the stolen data to unknown numbers of hacking groups and individual organizations are being extorted for princely sums in order to keep their data from being released. It bears note too that even if a ransom is paid, it is unclear whether the data being held hostage hasn’t already been shared/sold to others as well. So, paying a ransom may or may not even have any effect.
Some of the data is also inevitably laundered and then sold to Data Brokers which continue to help propagate social engineering attacks, albeit under the imprimatur of legitimate business activity.
EXTERNAL DATA PRIVACY MANAGEMENT
For organizations to get a handle on vendor risk mitigation and avoid third-party breaches like the Snowflake debacle requires more than the vendor questionnaires, documentation reviews, and both the onsite and remote security evaluations and assessments many already employ. The most contemporary thinking, as Gartner confirms in its 2024 Third Party Risk Management Report, involves implementing strong governance and compliance policies. Doing so necessarily requires having the capacity to establish, monitor and analyze vendor risk levels.
In the absence of any portion of these recommendations, the entire endeavor fails. In short, organizations know they need to ask probative questions of their vendors, but they may not be asking the right questions. Organizations may establish seemingly relevant governance and compliance standards, but they often lack the capacity to track and measure compliance with their strictures. Success in this effort will require all pieces of the VRM and GRC infrastructure to be in place supporting functional defenses against the phishing and other social engineering attack vectors being used to exploit third-party relationships.
The Privacy Bee platform – specifically the Vendor Risk Management element – enables organizations to not only assess and enforce privacy risk compliance among its internal workforce, but also provides the same set of tools to “cover” the employees within all third-party workforces. “Coverage” involves the removal of exposed PII from internet sources like Data Broker sites, People Search Sites, public records, social media sites, corporate websites and other publicly available sources. Whether an organization uses internal resources to remove the exposed PII or engages the Privacy Bee service to perform this work, Privacy Bee technology and services address all the elements required to field a successful privacy and vendor risk management practice as defined earlier in this document.
The process begins with the Privacy Bee “PRA” or Privacy Risk Assessment features. The Privacy Bee platform automates the process of delivering in-depth surveys to internal and external vendor employees alike. The two screen captures below illustrate how the surveys are administered.
With the responses captured by the exhaustive PRA process, the Privacy Bee platform is able to populate a risk assessment visualization for each and every individual within the organization and its external partners with access to sensitive data. All the data for each discrete vendor is then aggregated by the solution to provide an overall risk calculation and profile for every vendor or partner organization. In the screen capture below, we see a representation of a vendor risk management profile for a Privacy Bee for Business customer. On these screens, each vendor organization is assigned a risk score according to the volume of exposure identified among its workforce during the PRA. Columns on this visualization identify important metrics such as:
- Which department the vendor serves within the organization
- The number of employees within the vendor organization with access to your information systems
- The extent to which external data on employees within the organization has been removed from public records
- The percentage of change between privacy protection at the outset versus current state following cleansing activity
The VRM dashboard then derives a risk level for each vendor (which changes as Privacy Bee works to improve privacy within the relevant workforce elements of each vendor). It also provides an aggregate risk score for your entire base of vendors, helping your organization understand its relative risk of suffering a breach via social engineering and other attack vectors. The data can be segmented by internal department to isolate functional areas within your operation where the risk is highest so these problem areas can be targeted for more aggressive action. Or so departmental leaders can be held to internal governance regarding vendor risk levels.
This data can also be used to illustrate to vendors whose risk scores fall below acceptable tolerances their non-compliance with your governance rules/guidelines. Having such visibility and control over privacy risk helps enforce governance and minimum thresholds for acceptable privacy controls within your entire supply chain of vendors, service providers and any other external group with any level of access to your internal information systems. Procurement departments may also use these assessments in their RFx process, to set and enforce compliance goals. Vendors whose privacy scores fall below acceptable tolerances can be removed from service.
The VRM dashboard also provides the ability to understand the progress of risk mitigation activities over time. Either on an aggregate basis or on an individual vendor basis, the visualization illustrates the extent to which efforts to remove vendor-employee PII from accessibility on the internet are having the desired effect on lowering risk.
Want to learn more about how Privacy Bee for Business can help your organization (and your third party partners) from becoming the next victim of a catastrophic attack? Have you already been breached? Contact us today.
