Breach Teardown
What Caused the Microsoft Midnight Blizzard Breach?
A Russian state actor read Microsoft senior leadership email for about two months. The entry point, per Microsoft’s own disclosure: a password spray against a legacy, non-production test tenant account with no MFA, and a legacy OAuth application whose elevated permissions bridged that forgotten tenant into the corporate environment.
- Scale
- Senior leadership and security team mailboxes, ~2 months of access
- Attack vector
- Password spray on a legacy tenant, over-privileged OAuth app
- IAM domains implicated
- Auth/SSO, Cloud, Security
- Domino controls hit
- 2 of 4
The Incident
What Happened
On January 19, 2024, Microsoft disclosed that Midnight Blizzard (also tracked as NOBELIUM and APT29, attributed to Russia’s SVR) had accessed corporate email accounts, including members of senior leadership and employees in cybersecurity and legal functions. Access had begun in late November 2023 and was detected on January 12, 2024.
Per the Microsoft Security Response Center’s account, the actor used a low-and-slow password spray, routed through residential proxies to evade detection, to compromise a legacy non-production test tenant account that did not have multi-factor authentication enabled. From that foothold the actor compromised a legacy test OAuth application with elevated access to the corporate environment, created additional malicious OAuth applications and a new user account, and granted an application the Office 365 Exchange Online full_access_as_app role to read corporate mailboxes.
The blast radius extended beyond Microsoft. Exfiltrated correspondence included emails exchanged with customers and government agencies, prompting CISA to issue Emergency Directive 24-02 requiring US federal agencies to assess and remediate their exposure.
Attack Chain
How the Attack Compounded
Each step below marks the AXIS control that failed at that point in the chain, where one applies. Steps without a control marker were outside the victim's direct span of control.
A low-and-slow password spray from residential proxy infrastructure targets a legacy non-production test tenant.
AUTH-01
One tenant account has no MFA. A guessed password alone grants access.
AUTH-01
A legacy test OAuth application holds elevated permissions into the corporate tenant, bridging test to production.
CLOUD-02
The actor mints new OAuth apps and grants a mailbox-wide Exchange Online role. Non-human identities become quiet persistence.
CLOUD-02
The forgotten tenant and stale app permissions sit outside every posture review. Mailbox access runs about two months before detection.
SEC-05
Control Mapping
The IAM Controls That Failed
Every failure point below corresponds to a control in the AXIS question bank, the same 4 controls a maturity assessment would have scored before this incident.
| Control | Domain | Capability | How it failed here |
|---|---|---|---|
| AUTH-01 Domino | Auth/SSO | Adaptive MFA | A production-adjacent identity boundary, a legacy test tenant, accepted single-factor logins. Password spray only works where MFA is absent, and maturity is measured at the weakest tenant rather than the flagship one. |
| CLOUD-02 | Cloud | Non-Human Identity (NHI) Governance | A legacy OAuth application kept elevated cross-tenant permissions long after its purpose expired, and new app registrations with mailbox-wide roles went through without governance intervention. The missing inventory-review-and-least-privilege loop is what non-human identity governance provides. |
| SEC-05 | Security | Identity Posture & Attack-Surface Management (ISPM) | No identity posture process flagged a dormant tenant without MFA or a stale app with corporate reach. The attack surface that mattered had fallen out of every review cycle. |
| SEC-01 Domino | Security | Identity Threat Detection & Response (ITDR) | OAuth app creation, role grants, and sustained mailbox reads by a new principal ran for roughly two months before detection. The identity-layer telemetry existed; the detection and response loop did not close fast enough. |
The Maturity Lesson
What Would Have Changed the Outcome
The Domino Effect
AUTH-01 is a domino control, and this incident shows why legacy scope counts: the AXIS assessment asks about enforcement coverage across all identity boundaries, so one MFA-less test tenant holds the answer, and the overall score, down. CLOUD-02 is the quiet second failure. OAuth apps and service principals now carry the standing privilege that admin passwords used to.
The Maturity Level That Mattered
At level 2 or 3 on AUTH-01, MFA and conditional access apply tenant-wide, including non-production, which defeats password spray. At level 2 or 3 on CLOUD-02, OAuth applications are inventoried with owners and their permissions periodically recertified. A legacy test app with corporate mailbox reach fails that review immediately.
For assessment practice, enumerate identity boundaries before scoring them. Organizations routinely score their primary tenant and forget the acquisition tenant, the dev tenant, and the app registrations connecting them.
Related Compliance Frameworks
The controls implicated in this breach carry citations in these frameworks within the AXIS bank:
Sources
About This Analysis
This teardown is based exclusively on public disclosures, regulatory findings, and reporting cited above; it makes no claim of insider knowledge about the internal environment at Microsoft. Control mappings express how the publicly documented failure points correspond to capabilities in the AXIS methodology, for educational purposes. AXIS is not affiliated with Microsoft.
More From the Breach Radar
Would Your Program Have Caught This?
The 4 controls that failed here are questions in the AXIS assessment. Score your organization against them, and the rest of the bank, in about 20 minutes. No signup required to start.