On 12 January 2024 Microsoft detected that a Russian state actor it tracks as Midnight Blizzard (also known as NOBELIUM or APT29) had been reading corporate email, including mail of senior leadership and the security and legal teams. The intrusion had started in late November 2023. No zero-day was involved. The way in was a password spray against an account that nobody was watching closely.
This write-up walks through the chain as Microsoft described it in its guidance for responders, and maps each step to a control that would have stopped it.
Step 1: a spray built to stay under the alarms
A password spray flips brute force around. Instead of many passwords against one account (which trips lockout), the attacker tries one or two common passwords against many accounts, then waits and repeats. Each account sees only a failure or two, so per-account lockout thresholds never fire.
Microsoft says the actor "tailored their password spray attacks to a limited number of accounts, using a low number of attempts to evade detection and avoid account blocks based on the volume of failures." The attempts came from a distributed residential proxy network, so each request appeared to come from an ordinary home IP address. IP reputation lists and simple "too many failures from one IP" rules see almost nothing.
Lockout policies protect individual accounts. A spray attacks the population. You only see it when you look at failures across the whole tenant over days, not per account over minutes.
Step 2: the account nobody owned
The password that worked belonged to a legacy, non-production test tenant account without MFA. Test tenants and old service accounts are the classic weak spot: they predate current policy, they are excluded from conditional access "temporarily", and nobody gets paged when they sign in.
On its own that account had little value. What made it dangerous was what it could reach.
Step 3: from a test app to production mail
From the test tenant the actor found a legacy test OAuth application that had elevated access to the Microsoft corporate environment. It then:
1. Created additional malicious OAuth applications.
2. Created a new user account to grant consent to those apps in the corporate tenant.
3. Used the legacy app to grant them the Office 365 Exchange Online full_access_as_app role, which allows access to mailboxes.
4. Authenticated as those apps and pulled mail through Exchange Web Services (EWS).
Notice the shift. After step 3 the attacker no longer needs the sprayed password at all. Application credentials don't trigger MFA, don't show up in a user's sign-in history, and survive a password reset of the original account. That is why OAuth persistence is now the standard second move after any cloud account takeover.
How it was found
Microsoft says it identified the activity through EWS activity and its audit logging. Mail access by an app with full_access_as_app is unusual and loud if you log it. The MailItemsAccessed audit event is the one to retain and query.
Controls that break each link
Against the spray
• MFA on every account, including test, break-glass and service accounts. If an account can't do MFA, it should not be able to sign in interactively at all.
• Risk-based conditional access so a sign-in from an unfamiliar residential IP gets challenged.
• Tenant-wide failure analytics: alert on many accounts each failing once or twice from many IPs within a day. Microsoft Entra ID Protection raises password spray detections for this pattern.
• Banned-password lists that block seasonal and company-name passwords, which is what sprays try first.
Against OAuth abuse
• Inventory every app with EWS.full_access_as_app or ApplicationImpersonation. Microsoft's guidance names both. Few apps genuinely need them.
• Restrict who can create apps and grant consent, and require admin consent workflows.
• Alert on new app registrations, new credentials on existing apps, and new consent grants, especially outside change windows.
• Delete legacy and test apps. An unused app with high privileges is pure risk.
Against long dwell time
• Keep mailbox audit logs (including MailItemsAccessed) long enough to investigate months-old access.
• Hunt for mailbox access or SaaS actions from IPs that appear in password-spray detections.
The lesson for smaller teams
Most organisations don't face a nation-state, but the techniques are the same ones commodity crews use. A guessable password plus an account outside MFA is enough. The cheapest fix is to remove passwords from the places where they aren't needed: one-time codes and passkeys can't be sprayed.
osec.one adds one-time-code and Apple/Google sign-in to your app or site, so there is no password to spray. Free, rate limited per IP.
Try passwordless logins