Why is Midnight Blizzard the benchmark for supply chain APT work?
Because they have been patient, precise, and public-for-the-wrong-reasons across multiple iconic campaigns. SolarWinds in 2020 (the SUNBURST backdoor distributed via legitimate Orion updates) established the template. The 2023-2024 intrusion at Microsoft, disclosed by Microsoft in January 2024 and analyzed in its own 8-K filing and subsequent blog posts, showed the same group continuing to demonstrate mastery of identity-layer supply chain pivots. Microsoft attributes the activity to Midnight Blizzard, a.k.a. NOBELIUM, a.k.a. APT29, assessed by the U.S. government to be associated with Russia's SVR.
Two things define the group's supply chain tradecraft: they go through other people's trust to reach their real targets, and they stay quiet for long periods.
What did the Microsoft intrusion actually show?
Per Microsoft's own disclosures in January and March 2024:
- The initial foothold was a password-spray attack against a legacy, non-production test tenant that did not have MFA enabled.
- Within that tenant, the attackers found a legacy OAuth application with elevated privileges across Microsoft's corporate Entra ID (formerly Azure AD) tenant.
- Using that OAuth application, the attackers created additional OAuth applications with new grants, then accessed a small number of corporate email accounts belonging to executives and cybersecurity personnel.
- They read email. Slowly. For months.
- In some cases, they also accessed source code repositories.
Microsoft's forthrightness about the incident is instructive. The interesting lesson is not that Microsoft got breached; it is the specific chain that OAuth-application privileges on a legacy tenant could turn into corporate-inbox access. Most large organizations have equivalent hidden OAuth grants they have not audited.
What patterns recur across Midnight Blizzard campaigns?
Answer first: identity-layer persistence, vendor-to-customer pivoting, and careful signal management.
Across SolarWinds, the Microsoft intrusion, ongoing HP Enterprise mailbox access disclosed in early 2024, and repeated campaigns targeting diplomatic and policy entities (widely reported by Microsoft, Mandiant, and NCSC UK), the common threads are:
- Abuse of cloud identity trust. OAuth app grants, service principals, federated trusts, forged tokens (the "Golden SAML" technique, which Mandiant described in SolarWinds), and consent-phishing against privileged users.
- Lateral movement through trusted providers to reach final targets. SolarWinds was the archetype; subsequent campaigns have leveraged MSP access, SaaS admin tenants, and supply-chain partners' credentials.
- Low, slow, human-reviewed operations. Automation where it helps, but selective manual review of harvested data. Operators do not dump every mailbox; they read specific people.
- Patience. Dwell times measured in months. SUNBURST was in Orion builds for roughly a year before discovery.
Why is OAuth abuse such a recurring theme?
Because in a modern enterprise, an OAuth application with Mail.Read or Files.Read permission plus user consent is effectively a persistent backdoor that does not touch any endpoint and does not rely on any user password. It will survive password rotation, MFA enrollment, and most endpoint detection. Once an attacker can either create a new OAuth app with consent or hijack an existing one, they own a slice of the tenant's data at cloud scale.
Defender implications:
- Audit all existing enterprise applications and service principals in Entra ID, Google Workspace, and any other IdP. Particularly those with mail-read, drive-read, admin-consent-only, or long-lived token permissions.
- Disable user consent for all but a small allowlist of publishers. "User can consent to apps from unverified publishers" is a setting that should be off by default.
- Alert on new service principal creation and new admin consent grants. These are rare, high-fidelity events in most environments.
- Monitor OAuth app activity patterns. If an application that has been dormant for two years suddenly begins reading mailboxes at 3 a.m., that is an incident.
How does the vendor-to-customer pivot model work in practice?
SolarWinds is the canonical example: attackers compromised the Orion build pipeline, inserted SUNBURST into signed updates, and waited for customers to install. The customers who mattered - federal agencies, large enterprises - installed the update as part of normal maintenance, and the backdoor gave the attackers a foothold from which they could selectively escalate.
Later campaigns showed variants of the same pattern without requiring build-system compromise:
- Compromise of a cloud services reseller or MSP that holds delegated admin privileges over customer tenants.
- Compromise of an email hygiene or productivity SaaS that holds mailbox-level OAuth scopes across many tenants.
- Use of an identity-federation relationship between a customer and a vendor to move laterally.
The structural lesson: the more trust you have handed to external parties, the more of your environment is only as secure as their posture.
What should you change now?
- Inventory delegated admin and federated trust relationships. Who, externally, can act inside your tenant and at what privilege? This is not a once-a-year exercise; it should be a continuous monitor.
- Reduce dormant trust. Old test tenants, retired integrations, long-forgotten service accounts. Midnight Blizzard began the Microsoft intrusion in exactly this kind of backwater.
- Conditional access on service principals. Increasingly supported across identity providers. Limit which IPs, devices, and risk levels can authenticate as a service principal. Most production-critical automation sits on a predictable egress range.
- Key and token lifecycle. Short TTLs for SAS tokens, Workload Identity Federation instead of long-lived keys, mandatory rotation on PAT credentials. Long-lived tokens are the persistence tier that low-and-slow operators love.
- Log retention that matches dwell time. If you keep audit logs for 90 days and an APT dwells for 12 months, you cannot reconstruct their entry.
How do you detect low-and-slow?
Not easily, is the honest answer. But there are a few high-signal hunts worth building:
- Rare-pair anomaly on mailbox access: an admin-consented application that historically reads 20 mailboxes suddenly reads a different 10. Most UEBAs can detect this if you feed them the right events.
- Token use from unexpected geographies or ASNs for service principals.
- OAuth grants that expand in scope months after initial consent.
- Anomalous source-code enumeration patterns in repository audit logs, especially by service accounts that historically only read CI configs.
What is the strategic read for 2026?
Russian-nexus groups including Midnight Blizzard, Turla, and GRU-associated clusters are not going to retire their identity-layer supply chain tradecraft. If anything, the move toward cloud-first enterprises has made this category of attack more productive for them. Defenders should treat the identity plane as a primary battleground alongside endpoints and networks, and budget analyst time accordingly.
How Safeguard.sh Helps
Safeguard.sh gives you continuous visibility into the trust relationships - OAuth apps, delegated admin, federated identities, service principals with long-lived keys - that Midnight Blizzard-class actors target as their path of least resistance. We map your identity supply chain across tenants, flag dormant or over-scoped trust, correlate unusual service-principal and OAuth-app behavior against known APT29 tradecraft, and alert you when a connected vendor's posture changes in a way that could foreshadow a vendor-to-customer pivot. Low-and-slow dies when defenders see trust drift as it happens.