patch&proof.
← The dispatch

cloud / Archive analysis

Snowflake customer intrusions traced to stolen credentials, not a platform breach

Mandiant's 2024 investigation separated cloud-service compromise from compromise of accounts using that service.

Historical backfill · prepared 16 September 2026. Dates below describe the source or event; this is a local review edition.
Original figure from Mandiant’s June 2024 investigation; it reflects the report’s investigative scope. Image: Mandiant / Google Cloud ↗Source image · rights/provenance review pending

Incident brief

Mandiant reported in June 2024 that an actor it tracked as UNC5537 had accessed multiple organizations' Snowflake customer instances and sought to steal and extort data. In the incidents Mandiant investigated, access traced to customer credentials stolen by infostealer malware, sometimes years earlier. It said it had found no evidence that unauthorized access to these accounts stemmed from a breach of Snowflake's enterprise environment. This distinction matters: a common service can be the location of many customer losses without the provider's core infrastructure being the initial intrusion point.

What investigators observed

Mandiant identified three recurring conditions in the affected instances: accounts without multifactor authentication, credentials that remained valid after theft, and no network allow lists restricting access to trusted locations. Its reporting drew from incident response engagements and threat intelligence, not a complete audit of every Snowflake customer. The actor's label and motive are Mandiant's assessment. The source also described notifications to potentially exposed organizations, a wider group than confirmed compromises in its own response cases.

Defensive reading

Review service accounts and human accounts separately. Ask whether credential material used outside a managed device could be harvested and whether a stolen password alone permits high-volume access. Enforce stronger authentication where supported, rotate credentials after exposure, narrow network paths and alert on unusual export behavior. A historical infostealer event should remain relevant to a current cloud account if the credential was never changed. Asset owners should understand which datasets sit in each instance and which integrations can read them, so a suspected export can be investigated without guessing at scope.

What remains bounded

The report does not prove that every exposed account was used or that one control alone would have stopped every attack. It also does not establish a single universal cause for unrelated Snowflake incidents. The lesson is a shared-responsibility one: provider security and customer identity configuration are different layers, and a cloud incident report must say which layer the evidence actually implicates.

Evidence & dates

Follow the source.

Mandiant case visibility; no provider enterprise breach found in its investigated campaign, not a universal attestation for all customers.

Source published
2024-06-10
Event date
No single confirmed day assigned
Site publication
Unpublished · local review
UNC5537 Targets Snowflake Customer Instances for Data Theft and Extortion
Make it useful

Turn the reading into a decision.

Open the interactive lab ↗
Search the evidence
Source image / inspection view

View original source ↗Local review · rights and provenance pending owner approval