Midnight Blizzard vs Microsoft: a legacy test account and an over-permissioned OAuth app

What happened

In January 2024 Microsoft disclosed that the Russia-linked group Midnight Blizzard (APT29) accessed a small percentage of corporate email accounts, including senior leadership. The entry point was a legacy, non-production test tenant account that lacked multi-factor authentication. From there the attacker abused a legacy OAuth application with elevated access to Microsoft's corporate environment to grant itself mailbox permissions.

Root cause

A password spray succeeded against an old test account that had been forgotten and was not protected by MFA. The escalation then exploited OAuth application consent: an app held broad permissions that, once controlled, opened the door to mailboxes.

The identity lesson

Two classic gaps. Forgotten non-production and legacy accounts are real attack surface, not background noise, and they are exactly where MFA exceptions tend to hide. And OAuth application permissions are standing privilege: an app with broad scopes is a powerful non-human identity that attackers prize.

How to defend

• Enforce MFA with no exceptions, and actively hunt for accounts excluded from policy, especially legacy and test tenants.
• Inventory and review OAuth app consents and permissions; remove unused apps and over-broad scopes.
• Apply least privilege to applications, not just people, and alert on new high-privilege grants.
• Decommission unused tenants and accounts. An orphaned account is a liability.

Why this pattern keeps working

The OAuth half of this intrusion is the durable part, and it recurred through 2026. An application with broad delegated permissions is standing privilege that no access review looks at, because reviews are built around people. Nobody's manager attests to what an OAuth app can read.

Google Threat Intelligence Group reported in August 2026 that three suspected Russian clusters, including one overlapping with APT29, had moved further in this direction: fake "Continue with Google" pages that route through the real login and capture the resulting tokens, and device code phishing against Microsoft and WhatsApp accounts. The end state is the same as Midnight Blizzard's, an attacker holding a legitimate token rather than a password, so a reset changes nothing and the sign-in looks normal in the log.

Separately, Dirk-jan Mollema demonstrated in August 2026 that malware in a signed-in Windows session can drive a Windows Hello for Business key to obtain a Primary Refresh Token and register an attacker-controlled device, satisfying phishing-resistant conditional access along the way.

What to hunt for now

• New OAuth consent grants, especially applications requesting mail or directory scopes, and any grant to an application with no owner.
• Applications holding permissions nobody has used in 90 days, treated as entitlements to be removed rather than as configuration.
• Sign-ins with an empty device ID, which is the artifact of the Windows Hello technique, accepting that incognito sessions look the same.
• Device registrations that follow an authentication within minutes.
• Any account excluded from conditional access policy, with a dated justification. The exemption list is where the actual access model lives.

Related

Guide: what is a non-human identity. Vendors: ITDR, IGA. Glossary: password spraying, privilege escalation.