In January 2024, Microsoft disclosed that the Russian state-sponsored group Midnight Blizzard had read executive mailboxes for weeks after compromising a legacy, non-production test tenant that had no multi-factor authentication enforced. From that single foothold, the attackers escalated privileges to an OAuth application with mail.read scope across the corporate environment — never once needing to defeat an MFA prompt, because the privilege escalation path routed around it entirely. This is the pattern security teams increasingly call "MFA bypass via privilege escalation": rather than cracking a second factor, attackers exploit misconfigured roles, forged tokens, or vulnerable domain services to inherit access that MFA was never asked to protect. For software supply chains — where CI/CD identities, service accounts, and federated trust relationships multiply the number of privilege boundaries — this technique has become one of the fastest-growing initial-access-to-domain-dominance paths. Here's how it works, who's used it, and what actually stops it.
What Is MFA Bypass Via Privilege Escalation?
It's an attack chain where an adversary skips defeating a second factor by instead escalating privileges through a path that MFA doesn't cover, then using that elevated access to operate as if authentication never mattered. Classic MFA bypass techniques — SIM swapping, push-bombing, adversary-in-the-middle proxies like Evilginx — attack the authentication event itself. Privilege-escalation-based bypass is different: the attacker authenticates legitimately (often to a low-privilege or legacy account), then abuses a vulnerability, misconfigured trust relationship, or overly permissive role to reach resources that should have required a fresh, high-assurance MFA challenge. Common enablers include forged SAML/Kerberos tokens, service principals with excessive Azure AD or AWS IAM permissions, conditional access policies with legacy-auth exceptions, and unpatched domain controllers. CISA's #StopRansomware advisories from 2023–2024 repeatedly cite this exact chain — initial credential access followed by lateral privilege escalation — as the dominant pattern in double-extortion ransomware intrusions.
How Did Midnight Blizzard Bypass MFA at Microsoft in 2024?
They never had to touch MFA at all, because they went in through a test tenant that had none configured. Microsoft's January 19, 2024 disclosure detailed a low-and-slow password spray against a small number of accounts starting in late November 2023, which succeeded against a legacy non-production tenant. From there, the group — tracked as APT29/Midnight Blizzard, the same actors behind the 2020 SolarWinds compromise — used that tenant's OAuth application to grant itself the full_access_as_app role against Office 365 Exchange Online, then pivoted to corporate mailboxes belonging to senior leadership, cybersecurity, and legal teams. Because the escalation happened at the application-permission layer rather than the interactive-login layer, no user-facing MFA prompt was ever generated for the malicious activity. Microsoft's own root-cause analysis flagged this as a legacy-tenant governance failure, not an MFA cracking exploit — precisely the distinction that makes this attack class so dangerous for large organizations with sprawling identity estates.
What Role Does Golden SAML Play in This Attack Pattern?
Golden SAML lets attackers forge authentication tokens for any user or service, at any privilege level, once they've stolen an identity provider's signing key — making MFA irrelevant because the forged assertion claims MFA already happened. First documented publicly by CyberArk in 2017 and later confirmed as a technique used in the December 2020 SolarWinds/SUNBURST campaign, the attack requires compromising an Active Directory Federation Services (ADFS) server or equivalent SAML identity provider and exfiltrating its private signing certificate. With that certificate, an attacker can mint SAML tokens asserting arbitrary group memberships, arbitrary usernames, and — critically — an "AuthnContext" claiming multi-factor authentication was already satisfied. Downstream service providers (Microsoft 365, AWS, Salesforce, internal SSO-integrated apps) have no way to distinguish a forged assertion from a legitimate one, because the trust model assumes the IdP's signing key is secret. The privilege escalation step — gaining local admin or domain admin on the ADFS host — is what makes the MFA bypass possible; the token forgery is just the mechanical follow-through.
Which CVEs Have Directly Enabled MFA-Bypassing Privilege Escalation?
At least three widely exploited CVEs from 2020–2023 map directly onto this chain, each converting a domain or application vulnerability into full authentication bypass. CVE-2020-1472 ("Zerologon"), patched by Microsoft in August 2020, let an unauthenticated attacker on the local network reset a domain controller's machine account password and impersonate it, effectively granting domain admin without any credential or MFA check. CVE-2021-42278 and CVE-2021-42287 (chained together as "noPac" and disclosed in November-December 2021) allowed an attacker with a standard domain user account to impersonate a domain controller via Kerberos ticket manipulation, reaching domain admin in minutes. More recently, CVE-2023-29357, a Microsoft SharePoint Server privilege escalation flaw patched in June 2023 and demonstrated at Pwn2Own Vancouver, let attackers forge JWT auth tokens to gain administrator rights without valid credentials at all. In every case, the vulnerability sits below the authentication layer that MFA is designed to protect, which is exactly why patch cadence and identity hygiene matter as much as MFA enrollment rates.
Why Did the Uber Breach Succeed Even Though MFA Was Enabled?
Because the attacker used MFA fatigue to get past the login prompt, then found hardcoded admin credentials that escalated privileges far beyond what any single MFA challenge was scoped to protect. In the September 2022 breach, an 18-year-old affiliated with the Lapsus$ group bombarded a contractor with MFA push notifications until one was accepted, gaining initial VPN access. From there, the attacker discovered a PowerShell script on a network share containing hardcoded credentials for Uber's Thycotic privileged access management (PAM) system. Those PAM credentials unlocked administrator access to AWS, Google Cloud Platform, VMware vSphere, Slack, and Uber's internal vulnerability-management tooling — none of which prompted for a second MFA check, because the trust boundary had already been crossed at the PAM layer. Uber's own disclosure noted the attacker "found admin credentials... which had privileged access to all of the tools," underscoring that a single successful MFA bypass at the perimeter, combined with lateral privilege escalation, defeated an MFA program that was, on paper, fully deployed.
How Common Is This Pattern Across Recent Supply Chain Incidents?
It's now a recurring feature, not an edge case: at least three major 2023–2024 breaches — Okta's October 2023 support-system compromise, the Snowflake customer breaches affecting roughly 165 organizations disclosed in mid-2024, and the Change Healthcare ransomware attack in February 2024 — all involved credential or session compromise followed by privilege escalation into systems where MFA was either absent, misconfigured, or scoped too narrowly to catch the lateral move. Verizon's 2024 Data Breach Investigations Report found that the use of stolen credentials appeared in 31% of breaches analyzed, and Mandiant's M-Trends 2024 report separately noted that identity-based lateral movement techniques, including privilege escalation to bypass secondary controls, were present in a growing share of intrusions it investigated. For software supply chains specifically — where a single compromised CI/CD service account, build server, or federated identity provider can cascade into every downstream customer — this pattern is especially costly because the blast radius extends past the immediately compromised organization.
How Safeguard Helps
Safeguard is built to catch exactly this gap between "MFA is enabled" and "MFA actually protects every privileged path." Rather than treating authentication as a one-time checkbox, Safeguard continuously maps the identity and privilege graph across your CI/CD pipelines, cloud accounts, and federated identity providers — surfacing service accounts, OAuth grants, and role assignments that can reach sensitive resources without triggering a fresh, high-assurance challenge. Safeguard flags exactly the conditions that enabled the incidents above: legacy or non-production tenants missing MFA enforcement, over-permissioned OAuth applications with mail or directory-wide scopes, ADFS and IdP signing-key exposure risk, hardcoded credentials in scripts and build artifacts headed for a PAM or secrets vault, and unpatched domain services vulnerable to known privilege-escalation CVEs like Zerologon and noPac. Where traditional MFA monitoring stops at the login event, Safeguard's supply chain visibility tracks what happens after authentication — so a stolen session or a single accepted push notification can't quietly cascade into domain admin, cloud account takeover, or a forged SAML assertion. For teams that have already invested in MFA, that continuous, identity-aware line of sight is the difference between a contained credential incident and a Midnight Blizzard-style mailbox compromise.