Was Snowflake itself hacked?

Mandiant's investigation attributed the incidents it handled to compromised customer credentials, and found no evidence of a breach of Snowflake's enterprise environment.

Why do old credentials still work?

Because nothing forced a change. Expiry dates and rotation turn old leaks into dead ends.

What is an infostealer?

Malware that gathers saved passwords, cookies and other data from an infected computer and sends them to the attacker. Mandiant names several families in its report.

Is a strong password enough?

No. A strong password that has been stolen is just as usable. MFA and network limits matter because they work even after a password leaks.

Security

Hundreds of organisations were targeted through stolen logins, not a hacked platform

Old passwords taken from infected computers opened data warehouses. The three weaknesses are easy to check on your own systems.

Published October 20267 min read

Jump to the account audit

A login form with a username field and a masked password field

Photo: Username and password 20170626, Santeri Viinamäki, CC BY-SA 4.0, via Wikimedia Commons.

In 2024, a financially motivated group that Mandiant tracks as UNC5537 stole data from customers of the Snowflake cloud data platform and tried to extort them. Mandiant's report says the group targeted hundreds of organisations worldwide, and that Mandiant and Snowflake notified approximately 165 potentially exposed organisations.

The part that matters most for everyone else is how they got in. Mandiant says it found no evidence the access came from a breach of Snowflake's own enterprise environment. Every incident it responded to traced back to compromised customer credentials.

How the logins were obtained

According to the report, the credentials came mostly from infostealer malware: programs that run on an infected computer and collect saved passwords and session data. Mandiant names several families, including VIDAR, RISEPRO, REDLINE, RACOON STEALER, LUMMA and METASTEALER. It identified hundreds of customer Snowflake credentials exposed this way since 2020, and says at least 79.7% of the accounts the attacker used had prior credential exposure.

Some of the infections were on contractor systems used for personal activities as well as work. Mandiant notes that such devices, when they access multiple organisations, present a significant risk.

Three weaknesses, repeated across victims

Shared factor	What Mandiant reports	Why it mattered
No multi-factor authentication	The impacted accounts did not have MFA, so a valid username and password was enough.	A stolen password alone opened the account.
Credentials not rotated	Credentials seen in infostealer output were still valid, in some cases years later. The earliest infection date tied to a used credential was November 2020, and some credentials had not been rotated for as long as four years.	An old leak stayed useful for years.
No network allow lists	The instances did not limit access to trusted locations.	The attacker could log in from anywhere, including through commercial VPN services.

None of these needed a clever exploit. Each is a configuration choice, which is why the same list applies to a PostgreSQL server, a SaaS analytics tool or a shared reporting database.

What the attacker did with the access

Mandiant describes use of the platform's own web interface and command-line tool, plus a publicly available database management tool, DBeaver Ultimate, to run queries across instances. A utility tracked as FROSTBITE performed reconnaissance queries, such as listing users, current roles, IP addresses and session IDs. Stolen data was then moved to infrastructure the attacker controlled.

A database client is a normal tool. A login from an ordinary client, with valid credentials, from a VPN address looks a lot like a legitimate analyst, which is why logging and baselines matter.

List who can log in, then ask why

This audit was run on PostgreSQL 16. It lists roles that can log in, which are superusers, and which have no expiry date. Run it as an administrator.

SQL

SELECT rolname, rolsuper, rolcanlogin, rolvaliduntil
FROM pg_roles
WHERE rolcanlogin
ORDER BY rolsuper DESC, rolname;

-- Example output (names are fictional):
--    rolname   | rolsuper | rolcanlogin | rolvaliduntil
-- -------------+----------+-------------+---------------
--  dba_admin    | t        | t           |
--  agent_dev    | f        | t           |
--  llm_reader   | f        | t           |

A login with no expiry, a superuser nobody can explain and a shared account named after someone who left are each worth a conversation. To list only the logins that never expire:

SQL

SELECT rolname, rolsuper
FROM pg_roles
WHERE rolcanlogin AND rolvaliduntil IS NULL;

Set an expiry on a role so a forgotten password stops working on its own:

SQL

ALTER ROLE llm_reader VALID UNTIL '2027-01-01';

To see where connections are coming from right now, query the activity view. Look for addresses you do not recognise:

SQL

SELECT usename, client_addr, application_name, state
FROM pg_stat_activity
WHERE client_addr IS NOT NULL;

Limit where logins can come from

In PostgreSQL, the file pg_hba.conf decides who may connect from which addresses and how they must authenticate. This sketch allows one role from one office network, requires TLS and uses SCRAM password hashing. It was not run in this article; check the syntax against the documentation for your version.

pg_hba.conf

# TYPE    DATABASE  USER        ADDRESS          METHOD
hostssl   app       analyst     203.0.113.0/24   scram-sha-256
# Everything else is rejected by default if no other line matches.

A rotation drill

01List every credentialHumans, applications, scripts, notebooks, BI tools and contractors. If you cannot list it, you cannot rotate it.
02Rotate the shared and the oldStart with service accounts and anything that has not changed in a year.
03Add expiryGive roles a VALID UNTIL date or move to short-lived tokens.
04Turn on MFA or SSOFor every human who reaches the data, directly or through a tool.
05Restrict the networkAllow only known addresses, and review the list every quarter.
06Watch for exportsAlert on large result sets, new client applications and logins from new places.

The personal-device problem

Infostealers collect from whatever the user has saved, on whatever device is infected. If a contractor's personal laptop holds a saved warehouse login, rotating the password at the platform is only half the fix. Decide which devices may hold which credentials, and prefer sessions that expire to passwords that are saved.

What this does not show

It does not say every one of the 165 notified organisations lost data of the same kind. Mandiant reports exposure, not uniform loss.
It does not mean cloud platforms are unsafe. It shows that default or lax account settings on customer accounts were the weak point in these incidents.
It does not say MFA alone would have stopped every theft. Mandiant lists it as one of three shared factors.

Hunt in your own login records

Mandiant's report lists client application names it saw in the campaign, including DBeaver, SnowSQL and a custom utility, and notes that its threat-hunting guide uses queries over login and query history, where default retention for the relevant views covers 365 days. Whatever platform you use, the idea transfers: keep login records long enough to look back, and ask which clients and addresses are new.

This SQLite sketch finds users whose first-ever use of a client application, or of an IP address, is recent. It was run on sample data.

SQL

SELECT e.user, e.client_app, MIN(e.at) AS first_seen
FROM login_event e
GROUP BY e.user, e.client_app
HAVING MIN(e.at) >= DATE('now', '-7 day');

-- Same idea for addresses
SELECT e.user, e.ip, MIN(e.at) AS first_seen
FROM login_event e
GROUP BY e.user, e.ip
HAVING MIN(e.at) >= DATE('now', '-7 day');

A new client on its own is not suspicious. A new client, from a new address, at an unusual hour, followed by a large read, is worth a message to the account owner. Combine the signals so that people are not paged for every laptop upgrade.

Rotating credentials without an outage

People avoid rotating shared credentials because they fear breaking something. The way around that is to make rotation routine, with two valid credentials during the changeover.

01Create the new credentialAdd a second login or token for the same service account, with the same permissions.
02Switch the callers one at a timeUpdate the scheduler, the dashboard, the script. Test each one.
03Watch for the old credential being usedAnything still using it is something you forgot.
04Disable, then delete the old credentialDisable first and wait a few days. Delete once nothing complains.
05Record the datePut the next rotation in a calendar. A rotation policy no one tracks is a wish.

Mandiant found credentials that had not been rotated for as long as four years. Even a rotation every year would have made many of those stolen passwords worthless by the time they were used.

Contractors, personal devices and shared accounts

Mandiant observed initial compromises on contractor systems used for personal activities, and notes that such devices present a significant risk when they access several organisations. The practical response is to separate what a contractor can reach from what a laptop can store.

Give each contractor a named account with the minimum access, and an end date.
Do not share one login among several people. Shared accounts hide who did what.
Prefer access through a managed, monitored environment over saved passwords on a personal device.
Remove access the day an engagement ends, and check that you did.

Control	Would it limit a stolen password?	Effort
MFA or single sign-on on every human login	Yes: the password alone no longer works.	Medium
Network allow list	Yes: it works only from trusted locations.	Low to medium
Password rotation and expiry	Partly: the stolen password dies sooner.	Low
Short-lived tokens	Yes: stolen tokens expire quickly.	Medium
Login and query monitoring	Detects use, but does not prevent it.	Medium

Mandiant recommends enforcing MFA universally, rotating credentials, using network allow lists, alerting on abnormal access and securing contractor access. The table is a way of ordering the work; nothing in it is a substitute for doing the first two.

Questions that come up

Was Snowflake itself hacked?: Mandiant's investigation attributed the incidents it handled to compromised customer credentials, and found no evidence of a breach of Snowflake's enterprise environment.
Why do old credentials still work?: Because nothing forced a change. Expiry dates and rotation turn old leaks into dead ends.
What is an infostealer?: Malware that gathers saved passwords, cookies and other data from an infected computer and sends them to the attacker. Mandiant names several families in its report.
Is a strong password enough?: No. A strong password that has been stolen is just as usable. MFA and network limits matter because they work even after a password leaks.