How can organisations defend against Midnight Blizzard?

Why Midnight Blizzard defence starts with identity hardening

midnight blizzard-style intrusions are won early when attackers can reuse weak authentication, stale accounts, or poorly governed cloud access. Defending well means treating identity as the primary control plane: strong MFA, strict privileged access, reduced legacy authentication, and fast containment of any exposed account or token.

That also means looking beyond passwords. Unusual mailbox delegation, consent grants, forwarding rules, and OAuth application behaviour can be the first durable signs of abuse in a cloud tenant, so the defensive posture has to combine preventive controls with identity-centric detection.

For a campaign-specific threat overview and naming context, use the Threat Actor Groups Guide to map the activity to common adversary naming schemes and related campaigns. The technical pattern behind this defence is also reflected in Microsoft Midnight Blizzard breach, which shows why legacy account exposure and missing MFA matter in practice.

What organisations should check first in their cloud estate

Start with the accounts and sessions that can change tenant trust, not with broad perimeter scanning. Privileged users, mailbox delegates, app registrations, service principals, and federation paths should be checked for weak authentication, standing privilege, and any sign that a previously trusted identity has been repurposed.

Review whether legacy authentication is still enabled anywhere, whether conditional access actually blocks risky sign-ins, and whether token issuance is monitored closely enough to catch abnormal usage. If an attacker can authenticate once and persist through tokens, the exposure can last well beyond the initial login event.

The most useful validation is behavioural: look for unexpected inbox rules, consented applications, odd OAuth scopes, and mailbox access patterns that do not fit the user’s normal administrative or communication activity. In parallel, compare privileged access paths against the control expectations in TeamCity CVE-2023-42793 SVR exploitation 2023, which is a useful reminder that credential theft and downstream privilege abuse often travel together.

How to contain and recover without missing hidden persistence

Containment should focus on the identity objects an intruder can still use: reset credentials, revoke active sessions, remove malicious mailbox rules, disable suspicious OAuth grants, and re-check any delegated access or app permissions attached to the affected account. If a suspicious app or token has already been authorised, revocation is usually more important than waiting for conclusive proof of abuse.

Recovery should include a narrow but disciplined compromise review. Confirm whether the account touched mail, directory objects, security settings, or other administrative surfaces, then decide whether adjacent accounts, shared mailboxes, or service credentials need rotation as a consequence. The goal is not only to stop the current session, but to remove the attacker’s easiest path back in.

Where cloud controls are the main line of defence, align the response with NIST Cybersecurity Framework 2.0 so that identification, protection, detection, response, and recovery stay linked rather than handled as separate tasks. For identity-specific hardening and phishing-resistant authentication guidance, NIST SP 800-63 Digital Identity Guidelines is the most directly useful external reference.

Risk and Threat Considerations

Midnight Blizzard-type activity is dangerous because it blends legitimate cloud behaviour with attacker control. Once a trusted identity, token, or consented application is abused, defenders can miss persistence for days or weeks, especially if mailbox rules, delegated access, or OAuth grants are not continuously reviewed.

Failure mechanism: Weak or legacy authentication, excessive privilege, and insufficient monitoring allow an attacker to authenticate as a legitimate user, then pivot through mail, tokens, and app consent to preserve access after the original entry point is removed.

Impact: The result can be quiet tenant-wide exposure, including mailbox access, data theft, administrative abuse, and repeated re-entry through the same identity trust relationships unless credentials, sessions, and grants are all cleaned up.

Practitioner Guidance

What to prioritise: Put the highest effort into identities that can grant or extend access, especially admin users, mail delegates, and OAuth-enabled applications. If those controls are weak, the rest of the environment is harder to trust.

What to verify: Confirm that alerts cover consent grants, suspicious inbox rules, token replay, and impossible or unusual sign-in patterns. A healthy environment should show both prevention and detection, not just one or the other.

Decision rule: If an account or token could still access production mail or directory functions, contain it first and investigate later. If the account is confirmed clean but related grants remain active, treat the grants as the remaining risk object.

Practitioner takeaway: For this threat pattern, the most effective defence is to shrink the attacker’s usable identity surface quickly, then prove that the tenant no longer contains hidden trust relationships they can reuse.

Related resources from NHI Mgmt Group

• How should organisations defend against attack-as-a-service identity fraud?
• How should organisations defend biometric authentication against spoofing attacks?
• How should organisations defend against business email compromise when attackers use real conversations?
• How can organisations defend against AI-generated phishing and impersonation?