Postmortem: How Dormant OAuth Apps Enabled Midnight Blizzard

Somewhere in your Azure Active Directory sits a test tenant created five years ago by an engineer who no longer works at the company. It has a weak password, no multifactor authentication, and an obscure trust relationship with your production environment. You do not monitor it because it is not classified as production infrastructure.

This exact architectural blind spot is what Russian state-sponsored threat group Midnight Blizzard exploited to compromise corporate email systems. They did not burn expensive zero-day exploits or attempt to intercept authentication tokens from live users. They simply knocked on the front door of a legacy, non-production test tenant until a low-and-slow password spray let them walk right in.

The real masterstroke was not the initial access but the subsequent pivot. By hijacking a dormant application registration with excessive directory roles, the attackers minted their own credentials and established persistent, MFA-immune access. This is the anatomy of a breach driven by malicious oauth apps and the systemic failure to offboard legacy machine identities.

The Password Spray Sandbox

Security teams spend massive budgets locking down employee identities with hardware security keys and strict conditional access policies. Yet those same organizations frequently exempt test tenants and legacy service accounts from these exact controls. The justification is always that enforcing multifactor authentication breaks automated deployment scripts or interrupts integrations with legacy on-premises hardware. Advanced persistent threat groups know exactly where to look for this weak link.

Using a distributed residential proxy network to mask their true origin, the threat actor executed a highly distributed password spray attack. This maps perfectly to MITRE ATT&CK technique T1110.003. By targeting an ancient, forgotten legacy test account that predated mandatory security defaults, they completely bypassed modern authentication requirements. The proxy network ensured that no single IP address triggered brute-force lockouts or volume-based alerting thresholds.

A test account by itself rarely holds crown-jewel data. The danger always lies in its permissions and its proximity to production workloads. In this incident the compromised account had been granted elevated access to a legacy test OAuth application, effectively bridging the gap between a harmless development sandbox and the actual production environment. The attackers now had a foothold, but they needed a way to escalate their privileges without triggering identity protection alerts.

Pivoting Through Illicit Consent

Once inside the test tenant the attackers shifted their focus entirely from user identities to machine identities. Human accounts are notoriously noisy. They trigger conditional access alerts, anomalous travel warnings, and impossible travel flags when logging in from unusual infrastructure. Service principals operate under completely different rules, often exempt from geographic restrictions and typical behavioral analytics.

The Danger of Over-Privileged Roles

The compromised test account had administrative control over a dormant OAuth application. This application possessed highly privileged directory roles within the corporate tenant. Specifically the attackers sought out roles that allowed them to modify other applications or grant new permissions. This role is a virtual skeleton key for a cloud environment. It allows the bearer to grant any application permission to any API, including Microsoft Graph and Exchange Web Services.

Midnight Blizzard abused this permission to grant their hijacked application the highly coveted full access role for Exchange Online. This authorization bypasses user consent entirely. It allows an application to read any mailbox in the tenant without the user ever knowing, cleanly avoiding the phishing lures typically associated with malicious oauth apps. They did not need to trick executives into clicking an illicit consent prompt because they had the administrative power to grant that consent globally.

The distinction between delegated permissions and application permissions is the critical factor here. Delegated permissions require a user to be present and authenticate, limiting the application to only the data that specific user can access. Application permissions run as a background service and act globally. By securing global application permissions the threat actor gained the ability to query the Exchange environment silently, filtering for emails related to their own threat group to see what the targeted security team knew about them.

Minting Persistent Backdoors

Having secured the necessary Microsoft Graph and Exchange permissions the threat actor needed a way to authenticate as the application without relying on the original, highly visible test account. OAuth applications authenticate to identity providers using either client secrets or x509 certificates. Adding a new secret to an existing service principal is a completely standard administrative action, indistinguishable from routine developer maintenance if you only look at the event name.

Activity: Add service principal credentials. Actor: Compromised Test Account. Target: Legacy Test Application. Result: Success. — Unified Audit Log Excerpt

By appending their own symmetric key to the application registration the attackers severed their reliance on the initial password-sprayed account. Even if the blue team detected the spray attack and forced a password reset on the test user, the attackers retained unfettered, programmatic access to the environment. They had created a ghost identity that could authenticate directly to the Microsoft Graph API using standard OAuth client credentials flows.

This phase highlights a critical gap in many detection engineering programs. Security operations centers obsess over user credential modifications, password resets, and multifactor device registrations. They often ignore changes to application secrets. A newly minted client secret on an application with Exchange access is functionally equivalent to an administrative password reset for a global administrator, yet it routinely slips past the radar because analysts view service principal modifications as normal IT background noise.

Hunting the Phantoms in the Audit Log

Catching this attack chain requires shifting your hunt hypothesis from endpoint telemetry and EDR alerts to identity plane logging. The Unified Audit Log is your primary battleground. You must actively hunt for the specific events that indicate application hijacking, privilege escalation, and credential minting. You cannot wait for an alert; you have to query the raw telemetry.

High-Signal Audit Events

The first event to track is modifications to service principal credentials. When executed by an anomalous user or targeting an application that has not seen legitimate sign-in activity in several months, this should be treated as an immediate critical incident. You must correlate this event with the actor executing the change. If a generic test account is updating the secrets of an enterprise application, you have an active breach scenario.

Next look for consent events, particularly those granting application permissions rather than delegated permissions. If you see an app suddenly gaining mail read access or directory read-write permissions, your incident response team needs to isolate that service principal immediately. Look for the exact operation name relating to consent to application. Attackers often rename their malicious applications to mimic legitimate system processes, so you must verify the actual publisher and the underlying client ID, not just the display name.

Finally correlate these administrative actions with actual sign-in logs. Filter for service principal sign-in logs and look for unfamiliar IP addresses or autonomous system numbers authenticating with the newly modified application. If an application historically authenticated from your internal datacenter IP space and suddenly begins authenticating from residential proxy networks or foreign cloud providers, the credentials have been compromised.

Severing the Attack Path

Fixing this requires structural changes to how your organization manages the application lifecycle. You cannot rely on software developers to voluntarily clean up their old experiments or deprecate legacy tools. You need an automated, ruthless culling process for dormant identities and strict governance over how applications are granted permissions.

Start by auditing all App Registrations and Enterprise Applications in your identity environment. Any application that has not recorded a valid sign-in event in ninety days should have its credentials revoked and its state set to disabled. Archive the configuration documentation if necessary, but remove its execution capability entirely. An attacker cannot hijack a service principal that no longer exists.

Restrict user consent for applications across the board. End users should never have the authority to grant third-party applications access to corporate data. Implement an admin consent workflow where dedicated security engineers review the requested OAuth scopes before an application is authorized in the tenant. This prevents the traditional illicit consent phishing attacks and forces all new applications through a centralized security review.

Enforce strict conditional access policies on workload identities. Service principals should be bound to specific trusted locations or networks whenever architecturally possible. While human users need to roam across different networks, service principals usually execute from known cloud environments or specific datacenters. Treat machine identities with the exact same paranoia you apply to your highly privileged human administrators.

The takeaway

The Midnight Blizzard incident proves that attackers understand our cloud architecture better than we do. They know that while we hyper-focus on protecting human administrators with complex conditional access policies, our forgotten test environments and dormant OAuth registrations are gathering dust with their high-privilege access fully intact. A single forgotten test account is all it takes to unravel millions of dollars of security investments.

Closing this gap means treating service principal modifications as highly critical alerts and enforcing least privilege on machine identities. If you are struggling to separate legitimate developer activity from illicit consent grants, MailSleuth.AI can ingest and analyze your authentication logs to surface exactly these types of identity plane anomalies. Find the dormant backdoors in your tenant before an advanced threat group finds them for you.