Old infostealer logins opened Snowflake accounts that lacked MFA

What happened

Beginning in April 2024, Mandiant, part of Google Cloud, identified a pattern of unauthorized access to customer accounts on the Snowflake cloud data platform. Its published analysis attributes the activity to a financially motivated cluster it tracks as UNC5537 and states that the access relied on customer credentials previously stolen by infostealer malware, including several well-known families, some of which had been circulating since November 2020 and remained valid, unrotated, for as long as four years. Mandiant reports that none of the affected accounts had multi-factor authentication enabled and that Snowflake had, by design, allowed customers to configure network access controls that in these cases were not applied. By 22 May 2024, Mandiant had notified Snowflake of the broader pattern and began notifying roughly 165 potentially affected organizations.

One of those organizations was Live Nation Entertainment. Its own filing with the Securities and Exchange Commission states that on 20 May 2024 it identified unauthorized activity within a third-party cloud database environment, primarily affecting its Ticketmaster subsidiary, and that a threat actor later offered the data for sale. The filing describes the company notifying law enforcement and beginning regulatory and user notifications.

Confidence and limits

Mandiant's report and Live Nation's own securities disclosure are independent primary accounts that describe the same underlying pattern: credential theft unrelated to Snowflake's own systems, compounded by the absence of multi-factor authentication on the affected accounts. Mandiant's cluster attribution to UNC5537 is the firm's own analytic judgment, not a criminal court finding, and the documents reviewed here do not name or describe the outcome for any individual alleged to be responsible.

Why it mattered

The campaign showed that a cloud platform can be functionally sound while remaining exposed through customer-side authentication gaps, since Snowflake's own controls, including MFA and network policies, existed but were not required by default at the time. Because credentials can remain valid for years after an initial infostealer infection with no reuse by the account owner, a security posture that relies on the assumption that old, unused credentials are harmless is not supported by this case.

Defensive takeaway

Enforce multi-factor authentication and network allow-listing on every account with access to shared cloud data platforms as a default, not an opt-in, and periodically rotate or revoke credentials tied to accounts that have not authenticated recently.

• Can we confirm that multi-factor authentication is enforced, not merely enabled, for every account with access to our cloud data platforms?
• Do we have a process to detect and rotate credentials that appear in infostealer or credential-dump intelligence feeds, even years after they were reported?
• Have we reviewed our cloud vendor's default security posture against what it recommends as a best practice, since the two are not always the same?

Snowflake's own documentation, current as retrieved 16 September 2026, records that accounts created after a 2024 policy change require multi-factor enrollment by default for password-based sign-in, a shift that, whatever its stated rationale, addresses precisely the gap this campaign exploited.