Snowflake customer accounts breached throughout 2024 largely reused credentials from earlier leaks. Attackers simply replayed the captured username-and-password pairs because the majority of those accounts had no second factor enabled at all.
Once authenticated, the same static credentials granted full access to customer data warehouses. No hardware-bound challenge or cryptographic proof of possession interrupted the sessions, so enumeration, extraction, and persistence proceeded without further interaction.
How Reusable Credentials Created the Attack Path
Infostealer malware on employee devices harvested Snowflake login pairs that required no additional verification. Because these credentials carried no binding to any specific hardware, they remained valid from any location after capture. The authentication system treated every login attempt identically, whether it originated from the legitimate workstation or from an attacker’s machine.
This design meant that prior exposure in credential dumps directly translated into active compromise. Verizon DBIR data confirmed the pattern: the operators needed no real-time phishing or additional secrets once the initial pairs were obtained.
Why Standard MFA and Passkey Deployments Often Leave Exposure
Many organizations treat the addition of a second factor or FIDO2 passkeys as sufficient protection. In practice, these controls frequently retain registration, recovery, or fallback paths that still depend on copyable secrets such as email links, SMS codes, or backup passwords. When attackers already possess valid credentials, the absence of an enforced device-specific challenge at login removes the remaining safeguard.
Even well-deployed FIDO2 implementations can retain residual risk if account recovery steps reintroduce reusable values that an infostealer can intercept.
Device-Bound Public-Key Authentication Prevents Replay
MFA 2.0 replaces reusable credentials with public-key cryptography in which the private key never leaves the secure enclave or TPM of the device that generated it. The corresponding public key is registered with the identity provider, but it cannot be used to impersonate the account without the original hardware. This property applies across registration, device onboarding, routine authentication, and decommissioning.
Because no central database stores a copyable secret, an infostealer on a different machine obtains nothing usable. The same-device model requires no secondary hardware token. When a device is lost or retired, the provider simply removes the registered public key; no password reset or secret rotation is needed.
The result is prevention rather than detection. The attack vector exploited in the Snowflake incidents—replaying stolen usernames and passwords—cannot succeed when the factor the attackers need to steal does not exist.
