Midnight Blizzard and the Anatomy of an OAuth Breach

Organizations pour millions into endpoint detection and identity protection, forcing attackers to adapt. If you want to bypass multi-factor authentication, the easiest method is to completely ignore the human and attack the plumbing. Attackers know that security teams obsess over user identities while largely ignoring machine identities. Service principals and enterprise applications rarely trigger impossible travel alerts. They do not get phished. But they do hold keys to the kingdom, often with tenant-wide read access to Exchange mailboxes and SharePoint drives.

When Microsoft disclosed the Midnight Blizzard breach, the immediate takeaway for many was the danger of dormant test tenants. But the actual persistence mechanism was much more elegant. The Russian state-sponsored actor bypassed MFA entirely by compromising a legacy non-production tenant, then pivoting to weaponize an over-permissioned application that had been ignored for years.

Once an adversary controls a highly privileged application, they achieve persistent, MFA-proof access to your Microsoft 365 environment. Finding malicious oauth applications requires shifting your detection engineering focus away from interactive sign-ins and toward the Microsoft Unified Audit Log.

The Midnight Blizzard Blueprint

The attack chain executed by Midnight Blizzard, tracked by MITRE as APT29, represents a masterclass in identity pivoting. Initial access was frustratingly simple. The threat actor executed a password spray attack against an old, non-production test tenant that lacked multi-factor authentication. This tenant was physically distinct from the primary corporate environment but logically connected via legacy trust relationships. Initial access via brute force is noisy, but it is just the beachhead. The real damage occurred during the persistence phase.

Weaponizing the Service Principal

Once inside the legacy tenant, the actor identified a dormant legacy application that possessed high-privilege permissions to Microsoft corporate environments. They did not need to dump credentials, bypass EDR, or deploy malware to an endpoint. Instead, they modified the application by creating a new client secret. This allowed them to authenticate as the application itself, effectively wearing its skin to interact directly with the Microsoft Graph API.

This is a textbook OAuth credential addition attack. By appending their own credentials to an existing service principal, the attackers hijacked its permissions without triggering standard user-focused alerting. Since the application already held the rights to read Exchange Online data, the actors used it to quietly exfiltrate emails from senior executives and cybersecurity staff. The blast radius was determined entirely by the scopes granted years prior by an administrator who likely assumed the app was safe because it was internal.

Decoding Graph Permissions and the Blast Radius

To understand why this technique is so devastating, you have to separate how Microsoft Entra ID handles user access from how it handles machine access. Application permissions are fundamentally different from delegated permissions. Delegated permissions require a user to be present at the keyboard. The application acts on behalf of the signed-in user, meaning the access is strictly bounded by that user's own role. If a user cannot read another employee's inbox, an application using delegated permissions cannot either.

Application permissions act entirely on their own context. There is no user involved in the transaction. When an application is granted a scope like Mail.Read under the Application permissions model, it does not just read the mail of the person who created it. It reads the mail of every single user in the entire Entra ID tenant. This is by design, intended for background services and daemon apps, but it creates a massive target for threat actors.

The Most Dangerous Scopes

The danger compounds when attackers find applications holding AppRoleAssignment.ReadWrite.All. A service principal holding this scope can grant itself or other applications even higher privileges, effectively acting as a domain admin for the cloud. They can create a new backdoor application, grant it Exchange access, and hide it in plain sight. Similarly, RoleManagement.ReadWrite.Directory allows an application to alter Entra ID roles directly, elevating a standard compromised user to Global Administrator without triggering the usual Privileged Identity Management alerts.

When auditing your environment, the presence of these scopes on applications owned by unverified publishers or bound to single-developer test accounts is a critical red flag. The gap between what a service principal actually needs to function and what it was historically granted is exactly where threat actors establish persistence.

Hunting Consent Anomalies in the Unified Audit Log

Finding this activity requires diving into the Unified Audit Log and filtering out the noise of normal administrative tasks. You are looking for specific administrative operations that alter the authentication posture of service principals. The first event to track is the addition of new credentials to an existing app. When an attacker modifies a service principal to mint their own tokens, Entra ID logs an Update application or Update service principal event within the CoreDirectory record type.

RecordType: CoreDirectory, Operation: Update application, ModifiedProperties: Name: KeyDescription, NewValue: KeyIdentifier: 12345678-abcd-efgh-ijkl-1234567890ab, KeyType: Password — Microsoft 365 Unified Audit Log

That log entry is the smoking gun of an OAuth credential addition. It tells you someone just added a client secret or certificate to an application. You must correlate this event with the actor performing the action. If a user account that rarely interacts with Entra ID administration suddenly adds a secret to a high-privilege app, you are likely looking at a compromised identity preparing to pivot.

The second critical hunting vector is the consent grant itself. Look for the Consent to application operation. Attackers who cannot find an existing over-permissioned app will often register a new one and use a compromised admin account to grant it tenant-wide consent. The log will show an operation where the ConsentContext field includes the specific permissions granted.

Filter your SIEM for operations where the permissions string contains high-risk keywords. Scopes like Mail.Read, Contacts.Read, or Sites.Read.All appearing in a Consent to application event initiated by a non-standard admin account should immediately page the on-call analyst. You are looking for the exact moment the attacker authorizes their custom exfiltration tool.

Detecting Behavioral Anomalies and API Abuse

Catching the credential addition is ideal, but you also need behavioral detections for the actual data exfiltration. Once an attacker authenticates as a malicious application, their activity will appear in the Entra ID ServicePrincipalSignInLogs. Unlike user sign-ins, which happen from familiar corporate IPs and devices, service principals often authenticate from automated scripts running in generic data centers.

Spikes in MailItemsAccessed

This makes geographic anomaly detection difficult, but volume anomaly detection highly effective. Attackers scraping Exchange via the Graph API will generate a massive spike in MailItemsAccessed events. This operation, part of Exchange mailbox auditing, fires whenever mail data is read. Crucially, it records the AppId of the service principal performing the access.

This behavior aligns perfectly with MITRE ATT&CK technique T1114.002, Email Collection via Remote Email Collection. A normal service principal designed to process invoices might access a few dozen specific mailboxes a day based on a predictable schedule. An attacker performing reconnaissance or exfiltration will rapidly iterate through hundreds of mailboxes, pulling down messages in bulk. Alerting on a sudden spike in distinct mailbox access counts grouped by AppId over a narrow time window is a reliable way to catch automated data theft before the actor can extract the entire tenant history.

You should also monitor the UserAgent strings associated with Graph API calls. While attackers can easily spoof these, many custom exfiltration scripts use default Python requests or generic HTTP client headers out of sheer laziness. A service principal that historically authenticated via a verified Azure Logic App but suddenly signs in using a raw Python user agent from an unmanaged virtual private server is a massive anomaly.

Hardening the Tenant Against OAuth Abuse

Hunting is reactive. You must also implement architectural controls to shrink the attack surface. The most critical control is disabling the ability for standard users to consent to third-party applications. If you allow end-users to grant permissions to external apps, you are one phishing email away from an illicit consent grant attack where a user willingly hands over their inbox access to an external adversary.

Implement the admin consent workflow immediately. This forces any request for application permissions into a queue where security personnel can review the requested scopes, verify the publisher, and assess the business justification. Never approve a request for tenant-wide application permissions without interrogating why the application cannot use delegated permissions instead. If a vendor claims their calendar sync tool requires Application-level Mail.ReadWrite to function, push back. Poorly coded vendor integrations are often the very applications attackers target when they gain initial access.

Finally, treat workload identities with the same rigor you apply to human users. Microsoft Entra Conditional Access now supports workload identities. You can enforce policies that restrict where highly privileged service principals can authenticate from. If an application only needs to run from an internal Azure subnet, lock its authentication down to those specific IP ranges. If an attacker manages to steal the client secret, it becomes entirely useless outside your defined perimeter.

The takeaway

The Midnight Blizzard incident proved that legacy identity infrastructure is just as dangerous as an unpatched perimeter firewall. Attackers are shifting their focus to OAuth applications because they offer silent, persistent access that easily bypasses traditional MFA enforcement. Defending against this requires continuous auditing of app permissions, strict consent workflows, and aggressive monitoring of the Unified Audit Log.

When triaging suspicious consent events or tracking down rogue API calls, you need immediate visibility into what an application actually touched. We built MailSleuth.AI to help analysts untangle exactly these kinds of complex Exchange interactions, making it easier to determine if an app was just processing calendar invites or quietly archiving executive communications. Are you watching your machine identities as closely as your users?