Microsoft 365Incident TeardownsRetrospectives

Midnight Blizzard Breaches Microsoft (Jan 2024): A Legacy Test Tenant and an OAuth App

By OnCloudSec Research Team · Published Oct 6, 2026 · 5 min read

Facts in this article were checked against the sources listed below as of Oct 5, 2026.

Retrospective: this article looks back at events from January 2024, written in 2026 with the benefit of hindsight.

On January 19, 2024, Microsoft disclosed that Midnight Blizzard — the Russian state-sponsored actor also known as NOBELIUM or APT29, behind the SolarWinds campaign — had accessed a small percentage of Microsoft corporate email accounts, including members of its senior leadership team and employees in cybersecurity and legal functions. The attacker exfiltrated some emails and attached documents.

How it unfolded
  1. Password sprayLate November 2023: the actor compromises a legacy, non-production test tenant account that has no MFA.
  2. Legacy OAuth appIt finds a legacy test OAuth application with elevated access to Microsoft's corporate environment.
  3. PersistenceIt creates additional malicious OAuth applications and a new user account to grant consent.
  4. Mailbox accessThe legacy app is used to grant the Exchange Online full_access_as_app role, opening mailboxes.
  5. DetectionJanuary 12, 2024: Microsoft detects the attack; disclosure follows on January 19.

Microsoft published a detailed account for responders on January 25. The path it described is uncomfortably familiar: a forgotten test environment, an account without MFA, and an OAuth application with far more access than it needed.

What happened

According to Microsoft, the actor's access began in late November 2023. Microsoft detected the attack on January 12, 2024 and removed the actor from the affected email accounts on or about January 13.

The attack chain:

  1. Password spraying compromised a legacy, non-production test tenant account that did not have MFA enabled. The actor used residential proxy networks to make its traffic harder to block.
  2. In that environment, the actor found a legacy test OAuth application that had elevated access to Microsoft's corporate environment.
  3. It created additional malicious OAuth applications and a new user account to grant consent to them.
  4. It used the legacy test application to grant itself the Office 365 Exchange Online full_access_as_app role, which allows access to mailboxes.

In March 2024, Microsoft said the actor had also used information from the stolen emails to try to access source code repositories and internal systems.

Why it mattered

Test environments were connected to production. A "non-production" tenant held an application with access to the corporate environment. The security standard applied to test (no MFA) didn't match the access it led to.

OAuth apps were the escalation path. Applications with application permissions act without a signed-in user, bypassing MFA and many sign-in-based detections. The same technique featured in the SolarWinds campaign three years earlier.

It happened to Microsoft. The breach, together with Storm-0558 and the Cyber Safety Review Board's report, pushed Microsoft to expand its Secure Future Initiative and prioritize security over new features.

What to do now

  1. Inventory every tenant you own. Ask IT, development and business units about test, trial, project and acquired Microsoft 365 or Entra tenants. Check billing and partner records. Decommission what you don't need; bring the rest under the same Conditional Access and monitoring as production.
  2. Require MFA everywhere, including non-production and test accounts. Block legacy authentication in every tenant.
  3. List high-privilege applications. Look for application permissions such as full_access_as_app, Mail.ReadWrite, Files.ReadWrite.All, Directory.ReadWrite.All, AppRoleAssignment.ReadWrite.All and RoleManagement.ReadWrite.Directory. Defender for Cloud Apps app governance and Microsoft's Zero Trust Assessment can help.
  4. Find multitenant apps from your own other tenants. Service principals in production for apps registered in test tenants deserve scrutiny.
  5. Scope mail access. Replace full_access_as_app with RBAC for Applications in Exchange Online, limiting apps to specific mailboxes.
  6. Restrict who can grant admin consent and assign app roles, and manage those roles with Privileged Identity Management.
  7. Alert on the escalation pattern. New high-privilege app role assignments, new service principals created for external apps, and consent granted by newly created accounts.

How to detect OAuth application abuse

Application-based access bypasses user sign-in controls, so detection has to focus on directory changes and application behavior:

  • New app role assignments with high privileges. In Entra ID audit logs, alert on "Add app role assignment to service principal" where the permission includes full_access_as_app, Mail.ReadWrite or directory write permissions.
  • New credentials on existing apps. "Update application – Certificates and secrets management" and "Add service principal credentials" on high-privilege apps should be rare and expected.
  • New service principals for external apps. A service principal created in production for an app registered in another tenant — including your own test tenants — warrants review.
  • Mailbox access by applications. MailItemsAccessed events performed by an application across many mailboxes indicate broad app access in use.
  • Service principal sign-ins from residential proxy networks or unfamiliar autonomous systems.

Common mistakes

  • "It's only test." Test tenants and accounts often hold credentials, apps or trust relationships that reach production.
  • Granting full_access_as_app for convenience. Few applications genuinely need access to every mailbox.
  • No owner for applications. Apps without owners never get reviewed or removed.
  • Monitoring users but not workloads. Non-human identities now outnumber people in most tenants.

Lessons for 2026

The Midnight Blizzard breach was one of several incidents that pushed non-human identities to the top of security agendas. In 2025, attackers used stolen OAuth tokens from the Salesloft Drift integration to export data from hundreds of Salesforce instances, again bypassing user MFA entirely. In the same year, Microsoft introduced Entra Agent ID to give AI agents their own identities, recognizing that agents are becoming another large population of non-human identities with real permissions.

The common thread is that applications, integrations and agents now outnumber people in most environments, often with broader access and less oversight. A modern identity program needs the same inventory, ownership, least privilege and monitoring for these identities as it applies to employees. Microsoft's own response — an expanded Secure Future Initiative and a stated priority on security over new features — is a reminder that even the best-resourced organizations accumulate legacy access that attackers can find.

Questions for leadership

  • How many Microsoft 365 or Entra tenants does our organization own — including test and trial?
  • Do test environments follow the same MFA and monitoring standards as production?
  • Which applications can read everyone's email, and who approved them?

Key takeaways

  • Midnight Blizzard entered through a test tenant account without MFA, found via password spraying.
  • A legacy OAuth app with production access turned a test compromise into executive mailbox access.
  • Inventory tenants, enforce MFA everywhere, and govern high-privilege applications.
  • Scope application mail access to specific mailboxes and alert on new app role assignments.

Sources

  1. Microsoft Security Blog: Midnight Blizzard — guidance for responders on nation-state attack
  2. Wiz: Midnight Blizzard breach — analysis and best practices
midnight blizzard microsoft breachMidnight Blizzard breaches Microsoft2024

More on this story