What to Learn from the Snowflake Breach?

The recent Snowflake incident has sent shockwaves across the cybersecurity world—and not because the platform was breached. Despite initial fears, investigations confirmed there was no exploit or vulnerability in Snowflake’s infrastructure. Instead, attackers accessed over 165 customer environments using valid credentials stolen through infostealer malware, some dating back years.

This wasn’t a high-tech hack—it was a breakdown of basic security hygiene. Victims included major brands like AT&T, Santander, Ticketmaster, and LendingTree. The threat group behind the attack, UNC5537 (aka ShinyHunters), capitalized on unrotated passwords, absent MFA, and contractor devices lacking proper controls. Ransom demands followed, and some organizations reportedly paid up.

The breach serves as a sharp reminder that cloud security is a shared responsibility. Snowflake secured its platform, but customers failed to secure their credentials and access paths. When attackers can log in with old passwords and face no MFA or network restrictions, even strong platforms become vulnerable.

In this blog, we break down what really happened, separate fact from fear, and share key lessons every organization should act on now—because in the cloud, your weakest link is everyone’s risk.

The Nature of the Incident

On June 12, 2024, Snowflake disclosed a targeted campaign affecting numerous customer accounts. Headlines quickly labeled it a breach of Snowflake itself—but investigations revealed a more precise (and more alarming) truth: the platform wasn’t hacked. Customers were compromised.

There was no vulnerability, zero-day, insider threat, or platform misconfiguration. Instead, attackers used valid usernames and passwords—stolen via infostealer malware as far back as 2020—to directly log into customer Snowflake environments.

The malware families involved were prolific: VIDAR, RISEPRO, REDLINE, RACOON STEALER, LUMMA, and METASTEALER. These tools silently siphon stored browser credentials, cookies, session tokens, and autofill data. Once harvested, the data is trafficked through dark web marketplaces and Telegram channels—sometimes long after initial infection.

A recurring theme? Contractor systems. Many stolen credentials originated from contractor devices that doubled as personal machines—lacking enterprise-grade monitoring, endpoint protection, and security policies. These endpoints were often compromised via cracked software, torrenting, or unpatched vulnerabilities.

Critically, most of the exposed credentials were never rotated or expired, and many accounts lacked MFA, making them low-effort, high-reward targets.

Key Points:

• Threat actors used long-exposed, valid credentials to access Snowflake customer environments.
• Infostealer malware included VIDAR, RISEPRO, REDLINE, RACOON STEALER, LUMMA, and METASTEALER.
• Over 80% of affected accounts had prior credential exposure before the campaign began.
• Contractor-owned or unmanaged devices were a common infection vector.
• MFA was missing or unenforced on many accounts, enabling easy unauthorized access.

Detailed Findings

Mandiant’s Investigation

After the incident surfaced, Snowflake brought in Mandiant to lead a forensic investigation. The activity was attributed to UNC5537, a financially motivated threat group also known as ShinyHunters, notorious for credential theft and extortion. Their tactics in this case were simple but effective: use stolen credentials from infostealer malware to access customer environments.

Mandiant found that some credentials dated back to 2020—harvested from infostealer-infected machines and never rotated. Over 165 Snowflake customer environments were impacted, including high-profile firms like AT&T, Ticketmaster, and Santander.

The malware used included VIDAR, RISEPRO, REDLINE, RACOON STEALER, LUMMA, and METASTEALER, which silently extract credentials from browsers and send them to attacker-controlled servers. Alarmingly, over 80% of the accessed accounts had prior exposure in breach datasets.

Many of the logins exploited were “ghost” accounts—local password-based accounts still active even in environments using SSO. These paths bypassed identity federation and MFA when improperly configured.

Contractor devices were a recurring weak point. Often used for both personal and business purposes, they lacked endpoint protection and were infected via torrenting, gaming, or pirated software.

Snowflake’s Response

While Mandiant tracked attribution and scope, Snowflake issued alerts and began working with affected customers. One internal finding stood out: a legacy demo account, owned by a former employee, had been accessed. It held no sensitive data but lacked MFA and SSO—highlighting how unmonitored identities pose risk.

Snowflake emphasized this was not a platform breach, but a shared responsibility failure—with missing MFA, reused credentials, and misconfigured access controls on the customer side.

In response, Snowflake:

• Enhanced detection and alerting across customer accounts.
• Promoted phishing-resistant MFA (e.g., FIDO2 keys).
• Urged customers to remove unused local logins.
• Recommended IP allow-lists and stricter identity controls.

Separately, law enforcement arrested two individuals tied to UNC5537—one in Canada, another in Turkey—both linked to the campaign and extortion efforts.

Snowflake breach

Key Factors Contributing to the Breach

The Snowflake campaign wasn’t driven by zero-days or platform flaws—it was a slow, scalable compromise built on exposed credentials, poor endpoint hygiene, and cloud misconfigurations. Attackers didn’t hack in—they logged in using long-compromised credentials.

1. Weak or Misconfigured MFA

One of the biggest failures was the lack of enforced Multi-Factor Authentication (MFA). While Snowflake supports MFA, many impacted environments didn’t enable it across all login paths—particularly local user accounts that bypassed SSO. That meant attackers could authenticate with just a username and password, facing no secondary challenge.
Even large enterprises left password-based logins active, exposing themselves to reuse of stale credentials.

2. Old, Unrotated, and Orphaned Credentials

Many credentials dated back to 2020 or earlier and were still valid. Mandiant found them in malware logs and breach databases. Some accounts belonged to former employees or contractors but hadn’t been offboarded or expired. This failure to rotate, expire, or audit credentials created easy, silent access points.

3. No IP Allow Lists or Geo-Restrictions

Most affected environments didn’t restrict access by IP. That meant logins from VPNs, Tor nodes, and offshore VPS providers like ALEXHOST went unchecked. Basic IP allow-lists or geofencing could have prevented or flagged many of these access attempts.

4. Mass Credential Harvesting via Infostealers

The campaign leaned heavily on infostealer malware—VIDAR, REDLINE, LUMMA, RACOON, and others—which silently steal browser-stored credentials. Over 80% of compromised accounts had previously appeared in infostealer logs before the breach campaign even began.

These credentials were not newly stolen—they were collected over time, quietly traded, and reused. That’s what made this operation so scalable: no phishing, no exploits—just logging in with what was already exposed.

In short, the breach succeeded not because Snowflake failed technically—but because basic, preventable security lapses went unaddressed for too long.

Factors Contributing to the Breach

Root Cause

The Snowflake campaign stemmed from a fundamental identity failure: attackers used long-exposed, valid credentials harvested by infostealer malware over months or years. These credentials—circulated via dark web forums and Telegram—originated largely from contractor and third-party devices used for both work and personal activities.

Lacking EDR, patching, or usage restrictions, these endpoints were prime targets for malware like VIDAR, LUMMA, and REDLINE. Infections often stemmed from torrenting, cracked software, or gaming.

Critically, attackers didn’t exploit Snowflake’s platform. Instead, they leveraged “ghost” login paths—local username/password accounts that bypassed SSO and MFA in some customer setups. Combined with unrotated credentials and dormant accounts, this gave attackers seamless, persistent access.

The result: a low-effort, high-impact campaign where threat actors simply logged in using forgotten keys—without tripping alarms or needing advanced exploits.

Reconnaissance and Data Exfiltration

Once inside, attackers didn’t need to move laterally or escalate privileges—the credentials they used already had direct access to sensitive Snowflake environments. They relied on native tools like SnowSight (UI) and SnowSQL (CLI) to navigate databases, stage files, and exfiltrate data with minimal friction.

In several cases, they also used a custom enumeration tool called FROSTBITE (formerly referred to as “rapeflake”) to automate database mapping and asset discovery.

Key SQL commands used included:

• SHOW TABLES: To list databases and tables

• SELECT * FROM [table]: To extract full datasets

• CREATE TEMPORARY STAGE: To set up internal staging areas

• COPY INTO: To move and compress data for exfiltration

• GET: To download staged files to attacker-controlled systems or cloud storage like MEGA

Because attackers used legitimate tools and commands, their activity often blended in with normal usage—especially in environments lacking proper logging or anomaly detection.

Attribution and Infrastructure

The campaign was attributed to UNC5537, a financially motivated threat group now confirmed to be part of the ShinyHunters collective—responsible for several major data breaches and credential dumps over the years. Mandiant has tracked their activity since May 2024.

UNC5537 targeted over 165 organizations, operating with strong OPSEC. They frequently rebranded across Telegram, dark web forums, and breach marketplaces to evade detection.

To stay anonymous, the group used privacy-focused VPNs like Mullvad and PIA, along with bulletproof hosting providers like ALEXHOST SRL. Stolen data was routed through international VPS relays and cloud storage platforms such as MEGA, enabling large-scale exfiltration without detection.

Law enforcement operations have led to the arrest of two individuals tied to UNC5537—one in Canada and another in Turkey—highlighting global coordination in response to the group’s activity.

UNC5537’s modular tooling, evasive tactics, and infrastructure setup reflect a scalable, well-organized campaign exploiting widespread credential reuse and lax endpoint security.

Outlook and Implications

The Snowflake campaign highlights a harsh truth: attackers don’t need zero-days when exposed credentials and misconfigured access paths offer a clear way in. Snowflake’s infrastructure held firm, yet over 165 customer environments were compromised—many through orphaned accounts that bypassed SSO and lacked MFA.

This wasn’t a breach of systems, but a breach of discipline. Attackers used legitimate tools to explore and exfiltrate data, slipping past detection in poorly monitored environments. It proves that credential-based attacks are not rare—they’re industrialized and scalable.

Cloud platforms aren’t inherently insecure, but they magnify the impact of neglected security hygiene. As adoption grows, so does the risk surface—and so does regulatory pressure. Arrests have already begun, but enforcement alone won’t stop technical debt.

The real danger isn’t complexity—it’s complacency. When basics like MFA, credential rotation, and contractor oversight are skipped, even robust platforms become soft targets. That’s the lesson organizations must internalize—before it’s too late.

Lessons Learned

The Snowflake campaign wasn’t fueled by zero-days or advanced malware—it thrived on neglected fundamentals. Stolen credentials, legacy login paths, unsecured contractor devices, and weak enforcement of cloud policies were the real enablers. Even the most secure platforms falter when customers ignore the basics.

Here are three urgent takeaways for security teams:

1. Enforce Multi-Factor Authentication (MFA)

Many breached accounts lacked MFA—or used login paths that bypassed it (e.g., local Snowflake accounts that didn’t route through SSO). This gave attackers seamless access using old but valid credentials.

Action Points:

• Enforce MFA across all accounts, including service and legacy users.
• Disable password-based logins when SSO is available.
• Use phishing-resistant methods like FIDO2 keys or passkeys.
• Monitor for login flows that bypass MFA.

2. Lock Down Contractor and Third-Party Devices

A large number of compromised credentials came from contractor systems infected years ago. These devices often lacked EDR, patching, or policy enforcement—and were used for risky personal activities.

Action Points:

• Prohibit personal use on systems accessing corporate resources.
• Require EDR, MDM, and patching on all third-party endpoints.
• Audit credentials and session age for external users.

3. Own the Shared Responsibility Model

Snowflake’s platform wasn’t breached—customer-side gaps were. This reinforces the need for proactive ownership of identity, access, and configuration security.

Action Points:

• Audit login methods and enforce least-privilege access.
• Use conditional access, allow-lists, and secure defaults.
• Align with Snowflake’s security guidance and automate posture management.

Key Recommendations

1. Enforce MFA—and Eliminate Bypass Paths

Make phishing-resistant MFA mandatory for all users, including contractors and service accounts. In the Snowflake campaign, attackers exploited login paths that bypassed MFA and SSO.

Action Points:

• Enforce MFA across all account types.
• Disable local Snowflake logins where SSO is enabled.
• Prefer hardware keys (FIDO2) or passkeys over OTP or SMS.

2. Rotate Credentials and Audit Ghost Accounts

Many stolen credentials were years old yet still active. Regular rotation and auditing help reduce long-term exposure.

Action Points:

• Set rotation and expiration policies for passwords, API keys, and tokens.
• Audit for dormant accounts or stale tokens unused for 30–90 days.
• Automate detection of inactive credentials.

3. Restrict Access by IP and Geography

Snowflake attackers often connected from VPS nodes and anonymized IPs. Geo-blocking and allow lists can limit exposure.

Action Points:

• Create IP allow lists for user and admin access.
• Use geofencing to block high-risk regions.
• Monitor for access via known VPNs or proxies.

4. Monitor for Credential Exposure

Infostealer malware logs were key in this breach. Proactive monitoring helps stop unauthorized access early.

Action Points:

• Scan dark web, breach data, and infostealer logs (e.g., RedLine, Lumma, Raccoon).
• Revoke exposed credentials and kill active sessions.
• Use commercial or open-source feeds to automate alerts.

Key Recommendations

Cloud Security Is a Two-Way Street

The Snowflake breach is a blunt reminder: even the most trusted, secure-by-default platforms can be undone by forgotten credentials and misconfigured access paths. This wasn’t a case of advanced exploits or zero-days. The attackers didn’t break in—they logged in using years-old keys pulled from infected machines and unmonitored contractor systems.

Cloud providers like Snowflake offer robust tooling, secure infrastructure, and clear guidance. But none of that matters if customers fail to enforce MFA, rotate credentials, monitor access, or lock down legacy login paths that bypass SSO entirely.

As cloud adoption scales, so does complexity—and the risk of operational blind spots. With over 165 organizations impacted, and attackers exploiting simple gaps like unused internal accounts and ghost logins, the lesson is crystal clear: security isn’t a feature—it’s a process.

The good news? These failures are fixable. The tools exist. The controls are known. What’s missing is execution at scale.

Because the weakest link in cloud security isn’t always the platform—it’s the part you assumed someone else was handling.