‍Midnight Blizzard, Snowflake Incidents Underscore the Need for Stronger Identity Security, MFA Coverage

What Happened to Microsoft: The Midnight Blizzard Breach

On January 19, 2024, Microsoft publicly disclosed that its security team had detected a nation-state intrusion on its corporate systems eight days earlier, on January 12. Microsoft attributed the attack to Midnight Blizzard, the Russian state-sponsored group also tracked as Nobelium, a threat actor with a long history of social-engineering campaigns, including prior activity conducted over Microsoft Teams.

According to Microsoft's account, the attack began in late November 2023, when Midnight Blizzard used a password spray attack (attempting a small number of commonly used passwords across a large number of accounts, rather than many passwords against one account) to compromise a legacy, non-production test tenant. That single foothold was enough: the threat actor used the compromised account's permissions to move laterally into a small number of Microsoft corporate email accounts, including some belonging to senior leadership, and members of the legal and cybersecurity teams. Microsoft confirmed that some emails and attachments were exfiltrated, and said the group appeared to be searching specifically for information about how Microsoft was tracking Midnight Blizzard itself.

Critically, Microsoft stated the breach was not caused by a product vulnerability. It came down to a legacy test account that lacked modern authentication controls, a single-factor gap that gave a well-resourced nation-state actor everything it needed to get in.

Security researchers who examined the case afterward, including BeyondTrust's Morey Haber, pointed to the same conclusion: the incident was preventable through basic identity controls, including enforced MFA (ideally phishing-resistant methods like FIDO2, not SMS or email codes), least-privilege access, and identity threat detection that could catch anomalous logins on dormant or legacy accounts before they escalated.

What Happened at Snowflake: A Customer-Side Credential Campaign

The Snowflake story unfolded differently and, in its first 24 to 48 hours, was clouded by conflicting claims. On May 31, 2024, security vendor Hudson Rock published a post alleging a massive breach of Snowflake's own environment, naming a long list of well-known companies as potential victims. Snowflake disputed the characterization quickly, stating it had found no evidence that its platform had been compromised through any vulnerability or misconfiguration.

What Snowflake did confirm was narrower but still significant: a threat actor had obtained personal credentials belonging to a former Snowflake employee and used them to access a demo account, one that was not connected to Snowflake's production or corporate systems and, notably, was not protected by Okta or MFA, unlike Snowflake's own corporate and production environments.

Independent analysis pieced together a clearer picture of what actually happened. A group tracked as ShinyHunters had been buying stolen credentials harvested by infostealer malware, malicious software that silently lifts saved passwords, session tokens, and browser data from an infected device. Some of those credentials belonged to individual customer users at organizations including Santander and Ticketmaster, whose Snowflake accounts did not have MFA enforced. Using those credentials, the attackers logged directly into the affected customer environments and exfiltrated data. No exploit was required, just a valid username and password against an account with no second factor. Separately, credentials tied to a Snowflake sales engineer's infected machine gave the attackers access to internal ServiceNow ticketing data, which is where many of the other company names later associated with the story actually originated, as customers mentioned in support tickets, not as breached Snowflake tenants themselves.

The through line in both threads of the Snowflake story was identical to Microsoft's: valid credentials plus no MFA equaled a successful breach. Snowflake accounts that did have MFA enforced were not compromised in this campaign.

Why These Two Incidents Told the Same Story

Between Midnight Blizzard, the Snowflake customer breaches, and related identity-based compromises that same season affecting the SEC's and Mandiant's social media accounts (both linked to accounts without two-factor authentication), a clear pattern had formed by mid-2024:

• Attackers were logging in, not breaking in. IBM's threat intelligence found that abusing valid accounts had become attackers' most common entry point, and identity-related attacks had risen 71% year over year.
• MFA coverage, not just MFA policy, determined the outcome. In both the Microsoft and Snowflake cases, the compromised accounts were the ones that fell outside MFA enforcement: a legacy test tenant in Microsoft's case, individual customer and demo accounts in Snowflake's.
• Visibility was the missing piece. Neither organization lacked an MFA policy. What was missing was real-time, ground-truth visibility into which specific accounts, including legacy, dormant, or non-production ones, actually had MFA enforced versus which had quietly fallen outside that coverage.
• CrowdStrike's broader research backed this up: 80% of breaches that year involved compromised identities, reinforcing that identity, not infrastructure, had become the primary battleground.

The Identity Security Gap Behind Both Incidents

Having run into this exact problem directly, first at Microsoft, then as Chief Trust Officer at Salesforce, where I made MFA mandatory for every customer, I saw the same gap play out over and over: security teams could tell you their MFA policy, but not their MFA coverage. Knowing what should be protected is not the same as knowing, account by account, what actually was.

At Salesforce, closing that gap meant two things. First, eliminating weak factors like SMS and email-based one-time codes, which were no longer resistant to modern attack techniques like SIM-swapping. Second, and harder, building the ability to see, in real time, exactly where MFA had been successfully deployed and where coverage still had holes, instead of relying on manual, application-by-application audits that were stale the moment they were finished.

That second problem is what led me to co-found Oleria. Oleria's Trustfusion platform normalizes MFA and access data across an organization's connected SaaS applications into a single, continuously updated view, surfacing accounts with no MFA at all, as well as accounts technically "covered" by weak factors that still left them exposed. For CISOs, that meant replacing outdated, point-in-time reports with an always-current picture of exactly where identity risk was concentrated, so gaps like the ones exploited at Microsoft and Snowflake could be closed before an attacker found them.

Frequently Asked Questions

Did Midnight Blizzard exploit a vulnerability in Microsoft's software?
No. Microsoft stated explicitly that the breach was not the result of a vulnerability in its products or services. It resulted from a password spray attack against a legacy test account that lacked modern authentication controls.

Was Snowflake's platform itself hacked?
Snowflake maintained that it found no evidence its platform was compromised through a vulnerability, misconfiguration, or breach of its own systems. The confirmed access involved a demo account tied to a former employee's stolen credentials, and separately, customer accounts that were compromised using credentials stolen from those customers' own users via infostealer malware, not a flaw in Snowflake's product.

What did the Microsoft and Snowflake incidents have in common?
Both ultimately came down to accounts, a legacy test tenant at Microsoft, and demo and customer accounts tied to Snowflake, that lacked MFA enforcement. Attackers used valid, stolen or guessed credentials rather than technical exploits to gain access.

Would MFA have prevented these breaches?
In both cases, the specific accounts that were compromised lacked MFA, while accounts and systems with MFA enforced were not breached through this method. That made MFA coverage, full, verified coverage, not just policy, one of the clearest lessons from both incidents.