Password spray against a legacy non-production Microsoft test tenant account that lacked MFA gave Midnight Blizzard its late-November 2023 foothold. According to Microsoft's MSRC blog on 19 January 2024, the Russian state-sponsored actor also known as Nobelium then used that account's permissions to reach a very small percentage of corporate email accounts and exfiltrate some emails and attachments. Phishing-proof MFA 2.0 on every workforce and test-tenant path removes the password-only surface that spray needs. It does not undo mailbox rights after a valid session already exists.
For the full attack-chain narrative, read the companion on legacymfa.sucks.
FAQ
Would MFA 2.0 have stopped Midnight Blizzard's password spray?
Yes for initial access. Midnight Blizzard password-sprayed a legacy non-production Microsoft test tenant account that had no MFA, so the login surface was password-only. Phishing-proof MFA 2.0 replaces guessable passwords with device-bound keys that never leave the hardware, so a remote spray has no secret to try and no transferable OTP, SMS code, or push to complete. Enforcing that control on every tenant path, including non-production accounts, closes the credential-phase foothold Microsoft documented. Once the actor already held a valid session under the sprayed account, login MFA could not revoke mailbox permissions that account already had.
Why must test and non-production tenants get the same MFA as production?
Because Midnight Blizzard's Microsoft intrusion started on a legacy non-production test tenant account, not a production admin console. Password spray ignores the label on the tenant. Any workforce or test path that still accepts a password alone is a spray surface. MFA 2.0's model is prevention, not detection: device-bound proof on every identity path that can mint a session, including lab, staging, and forgotten test tenants. Production-only hardening leaves the exact gap this actor used.
Can MFA 2.0 undo corporate email access after the sprayed account signed in?
No. After Midnight Blizzard authenticated as the compromised legacy account, corporate mailbox reach used that account's existing permissions. That is post-authentication access. No login MFA, including phishing-proof MFA 2.0, undoes rights already granted to a live session. Closing the phishable login stops this path. Cleaning up after a legitimate-looking session needs revoke, permission review on test identities, and detection. Microsoft reported no evidence of access to customer environments, production systems, source code, or AI systems. Public reporting does not establish exact mailbox or document counts.
How does MFA 2.0 differ from adding OTP to a legacy test account?
OTP or push still leaves a password to spray and a factor an attacker can later relay, fatigue, or social-engineer. MFA 2.0 is phishing-proof across the identity lifecycle: there is no central password worth spraying, and the server holds only public keys. Device-bound signatures never transit the network as reusable secrets. Bolting SMS or app OTP onto a forgotten test tenant shrinks one failure mode and keeps others. Why legacy MFA was dropped starts from that gap: transferable factors fail remote guessing and coaching; hardware-bound keys remove the guessable surface entirely.
What should defenders change first after a Midnight Blizzard-style spray?
Inventory every Entra ID and Microsoft 365 path that can still authenticate with a password alone, especially legacy, test, and non-production tenants, then enforce phishing-proof device-bound MFA there before chasing exotic detections. Microsoft stated the attack was not the result of a vulnerability in its products or services. The documented gap was a no-MFA legacy test tenant account exposed to spray. Stop that class of foothold at authentication. Residual risk after any successful sign-in is session revoke and least privilege on accounts that can reach corporate mail, not a stronger prompt on a password that should not exist.
