Parag Mali - tag: patchguard

The Same-Privilege Paradox: Twenty-One Years of Windows Kernel Self-Defense

noreply@paragmali.com (Parag Mali) — Wed, 03 Jun 2026 00:00:00 GMT

Microsoft has spent twenty-one years defending the Windows kernel from itself. PatchGuard, KASLR, KDP, and the Win32k Lockdown are four answers to a single problem -- the **same-privilege paradox**, that a defense at the attacker's privilege level cannot succeed in principle. The trajectory is migration: from in-kernel obfuscation (PatchGuard, 2005), to address-space tricks (KASLR 2007, KVA Shadow 2018), to hypervisor-anchored isolation (KDP, 2020), and finally to attack-surface deletion (Win32k filter, 2017). Microsoft's own Security Servicing Criteria say PatchGuard is not a security boundary [@ms-servicing-criteria], and that admission is the load-bearing premise of every modern Windows kernel mitigation.

1. If the attacker is already in the kernel, what is left to defend?

For three years, a Russian-attributed espionage rootkit called Uroburos ran on Microsoft's most heavily defended kernel -- the 64-bit Windows kernel with PatchGuard active -- and PatchGuard never made a sound [@gdata-uroburos-blog]. The reason is the one the marketing copy will not tell you: PatchGuard is not, and was never designed to be, a security boundary; Microsoft says so in its own Security Servicing Criteria [@ms-servicing-criteria]. The twenty-one-year history of Windows kernel self-defense is the story of why the answer to "the kernel cannot defend itself from itself" turned out to be "stop trying to defend it from inside."

That sentence will read like editorial provocation until you see the architecture. Uroburos did not bypass PatchGuard. It side-stepped it. The rootkit shipped a signed-but-vulnerable copy of Oracle's VBoxDrv.sys, used the vulnerability to flip the g_CiEnabled flag that gates Driver Signature Enforcement, loaded its own unsigned kernel driver, and then operated alongside PatchGuard for three years (2011 -- 2014) without ever modifying anything PatchGuard checked [@gdata-uroburos-blog] [@stmxcsr-turla]. The Stage 2 evolution survey calls this the canonical refutation of the most common reader misconception about PatchGuard: not "PatchGuard was broken" but "PatchGuard's protected-structure list is, by construction, narrower than the kernel-modification surface."

A defense that shares its CPU privilege level with the attacker can in principle always be subverted by an attacker at that privilege level, because every code path and data structure the defense relies on is, by construction, mutable by the attacker. The paradox is not a formal impossibility theorem in the cryptographic sense, but it is the de facto design constraint Microsoft has acknowledged in writing through its Security Servicing Criteria [@ms-servicing-criteria]. A Microsoft kernel feature that periodically verifies a fixed list of kernel structures -- the SSDT, IDT, GDT, syscall MSRs, the in-memory `nt` and `hal` images, and select processor control registers -- and bug-checks the system with stop code `CRITICAL_STRUCTURE_CORRUPTION` (0x109) on mismatch. Introduced April 25, 2005 in Windows XP Professional x64 Edition and Windows Server 2003 x64 Edition; never shipped on x86 [@ms-advisory-932596] [@ms-driver-x64-restrictions]. PatchGuard is an *engineering deterrent*, not a security boundary.

This article covers four mitigations across twenty-one years -- April 25, 2005, when PatchGuard shipped with Windows XP Professional x64 Edition and Windows Server 2003 x64 Edition [@ms-advisory-932596], through June 2026, when kCET and the VTL1-anchored stack are the front line. The four mitigations are PatchGuard (KPP), KASLR (and its 2018 successor KVA Shadow), KDP (Kernel Data Protection), and the two-stage Win32k Lockdown that began in 2012 with DisallowWin32kSystemCalls and resolved in 2017 with Win32kSystemCallFilter [@ms-syscall-disable-policy] [@ms-syscall-filter-policy]. They do not look like they belong together until you notice the direction. Each generation moves the defense one step further away from where the attacker lives: from in-kernel obfuscation, to address-space tricks, to hypervisor-anchored isolation (VTL1), to attack-surface deletion.

Key idea: Every meaningful Windows kernel mitigation since 2017 has moved the enforcement to a privilege level the kernel-mode attacker cannot reach -- hypervisor (VTL1), CPU silicon (KTRR on Apple, kCET shadow stack hardware on Intel / AMD), or out of the syscall surface entirely. The reason is the same-privilege paradox: a defense that lives where the attacker lives cannot, in principle, succeed.

Four misconceptions are worth retiring before we start. First, "PatchGuard is the load-bearing kernel-rootkit defense"; in fact, Microsoft says it is not a security boundary at all, and Uroburos operated alongside it for three years. Second, "PatchGuard is x64-only"; the documentation is x64-centric, but in 2026 PatchGuard also runs on 64-bit ARM Windows -- the one architectural truth in the framing is that PatchGuard never shipped on 32-bit Windows. Third, "KASLR is dead because entropy is the variable that matters"; the Hund-Willems-Holz 2013 result and Gruss et al. 2017 generalization showed that randomness was never the load-bearing defense -- structural unreachability is [@doi-hund-2013] [@gruss-kaiser-pdf]. Fourth, "Win32k Lockdown killed half the LPE class"; the lockdown removes roughly the historically-vulnerable syscall surface from sandboxed renderers specifically, not from the operating system in general [@pz-breaking-chain].

To see why Microsoft has spent twenty-one years on a problem that, by their own admission, has no in-kernel answer, we have to go back to April 25, 2005 -- and to the architectural break that made the new contract politically possible.

2. Why Microsoft built PatchGuard at all (1998 -- 2005)

Before April 2005, the Windows kernel was a public hooking surface by design. McAfee, Symantec, F-Secure, and Trend Micro patched the System Service Descriptor Table (SSDT), hooked the Interrupt Descriptor Table (IDT), and inline-patched nt!Nt* system-service routines as legitimate engineering practice. The same primitives, applied with malicious intent, became the rootkit canon of the late 1990s and early 2000s: NTRootkit, FU, Hacker Defender. From the operating system's point of view, the defender and the attacker were architecturally indistinguishable.

A kernel data structure on Windows containing function pointers to every system service routine (the `Nt*` functions that implement system calls). On 32-bit Windows, anti-virus vendors routinely patched the SSDT to intercept system calls before the kernel processed them. On x64, modifying the SSDT is prohibited and PatchGuard treats it as a `CRITICAL_STRUCTURE_CORRUPTION` event [@ms-driver-x64-restrictions].

The symmetry was awkward enough in normal operation. It became politically untenable in October 2005, when Mark Russinovich discovered that Sony BMG's XCP DRM software, shipped on tens of millions of audio CDs, installed an actual cloaking rootkit on consumer Windows machines.Russinovich's October 31, 2005 Sysinternals post "Sony, Rootkits and Digital Rights Management Gone Too Far" turned a niche kernel-internals topic into national news within a week. The lawsuit settlements and CD recall that followed established, in pop-culture terms, the symmetry between "legitimate kernel hooking" and "malware kernel hooking" that the security industry had been arguing about for years. The XCP code was structurally identical to malware -- it hid files whose names began with $sys$ , modified system calls, and resisted removal -- and it shipped under a Sony certificate.

What Microsoft needed was an architectural break large enough that they could rewrite the kernel contract without having to honor the old one. They got it from AMD. The x64 architecture, productised as AMD64 and adopted by Intel as EM64T, was Microsoft's once-in-a-decade chance to publish a new contract incompatible with the old. Windows XP Professional x64 Edition and Windows Server 2003 x64 Edition shipped on April 25, 2005 [@ms-advisory-932596]. The new kernel-mode contract had two enforcement layers. PatchGuard was the engineering enforcement -- the code that periodically inspected the kernel's most sensitive structures and bug-checked the system on mismatch. Kernel-Mode Code Signing (KMCS) was the policy enforcement -- the rule that production x64 kernels would load only Authenticode-signed drivers.

The policy on 64-bit Windows that the kernel will load only Authenticode-signed kernel drivers in production (test-signing modes exist for development). KMCS shipped with the same April 2005 release as PatchGuard and is its policy counterpart -- KMCS controls what code enters the kernel; PatchGuard checks the kernel structures the loaded code is expected to leave alone [@ms-driver-x64-restrictions].

The combination did exactly what the AV industry feared. Their entire detection methodology was, by the new contract, illegal on x64. McAfee bought a full-page ad in the Financial Times in October 2006 to call Microsoft's behaviour anti-competitive. Symantec joined the EC complaint. The verbatim industry framing was delivered by Vincent Weafer, then Symantec's senior director of security response, in a CRN report: "Either everybody has access to the kernel or nobody has access to the kernel -- and we believe in the latter" [@crn-mcafee-symantec]. Microsoft declined to publish a signed bypass API. By the time the dust settled, the AV-vendor hooking pattern on Windows had been industrially ended.

Either everybody has access to the kernel or nobody has access to the kernel -- and we believe in the latter. -- Vincent Weafer, Symantec, quoted in CRN, September 25, 2006 [@crn-mcafee-symantec]. McAfee and Symantec argued that Vista x64 plus PatchGuard locked third-party security vendors out of the kernel while Microsoft's own Windows Defender remained free to ship integrations Microsoft had not exposed to anyone else. The EC investigation eventually closed without forcing Microsoft to expose a signed bypass API. The 2024 CrowdStrike Falcon outage -- where a single bad signature update propagated through a kernel driver and bricked an estimated 8.5 million Windows machines worldwide -- is now widely read, retroactively, as vindication of Microsoft's 2006 position. The argument that "everybody or nobody" has kernel access turned out to have a third answer: "as few people as possible, with as small a kernel footprint as possible, mediated by user-mode brokers." That is the design move the rest of this article is about.

The historical record has one quirk worth flagging. No primary 2005 PatchGuard launch document is preserved in Microsoft's current documentation surface; the earliest official primary is Microsoft Security Advisory 932596 from August 2007, which describes Kernel Patch Protection as protecting "code and critical structures in the Windows kernel from modification by unknown code or data" and announces an upcoming PatchGuard update [@ms-advisory-932596]. The technical detail of what PatchGuard checked was reverse-engineered by the offensive security community before Microsoft documented it.

gantt title Windows kernel self-defense, 2005-2026 dateFormat YYYY-MM section Same-privilege (CPL=0) PatchGuard v1 :2005-04, 2008-02 PatchGuard v2-v3 :2006-11, 2010-10 PatchGuard v7-v8 :2012-08, 2026-06 KASLR (8-bit entropy) :2007-01, 2018-01 section CPU mediated KVA Shadow :2018-01, 2026-06 kCET / shadow stack :2022-09, 2026-06 section VTL1 anchored HVCI :2015-07, 2026-06 kCFG with VBS bitmap :2017-04, 2026-06 KDP static plus dynamic :2020-05, 2026-06 section Surface deletion DisallowWin32kSystemCalls:2012-08, 2017-10 Win32kSystemCallFilter :2017-10, 2026-06

So the contract was published, the kernel was no longer a public hooking surface, and Microsoft shipped a feature called PatchGuard that ran inside the kernel and checked the kernel's most sensitive structures. The question Skywing and skape would publish nine months later was the question everybody in offensive security had been waiting for: how do you defend a kernel from inside the kernel?

3. PatchGuard v1 and v2: obfuscation as defense (2005 -- 2008)

PatchGuard v1 was an engineering answer to a political problem. It worked exactly the way a defense works if you do not state out loud that the attacker is in the same address space: a periodic timer fired, a checksum was recomputed, a mismatch caused the machine to bug-check with stop code CRITICAL_STRUCTURE_CORRUPTION (0x109), and the assumption was that the cost of figuring out which timer, which checksum, and which DPC handler was high enough to deter casual rootkit authors. And for nine months, that was the story.

The Windows bug-check stop code raised by PatchGuard when one of its periodic integrity checks detects an unexpected modification to a protected kernel structure. The bug-check call goes through `KeBugCheckEx`, which on later PatchGuard generations is itself a protected structure -- swallowing the bug-check from a hooked `KeBugCheckEx` was one of the four bypass classes Skywing and skape catalogued in 2005 [@uninformed-v3-archive].

What does PatchGuard actually check? The protected-structure list has grown across generations, but the core, as Microsoft documents it for driver authors, has been remarkably stable [@ms-driver-x64-restrictions]:

The SSDT and KeServiceDescriptorTable[Shadow] (the function-pointer tables that dispatch system calls)
The Interrupt Descriptor Table (IDT), read from the CPU via IDTR
The Global Descriptor Table (GDT), read from the CPU via GDTR
The syscall-related model-specific registers: IA32_LSTAR, IA32_STAR, IA32_CSTAR, and the IA32_SYSENTER_* family
The in-memory nt and hal kernel images (so you cannot inline-patch nt!NtCreateFile)
KdpStub, KeBugCheckCallbackHead, and other kernel call-back tables
Select processor control registers and debug registers

Mechanism: a context block built by nt!KiInitializePatchGuard at boot, scattered across allocations, XOR-encrypted; a DPC-driven verifier routine that fires at randomized intervals; a per-fire recomputation of expected checksums; a KeBugCheckEx(0x109, ...) call on any mismatch. The load-bearing property of the design -- the one that drives the rest of the story -- is that the defense lives at CPL=0, alongside the attacker. The verifier, the keys, the schedule, the bug-check routine itself: all of it lives in the same address space as the rootkit it is meant to detect.

flowchart TD A[Timer fires at random interval] --> B[DPC routine dispatched] B --> C[Decrypt scattered context fragment] C --> D[Hash protected structures] D --> E{Hash matches expected} E -- yes --> F[Reschedule next check] E -- no --> G[Call KeBugCheckEx 0x109] G --> H[System bug-check CRITICAL_STRUCTURE_CORRUPTION] F --> A

In December 2005, eight months after PatchGuard shipped, Skywing and skape published "Bypassing PatchGuard on Windows x64" in Uninformed Volume 3 [@uninformed-v3-archive]. The paper enumerated four architectural bypass classes that would, with minor variations, survive every PatchGuard generation Microsoft has shipped since:

Patch the verifier timer. If you control the DPC queue, you can prevent the check from ever firing.
Hook the verification callback. Replace the function pointer the DPC routine is dispatched through.
Replace the DPC routine. Rewrite the bytes of nt!KiPatchGuardCheckRoutine itself, before it executes.
Swallow the bug-check. Hook KeBugCheckEx so that the eventual mismatch call returns to the attacker's handler instead of crashing the system.

The KiInitializePatchGuard initialization routine itself uses the "scattered initialization" tradition Microsoft inherited from Windows 2000 -- the context block is not allocated as a single contiguous structure but assembled from fragments at randomized offsets, each XOR-keyed against a derived value the verifier alone reconstructs at check time. The fragments are referenced through call-graph paths designed to be inaccessible to a static reader. This is exactly the engineering cost layer that Skywing's 2005 paper would later identify as raising the cost of bypass without affecting any structural bypass class.

The thesis the Uninformed paper stated in its abstract was the framing Microsoft would not formally adopt in writing for another twelve years: any defense at the same privilege as the attacker can be subverted in principle, because the attacker can do anything the defense can do -- including reading the obfuscation key and rewriting the check. The argument is structural, not empirical. Skywing's contribution was not "we broke PatchGuard"; it was "PatchGuard's class of defense has a fixed structural ceiling, and the ceiling is below 'security boundary.'"

The biographical pattern that ran through this story is unusual and worth naming explicitly. Skape (Matt Miller) later joined Microsoft and became the lead on multiple mitigation features. Skywing (Ken Johnson) later wrote the bylined MSRC blog post that introduced KVA Shadow in 2018 [@ms-kva-shadow-blog]. Andrea Allievi, who reverse-engineered PatchGuard 8.1 at NoSuchCon 2014 [@allievi-nsc2014], later co-authored *Windows Internals 7e Part 2* and the 2020 KDP launch blog [@ms-kdp-blog]. The pattern is not random: the offensive-research community that proved the same-privilege paradox was the same community Microsoft eventually hired to design the cross-privilege answer.

Microsoft did exactly what you would expect a serious engineering organisation to do when an obfuscation layer is partially peeled back: they added another. PatchGuard v2 shipped in 2006 servicing updates and was inherited by Vista x64 in November 2006. It introduced an XOR-encrypted-and-scattered context, decoy DPC routines, a generalised anti-hook framework that flagged modifications to additional kernel function tables, and randomized timer phase. In January 2007 Skywing published "Subverting PatchGuard Version 2" in Uninformed Volume 6, walking through the v2 hardening in detail and demonstrating that the same four bypass classes survived [@uninformed-v6-archive]. The engineering cost was raised; the structural ceiling was not.

It is worth seeing the integrity check as a teaching primitive. The real implementation is hardened with anti-disassembly and anti-debugging tricks that we will not reproduce; the underlying control loop is plain.

{` // Conceptual demonstration only -- the real PatchGuard is far more obfuscated const protectedStructures = { SSDT: 'eb2f4c1abe007f29d6c910a9c66e0b21', IDT: '7c4b48a39b22d5f0a1e4ecb0d80b1c2a', GDT: '0d1f3a72b9aa6d8a14e88f9d22cc66ab', KeBugCheckEx: '6677aabbccdd0011223344556677ff88', }; const expected = {...protectedStructures};

function hashStructure(name) { // In real KPP this is a derived hash over current memory contents return protectedStructures[name]; }

// Simulate one tick of the verifier patchguardCheck();

// Simulate an attacker modifying SSDT protectedStructures.SSDT = 'ffffffffffffffffffffffffffffffff'; patchguardCheck(); `}

The toy is honest about the shape: a verifier walks a fixed list, computes a hash, compares against a stored expected value, calls a bug-check on mismatch. Everything Skywing's bypass classes targeted -- the verifier's schedule, the verifier's code, the expected-hash store, the bug-check primitive -- is sitting in the address space the attacker also writes.

By January 2007, the pattern was set. Microsoft adds an obfuscation layer; Skywing peels it back; Microsoft adds another. Both sides were right. Microsoft was right that the engineering cost mattered: the AV-vendor hooking pattern was being industrially ended, signed third-party kernel drivers were a much narrower entry point than the old free-for-all, and casual rootkit authors were locked out of the bypass class. Skywing was right that engineering cost is not a security boundary. The next decade would prove both.

4. The evolution, generation by generation (2008 -- 2016)

Twelve years of cat-and-mouse ran on two parallel tracks. PatchGuard added DPC-based checks in v3 (Vista SP1 / Server 2008, February 2008) [@uninformed-v8-archive], HAL function-table verification and stack-context randomisation in Windows 7 -- 8 (2009 -- 2012), and a context-block ring in Windows 8.1 (2013) -- which Andrea Allievi reverse-engineered at NoSuchCon 2014, again finding four independent bypass paths [@allievi-nsc2014]. Meanwhile, two quieter developments laid the groundwork for what was coming: KASLR shipped on Vista x64 in 2007 [@russinovich-vista-part3], and Jurczyk and Coldwind's Bochspwn project in 2013 falsified the industry's assumption that win32k LPE bugs were a tail of accidents [@j00ru-bochspwn-blog].

The PatchGuard generation ladder

Each generation tightened the engineering cost without changing the structural ceiling. The table below summarises the evolution; the right-most column lists the canonical reverse-engineering primary, which in every generation came from outside Microsoft.

Generation	Year, OS first shipped	Key delta	Canonical reverse-engineering primary
v1	April 2005, XP x64 / Server 2003 SP1 x64	Baseline -- single context block, fixed protected-structure list, single DPC	Skywing & skape, Uninformed v3, Dec 2005 [@uninformed-v3-archive]
v2	2006 servicing, inherited by Vista x64 Nov 2006	XOR-encrypted scattered context, decoy DPCs, anti-hook framework	Skywing, Uninformed v6, Jan 2007 [@uninformed-v6-archive]
v3	Vista SP1 / Server 2008, Feb 2008	Multiple concurrent contexts, randomised timer phase, `KeBugCheckEx` self-protection	Skywing, Uninformed v8, Sep 2007 [@uninformed-v8-archive]
v7 (Windows 7)	2009 -- 2010	HAL function-table verification, stack-context randomisation	Community RE; no single canonical paper
v8 (Windows 8)	2012	`KeServiceDescriptorTableShadow` added (now covers win32k syscall table), expanded MSR list	Community RE
v8.1	2013 (Windows 8.1)	Single context block replaced by context-block ring; atomic patching of every block required; 247 protected structures (vs ~26 on Vista x64)	Andrea Allievi, NoSuchCon 2014 [@allievi-nsc2014]

Allievi's 2014 talk is the clearest single picture of what hardening looked like by the Windows 8.1 era. The single context block had become a singly-linked list (SLIST) of context blocks. The cryptographic self-integrity check now ran across the SLIST. The protected-structure set had grown from roughly twenty-six on Vista x64 to two hundred and forty-seven by Windows 8.1, including HalPrivateDispatchTable and HalpInterruptController [@allievi-nsc2014]. And the four 2006 bypass classes still worked. The engineering cost of bypassing PatchGuard had risen by an order of magnitude; the architectural class of bypass had not changed.

KASLR on Vista, February -- April 2007

In parallel with the PatchGuard generation ladder, Microsoft shipped a different style of defense on the same kernel. Mark Russinovich's three-part Inside the Windows Vista Kernel series in TechNet Magazine documented the new mitigation in April 2007 [@russinovich-vista-part3]: the kernel image base, instead of being constant, was selected at boot from a small space of possible offsets.

Randomising the kernel image base across boots, so that an attacker with a stale or guessed kernel address cannot use it as an absolute reference. On Vista x64 the implementation had roughly eight bits of entropy (256 possible kernel base addresses), selected at boot time by `winload.exe` [@russinovich-vista-part3]. The mitigation is *probabilistic* by construction: it raises the cost of an unprivileged information-leak, but cannot survive a deterministic side-channel attacker.

The Vista bootloader, winload.exe, was the component that picked the kernel image base at boot. The choice of selecting the offset early -- before the kernel proper executes -- was deliberate; KASLR after the kernel is mapped is harder to do because every kernel pointer recorded so far becomes invalid. The Vista bootloader was also the component PatchGuard's protected list depended on: an attacker with bootloader code execution simply chose their own offset.

The probabilistic framing held until 2013. Hund, Willems, and Holz published "Practical Timing Side Channel Attacks Against Kernel Space ASLR" at IEEE S&P 2013 [@doi-hund-2013]. Their technique exploited the shared TLB and cache state between user mode and kernel mode on every x86 / x64 CPU then shipping: an unprivileged user-mode timer could measure differential cache behaviour when accessing addresses near where the kernel mapped its image, and recover the kernel base in seconds. Eight bits of entropy collapse fast under a side-channel that gives you one bit per probe. Gruss et al. generalised the argument in 2017 with a paper whose title was the thesis: "KASLR is Dead: Long Live KASLR" [@gruss-kaiser-pdf]. The structural answer would have to be something other than entropy.

The 2012 Windows 8 attempt at attack-surface deletion

While KASLR's structural limits were being demonstrated in academia, Microsoft shipped a different style of mitigation in Windows 8: DisallowWin32kSystemCalls, a process-level option enabling the kernel to refuse every win32k system call from a process that opted in [@ms-syscall-disable-policy]. The semantics are all-or-nothing: a process either can call into win32k.sys or it cannot. Useful for non-UI broker processes (where the answer is "never"). Structurally inadequate for browser renderers, which need to draw windows, render fonts, and dispatch input through a constrained-but-non-empty subset of the win32k surface. The mitigation languished for five years, waiting for the per-syscall version that arrived in 2017.

The Bochspwn empirical surprise

In 2013, Mateusz Jurczyk and Gynvael Coldwind presented Bochspwn at SyScan and at Black Hat USA [@j00ru-bochspwn-blog] [@j00ru-bhusa-pdf]. The methodology was a Bochs x86 emulator instrumented to trace every memory access made by the kernel during syscall handling. The instrumentation found classes of bugs -- specifically double-fetch bugs, where the kernel reads the same user-controlled memory twice without re-validating between reads -- by tagging each user-pointer dereference and looking for repeats.

A double-fetch happens when kernel code reads a value from user-mode memory, validates it, and later reads the *same* address again expecting the value to be unchanged. A racing user-mode thread can flip the value between the two reads, defeating the validation. Detecting double-fetches statically is hard; detecting them by static analysis on a closed-source kernel is harder still. Bochspwn solved the detection problem at the emulator level: instrument the entire kernel under Bochs, log every memory read of every page table mapped writable from user mode, and post-process the trace for "same address, same kernel function, two reads, no intervening synchronisation." The result: dozens of exploitable kernel race conditions across multiple Windows versions, the *majority* in `win32k.sys` [@j00ru-bochspwn-blog]. The win32k bug class was systemic, not accidental.

Jurczyk's empirical finding mattered because it pre-dated the design of the eventual lockdown by four years. The community knew, by mid-2013, that win32k.sys was a bug class, not a bug tail. Microsoft's eventual answer -- per-process filtering of the win32k syscall surface -- had a clean empirical motivation by the time it shipped.

The pre-Bochspwn high-profile example was already in the literature: Bruce Dang and Peter Ferrie's December 2010 talk at the 27th Chaos Communication Congress ("Adventures in Analyzing Stuxnet") had named CVE-2010-2743, a win32k.sys NtUserLoadKeyboardLayoutEx LPE that Stuxnet used to escalate from user to kernel on Windows XP [@nvd-cve-2010-2743]. Stuxnet placed one of the most consequential kernel-level malware operations on record on top of a single win32k vulnerability. Bochspwn explained why: the surface was structurally vulnerable, not accidentally so.

The intellectual surprise of this act -- Uroburos coexisted with PatchGuard

The cleanest demonstration that the same-privilege paradox is empirical, not theoretical, came in February 2014. G Data SecurityLabs published its analysis of Uroburos, a Russian-attributed espionage rootkit that had been operating in production for an estimated three years [@gdata-uroburos-blog]. Uroburos did not bypass PatchGuard. It loaded a copy of Oracle's VBoxDrv.sys (a signed third-party driver shipped as part of VirtualBox), used a privilege-escalation vulnerability in that driver to flip the g_CiEnabled flag (the gate for Driver Signature Enforcement), loaded its own unsigned rootkit driver, and then operated for three years in production without ever modifying anything PatchGuard checked [@stmxcsr-turla].

Note: The most-repeated misreading of PatchGuard's track record is "Uroburos was a PatchGuard bypass." It was not. Uroburos was a Driver Signature Enforcement (DSE) bypass that operated alongside PatchGuard for three years (2011 -- 2014) without modifying any PatchGuard-protected structure [@gdata-uroburos-blog] [@stmxcsr-turla]. The lesson is structural: PatchGuard's protected-structure list is, by construction, narrower than the kernel-modification surface, and a disciplined attacker simply stays outside the list. The corollary -- that no in-kernel integrity monitor can be wider than its protected-structure list, and any list narrower than "all kernel memory" leaves gaps -- is the empirical anchor for the same-privilege paradox.

The policy on 64-bit Windows that the kernel will load only Authenticode-signed drivers in production. DSE is gated by an in-memory flag (`nt!g_CiEnabled` historically, `nt!g_CiOptions` on later builds). An attacker with arbitrary kernel write can flip the flag and load unsigned drivers -- which is precisely how the BYOVD attack pattern works [@gdata-uroburos-blog] [@hfiref0x-upgdsed].

Three insights converged from this act. From the side-channel KASLR literature: some defenses cannot succeed at CPL=0 because the attack is below the operating system. From Allievi 2014 and Uroburos 2011 -- 2014: same-privilege obfuscation is permanently bounded by engineering cost, no matter how much engineering cost you pay. From Bochspwn: win32k is not a bug tail but a bug class -- the only structural answer is to delete the surface rather than defend it. The 2017 calendar year was about to land all three answers at once.

5. 2017's triple inflection

In a single calendar year, three mutually independent breakthroughs reshaped kernel self-defense. June 2017: CyberArk's Kasif Dekel published GhostHook, an Intel-PT-based PatchGuard bypass that forced Microsoft's first public statement that PatchGuard is not a security boundary [@cyberark-ghosthook]. July 2017: Gruss et al. published "KASLR is Dead: Long Live KASLR" at ESSoS, proposing kernel page-table isolation as the structural answer [@gruss-kaiser-pdf]. October 2017: Windows 10 1709 shipped Win32kSystemCallFilter, the per-process, per-syscall allow-list designed for the Chrome and Edge renderer sandboxes [@ms-syscall-filter-policy]. Three teams, three mitigations, three facets of the same paradox.

Win32kSystemCallFilter (October 17, 2017)

The Windows 8 mitigation DisallowWin32kSystemCalls had been the right idea applied as a meat-axe: an opted-in process loses access to every win32k system call. Windows 10 1709 introduced the surgical version. PROCESS_MITIGATION_SYSTEM_CALL_FILTER_POLICY registers a per-process bitmap of system-defined FilterId values that the process is allowed to call; everything outside the bitmap is denied [@ms-syscall-filter-policy]. The filter is applied via UpdateProcThreadAttribute(PROC_THREAD_ATTRIBUTE_MITIGATION_POLICY, ...) at CreateProcess time -- not at runtime.

A Windows 10 1709+ process-mitigation policy (`PROCESS_MITIGATION_SYSTEM_CALL_FILTER_POLICY`, header `ntddk.h`) that registers a per-process bitmap of allowed system-defined `FilterId` values for win32k system calls. Calls outside the bitmap terminate the calling process. Used by the Chromium sandbox to constrain the win32k surface available to a renderer process [@ms-syscall-filter-policy] [@chromium-sandbox-doc].

The "at CreateProcess time, not at runtime" detail is load-bearing. James Forshaw and Ivan Fratric's November 2016 Project Zero post "Breaking the Chain" documented how Edge's window-broker architecture, which applied syscall restrictions to a child process after it had started, was subject to a window-of-opportunity race between the child's earliest syscall and the broker's policy application [@pz-breaking-chain]. If the policy is not in place by the time the first attacker-controlled syscall fires, the policy has not happened. The lesson the Windows 10 1709 design banked: mitigations belong on the CreateProcess boundary, not on a later thread.

sequenceDiagram participant R as Renderer process (VTL0 user) participant SD as Syscall dispatcher (kernel) participant W as win32k handler participant EP as EPROCESS filter bitmap R->>SD: NtUser/NtGdi syscall with FilterId N SD->>EP: Consult per-process filter bitmap EP-->>SD: bit N set or unset alt FilterId allowed SD->>W: Dispatch to win32k handler W-->>R: Return result else FilterId denied SD->>R: Terminate process via fast-fail end

The Forshaw / Fratric Edge race is a textbook case of why "apply at runtime" is a security anti-pattern for process mitigations. The Microsoft Edge of late 2016 used a sandbox model in which a renderer process started with limited restrictions and then upgraded itself to the full lockdown profile after initialisation. Forshaw and Fratric showed that an attacker who landed code execution before the upgrade completed -- a window of milliseconds -- could simply not upgrade. The lesson generalises beyond Edge: every per-process mitigation in modern Windows is applied at process creation time precisely so there is no window the attacker can race [@pz-breaking-chain].

The cleanest way to see the two-mitigation contrast is side by side:

Property	`DisallowWin32kSystemCalls`	`Win32kSystemCallFilter`	Chromium's actual choice
First shipped	Windows 8, 2012 [@ms-syscall-disable-policy]	Windows 10 1709, October 2017 [@ms-syscall-filter-policy]	Both, in different process types
Granularity	All-or-nothing	Per-syscall allow-list	Blanket-disable for non-UI; per-syscall for renderer
Mitigation policy struct	`PROCESS_MITIGATION_SYSTEM_CALL_DISABLE_POLICY`	`PROCESS_MITIGATION_SYSTEM_CALL_FILTER_POLICY`	Composes both with LPAC privilege reduction
Use case	Non-UI broker processes (GPU broker, network process)	Renderer processes that draw windows	The renderer needs a constrained-but-non-zero win32k subset [@chromium-sandbox-doc]

The Chromium sandbox composes the two mitigations with one more: the Less Privileged AppContainer (LPAC). LPAC removes ambient access to user data, the network, and most named-object namespaces; Win32kSystemCallFilter removes the syscall surface; DisallowWin32kSystemCalls applies to processes that need no UI at all. Defense in depth at the surface level rather than the structural level.

A Windows AppContainer variant introduced in Windows 10 that further restricts the ambient capabilities available to the contained process -- no access to user files, no access to most named objects, restricted ability to enumerate the system. Combined with `Win32kSystemCallFilter`, LPAC gives the Chromium renderer a process model in which both *what the renderer can ask the kernel to do* and *what the renderer can see in user mode* are deliberately narrow [@chromium-sandbox-doc].

Note: Win32kSystemCallFilter is the first mitigation in the 21-year arc that deletes attack surface rather than defending it. PatchGuard and KASLR are kernel defenses: they live inside the kernel and protect kernel state. The win32k filter is a process-mitigation policy enforced by the kernel's system-call dispatcher at the syscall boundary. The protection is realised by not letting the kernel be called rather than by checking the kernel's state afterwards. Once you see this shape, the rest of the modern Windows mitigation stack -- KDP, kCFG-with-VBS-bitmap, kCET -- becomes legible as variations on the same move: put the enforcement outside the attacker's reach.

KAISER and the page-table split

In July 2017, Gruss et al. presented "KASLR is Dead: Long Live KASLR" at ESSoS [@gruss-kaiser-pdf]. The acronym was KAISER -- Kernel Address Isolation to have Side-channels Efficiently Removed. The architecture is simple to describe, hard to engineer, and devastating to a side-channel attacker.

A modern x64 kernel runs in the same virtual address space as the calling user process, distinguished by privilege bits in page-table entries. A syscall does not change the page tables; it only changes the privilege level. The TLB is therefore shared between user and kernel mappings, and side-channel attacks like Hund 2013 work by timing the resulting cache and TLB behaviour. KAISER's answer was to give each process two sets of page tables: a "user" CR3 in which the kernel address space is not mapped, and a "kernel" CR3 in which the full virtual address space is mapped. The syscall entry path switches from user CR3 to kernel CR3; the sysret path switches back. The kernel address space is not just unknown to a user-mode attacker -- it is structurally unreachable.

A design proposed by Gruss et al. (KAISER, ESSoS 2017) [@gruss-kaiser-pdf] in which each process has two page-table hierarchies: a user CR3 that does not map the kernel and a kernel CR3 that maps both. CR3 is switched on every syscall entry and exit. The kernel is no longer just *hard to find* (the KASLR posture); it is *unreachable* from user CR3 (the structural posture). Linux shipped KAISER as KPTI in early 2018; Microsoft shipped a re-engineered variant as KVA Shadow [@ms-kva-shadow-blog]. sequenceDiagram participant U as User-mode thread participant CPU as CPU CR3 participant K as Kernel U->>CPU: syscall (SYSCALL instruction) CPU->>CPU: Switch CR3 from user to kernel CPU->>K: Kernel now mapped, enter system service K->>K: Handle request K->>CPU: SYSRET CPU->>CPU: Switch CR3 back to user CPU->>U: Return to user mode, kernel unmapped

The Gruss paper landed six months before anyone knew why it mattered. Then, on January 3, 2018, Jann Horn published "Reading privileged memory with a side-channel" on Project Zero [@pz-meltdown-post], the same day the academic teams (Lipp et al., independently) published the Meltdown disclosure [@usenix-lipp-meltdown]. Meltdown -- CVE-2017-5754, "rogue data cache load" -- exploited transient out-of-order execution on Intel CPUs to read kernel memory from user mode. The only structural fix was to ensure the kernel pages were not present in the user-mode page table. KAISER's design, drafted as a generic side-channel countermeasure, was suddenly Meltdown's required mitigation.

GhostHook and the formal admission

In June 2017, Kasif Dekel published GhostHook [@cyberark-ghosthook]. The mechanism is elegant. Intel Processor Trace (Intel PT) is a CPU feature for low-overhead recording of control flow, designed for performance analysis and debugging. The trace is written to a Table of Physical Addresses (ToPA), and when a configured ToPA region fills, the CPU raises a performance-monitoring interrupt (PMI). The OS's PMI handler is a function pointer. PMI handlers run in kernel mode, with full kernel privilege. GhostHook configured Intel PT with a tiny ToPA covering an address near IA32_LSTAR (the syscall entry MSR), arranged for the buffer to fill immediately, and registered an attacker-controlled PMI handler. Every kernel transition fired the PMI; the attacker's handler ran first. PatchGuard does not enumerate Intel PT. By design.

Microsoft's response, as reported in the CyberArk write-up, was the formal end of an eleven-year ambiguity. PatchGuard is "considered an in-depth security feature" but not a security boundary; the GhostHook bypass would "be considered for a future version of Windows" but did not warrant an out-of-band fix [@cyberark-ghosthook]. The Microsoft position aligns with the Security Servicing Criteria: admin-to-kernel is not a security boundary, and an attacker who has already reached kernel mode (the precondition for installing a GhostHook-style PMI handler) is outside the scope of what PatchGuard exists to prevent [@ms-servicing-criteria].

While the technique was found to bypass PatchGuard, Microsoft has graciously agreed to consider [the issue] for a future version of Windows. As such, no immediate risk exists for customers. -- Microsoft response to GhostHook, June 2017 [@cyberark-ghosthook].

The three breakthroughs of 2017 were structurally aligned. Win32kSystemCallFilter deleted the most-vulnerable syscall surface from sandboxed renderers. KAISER's page-table split made KASLR's probabilistic defense obsolete and structurally unreachable. GhostHook forced the public admission that the same-privilege class of defense has a ceiling Microsoft already knew about. And then, on the morning of January 3, 2018, the academic paper of six months earlier became an emergency engineering deliverable.

6. State of the art: KDP, KVA Shadow, kCFG, kCET, and the Secure Kernel shift (2018 -- 2026)

January 3, 2018: Meltdown's public disclosure forces every major operating system to ship page-table isolation within weeks [@pz-meltdown-post]. Microsoft's response, KVA Shadow, ships in the Windows 10 1709 cumulative security update the same day. The engineering write-up is bylined to Ken Johnson of the Microsoft Security Response Center [@ms-kva-shadow-blog]. The same Ken Johnson who, twelve years earlier, co-authored Bypassing PatchGuard on Windows x64 under the name Skywing [@uninformed-v3-archive]. The offensive-research outsider had become the bylined Microsoft defender. The same loop was about to close on the architectural question: where, exactly, does the defense live?

The Ken Johnson / Skywing trajectory -- offensive Uninformed paper in 2005, the bylined MSRC blog post in 2018, twelve years later -- is the cleanest single illustration of the offensive-research-to-Microsoft pattern. He is engineering credit attributed to Ken Johnson on the MSRC byline; the offensive identity is widely known but not asserted by Microsoft. Either reading of the byline is valid; the structural point is that the same person whose 2005 paper identified the architectural ceiling of CPL=0 obfuscation later shipped the cross-privilege answer for Meltdown [@uninformed-v3-archive] [@ms-kva-shadow-blog].

KVA Shadow: the productisation of KAISER

KVA Shadow is the Windows productisation of KAISER. Two CR3-loadable page tables per process: a user-mode shadow that does not map most of the kernel, and a kernel-mode page table that does. CR3 is switched on every syscall entry and exit. The kernel address space is unmapped from user CR3 [@ms-kva-shadow-blog]. The structural Meltdown fix is exact: a Meltdown-class transient read of a kernel address from user mode now hits an unmapped page-table entry and raises a fault before any cached side-channel evidence is produced.

Two things to be precise about. First, KVA Shadow addresses Variant 3 (Meltdown, CVE-2017-5754) only. Spectre Variant 1 (CVE-2017-5753), Variant 2 (CVE-2017-5715), and Variant 4 (Speculative Store Bypass) require their own mitigations (microcode updates, retpoline, IBRS / IBPB, SSBD); KVA Shadow does nothing for them [@usenix-lipp-meltdown]. Second, the performance cost of the CR3-switch on every syscall is real -- Fortinet's analysis of the KVA Shadow build measured significant slowdowns for syscall-heavy workloads, mitigated on newer CPUs by Process-Context Identifiers (PCID) that keep TLB entries valid across CR3 switches [@fortinet-kva-shadow].

HVCI: the VTL1 enabler

Hypervisor-Protected Code Integrity (HVCI) is not, strictly, a kernel defense -- it is the foundation everything else in the modern stack stands on. HVCI uses Virtualization-Based Security (VBS) to run a small Secure Kernel in Virtual Trust Level 1 (VTL1), one privilege level above the NT kernel in VTL0. The Secure Kernel manages the Second-Level Address Translation (SLAT) page tables -- Intel EPT or AMD NPT -- that mediate physical memory access for the NT kernel. With HVCI on, kernel pages are managed W^X (writable XOR executable): a kernel-mode driver attempting to make a writable page executable triggers a SLAT fault that VTL1 catches.

A Windows architecture in which the hypervisor partitions the system into two Virtual Trust Levels. VTL0 hosts the normal NT kernel, drivers, and user-mode processes. VTL1 hosts a Secure Kernel and a small set of trustlets that enforce policy on VTL0. Cross-VTL transitions are mediated by the hypervisor; a VTL0 kernel-mode attacker cannot reach VTL1, even with arbitrary kernel write. VBS is the architectural primitive that makes HVCI, KDP, and kCFG-with-VBS-bitmap possible [@ms-kdp-blog].

For this article HVCI is the cross-cutting dependency: it is what makes KDP and the VBS-protected kCFG bitmap work. Once you have a hypervisor enforcing SLAT on the NT kernel, every defense you want to anchor outside the NT kernel has a home.

KDP: static and dynamic kernel data protection

Microsoft announced Kernel Data Protection on July 8, 2020, with Windows 10 version 2004 [@ms-kdp-blog]. Two flavours.

Static KDP uses the MmProtectDriverSection API, called from DriverEntry, to mark a section of the driver's image as read-only for the rest of the kernel's lifetime. The intended use is for tables of policy data the driver expects never to modify after initialisation: function-pointer arrays, configuration constants, signed policy blobs. Once MmProtectDriverSection returns, the section's pages are tagged read-only in the VTL1-managed SLAT; a VTL0 kernel-mode attempt to write them takes a hardware page fault that VTL0 has no way to relax.

Dynamic KDP is for runtime-allocated state. The canonical API is ExAllocatePool3, called with a POOL_EXTENDED_PARAMETER array containing a POOL_EXTENDED_PARAMS_SECURE_POOL extended parameter [@ms-kdp-blog]. The flags SECURE_POOL_FLAGS_FREEABLE (1) and SECURE_POOL_FLAG_MODIFIABLE (2) control whether the allocation can later be freed and whether further protected modifications are permitted. The secure-pool extension routes the allocation through the Secure Kernel; the resulting memory is verified by VTL1 and protected by SLAT.

Note: KDP does not automatically protect "all kernel memory." It protects exactly the memory a driver author opts in to protect via MmProtectDriverSection (static) or ExAllocatePool3 with the secure-pool extension (dynamic) [@ms-kdp-blog]. Memory allocated through the normal ExAllocatePool2 path is not KDP-protected. A defender architecting around KDP must explicitly opt the data they care about into the secure pool; the protection is targeted, not blanket.

A Microsoft kernel-memory protection introduced with Windows 10 version 2004 (July 2020) that allows drivers to mark sections of kernel memory as read-only and have the protection enforced by the Secure Kernel in VTL1 via the SLAT page tables. Static KDP uses `MmProtectDriverSection`; Dynamic KDP uses `ExAllocatePool3` with a `POOL_EXTENDED_PARAMS_SECURE_POOL` extended parameter passed via `POOL_EXTENDED_PARAMETER`. The enforcement lives at a privilege level the VTL0 attacker cannot reach [@ms-kdp-blog].

The Microsoft launch blog makes the architectural point in one sentence: "the memory managed by KDP is always verified by the secure kernel (VTL1) and protected using SLAT tables by the hypervisor" [@ms-kdp-blog]. This is the first kernel self-defense mitigation in the Windows lineage whose enforcement is structurally outside the NT kernel. A VTL0 attacker with arbitrary kernel write cannot relax the SLAT entry that protects a KDP-tagged page, because the SLAT entry is managed by VTL1, and VTL1 is not in VTL0's address space.

flowchart TD A[VTL0 NT kernel plus attacker driver] -->|attempt write to KDP-protected page| B[CPU memory access] B --> C[SLAT page table consulted] C --> D{SLAT entry writable for VTL0} D -- no, RO by VTL1 --> E[Hardware EPT or NPT fault] D -- yes --> F[Write succeeds] E --> G[Secure Kernel in VTL1 receives fault] G --> H[VTL0 attacker has no path to relax SLAT entry]

Note: The canonical pre-boot PatchGuard bypass, EfiGuard, is a UEFI bootkit that patches the loaded kernel image to disable PatchGuard and DSE before the kernel runs [@mattiwatti-efiguard]. It works precisely because PatchGuard, DSE, and the kernel image all live in VTL0 -- a pre-boot agent has the same architectural reach. But once the system boots into a VBS-enabled configuration, the SLAT enforcement lives in VTL1, and the launching firmware does not have VTL1's privileges. The same attacker that defeats PatchGuard at the kernel level cannot defeat HVCI from the same vantage. This is the cleanest cross-mitigation demonstration that the architectural-layer choice -- "which privilege level does the defense live at?" -- is the load-bearing variable.

kCFG: forward-edge integrity

Control Flow Guard (CFG) is Microsoft's compiler-assisted forward-edge CFI. Every indirect call is replaced by a check against a bitmap of valid call targets; an invalid target raises a fast-fail [@ms-cfg]. The kernel variant -- kCFG -- is enabled by /guard:cf and protects indirect calls in ntoskrnl and CFG-compiled drivers. With HVCI on, the CFG bitmap is stored in VTL1-protected memory; a VTL0 attacker who can write arbitrary kernel pages still cannot tamper with the bitmap. kCFG defeats jump-oriented and call-oriented programming (JOP / COP) against the forward edge. It does nothing for the backward edge.

kCET: backward-edge integrity in hardware

Kernel-mode hardware-enforced stack protection (informally kCET, formally documented as "Kernel Mode Hardware-enforced Stack Protection") closes the backward edge using the Intel CET and AMD Shadow Stack hardware features [@ms-kernel-mode-hsp]. A CPU-maintained shadow stack records every CALL return address; every RET validates the popped address against the shadow stack and fast-fails on mismatch. The shadow-stack pages are marked Shadow Stack in the kernel-mode PTE, which the CPU enforces directly; with VBS on, the Secure Kernel additionally locks the shadow-stack mappings against VTL0 write.

kCET requires Intel 11th-generation Tiger Lake or later, or AMD Zen 3 or later, plus VBS and HVCI [@ms-kernel-mode-hsp]. It is off-by-default on Windows Server 2025 because enabling it system-wide requires every loaded driver to be compiled with the /CETCOMPAT flag; a single non-/CETCOMPAT driver disables kCET for the entire system at load time. As of June 2026, the rollout is gated on driver vendor adoption.

An adjacent technique worth knowing about by name is eXtended Flow Guard (XFG). XFG augmented kCFG's bitmap-membership check with a per-function type-derived 64-bit hash compared at the call site -- a defense that detects not just "is this target valid?" but "is this target the right target for this call's signature?" XFG was prototyped in MSVC and partially shipped on Windows 10 Insider builds, but the instrumentation never reached full inbox-kernel coverage and the feature is no longer Microsoft's strategic investment direction. The shipping equivalent on 2026 hardware is kCET for the backward edge plus kCFG for the forward edge.

Connor McGarr's Black Hat USA 2025 deck, "Out of Control: KCFG and KCET," documents the 2026 frontier of kCET bypasses -- an iretq-frame corruption combined with a write-what-where primitive can pivot around the shadow stack [@mcgarr-bh25-blackhat] [@mcgarr-km-shadow] [@mcgarr-github]. The bypass requires the attacker to already control a kernel-mode write primitive and several CFG-clean targets, which is exactly the precondition KDP, kCFG, and HVCI are designed to make hard.

ARM64 Pointer Authentication

The recurring framing of PatchGuard as "x64-only" is documentation-accurate but deployment-incomplete. In 2026, PatchGuard, kCFG, and Pointer Authentication Codes (PAC) ship on 64-bit ARM Windows as well as x64. PAC is an ARMv8.3-A feature in which a tag computed over a pointer value and a per-process key is stored in the unused high bits of the pointer; the CPU validates the tag on dereference. PAC closes a different class of pointer-corruption attacks than kCFG/kCET. The structural point is that the kernel self-defense investment is fully cross-architecture, not x64-only.

The Microsoft Vulnerable Driver Blocklist

The reactive answer to BYOVD is the Microsoft Recommended Driver Block Rules -- a list of known-vulnerable signed third-party drivers that Windows refuses to load when App Control for Business (formerly WDAC) is enabled [@ms-driver-block-rules]. The list is default-on with Memory Integrity, Smart App Control, and S-mode since Windows 11 22H2 and is updated through Windows Update. Verification on a modern system: CiTool --list-policies and look for a policy whose friendly name is Microsoft Windows Driver Policy and Is Currently Enforced: true. The blocklist is the structural answer to the Uroburos pattern -- Microsoft cannot prevent any signed third-party driver from having a write-primitive bug, but they can refuse to load specific drivers known to have shipped such bugs.

The attack pattern in which an attacker, having reached administrator privilege, installs a *legitimate* signed third-party kernel driver known to contain a privilege-escalation vulnerability, then exploits that vulnerability to obtain arbitrary kernel-mode primitives. The Uroburos VBoxDrv abuse [@gdata-uroburos-blog] is the canonical 2011 example; the Microsoft Recommended Driver Block Rules are the 2024+ reactive answer [@ms-driver-block-rules].

Synthesis

By 2026, the Windows kernel self-defense stack is no longer a single mitigation; it is a stack organised by where the defense actually runs. The 21-year trajectory now resolves into a single thesis: every generation has been a partial answer to the same-privilege paradox, and Microsoft's strategy has progressively migrated the defense out of the kernel -- first into instruction-level obfuscation, then into address-space tricks, then into VBS-anchored isolation, and finally into attack-surface deletion. Before we name that thesis formally, it is worth asking: what did the rest of the industry do?

7. What the rest of the industry did differently

The Microsoft answer to the same-privilege paradox -- twenty-one years of compounding investment in same-privilege deterrents while progressively shifting enforcement to VTL1 -- is not the only answer. Apple and the Linux mainline community took architecturally opposite paths, each correct for a different platform constraint.

Apple: push the defense into silicon

Apple's answer was to put enforcement below the kernel, into hardware Apple controls end-to-end. On Apple Silicon, the Kernel Text Read-only Region (KTRR) is hardware-enforced via the AMCC (Apple Memory Cache Controller). At boot, after the kernel is mapped and before user code runs, the kernel text region is locked read-only at the memory-controller level. Once locked, no software running at any privilege level can modify it -- not the kernel itself, not a kernel extension, not a hypothetical EL2 hypervisor [@siguza-ktrr].

Apple Silicon's hardware-enforced read-only kernel text region. After boot, the kernel image is locked via the AMCC memory controller; no software at any privilege level can write to the protected region for the lifetime of that boot [@siguza-ktrr]. Apple's architectural answer to the same-privilege paradox: push the defense *below* the kernel, into hardware Apple controls.

The corollary is that Apple's hardware control allows them to make a software move Microsoft cannot. Apple deprecated third-party Kernel Extensions (KEXTs) in favour of user-mode DriverKit and Endpoint Security, structurally removing the BYOVD class from the platform.Apple's deprecation of third-party KEXTs began in macOS Catalina (2019) with a deprecation warning, escalated to "system extensions" requiring user approval and reduced kernel-mode footprint, and reached a near-complete migration target on Apple Silicon. The architectural cost is that legitimate device-driver vendors and EDR products had to rebuild their stacks on top of user-mode brokers and Apple-curated APIs; the architectural benefit is that a 2024-style CrowdStrike Falcon kernel-driver outage is structurally not possible on Apple Silicon, because the EDR product runs in user mode against an Endpoint Security framework that mediates the kernel for it.

Linux mainline: privilege reduction, not integrity monitoring

The mainline Linux community's strategy is structurally the opposite of Microsoft's: do not invest in same-privilege deterrents at all; invest in privilege reduction and surface isolation instead. LKRG (Linux Kernel Runtime Guard, maintained by Openwall) is the closest functional analogue to PatchGuard [@openwall-lkrg-page] [@openwall-lkrg-github]. Its own documentation describes it as "bypassable by design" -- an openly-acknowledged same-privilege paradox.LKRG's frank framing is unusual in the security tools space. The project explicitly tells operators that LKRG is a hardening layer that raises the engineering cost of common kernel rootkit techniques, not a security boundary, and that a determined kernel-mode attacker can defeat it. This is the same architectural truth Skywing made in 2005 and that Microsoft published in the Servicing Criteria a decade later, stated upfront in a project README.

Beyond LKRG, the mainline mechanisms have a recurring structural shape. Each row of the table below is structurally a privilege-reduction or surface-removal mechanism rather than a same-privilege integrity check.

Linux mechanism	Status (as of June 2026)	What it protects	Windows analogue
Lockdown LSM	Mainline since 5.4 (2019)	Restricts root's ability to modify the running kernel	Driver Signature Enforcement plus HVCI
FG-KASLR	Out-of-tree	Per-function rather than per-image randomisation	No direct analogue; closest is kASLR base randomisation
Clang KCFI (`-fsanitize=kcfi`)	Mainline since 6.1 (Dec 2022)	Forward-edge CFI for the Linux kernel	kCFG
Shadow Call Stack (ARM64)	Mainline since 5.8 (2020)	Backward-edge integrity on ARM64	kCET (on x64 / AMD), SCS on ARM64 Windows
seccomp-bpf	Mainline since 3.5 (2012)	Caller-defined per-syscall filter for any process	`Win32kSystemCallFilter` (system-defined IDs)
eBPF kernel-mode restrictions	Mainline since 5.8 (2020)	Limits unprivileged users from loading eBPF programs that touch kernel state	No direct Windows analogue

The shared design move across all six is structural privilege reduction rather than same-privilege integrity monitoring. seccomp-bpf is particularly instructive as a counterpoint to Win32kSystemCallFilter. The Linux design is caller-defined: any process can register a BPF program that filters its own syscalls. The Windows design is system-defined: a process registers an opaque bitmap of FilterId values whose semantics are decided by the kernel. The two are not interchangeable, but they answer the same architectural question -- "how do you let a process tell the kernel which syscalls it does not want?" -- with the same fundamental move: per-process surface deletion at the syscall boundary.

Hypervisor-anchored alternatives at the application level

The third philosophy applies the "live at a different privilege than the attacker" answer at the application level rather than the kernel level. Bromium / HP Sure Click and Windows Defender Application Guard open every tab or document in its own micro-VM. The hypervisor is the protection boundary; the kernel inside the VM may be fully compromised without affecting the host. This is structurally the same move Microsoft makes with VBS / VTL1, applied one level up the stack.

Three philosophies, one shared admission

Three platforms, three philosophies, one shared admission: every architecture eventually had to admit that a defense at the same privilege as the attacker cannot succeed in principle. Apple put the defense in silicon. Linux invested in surface reduction instead of integrity monitoring. Microsoft built a same-privilege deterrent first, then migrated the load-bearing pieces of it to VTL1. The interesting disagreement is not whether the paradox exists -- it is where, exactly, to put the defense instead. That is a question with no single right answer, and to see why, we have to state the paradox formally.

8. The same-privilege paradox, formally

Now we can state the paradox in a sentence: a defense that shares its CPU privilege level with the attacker can in principle always be subverted by an attacker at that privilege level, because every code path and data structure the defense relies on is, by construction, mutable by the attacker. It is not a formal impossibility theorem in the cryptographic sense -- there is no FLP-style no-go proof for kernel self-defense -- but it is the de facto design constraint Microsoft has acknowledged in writing.

Microsoft's formal admission

The Microsoft Security Servicing Criteria for Windows defines a "security boundary" as "a logical separation between the code and data of security domains with different levels of trust", with kernel-mode versus user-mode as the canonical example [@ms-servicing-criteria]. The document then enumerates which transitions Microsoft treats as security boundaries (kernel / user, hypervisor / kernel, VTL1 / VTL0, virtual machine / host, network), and explicitly does not enumerate admin-to-kernel or kernel-to-kernel as boundaries. The exclusion is the cleanest possible architectural admission of the paradox: no defense at CPL=0 in the attacker's kernel can be a security boundary, no matter how cleverly engineered. PatchGuard, by Microsoft's own classification, is not a boundary and never has been.

Key idea: The same-privilege paradox is, formally, the observation that the reference monitor of a security policy must be tamper-resistant from the principals it monitors, and that "tamper-resistant from a co-resident kernel-mode attacker" is structurally unachievable in a single-address-space single-privilege design. Every modern Windows kernel mitigation either raises the cost of tampering (the engineering-deterrent class: PatchGuard, KASLR, kASLR variants) or moves the monitor outside CPL=0 (the structural class: KDP, kCFG-with-VBS-bitmap, kCET, the entire VTL1-anchored stack). Only the second class can claim a security boundary.

The KASLR-specific bound

The cleanest mathematical version of the paradox lives in the KASLR side-channel literature. Suppose an x64 system has $n$ bits of entropy in its kernel base address; the probabilistic floor on guessing it from one shot is $2^{-n}$. The Hund-Willems-Holz 2013 result is that a co-resident user-mode attacker with access to a shared TLB or cache state can extract bits of the kernel base at a rate of one bit per probe, recovering the address in $O(n)$ probes -- a polynomial-time defeat of the probabilistic defense [@doi-hund-2013]. Increasing $n$ does not change the asymptotic; it only changes the constant. Gruss et al. 2017 generalised the argument across micro-architectural side channels and concluded that any operating system implementing user / kernel address-space sharing on a CPU with shared TLB / cache state must leak the kernel base address to an unprivileged user-mode timing observer [@gruss-kaiser-pdf]. The structural fix is not to add entropy: it is to remove the sharing. KVA Shadow / KPTI is the structural answer.

The shape of the bound is general. Wherever a defense's correctness reduces to the attacker not knowing X, and X leaks across a shared micro-architectural channel, the defense is asymptotically defeated.

The proper formal anchor: Anderson 1972

The right formal anchor for the same-privilege paradox is the reference-monitor concept introduced in Anderson's 1972 Computer Security Technology Planning Study for the US Air Force [@csrc-anderson-1972]. Anderson's "reference monitor" must satisfy three properties:

Always invoked. Every reference of a subject to an object is mediated.
Tamper-resistant. The reference monitor cannot be modified by the subjects it monitors.
Small enough to be analysed. The Trusted Computing Base (TCB) is small enough to be verified.

PatchGuard fails property 2 by construction: it lives in the same address space as the subjects it monitors, and any subject with kernel-mode write can modify the verifier code, the verifier schedule, the expected-hash store, or the bug-check primitive. KDP, by contrast, satisfies property 2 because its enforcement lives in VTL1 and a VTL0 subject cannot reach VTL1.

A recurring confusion in the kernel-security literature is to anchor same-privilege-paradox arguments in the Bell-LaPadula or Biba multi-level security models (1973 / 1977). Those models formalise *information flow* across security domains -- which subjects may read or write which objects given their lattice levels. They are silent on the question of whether the policy *enforcement mechanism itself* can be tamper-resistant against a co-resident attacker. That is Anderson's reference-monitor property, formalised in the 1972 USAF report [@csrc-anderson-1972]. Bell-LaPadula assumes a tamper-resistant reference monitor as a precondition; Anderson's report is the document that *names* the precondition. For the same-privilege paradox, Anderson is the load-bearing anchor.

The existence proof for what a minimal verifiable TCB looks like is seL4 (Klein et al., SOSP 2009): a roughly 8,700-line microkernel formally verified down to its C implementation against a high-level specification of access control. seL4 is the constructive counterpoint to the Microsoft-style mitigation stack: instead of adding integrity monitors to a large kernel, build a small kernel small enough to verify and put everything else in user-space servers. Windows' VBS / VTL1 architecture is a partial gesture in the same direction -- the Secure Kernel is far smaller than the NT kernel and hosts only policy-enforcement trustlets -- but it is not a from-scratch redesign.

Upper and lower bounds, mitigation by mitigation

The 21-year story now lays out cleanly as a table of bounds.

Mitigation	Upper bound achieved	Lower bound that remains	Structural reason
PatchGuard	Engineering-deterrent class; raises cost of casual kernel hooking	Zero structural lower bound; same-privilege bypass class always exists [@uninformed-v3-archive] [@cyberark-ghosthook]	Verifier lives at attacker's privilege
KASLR (entropy alone)	Probabilistic floor against blind-guess attacker	Zero structural lower bound against side-channel attacker [@doi-hund-2013]	TLB / cache shared between user and kernel
KVA Shadow / KPTI	Structural Meltdown fix (Variant 3)	Spectre Variants 1, 2, 4 require separate mitigations [@usenix-lipp-meltdown]	Address-space split addresses only the user-to-kernel transient read
HVCI	Structural W^X for kernel pages, enforced by VTL1	VBS-coverage gap on systems that cannot run VBS [@ms-kdp-blog]	Hypervisor is the protection boundary
KDP (static and dynamic)	Structural read-only-after-init for explicitly-tagged kernel data	Protects only what is explicitly opted in [@ms-kdp-blog]	VTL1 enforces SLAT page tables outside VTL0 reach
kCFG (with HVCI)	Structural forward-edge CFI; bitmap in VTL1-protected memory	Backward edge unprotected; same-call-target overwrite via type confusion possible without XFG [@ms-cfg]	Bitmap stored outside VTL0
kCET	Structural backward-edge CFI in CPU hardware	Off-by-default on Server 2025; gated on driver `/CETCOMPAT` [@ms-kernel-mode-hsp] [@mcgarr-bh25-blackhat]	Shadow stack hardware enforced in silicon
Win32kSystemCallFilter	Structural surface deletion for sandboxed renderers	Full lockdown not viable for UI-bearing processes [@ms-syscall-filter-policy]	Per-process bitmap consulted by syscall dispatcher

The gap between the same-privilege upper bound (PatchGuard, KASLR-alone -- structurally zero) and the cross-privilege upper bound (HVCI, KDP, kCET -- structurally meaningful) is exactly the gap Microsoft has spent twenty-one years migrating across. With the paradox stated formally, the rest of the article is a single question: where in the privilege hierarchy does the next problem live, and how is Microsoft positioned to answer it?

9. Open problems on the June 2026 frontier

The same-privilege paradox is in 2026 closer to architecturally resolved than at any prior point in Windows history -- the VTL1-anchored stack of HVCI / KDP / kCFG / kCET makes the cross-privilege answer real. But every structural mitigation has a practical residual, and five of them are large enough to be the article's frontier.

BYOVD: the dominant 2026 attacker path

Bring-Your-Own-Vulnerable-Driver is the dominant practical defeat of every structural mitigation in the 2026 stack. Uroburos's 2011 pattern is essentially what current attackers do: locate a signed third-party driver with a kernel-write primitive (an IOCTL that allows arbitrary physical memory read or write, or arbitrary MSR manipulation), install it through a legitimate driver-load path, exploit the primitive to obtain arbitrary kernel write, then flip the policy flags or hook the structures Microsoft thought were protected. Elastic Security Labs' 2024 survey of in-the-wild Windows kernel LPE 0-days confirms that BYOVD remains a recurring subsystem of incidents [@elastic-lpe-survey], and the Project Zero "0day In the Wild" tracker continues to record Windows kernel-mode CVEs across DWM, win32k, and ALPC subsystems [@pz-0days-tracker]. Every structural mitigation collapses the moment an attacker reaches arbitrary kernel write through a legitimately-loaded driver: KDP-protected pages can be ignored if the attacker can install a new driver that simply does not allocate from the secure pool; kCFG can be bypassed by writing to memory that was not opted in; kCET can be bypassed via McGarr-style iretq corruption [@mcgarr-km-shadow]; PatchGuard can be hooked from a coexisting driver.

The Microsoft Recommended Driver Block List [@ms-driver-block-rules] is the reactive answer. The structural problem -- that signed third-party drivers with kernel-write primitives exist at all, and that the third-party driver supply chain cannot be removed for compatibility reasons -- is unresolved.

Note: A defender architecting around the 2026 Windows kernel mitigation stack must assume BYOVD as the dominant practical bypass. The structural mitigations -- KDP, kCFG, kCET, HVCI -- are sound against an attacker who is constrained to operate within the inbox kernel. They are not sound against an attacker who can load any of the recurring vulnerable signed drivers the Microsoft Recommended Driver Block List exists to catalogue [@ms-driver-block-rules] [@elastic-lpe-survey]. Verify that the block list is enforced (CiTool --list-policies), watch CodeIntegrity Event ID 3099, and treat BYOVD as the threat model that drives mitigation selection.

The VBS coverage gap

Every VTL1-anchored mitigation collapses on systems that cannot run VBS. Older silicon (pre-2015 Intel without VT-x / VT-d / EPT, AMD parts predating AMD-V / NPT), enterprise-imaged corporate fleets that disabled VBS for compatibility, ARM64 devices below a baseline, and any system without UEFI Secure Boot all fall back to the same-privilege defenses we just classified as structurally bounded. The defender's threat model is the worst case in the fleet, not the average case in the Microsoft launch announcement.

Win32k Lockdown coverage in UI-bearing processes

Office, browsers' GPU and UI processes, and any application that draws windows cannot use the full Win32kSystemCallFilter lockdown. Their allow-lists must cover composition, font rendering, and a substantial fraction of the GDI surface -- which is exactly the surface from which historical LPE bugs emerged. The 2016 win32kbase.sys / win32kfull.sys typeisolation refactor (Windows 10 v1607, build 14393) split win32k.sys to make the surface more attributable, but per-app auto-tuning of the allow-list from observed-call traces remains an open product-engineering problem [@j00ru-syscalls-table]. Until UI-bearing processes can use a tight allow-list rather than a permissive one, the win32k surface remains the systemic LPE foothold Bochspwn identified in 2013 [@j00ru-bochspwn-blog].

Hypervisor escapes as the structural counter

Every VTL1-anchored mitigation assumes VTL1 is uncompromised. Hyper-V CVEs show that the hypervisor TCB hosts its own vulnerability surface. CVE-2024-38080 (Hyper-V SLAT vulnerability) is a 2024 example with Akamai write-up [@akamai-hyperv-cve]. Joanna Rutkowska's 2006 Blue Pill demonstration at Black Hat USA, Subverting Vista Kernel for Fun and Profit, was the seminal academic primary for the hypervisor-rootkit class and remains the canonical "Hyperjacking" reference [@blackhat-rutkowska-bluepill]. Every step the Windows mitigation stack takes toward putting more enforcement in VTL1 raises the criticality of VTL1's own correctness. The Hyper-V code base is small relative to ntoskrnl but is not zero, and the post-2018 trend of finding side-channel and architectural bugs in CPU hardware applies to VTL1 as much as it does to VTL0.

kCET deployment completion

kCET is shipping but off-by-default on Windows Server 2025, gated on driver /CETCOMPAT compatibility [@ms-kernel-mode-hsp]. Until kCET is on-by-default across the inbox kernel and all loaded drivers, the backward-edge ROP class against the Windows kernel remains exploitable in practice. McGarr's 2025 Black Hat USA deck documents both the structural-bypass frontier and the operational gating problem [@mcgarr-bh25-blackhat] [@mcgarr-github] [@mcgarr-km-shadow].

On July 19, 2024, a faulty kernel-mode signature update from CrowdStrike Falcon triggered a Windows page fault in a CrowdStrike driver, crashing an estimated 8.5 million Windows endpoints worldwide and disrupting airline operations, hospital systems, payment processing, and emergency-services dispatch for hours to days. The post-incident discussion produced one architectural takeaway widely shared across the kernel-security community: a single signed third-party kernel driver, even one shipped by a defender, can take the operating system down -- and there is no in-kernel protection against it that does not also break legitimate EDR vendors. Microsoft's 2006 position that the right answer is "as few third-party kernel drivers as possible, with as much functionality as possible mediated by user-mode brokers" got eighteen years of pushback before being retroactively vindicated. The 2024-2026 product direction -- Microsoft's announcement of the Windows Endpoint Security Platform, a user-mode EDR API that lets vendors build without kernel drivers -- is the inheritor of that position.

Historical anchoring: the win32k LPE share

The "win32k killed half of LPE" framing in the article's subtitle deserves time-scoping. Pre-lockdown, win32k was the dominant Windows kernel LPE subsystem -- Stuxnet 2010 (CVE-2010-2743) is the historical anchor [@nvd-cve-2010-2743], Bochspwn 2013 documented the systemic shape [@j00ru-bochspwn-blog] [@j00ru-bhusa-pdf], Forshaw 2016 reports that the Chrome M54 lockdown "blocked the sandbox escape of an exploit chain being used in the wild" [@pz-breaking-chain], and Elastic Security Labs' 2024 in-the-wild survey continues to name win32k among the recurring subsystems [@elastic-lpe-survey]. The Project Zero 0day tracker also confirms that win32k remains in the post-lockdown attacker mix [@pz-0days-tracker]. The lockdown removed roughly half the historically-vulnerable syscall surface from sandboxed renderers specifically; both the fraction and the scope are time- and context-bounded, and a precise percentage cannot be cited to the Project Zero tracker because the tracker does not publish per-subsystem aggregates.

flowchart TD subgraph SD["Surface deletion (kernel system-call boundary)"] SDF["Win32kSystemCallFilter per-process bitmap"] SDD["DisallowWin32kSystemCalls all-or-nothing"] end subgraph V1["VTL1 (Secure Kernel anchored)"] V1H["HVCI (W^X SLAT for kernel pages)"] V1K["KDP static and dynamic via SLAT RO"] V1C["kCFG bitmap in VTL1-protected memory"] end subgraph CPU["CPU mediated (hardware enforced)"] CPUS["kCET shadow stack on Intel CET / AMD"] CPUK["KVA Shadow CR3 switch"] end subgraph V0["VTL0 same-privilege (CPL=0)"] V0P["PatchGuard integrity checks"] V0K["KASLR base-address randomisation"] end SD --> V1 V1 --> CPU CPU --> V0

BYOVD is in 2026 what same-privilege bypass was in 2007 -- the dominant practical defeat of a mitigation stack whose individual pieces are each structurally sound. The next twenty-one years of Windows kernel self-defense will be substantially the story of what Microsoft does about it.

10. What a Windows defender or driver developer actually does today

The article's intellectual payoff has been made; the practical payoff is the rest of this section. Five concrete decision questions, in roughly the order a working practitioner would reason through them.

1. Is the system Secured-core or Windows 11 22H2+ with Memory Integrity on?

If yes, HVCI, KDP, kCFG, and the Microsoft Recommended Driver Block Rules are baseline [@ms-kdp-blog] [@ms-driver-block-rules]. Layer kCET if all loaded drivers are /CETCOMPAT and the CPU is Intel 11th-gen Tiger Lake or later or AMD Zen 3 or later [@ms-kernel-mode-hsp]. The baseline gets you the structural mitigations the same-privilege paradox argues are required; everything else is layered on top.

2. Is the workload a sandboxed renderer or sandboxable child process?

Apply Win32kSystemCallFilter (Windows 10 1709+) via UpdateProcThreadAttribute(PROC_THREAD_ATTRIBUTE_MITIGATION_POLICY, ...) at CreateProcess time, not at runtime [@ms-syscall-filter-policy]. The Forshaw / Fratric race-the-mitigation Edge demonstration is the empirical reason -- if the filter is applied after the child process has started, an attacker who races the policy application can simply not be filtered [@pz-breaking-chain]. The Chromium sandbox is the canonical consumer reference for what this composition looks like in a production browser [@chromium-sandbox-doc].

Note: Every per-process mitigation in modern Windows -- Win32kSystemCallFilter, DisallowWin32kSystemCalls, ACG, CIG, Strict CIG, user-mode shadow stack, CFG -- belongs on the CreateProcess boundary. The Forshaw / Fratric Project Zero finding on Edge's window-broker race [@pz-breaking-chain] is the empirical proof that mitigations applied to a running process leave a race window. The Windows API path is STARTUPINFOEXW with a PPROC_THREAD_ATTRIBUTE_LIST containing PROC_THREAD_ATTRIBUTE_MITIGATION_POLICY; the policy enums to set are documented in ntddk.h for the filter [@ms-syscall-filter-policy] and in winnt.h for the disable [@ms-syscall-disable-policy].

3. Is the workload UI-bearing?

Full lockdown is out of reach for processes that draw windows, render fonts, or dispatch input. The practical answer is the adjacent mitigation set: Arbitrary Code Guard (ACG), Code Integrity Guard (CIG), Strict CIG, user-mode shadow stack, and CFG, plus PatchGuard, HVCI, and kCFG at the system level. The composition raises the cost of remote exploitation without requiring the renderer-style syscall-surface deletion.

For a sandboxed renderer-class process on Windows 11 22H2+:

Win32kSystemCallFilter -- PROCESS_MITIGATION_SYSTEM_CALL_FILTER_POLICY with the bitmap permitting only the FilterId values the renderer needs [@ms-syscall-filter-policy].
ACG (Arbitrary Code Guard) -- forbid dynamic code generation in the process.
CIG / Strict CIG (Code Integrity Guard) -- forbid loading non-Microsoft-signed DLLs (CIG), or non-Microsoft-signed-and-not-store-signed DLLs (Strict CIG).
User-mode shadow stack and CFG -- backward and forward edge CFI in user mode.

All four are applied via UpdateProcThreadAttribute(PROC_THREAD_ATTRIBUTE_MITIGATION_POLICY, ...) at CreateProcess time, in the same call. The Chromium renderer is the canonical reference deployment [@chromium-sandbox-doc].

4. Are you a driver author?

Three things to do, in order:

Mark RO-after-init data via Static KDP. Call MmProtectDriverSection from DriverEntry on any image section that should be read-only for the rest of the driver's lifetime [@ms-kdp-blog].
Allocate runtime-protected state via Dynamic KDP. Call ExAllocatePool3 with a POOL_EXTENDED_PARAMETER array containing a POOL_EXTENDED_PARAMS_SECURE_POOL extended parameter. Set SECURE_POOL_FLAGS_FREEABLE if the allocation needs to be freeable; set SECURE_POOL_FLAG_MODIFIABLE only if the allocation must be modifiable under further protected control [@ms-kdp-blog].
Compile with /guard:cf and /CETCOMPAT. The first enables CFG instrumentation across the driver image; the second tells the loader the driver is compatible with kernel-mode shadow stack [@ms-cfg] [@ms-kernel-mode-hsp].

The driver-side KDP pattern is short enough to show in full:

// DriverEntry-time static KDP: mark a .rdata-like section as read-only
NTSTATUS DriverEntry(_In_ PDRIVER_OBJECT DriverObject,
                     _In_ PUNICODE_STRING RegistryPath) {
    NTSTATUS status = MmProtectDriverSection(
        &g_PolicyTable,        // address of the section to protect
        sizeof(g_PolicyTable), // size in bytes
        0);                    // reserved
    if (!NT_SUCCESS(status)) return status;
    // ... rest of driver init
    return STATUS_SUCCESS;
}

// Runtime dynamic KDP allocation: a secure pool buffer
POOL_EXTENDED_PARAMETER params[2] = {0};
params[0].Type = PoolExtendedParameterSecurePool;
params[0].SecurePoolParams = &(POOL_EXTENDED_PARAMS_SECURE_POOL){
    .SecurePoolFlags = SECURE_POOL_FLAGS_FREEABLE,
    .SecurePoolBuffer = NULL,
    .Cookie = 0xC0FFEEDEADBEEFULL,
    .NoFill = FALSE,
};
params[1].Type = PoolExtendedParameterInvalidType;

PVOID secureBuffer = ExAllocatePool3(
    POOL_FLAG_NON_PAGED,    // pool flags
    bufferSize,             // size
    'KDPx',                 // pool tag
    params,                 // extended parameters
    1);                     // count of extended parameters

5. Are you a defender on an existing fleet?

Verify that the Recommended Driver Block Rules are active via CiTool --list-policies. Look for a policy whose Friendly Name is Microsoft Windows Driver Policy and Is Currently Enforced is true [@ms-driver-block-rules]. Watch Event ID 3099 in the CodeIntegrity Operational log for block events. For verifying the broader VBS / HVCI state, the canonical PowerShell query is Get-CimInstance Win32_DeviceGuard followed by selecting VirtualizationBasedSecurityStatus, SecurityServicesRunning, and AvailableSecurityProperties. For KVA Shadow specifically, Get-SpeculationControlSettings reports the state. For per-process mitigation policy, Get-ProcessMitigation -System for the system policy and Get-ProcessMitigation -Name <name> for a specific process; the Chromium internal page chrome://sandbox shows the per-process filter state from inside the browser.

A reader who wants to play with the field-decoding logic can do it in a browser. The Python below mirrors what the PowerShell pipeline does -- enumerate the bits, decode by name. The real Windows API surface is bigger, but the decoding shape is the same.

Conceptual decoder for Win32_DeviceGuard fields Real PowerShell: Get-CimInstance Win32_DeviceGuard | Select VirtualizationBasedSecurityStatus, SecurityServicesRunning, AvailableSecurityProperties

VBS_STATUS = { 0: "VBS not enabled", 1: "VBS enabled but not running", 2: "VBS enabled and running", }

SECURITY_SERVICES = { 0: "None", 1: "Credential Guard", 2: "HVCI", 3: "System Guard Secure Launch", 4: "SMM Firmware Measurement", 7: "Kernel Mode Hardware-enforced Stack Protection (kCET)", 8: "Hypervisor-Protected Code Integrity (HVCI legacy)", }

AVAILABLE_PROPERTIES = { 1: "Base virtualization support", 2: "Secure boot", 3: "DMA protection", 4: "Secure memory overwrite", 5: "UEFI code readonly", 6: "SMM security mitigations", 7: "Mode-based execute control for HVCI", 8: "APIC virtualization", }

def decode(field_name, value, table): if isinstance(value, list): names = [table.get(v, f"unknown({v})") for v in value] print(f" {field_name}: {names}") else: print(f" {field_name}: {table.get(value, f'unknown({value})')}")

Simulated CIM response from a Secured-core PC

sample = { "VirtualizationBasedSecurityStatus": 2, "SecurityServicesRunning": [1, 2, 7], "AvailableSecurityProperties": [1, 2, 3, 5, 7], }

print("Win32_DeviceGuard decoded:") decode("VirtualizationBasedSecurityStatus", sample["VirtualizationBasedSecurityStatus"], VBS_STATUS) decode("SecurityServicesRunning", sample["SecurityServicesRunning"], SECURITY_SERVICES) decode("AvailableSecurityProperties", sample["AvailableSecurityProperties"], AVAILABLE_PROPERTIES) `}

Common pitfalls

A short reference list of mistakes that recur in real-world reviews:

Apply mitigations at CreateProcess, not at runtime. The Forshaw / Fratric race is the cited example [@pz-breaking-chain].
Do not assume DisallowWin32kSystemCalls is the modern lockdown. It is the Windows 8 ancestor of Win32kSystemCallFilter and is structurally distinct -- different mitigation enum, different policy struct [@ms-syscall-disable-policy] [@ms-syscall-filter-policy].
Do not use MmAllocateNodePagesForMdlEx for Dynamic KDP. The canonical API is ExAllocatePool3 with the secure-pool extended parameter; the NUMA-MDL API is a different API for a different purpose [@ms-kdp-blog].
kCET disables system-wide on a non-/CETCOMPAT driver. A single non-compat driver in the inbox set turns it off [@ms-kernel-mode-hsp].
PatchGuard is not a security boundary. Do not architect a defense whose security argument rests on it; Microsoft's own Servicing Criteria say so [@ms-servicing-criteria].

None of these decisions makes the kernel a security boundary; together they make the kernel as hard to defeat as today's stack allows. The remaining questions are FAQs.

11. Frequently asked questions

No. Microsoft's own *Security Servicing Criteria for Windows* explicitly does not enumerate admin-to-kernel or kernel-to-kernel as a security boundary; PatchGuard is an *engineering deterrent*, not a security boundary [@ms-servicing-criteria]. The most empirically grounded refutation is Uroburos's 2011 -- 2014 operational coexistence with PatchGuard on production Windows systems [@gdata-uroburos-blog]. PatchGuard raises the cost of a class of attacks; it does not eliminate any class of attacks. No. PatchGuard shipped on April 25, 2005, with Windows XP Professional x64 Edition and Windows Server 2003 x64 Edition [@ms-advisory-932596]. Vista x64 (November 2006) inherited PatchGuard v2 from the 2005 release; the x86 editions of Vista never received PatchGuard. The "Vista first" misreading conflates PatchGuard's first widely-publicised release with its first shipping release. No. Uroburos was a Driver Signature Enforcement (DSE) bypass that coexisted with PatchGuard for three years (2011 -- 2014) without modifying any PatchGuard-protected structure. It loaded a signed-but-vulnerable copy of Oracle's `VBoxDrv.sys`, used the vulnerability to flip the `g_CiEnabled` DSE-gating flag, loaded its own unsigned rootkit driver, then operated alongside PatchGuard [@gdata-uroburos-blog] [@stmxcsr-turla]. The canonical PatchGuard *bypass* is GhostHook (Kasif Dekel, CyberArk, June 2017), which uses an Intel-PT-buffer-fill PMI to redirect execution without touching any structure PatchGuard enumerates [@cyberark-ghosthook]. No. They are distinct `SetProcessMitigationPolicy` enums with distinct semantics. `DisallowWin32kSystemCalls` shipped in Windows 8 (2012) as a `PROCESS_MITIGATION_SYSTEM_CALL_DISABLE_POLICY` and is all-or-nothing [@ms-syscall-disable-policy]. `Win32kSystemCallFilter` shipped in Windows 10 1709 (October 2017) as a `PROCESS_MITIGATION_SYSTEM_CALL_FILTER_POLICY` and is a per-syscall allow-list driven by a bitmap of system-defined `FilterId` values [@ms-syscall-filter-policy]. Chromium uses *both* in different process types -- the blanket-disable for processes that need no UI, the per-syscall filter for the renderer [@chromium-sandbox-doc]. Microsoft's documentation still calls it an x64 feature [@ms-driver-x64-restrictions], but in deployment it is also enforced on 64-bit ARM Windows in 2026. It has never shipped on x86 -- the precise framing is "64-bit Windows only, both x64 and ARM64." The "x64 only" framing is documentation-accurate but deployment-incomplete. Mostly no. KDP is a VBS-backed (Secure Kernel / VTL1) mitigation that *protects* kernel memory but is *enforced* outside the kernel. The Microsoft launch blog states the architecture directly: "the memory managed by KDP is always verified by the secure kernel (VTL1) and protected using SLAT tables by the hypervisor" [@ms-kdp-blog]. KDP is the canonical example of the same-privilege paradox resolved by structural means: the enforcement lives at a privilege level the VTL0 attacker cannot reach. Title hyperbole, time-scoped. Pre-lockdown, win32k was the dominant Windows kernel LPE subsystem -- Stuxnet 2010 used a `win32k.sys` keyboard-layout LPE [@nvd-cve-2010-2743]; Bochspwn 2013 documented the systemic shape [@j00ru-bochspwn-blog]; Forshaw reports that Chrome's M54 win32k lockdown "blocked the sandbox escape of an exploit chain being used in the wild" [@pz-breaking-chain]. Elastic Security Labs' 2024 in-the-wild survey continues to name win32k among the recurring subsystems [@elastic-lpe-survey]. The lockdown removed roughly half the historically-vulnerable syscall surface *from sandboxed renderers specifically* -- both the fraction and the scope are time- and context-bounded.

Key idea: PatchGuard, KASLR, KDP, Win32kSystemCallFilter -- four answers, twenty-one years, one paradox. The arc resolves: every meaningful kernel defense in modern Windows ultimately lives at a privilege level the attacker does not have, because the alternative -- defending the kernel from inside the kernel -- is the one thing the architecture cannot do.

Eight Primitives, One Worm: The Windows Security Wars Part 2 (2002-2008)

noreply@paragmali.com (Parag Mali) — Fri, 29 May 2026 00:00:00 GMT

Between Bill Gates's January 15, 2002 Trustworthy Computing memo and Windows 7's October 22, 2009 general availability, Microsoft executed the largest single security re-architecture in Windows's history -- and shipped most of it inside Windows Vista, one of the most poorly received consumer Windows releases ever made.

This is the story of what that re-architecture built (UAC, Mandatory Integrity Control, UIPI, ASLR, mandatory x64 driver signing, Service Hardening, BitLocker, the Windows Filtering Platform, Windows Resource Protection, and -- inherited from an April 2005 x64-only release that Vista did not introduce -- Kernel Patch Protection), and what Vista broke for compatibility and goodwill along the way.

Then Conficker (late November 2008, twenty-nine days after the MS08-067 patch) proved that deployment velocity, not discovery latency, is the binding constraint on Internet security. Windows 7's polished re-release of substantially the same security architecture is the article's evidence that the user-hostility tax is payable -- if the work is done.

1. The Patch Was Already a Month Old

On Thursday, October 23, 2008, the Microsoft Security Response Center shipped MS08-067 out of band -- not on the next Patch Tuesday, because the analysts who triaged the bug believed a wormable exploit was weeks away, not months [@s-ms08-067]. They were right about the direction and wrong about the calendar. Roughly twenty-nine days later, anchored to November 20, 2008 in SRI International's technical analysis, Conficker.A began walking the IPv4 address space on TCP/445 [@s-sri-conficker-c-addendum]. Within four months the worm had infected somewhere between nine and fifteen million machines on a vulnerability whose patch had existed the entire time [@s-cwg-lessons-learned-2019].

The October 23, 2008 Microsoft Security Bulletin patching CVE-2008-4250, a stack buffer overflow in the path-handling code reachable through the Server service's `srvsvc` RPC interface on TCP/445 (and TCP/139 in NetBT environments). The bulletin text warns the vulnerability "could be used in the crafting of a wormable exploit" -- a prediction that Conficker.A confirmed twenty-nine days later [@s-ms08-067]. A Microsoft security update released outside the regular monthly Patch Tuesday cadence (the second Tuesday of the month). Microsoft reserves out-of-band releases for vulnerabilities whose risk profile -- active exploitation, imminent worm potential, or critical pre-authentication remote code execution -- does not survive the wait until the next monthly bulletin window [@s-msft-secupdates-index].

This article is the story of what Microsoft built between January 15, 2002 (the Trustworthy Computing memo) and October 22, 2009 (Windows 7 general availability), the architectural and cultural costs of that build, and the operational lesson Conficker forced everyone to acknowledge.

The architectural defenses that Trustworthy Computing produced -- Data Execution Prevention, Address Space Layout Randomization, the Windows Firewall on by default, Service Hardening, the integrity-level stack -- could only protect machines that ran the new code. The installed base did not run the new code. Server 2003 and Windows XP were still the working majority on TCP/445-reachable subnets in late 2008, and Vista's DEP and ASLR materially raised exploitation cost on Vista without raising it on the systems the worm actually walked.

Confusing the October-2008 in-the-wild MS08-067 exploitation with Conficker is the most common single error in retellings of this period. The NVD entry for CVE-2008-4250 is explicit: the October-2008 in-the-wild exploitation was Gimmiv.A, a narrower non-self-propagating Trojan, not Conficker [@s-nvd-cve-2008-4250]. Conficker.A first appeared on the Internet on November 20, 2008 per SRI International [@s-sri-conficker-c-addendum].

sequenceDiagram autonumber participant MSRC as Microsoft Security Response Center participant SRV as Server service over TCP/445 participant VISTA as Vista with DEP and ASLR participant XP as XP and Server 2003 installed base participant CONF as Conficker.A MSRC->>SRV: Oct 23, 2008 out-of-band MS08-067 patch Note over MSRC,SRV: Bulletin warns "wormable exploit" possible SRV-->>XP: Patch must propagate via Automatic Updates or WSUS SRV-->>VISTA: Patch applied, DEP and ASLR raise exploit cost Note over XP,VISTA: Late October, in-the-wild Gimmiv.A Trojan uses CVE-2008-4250 narrowly CONF->>XP: Nov 20, 2008 Conficker.A scans TCP/445 across IPv4 Note over CONF,XP: Unpatched XP and Server 2003 are the dominant targets XP-->>CONF: Successful exploitation, lateral spread, DGA callback Note over CONF,XP: Jan to Apr 2009, 9 to 15 million infections worldwide

By the end of the article you will be able to name every XP SP2 and Vista mitigation, the attack class it broke, the compatibility cost it imposed, and which Windows release inherited or smoothed it. You will know why the most important Trustworthy Computing lesson was not architectural at all -- it was operational.

Key idea: The patch existed the entire time. Deployment did not. Every Trustworthy Computing mitigation in this article is a partial answer to the question "what reaches the installed base on time?" Conficker is the era's answer to the question "what does not?"

How did we get from the Code Red era to a Trustworthy-Computing world where a wormable RCE could still infect millions? Start with one memo and a stand-down.

2. Where Part 1 Left Off

On the morning of January 16, 2002, the engineers who worked on Windows came back to work and could not check in code. Bill Gates's memo had gone out the previous afternoon and reading it took about eleven minutes. The order in the building was the simple part: stop everything, sit through retraining, do not commit until you can argue your changes against a threat model.

The slower part was naming what had just happened. It was not a campaign. It was a directive that quietly changed the unit of work at Microsoft from "ship the feature" to "ship the feature you can prove will not get someone exploited."

The memo itself was the institutional charter for everything in this article. It opened in plain prose -- "Every few years I have sent out a memo talking about the highest priority for the company" -- and arrived at its load-bearing sentence in the fifth sentence of the first paragraph: "Trustworthy Computing is the highest priority for all the work we are doing" [@s-gates-twc-wired]. The line read in 2002 as a corporate goal-setting exercise. In retrospect it read as a contract.

The Wired and CNET reproductions of the memo carry the same body but differ on the timestamp in the "Sent:" header. Wired records "Sent: Tuesday, January 15, 2002 5:22 PM" [@s-gates-twc-wired]; CNET's parallel reproduction shows "Sent: Tuesday, January 15, 2002 2:22 PM" [@s-gates-twc-cnet]. The three-hour delta is the Eastern-vs-Pacific wall-clock difference, consistent with Wired having an Eastern copy and CNET reproducing a Pacific one. The article renders the send time as "2:22 PM Pacific / 5:22 PM Eastern."

Trustworthy Computing is the highest priority for all the work we are doing. -- Bill Gates, internal Microsoft memo, January 15, 2002 [@s-gates-twc-wired]

The next two months turned the memo into engineering. From roughly February through March 2002, Microsoft ran the Windows security stand-down: approximately 8,500 Windows engineers were pulled off feature work to read Howard and LeBlanc's Writing Secure Code, 2nd edition (Microsoft Press, 2002) [@s-howard-leblanc-wsc2e] and to be retrained on threat modeling, input validation, integer-overflow defense, secure default selection, and the privilege-reduction patterns the book named explicitly. Three Microsoft Press security titles served as the canonical training corpus for the next several years; Writing Secure Code 2e was the one that lived on every desk.

But the stand-down was a one-time event. The thing that had to outlast it was the process. The Trustworthy Computing Security Development Lifecycle, formally adopted as a mandatory company-wide engineering process in 2004 and described at the Annual Computer Security Applications Conference that December, is the right pivot to point to.

The canonical paper, Lipner and Howard's "The Trustworthy Computing Security Development Lifecycle," ran in the ACSAC 2004 proceedings [@s-lipner-howard-acsac2004-doi]; the IEEE Xplore PDF is paywalled in 2026, so the 2006 Microsoft Press book The Security Development Lifecycle is the cite-when-possible substitute [@s-howard-lipner-sdl-book]. The SDL is what made every later Windows release feasible: each new version's threat model, security design review, fuzzing budget, and security push had a name and a sign-off list.

Microsoft's formal process specification for security engineering across the product lifecycle. The SDL mandates threat modeling, secure design review, security training, banned-API enforcement, fuzzing, attack-surface review, and a final security push before any product ships. Mandatory company-wide at Microsoft starting in 2004; the definitive ACSAC 2004 paper is the formal record [@s-lipner-howard-acsac2004-doi], and the 2006 Microsoft Press book is the publicly accessible canonical reference [@s-howard-lipner-sdl-book].

The two-and-a-half years between the memo and XP Service Pack 2 were not quiet. MS03-026 in July 2003 led to Blaster three weeks later [@s-msft-ms03-026]; MS03-039 in August 2003 led to Welchia [@s-msft-ms03-039]; MS04-011 in April 2004 led to Sasser [@s-msft-ms04-011]. Each worm was, by the standards of late 2003, a public referendum on whether the "patch fast" model could work for an installed base of hundreds of millions of machines whose users never opened Windows Update. The pattern is worth a small table.

Date	Event	Why it mattered
Jan 15, 2002	Gates Trustworthy Computing memo	Institutional charter for the next eight years of Windows security work
Feb-Mar 2002	Windows security stand-down	About 8,500 engineers retrained on secure-coding patterns
Jul 16, 2003	MS03-026 patches DCOM RPC	Patch ships about three weeks before Blaster (Aug 11)
Aug 11, 2003	Blaster worm	Patched RPC vulnerability exploited in the wild; deployment lag obvious
Aug 2003	Welchia "good worm"	Nematode-style attempt to push the patch; spreads exactly as fast as Blaster
Apr 13, 2004	MS04-011 patches LSASS	Patch ships about two weeks before Sasser
Apr 30, 2004	Sasser worm	Hits ATMs, banks, airlines; the second wormable post-patch event in a year
Dec 2004	SDL formalised at ACSAC	Process becomes a paper; mandatory across Microsoft engineering

What Microsoft was about to ship in August 2004 was not a service pack. It was a feature release with a service-pack number on it -- and it would prove that the right unit of analysis for OS-level security is not the mitigation itself but the deployment threshold the default reaches.

3. Why XP SP2 Was Treated as a Major OS Release

By the end of 2003 the SP1-era model had collapsed. The bulletin cadence was monthly; the patch was per-CVE; the deployment mechanism was opt-in; and Blaster and Sasser had both shipped while that model was running [@s-msft-secupdates-index]. None of the four design decisions individually was unreasonable. Together they had produced a Windows world in which a worm could outrun a patch by weeks, sometimes months, and the only thing standing between a Class B subnet and an exploitation rate close to 100% was whether enough users had clicked "Install."

Microsoft's response was a year-long slip. XP Service Pack 2, internally codenamed "Springboard," moved from a planned H2 2003 release to August 6, 2004, and along the way it was upgraded from "service pack" to "feature release with a service-pack number on it."

The bundle that shipped that day did five things that no prior Windows release had ever done in a single update. The Windows Firewall arrived on by default and active during the boot sequence, closing the Blaster-window race condition. Data Execution Prevention shipped with default-on policy for Windows binaries.

The Attachment Execution Service became the system-wide enforcement substrate of the Zone.Identifier NTFS Alternate Data Stream. Internet Explorer 6 SP2 got a pop-up blocker on by default plus an ActiveX opt-in framework and a Local Machine Zone lockdown. Security Center became the first centralized Control Panel surface that aggregated firewall, Automatic Updates, and antivirus state into a single place a non-technical user could understand.

James Forshaw's Project Zero retrospective on Windows network access is blunt about how thin the pre-SP2 firewall story was [@s-forshaw-projectzero-wfp]. The Internet Connection Firewall in XP RTM was technically present, but it was off by default, scoped to the Internet-facing interface, and the first thing most OEM imaging scripts disabled.

Prior to XP SP2 Windows didn't have a built-in firewall, and you would typically install a third-party firewall such as ZoneAlarm. -- James Forshaw, Google Project Zero [@s-forshaw-projectzero-wfp]

The conceptual move underneath SP2 is the one that matters for the rest of the article. Microsoft did not invent a single new mitigation in SP2. Software firewalls, NX-style memory protection, file-provenance tagging, pop-up blockers, and centralized policy notifications all existed somewhere already in 2003 -- in third-party products, in PaX on Linux, in OpenBSD, in academic research. What SP2 did was take those mitigations off the customer's optional configuration menu and put them in the default install.

A security control whose default configuration on a freshly installed or upgraded system is "active," not "available to be enabled." On-by-default mitigations reach approximately the entire installed base of a release; opt-in mitigations reach approximately the small fraction of users who actively configure them. The asymmetry is roughly two orders of magnitude in deployment reach, which is the engineering reason XP SP2 was treated as a re-release rather than as a service pack [@s-forshaw-projectzero-wfp].

The "5%/95%" framing is shorthand for the on-by-default-vs-opt-in asymmetry -- a two-orders-of-magnitude reach gap [@s-forshaw-projectzero-wfp] that motivated default-on Firewall, default-on DEP for system binaries, default-on Automatic Updates, and default-on UAC.

Here is the SP2 bundle as a table. The third column is the load-bearing one: every default-on choice in SP2 came with a real compatibility cost, and the article's later sections are partly the story of those costs being paid down.

SP2 mitigation	Attack class broken	Compatibility cost
Windows Firewall on by default	Worm-style unauthenticated TCP/445, TCP/135 RPC	Apps binding listening ports without firewall exception manifest
Data Execution Prevention	Stack and heap shellcode execution	First-generation JITs that wrote executable code into RW pages
AES + Zone.Identifier ADS	Outlook and IE auto-launch of attachments	Legitimate self-extracting installers from network shares
IE6 SP2 hardening	Drive-by ActiveX install, pop-up ad layers, MIME confusion	Line-of-business intranet ActiveX apps; legacy webmail pop-ups
Security Center	Status invisibility for non-technical users	Third-party AV vendors objected to display of competing status

Key idea: Once the 5%/95% threshold becomes the unit of analysis, the question changes. The question is no longer "what is the best mitigation we could ship?" It is "what mitigation will the user not turn off?" Every Vista feature in the next chapter is an answer to that question -- and every Vista feature that broke compatibility is the price the answer cost.

XP SP2 reached the broad public via Automatic Updates by late August 2004. By the end of the year Microsoft had pushed the largest single security update in the operating system's history onto roughly the entire XP installed base. The five mitigations that landed that day deserve their own catalogue.

4. The XP SP2 Mitigation Catalogue

XP SP2 shipped on August 6, 2004 and reached the broad public via Automatic Updates by late August. The five mitigations below are not equally famous, but they are equally load-bearing for what came next in Vista. Each subsection opens with what the mitigation broke (the attack class) and ends with what it broke (the compatibility cost).

4.1 Windows Firewall on by default

Pre-SP2, XP had something called the Internet Connection Firewall. It was off by default; it bound only to the interface flagged as the Internet connection during setup; and any application that wanted a listening port could simply listen on a different interface and never trigger it. The Blaster window -- the moment between a fresh XP installing on a network and Automatic Updates pulling MS03-026 -- was open for as long as DHCP plus the first reboot took, which on a 2003-era cable modem was about ninety seconds. Welchia exploited the same window in reverse.

The fix in SP2 was structural. The renamed Windows Firewall came on by default on every interface, was active during the boot sequence (before user-mode services finished initialising), and ran during a brief boot-time stateful inspection window before the regular policy engine took over [@s-forshaw-projectzero-wfp].

What this broke for compatibility: every legitimate application that bound a listening port without registering a firewall exception manifest. Domain join, the older SMB RPC paths, and a long list of corporate management tools needed exception entries pushed via Group Policy before they would work on freshly joined SP2 machines. The forward link is to Vista's Windows Filtering Platform in section 6.6, which gave third-party firewalls and IDS/IPS vendors a supported extension surface instead of forcing them to keep hooking NDIS.

4.2 Data Execution Prevention

Data Execution Prevention is the Windows trade name for refusing to execute instructions from pages marked as data. Hardware-enforced DEP uses the AMD NX bit ("No-eXecute") or the Intel XD bit ("eXecute Disable"), both shipped in commodity x86 silicon by 2004 -- the AMD64 Athlon 64 launched with the NX bit on September 23, 2003 [@s-wp-athlon-64], and Intel followed with XD on the Prescott Pentium 4 stepping in mid-2004.

Software-enforced DEP on CPUs without the bit relied on SafeSEH-based exception-handler validation, which closed the most common shellcode-staging pattern of the era (overwrite a saved exception handler on the stack, trigger an exception, jump into shellcode) without actually marking pages non-executable [@s-msft-sehop-kb956607]. SP2 introduced four configurations -- OptIn, OptOut, AlwaysOn, AlwaysOff -- selectable via boot.ini and later via BCD; the default on consumer XP was OptIn (system DLLs only) [@s-windows-internals-5e].

A defense that refuses to fetch and execute instructions from memory pages whose protection bits mark them as non-executable. Hardware-enforced DEP uses the NX page-table bit on x86 / x64 silicon (AMD's branding) or the XD bit (Intel's branding). Software-enforced DEP without the page bit relies on safe exception handlers (SafeSEH) to close the dominant stack-overflow exploitation pattern [@s-msft-sehop-kb956607]. Shipped in XP SP2 in August 2004 and refined repeatedly through Windows 10 [@s-windows-internals-5e]. A single bit in an x86 / x64 page table entry that, when set, instructs the CPU to fault on an instruction fetch from that page. AMD's name is NX (No-eXecute) and shipped first in 2003 on the Opteron; Intel's equivalent is XD (eXecute Disable). The bit is the hardware substrate for DEP and for the W^X (Write XOR Execute) memory policy that OpenBSD and PaX had pioneered earlier in the decade [@s-pax-aslr-live, @s-openbsd-3-4-wayback].

The academic prior art is older than DEP by six years. Crispin Cowan's StackGuard paper at the 7th USENIX Security Symposium in January 1998 [@s-cowan-stackguard] introduced the canary-based stack-overflow detector that the Visual C++ /GS flag adopted in 2002 with Visual Studio .NET [@s-msft-gs-buffer-security-check, @s-wp-vs] and that DEP complemented rather than replaced. On the Linux side, the PaX project had shipped W^X plus mmap-base randomization in 2003 [@s-pax-aslr-live, @s-pax-docs-index]. OpenBSD 3.4, released on November 1, 2003, was the first general-purpose operating system to ship integrated W^X plus library-load-order randomization default-on [@s-openbsd-3-4-wayback]. Vista's ASLR three years later was, by mainstream-OS standards, late.

The DEP-versus-JIT compatibility breakage is the canonical "good security default that breaks shipping software" story of the SP2 era. JavaScript engines, Java, .NET, and Flash all generated executable code into RW pages at runtime and ran headlong into DEP's first-generation policy. The modern fix is the explicit VirtualProtect transition (RW into RX and back) that every JIT now uses, but the engineering took years to converge across vendors. The next pass through the same problem -- W^X enforced by CPU mode in Apple silicon -- finally made the explicit-transition pattern a first-class API.

4.3 Attachment Execution Service and the Zone.Identifier ADS

This is the subsection that most retellings of XP SP2 get backwards. The Mark-of-the-Web -- the HTML comment of the form  that Internet Explorer reads on a saved web page to decide which security zone to apply -- did not ship with SP2. It shipped two years earlier in Internet Explorer 6 Service Pack 1 in 2002.

What SP2 added is the Attachment Execution Service: the system-wide enforcement substrate that, when a file arrives via Outlook, Outlook Express, Internet Explorer, Windows Messenger, or any caller of the IAttachmentExecute shell API [@s-msft-iattachmentexecute], writes a Zone.Identifier NTFS Alternate Data Stream tagging the file with its originating security zone.

The XP SP2 shell service that, on attachment download from a recognised zone-aware caller (Outlook, IE, Messenger, the `IAttachmentExecute` API [@s-msft-iattachmentexecute]), writes a `Zone.Identifier` NTFS Alternate Data Stream tagging the file with its originating zone (Internet, Restricted, Trusted, Local Intranet). AES is the system-wide enforcement substrate that materialised the existing Mark-of-the-Web concept into a persistent file-system record the Shell consults at execute time. Substrate, not ancestor. An NTFS Alternate Data Stream named `Zone.Identifier`, attached to a file by the Attachment Execution Service or its callers. The ADS body is a small INI file with a `[ZoneTransfer]` section whose `ZoneId` value (3 for Internet, 4 for Restricted, 2 for Trusted, 1 for Local Intranet, 0 for Local Machine) the Shell reads on execute attempts. The ADS persists with the file across copies on NTFS volumes; copying to FAT32 or onto a non-NTFS share strips it -- which is why USB sticks and consumer file-sharing services have historically been laundering paths for web-originated executables.

{ // Illustrative parser. The real call is to CreateFileW on a path of // the form "C:\\\\downloads\\\\foo.exe:Zone.Identifier", reading the // resulting stream as a tiny INI file. const adsContent = [ "[ZoneTransfer]", "ZoneId=3", "ReferrerUrl=example.com/", "HostUrl=example.com/downloads/foo.exe", ].join("\\n"); const zoneNames = { 0: "Local Machine", 1: "Local Intranet", 2: "Trusted", 3: "Internet", 4: "Restricted" }; const lines = adsContent.split("\\n"); const kv = Object.fromEntries( lines.filter(l => l.includes("=")).map(l => l.split("="))); const zone = parseInt(kv.ZoneId, 10); console.log(\File originated from zone ${zone} (${zoneNames[zone]})`); console.log(`Referrer: ${kv.ReferrerUrl}`); `}

The architectural property the substrate produces is the one downstream tools cannot live without. Office Protected View opens with restricted privileges precisely when the document's Zone.Identifier reports Internet origin. SmartScreen warns on first execute of any binary whose ADS says Internet. Microsoft Defender Application Control treats Zone.Identifier as a first-class file attribute in its policy language. None of those tools would work the way they do if AES had not made the zone tag a persistent file-system property in 2004.

4.4 Internet Explorer 6 SP2 hardening

The IE6 SP2 hardening pass is the largest browser security delta in any service-pack-era Windows update before or since. The pop-up blocker on by default plus the Information Bar gave the browser a way to defer execution of script-launched popups behind an explicit user click. MIME-handling lockdown closed the MIME-sniffing attacks the Outlook MHTML class had enabled (an attacker could serve a binary as Content-Type: text/plain and have IE sniff and execute it anyway).

The Local Machine Zone lockdown blocked script execution from the LMZ by default for IE-rendered documents, closing the cross-zone elevation path that several earlier IE vulnerabilities had taught attackers to chain through mhtml: and file:// URL tricks. The ActiveX opt-in framework required user confirmation before any controls were installed from the Internet. The compatibility cost was real and immediate: legitimate ActiveX line-of-business intranet apps, legacy webmail pop-ups, and corporate intranet portals all required exemption configuration before they would keep working as before.

4.5 Security Center

Security Center is easy to underestimate because its UI looked like a Control Panel applet. It was the first centralised surface that aggregated three previously invisible state signals -- firewall status, Automatic Updates status, antivirus status (presence, definitions currency, real-time protection enabled) -- into a single interface a non-technical user could read.

The balloon-tip notification UI surfaced negative states aggressively; the visible degradation was the entire point. The third-party AV vendors -- Symantec and McAfee in particular -- objected publicly to Microsoft's display of competing status, and the resulting friction previewed the 2009 European Union agreement that constrained Microsoft's default-bundled-AV options for the rest of the era.

Three of these five mitigations made it into Vista substantially unchanged. Two of them -- the firewall and the ADS-based zone tagging -- were re-architected because Vista's threat model went past the application-on-the-network and into the application-on-the-desktop. To see why, we have to leave XP behind and walk year by year through what happened next.

5. Year by Year, 2005 Through 2009

If XP SP2 was the proof of concept for on-by-default mitigations, the next four years were the proof of work. Microsoft was shipping kernel self-protection, anti-exploit defenses, and the first real attempt at a privilege model the consumer would actually use. The security research community was learning faster than the shipping cadence could absorb. Two industry coordination moments and one wormable RCE close the period.

gantt dateFormat YYYY-MM-DD axisFormat %b %Y section Memos and process Trustworthy Computing memo :a1, 2002-01-15, 7d Security stand-down :a2, 2002-02-01, 60d SDL mandated at Microsoft :a3, 2004-09-01, 120d Mojave Experiment :a4, 2008-07-01, 30d section Windows releases XP SP2 :b1, 2004-08-06, 90d XP x64 and Server 2003 x64 :b2, 2005-04-25, 30d Vista RTM :b3, 2006-11-08, 14d Vista consumer GA :b4, 2007-01-30, 14d Vista SP1 RTM :b5, 2008-02-04, 14d Vista SP1 GA :b6, 2008-03-18, 14d Windows 7 RTM :b7, 2009-07-22, 14d Windows 7 GA :b8, 2009-10-22, 14d section Attacks Blaster :c1, 2003-08-11, 30d Welchia :c2, 2003-08-18, 30d Sasser :c3, 2004-04-30, 30d MS08-067 out-of-band patch :c4, 2008-10-23, 7d Conficker.A first detected :c5, 2008-11-20, 30d Conficker.C DGA expansion :c6, 2009-03-04, 30d section Research Cowan StackGuard USENIX :d1, 1998-01-26, 7d PaX ASLR design doc :d2, 2003-03-15, 7d OpenBSD 3.4 W^X plus library randomization :d3, 2003-11-01, 7d Shacham et al CCS 2004 ASLR analysis :d4, 2004-10-25, 7d Hoglund and Butler Rootkits book :d5, 2005-06-01, 7d skape and Skywing Uninformed Vol 3 :d6, 2005-12-01, 7d Symantec McAfee public PatchGuard objection :d7, 2006-10-01, 30d Ferguson BitLocker whitepaper :d8, 2006-08-01, 30d Shacham ROP CCS 2007 :d9, 2007-10-29, 7d Halderman cold-boot USENIX 2008 :d10, 2008-07-28, 7d Conficker Working Group forms :d11, 2009-02-12, 14d CWG Lessons Learned final :d12, 2010-06-17, 7d

5.1 April 2005: XP Professional x64 Edition and Server 2003 x64

Windows XP Professional x64 Edition and Windows Server 2003 x64 Edition were the first Windows releases to ship Kernel Patch Protection -- the kernel self-defense mechanism widely known as PatchGuard. The common version of the story moves PatchGuard's debut to Vista by twenty months. It did not debut on Vista.

Microsoft Security Advisory 932596 (published August 14, 2007, updated April 23, 2008) is unambiguous: "An update is available for Kernel Patch Protection included with x64-based Windows operating systems" [@s-msft-adv-932596]. The x64-based qualifier is load-bearing. Vista x64 inherited PatchGuard v2 in November 2006; Vista SP1 x64 shipped v3 in February 2008. The x86 editions of Vista never got PatchGuard.

Microsoft's kernel-mode self-protection feature on x64 Windows. PatchGuard periodically verifies the integrity of a fixed list of kernel data structures (SSDT, IDT, GDT, MSRs, system images, the kernel's own code pages) and bug-checks the system on detected modification. Shipped first in April 2005 in Windows XP Professional x64 Edition and Windows Server 2003 x64 Edition. Vista x64 inherited it (v2 in Vista RTM, v3 in Vista SP1). Vista did NOT introduce PatchGuard [@s-msft-adv-932596].

The architectural target of PatchGuard is the 2003-era rootkit class catalogued in Hoglund and Butler's Rootkits: Subverting the Windows Kernel (Addison-Wesley, 2005) [@s-hoglund-butler-rootkits]: SSDT hooks, IDT hooks, inline patches of function prologues, modifications to the System Service Descriptor Table, manipulation of the Object Manager's namespace. The same April 2005 release also introduced advisory (warnings, not enforcement) kernel-mode driver signing. Mandatory kernel-mode driver signing arrived with Vista x64 a year and a half later [@s-msft-driver-signing].

5.2 October 2006: Symantec and McAfee object to PatchGuard in public

The first major public clash between kernel self-defense and the kernel-extension model that the antivirus industry had built businesses on came in October 2006, weeks before Vista RTM. Symantec and McAfee both took the position that PatchGuard would make their products materially less effective by closing off the kernel-mode hooking patterns their behavioural detection engines depended on [@s-wp-kpp].

Microsoft's response was to formalise the existing Cm, Ob, and Ps notification routines (registry, object-manager, and process callbacks) and the Filter Manager and Windows Filtering Platform callout architectures as supported extension surfaces. The pattern -- a kernel-integrity feature pressed up against existing AV business models, followed by a published callback API that gives the AV industry a supported path -- recurs with Driver Signature Enforcement in Vista x64, with Early Launch Antimalware in Windows 8, with HVCI in Windows 10 and 11, and with the Microsoft Vulnerable Driver Block list rollout from 2020 onward.

5.3 December 1, 2005: skape and Skywing's "Bypassing PatchGuard on Windows x64"

In December 2005, eight months after PatchGuard's debut, skape (Matt Miller) and Skywing (Ken Johnson) published "Bypassing PatchGuard on Windows x64" in Uninformed Vol. 3 [@s-skape-skywing-patchguard]. The paper is widely mis-cited: it is dated December 1, 2005 (the Uninformed volume publication is January 2006); it is co-authored, not single-authored; it has no subtitle. Upstream secondary references occasionally attribute the paper to Skywing alone with a July 2006 date and the subtitle "Bypassing Kernel Patch Protection on Windows x64." The corrected metadata is what the article uses.

The structural observation that any defense which runs at a given privilege level cannot fundamentally constrain an attacker who also runs at that privilege level. PatchGuard runs at ring 0; rootkits run at ring 0; therefore PatchGuard is bypassable in principle from a sufficiently privileged kernel-mode attacker. skape and Skywing's December 2005 *Uninformed* paper demonstrated three concrete bypass technique classes [@s-skape-skywing-patchguard]. The genuine architectural fix waits for hypervisor-protected mechanisms (HVCI in Windows 10 Anniversary Update, August 2016; VBS and Pluton in Windows 11) that run the integrity verifier from a more privileged execution mode than the attacker. Any defense that runs at the same privilege level as the attacker is fundamentally bypassable. -- paraphrased from the load-bearing conclusion of skape and Skywing, *Uninformed* Vol. 3, December 1, 2005 [@s-skape-skywing-patchguard]

5.4 November 8, 2006: Vista RTM

Windows Vista released to manufacturing on November 8, 2006. Volume-license availability via the Microsoft Volume Licensing portal began "sometime before Nov. 30, 2006" per the same-day Computerworld press-conference coverage [@s-lai-computerworld-vista-rtm]. Consumer general availability was January 30, 2007. Keep these as three distinct dates: the gap between RTM and consumer GA is where most enterprise IT departments tested compatibility, and where the volume-license customers who later complained loudest about Vista actually first encountered it.

5.5 January 30, 2007: Vista consumer GA and the reception

The pivot from technical release to cultural event happened in the first six months of 2007. Apple's "Get a Mac" television-spot series ran "Security" and "Cancel or Allow" through the summer, dramatizing UAC prompt fatigue for a mass audience [@s-wp-get-a-mac].

The Kelley v. Microsoft Corp. lawsuit (No. 2:07-cv-00475-MJP, W.D. Wash.) was filed on March 29, 2007 and certified as a class action in February 2008 [@s-cw-vista-capable-class], alleging that Microsoft had marketed machines as "Vista Capable" that could only run Home Basic without the Aero compositor or many of the security features the launch had highlighted. The Mojave Experiment in July 2008 -- Microsoft showing Vista to focus groups under a different name and getting positive reactions -- was the era's confession that the perceptual layer mattered as much as the architectural layer [@s-msft-mojave-experiment, @s-wp-mojave-experiment].

The Vista Capable case is Kelley v. Microsoft Corp., No. 2:07-cv-00475-MJP, W.D. Wash., filed March 29, 2007 and certified February 22, 2008 [@s-cw-vista-capable-class]. Coverage that condenses the timeline to "Vista launched and was sued" tends to misstate the filing month as April or May.

Was Vista the most-hated Windows release? Windows ME and Windows 8 have competing claims, and any honest treatment needs to acknowledge them. Call Vista one of the most poorly received Windows consumer releases of its era. The reception was uniquely consequential -- the SP1-era enterprise inertia, the consumer skipping that left a large XP-to-7 leap, and the marketing problem Windows 7's launch had to solve. The substantive argument does not depend on the superlative.

5.6 February 4, 2008: Vista SP1 RTM

Vista Service Pack 1 released to manufacturing on February 4, 2008, with broad availability starting March 18, 2008 [@s-msft-news-vista-sp1-rtm]. This is the "real Vista" enterprise IT deployed. PatchGuard v3 shipped with SP1. The file-copy engine got the performance fix that Vista's reviewers had spent a year complaining about. Windows Search was refactored to reduce IO contention with foreground work. A set of compatibility shims relaxed UAC on several common operations that had been hitting too many false-positive prompts.

Vista SP1 RTM is February 4, 2008 (build 6001.18000); broad GA is March 18, 2008 [@s-msft-news-vista-sp1-rtm]. Upstream summaries sometimes mis-state the RTM as November 2007 -- that date is actually the SP1 Release Candidate 1 milestone, not RTM.

5.7 October 23, 2008: MS08-067 out-of-band

The vulnerability behind MS08-067 is a stack buffer overflow in the path-handling code (the function commonly named NetprPathCanonicalize in the NetAPI library), reachable through the Server service's srvsvc RPC interface over SMB on TCP/445 (and TCP/139 in NetBT environments) without authentication. CVE-2008-4250 [@s-nvd-cve-2008-4250]. The patch is out-of-band because the MSRC analysts who reviewed the bug believed weaponisation was weeks away.

Vista's DEP and ASLR materially raised the cost of exploitation on Vista compared to XP -- the bulletin rates the issue Critical on Windows 2000, XP, and Server 2003 but Important on Vista and Server 2008 [@s-ms08-067]. The October 2008 installed base, however, was overwhelmingly Server 2003 and XP. The first in-the-wild MS08-067 exploitation in October 2008 was Gimmiv.A, a narrower non-self-propagating Trojan, per NVD [@s-nvd-cve-2008-4250]. Conficker was three weeks away.

5.8 Late November 2008: Conficker.A is first detected

Conficker.A was first detected in late November 2008, anchored to November 20, 2008 in SRI International's "An Analysis of Conficker C" addendum, whose introductory paragraph reads: "Conficker malware family, which first appeared on the Internet on 20 November 2008" [@s-sri-conficker-c-addendum]. The gap from MS08-067 to Conficker.A is approximately twenty-nine days. The October-2008 in-the-wild MS08-067 exploitation was Gimmiv.A; Conficker is a separate, later, much larger event.

The audit-mandated date correction: Conficker.A first detected in late November 2008, with November 20, 2008 as the canonical SRI anchor [@s-sri-conficker-c-addendum]. The October-2008 in-the-wild MS08-067 exploitation reported in NVD is Gimmiv.A, not Conficker [@s-nvd-cve-2008-4250].

5.9 December 2008 through April 2009: Conficker.B, C, E

The variant taxonomy matters because it is the evidence base for how quickly the worm's authors learned, and how the Conficker Working Group's coordinated defense responded. Conficker.B in late December 2008 added removable-drive autorun spreading, a dictionary attack against weak shares, and a fallback exploit path against the older MS06-040 vulnerability for the small fraction of targets that were still unpatched against it.

Conficker.A already had a 250-domain-per-day Domain Generation Algorithm; what Conficker.C added on March 4, 2009 at 6 p.m. PST (March 5 UTC) was a 50,000-domain-per-day rendezvous-pool expansion across 110 top-level domains and a peer-to-peer coordination channel that no longer required successful DNS rendezvous -- two functional additions of the same variant, not two sequential revisions. The SRI "An Analysis of Conficker C" addendum is explicit on this: variant C "incorporates a major restructuring of B's previous thread architecture and program logic, including major functional additions such as a new peer-to-peer (P2P) coordination channel, and a revision of the domain generation algorithm (DGA)" [@s-sri-conficker-c-addendum]. Conficker.E, in April 2009, added payload-delivery for scareware and the Waledac spam botnet; the in-era variant chain runs A to B to C to E, matching both the SRI primary and the CWG taxonomy.

Conficker.B's MS06-040 fallback exploit path was scoped to Windows 2000 targets only -- the older bulletin's RCE vector did not reach the post-2003 SMB stack the same way. The Conficker Working Group taxonomy is sometimes summarised in ways that imply the MS06-040 fallback was a broader secondary attack vector; it was not.

5.10 February 12, 2009: Conficker Working Group and the $250,000 bounty

On February 12, 2009 Microsoft posted a US$250,000 bounty for information leading to the arrest and conviction of Conficker's authors, and the Conficker Working Group formally constituted itself as a coordinated industry response -- Microsoft, ICANN, F-Secure, Symantec, Verisign, Georgia Tech, and roughly 120 other participating organisations [@s-cwg-lessons-learned-2019].

The CWG's "Lessons Learned" final report (June 17, 2010) is the canonical post-mortem primary that the rest of this article relies on for variant taxonomy, infection-count framing, and the deployment-velocity-ceiling argument [@s-cwg-lessons-learned-2019]. The 9-to-15-million infected machines figure is the report's own range; counts varied with measurement methodology and with which Conficker variants the counter included.SRI International's per-country infection table from the same period shows the geographic distribution: China (about 2.65M observed bots), Brazil (about 1.02M), Russia (about 836K), India (about 607K), Argentina (about 569K) topping the list [@s-sri-conficker-resources]. The distribution tracked installed-base size of unpatched XP and Server 2003 closely.

Vista shipped on November 8, 2006 and the world made up its mind about the reception by mid-2007. To understand why the architecture survived the reception, we have to look at what the architecture actually was -- feature by feature -- and what each feature defended against.

6. The Vista Security Catalogue

Open Windows Internals, 5th edition (Russinovich, Solomon, and Ionescu, Microsoft Press, 2009) [@s-windows-internals-5e] to the security chapter and the table of contents reads like a list of features Microsoft did not have eighteen months earlier. Eight features in particular form the Vista security architecture, not because they were the only changes, but because every other Vista security improvement either depends on one of these or polishes one of these.

6.1 The integrity-level stack: UAC, MIC, and UIPI

User Account Control is the consumer-visible part. Underneath sit two architectural primitives that do almost all the work: Mandatory Integrity Control and User Interface Privilege Isolation.

UAC's split-token model works like this. When an interactive user logs on whose group membership includes Administrators, the Local Security Authority issues two access tokens, not one. The filtered token has Administrators removed (more precisely, marked deny-only) and the high-privilege list stripped down to the standard-user set; the full token retains everything.

The user session starts running under the filtered token by default. When a program tries to perform an operation that requires the full token -- writing under %ProgramFiles%, modifying HKLM, loading a driver -- the Application Information service displays a Secure Desktop consent prompt. On consent, the full token is released for that process only; the rest of the session continues on the filtered token.

The Vista feature that runs interactive administrator accounts under a filtered standard-user token by default and prompts for explicit consent before releasing the full administrator token to a specific process. The Secure Desktop switch isolates the consent prompt from window-message injection by lower-integrity processes. Russinovich is explicit in the load-bearing primary: elevations were introduced as a convenience, and their existence "prevents OTS elevations from being a security boundary" [@s-russinovich-uac-technet]. The boundary classification arrives much later with Administrator Protection in the 2024 to 2026 Windows 11 era.

Mandatory Integrity Control adds the second axis the discretionary-access-control model never had. Every process token carries an integrity-level SID drawn from a small set -- Untrusted S-1-16-0, Low S-1-16-4096, Medium S-1-16-8192, High S-1-16-12288, System S-1-16-16384 -- and every securable object carries an integrity-level access control entry indicating the minimum integrity required to write (and optionally read or execute). The kernel's access check evaluates integrity before the discretionary ACL [@s-msft-mic-win32]. A Low-integrity process holding a handle to a Medium-integrity registry key cannot write to it regardless of what the DACL says.

Vista's mandatory-access-control primitive added to the Windows access-check pipeline. MIC attaches an integrity-level SID to every process token and an integrity-level ACE to every securable object, then evaluates the integrity comparison before the discretionary access control list. MIC is the architectural substrate every later Windows containment story (AppContainer, Modern Apps, browser sandbox, Office Protected View, WDAG, VBS) inherits [@s-msft-mic-win32].

User Interface Privilege Isolation closes the third class of cross-integrity attack: window-message injection. Before UIPI, any process in the same desktop could send window messages (SendMessage, PostMessage, WM_TIMER, SetWindowsHookEx) to any other process's windows, including elevated ones. Chris Paget's 2002 "shatter attack" paper had walked through the attack surface methodically. UIPI prevents a lower-integrity process from sending most messages to higher-integrity windows; the Secure Desktop completes the closure for the consent UI itself by drawing it on a separate desktop the user-session processes cannot reach.

Vista's mechanism preventing lower-integrity processes from sending window messages (SendMessage, PostMessage, SetWindowsHookEx, WM_TIMER, etc.) to higher-integrity windows on the same desktop. Closes the shatter-attack class documented by Chris Paget in 2002. Together with the Secure Desktop, UIPI is the closure that makes the UAC consent prompt actually resistant to programmatic dismissal from a malware process running in the same user session. flowchart TD A[Interactive logon as Administrator] --> B[LSA splits token] B --> C[Filtered standard-user token] B --> D[Full administrator token held aside] C --> E[User session starts under filtered token] E --> F[Program requests admin operation] F --> G[Application Information service intercepts] G --> H[Secure Desktop switch] H --> I[UAC consent prompt] I --> J{"Consent?"} J -- Yes --> K[Full token released to this process only] J -- No --> L[Operation denied] K --> M[Process runs at High integrity] L --> E

Russinovich's "Inside Windows Vista User Account Control" in TechNet Magazine June 2007 is the canonical primary on design intent [@s-russinovich-uac-technet]; a separate Mark's-Blog post dated February 12, 2007 anchored the multi-part TechNet blog series on PsExec and the restricted-token discussion [@s-russinovich-psexec-blog]. The two are distinct primaries and the article does not conflate them.

The TechNet Magazine UAC article is a single standalone piece at asset id cc138019 [@s-russinovich-uac-technet]. There is a separately numbered Magazine asset at cc162493 that is sometimes mis-cited as "Part 2" of the UAC series; live fetches of that URL return an unrelated Raymond Chen column. The article cites cc138019 only and treats the February 12, 2007 blog post as the start of the distinct multi-part blog series.

6.2 Anti-exploit mitigations: ASLR and Vista-era DEP refinements

Vista is the first Windows release to ship Address Space Layout Randomization. Vista's ASLR randomizes the load address of system DLLs and of executables linked with /DYNAMICBASE; it is opt-in for user code. Mandatory ASLR for all images is a later-Windows feature, with Force ASLR appearing in EMET and in Windows 8, and full enforcement landing in Windows 10. The randomization is per-boot for system images and per-process-load for user images. Entropy on x86 is roughly 8 bits (256 possible base addresses), and considerably more on x64.

A defense that randomizes the base addresses of executable images, libraries, the stack, and the heap so attackers cannot predict the location of useful code or data. Vista (January 2007) was the first Windows release to ship ASLR; Vista's implementation randomized system DLLs and `/DYNAMICBASE`-linked user images, with per-boot randomization for system images and per-process-load randomization for user images. The Linux-side prior art is PaX [@s-pax-aslr-live, @s-pax-docs-index], and OpenBSD 3.4 (November 1, 2003) was the first general-purpose OS to ship integrated W^X plus library-load-order randomization default-on [@s-openbsd-3-4-wayback]. The brute-force entropy bound is the Shacham et al. CCS 2004 result [@s-shacham-asrandom-ccs2004].

The Shacham et al. CCS 2004 paper showed that 8 bits of ASLR entropy yields an expected $2^{7} = 128$ attempts to brute-force the base on a target process that respawns after crash [@s-shacham-asrandom-ccs2004]. The result is why x64 ASLR (with substantially more bits of entropy) is qualitatively different and why Force ASLR in Windows 8 was a categorical improvement over Vista's opt-in model.

The DEP refinements in Vista are mostly about loader cooperation. Vista's PE loader respects the IMAGE_DLLCHARACTERISTICS_NX_COMPAT flag, so binaries that opt in to DEP get the policy applied without per-process configuration. SEHOP (Structured Exception Handler Overwrite Protection) precursor work also lands.

Three years later, Hovav Shacham's CCS 2007 paper on Return-Oriented Programming will show that DEP alone is necessary but not sufficient: an attacker who cannot inject and execute new code can still chain together existing executable-code "gadgets" from already-loaded modules to construct functional payloads [@s-shacham-rop-geometry-ccs2007]. That insight is what drives the next generation of Windows mitigations -- CFG, CET, /GUARD:EH -- but those are out of era.

6.3 Kernel self-protection on x64: inherited PatchGuard, new mandatory KMCS

Vista did not introduce PatchGuard; it inherited the April 2005 x64 mechanism. What Vista x64 did introduce is mandatory kernel-mode driver signing. Unsigned drivers do not load on Vista x64 under the Kernel-Mode Code Signing policy.

The documented escape hatch for development is bcdedit /set testsigning on, which causes the boot loader to honour test-signing-rooted certificates and which displays a permanent desktop watermark to make the state of the machine visible. Together with the inherited PatchGuard, the combination foreclosed the dominant 2003-era rootkit installation path: drop a .sys, register it via SCM, kernel loads it with no signature check, kernel hooks become trivial [@s-msft-driver-signing].

The Vista x64 policy that refuses to load kernel-mode drivers unless they carry a digital signature rooted in a Microsoft-trusted certificate chain (Microsoft WHQL, a cross-certified third-party CA, or a Microsoft Hardware certificate). `bcdedit /set testsigning on` is the documented development-time escape hatch. Vista x86 never received mandatory KMCS, which is one of the structural reasons x64 became the dominant Windows architecture during the next decade [@s-msft-driver-signing].

x86 Vista did not get mandatory KMCS, because the installed-base compatibility cost was deemed too high; the x86 / x64 asymmetry is one reason x64 became the dominant Windows architecture by 2010. The post-2010 afterlife is "Bring Your Own Vulnerable Driver" attacks: KMCS forecloses unsigned drivers but does not address the case of a legitimately signed driver containing a vulnerability the attacker exploits to gain kernel-mode code execution. BYOVD became the dominant rootkit-loading path from approximately 2010 onward, and the Microsoft Vulnerable Driver Block list (2020 onward) is the architectural response.

The post-KMCS attack pattern in which an attacker installs a legitimately signed kernel-mode driver that contains an exploitable vulnerability, then exploits the driver to gain ring-0 code execution. KMCS forecloses the unsigned-driver path but does not prevent loading of signed drivers, so attackers brought their own. Architectural closure waits for the Microsoft Vulnerable Driver Block list and Hypervisor-Protected Code Integrity, both of which post-date this article's era.

6.4 Service Hardening

Service Hardening is the Vista feature that most reduced the blast radius of a service-level exploit even when exploitation succeeded. Three changes did the work. Per-service SIDs of the form NT SERVICE\<servicename> give every service a distinct security principal -- the previous model was that every service running as LocalSystem shared the same identity.

NT AUTHORITY\WRITE RESTRICTED tokens constrain a service to writing only to resources whose DACL explicitly grants its per-service SID, even when the service token nominally has higher privileges. Minimum-privilege configuration replaces the historical LocalSystem superset; the SCM lets services declare exactly which privileges they require. And Windows Firewall rules can be authored per-service-SID, so a compromised service can be blocked from reaching the network even if the rest of the box can. The print primary is Windows Internals, 5th edition (Russinovich, Solomon, Ionescu, Microsoft Press, 2009) [@s-windows-internals-5e].

A security identifier of the form `NT SERVICE\` distinct to each Windows service, automatically derived from the service short name. Per-service SIDs are the primitive that lets a host firewall rule, a `WRITE RESTRICTED` token policy, or a registry-key DACL constrain a single service without affecting any other service in the same `svchost.exe` process or any other principal sharing the same logon SID.

6.5 Windows Resource Protection

Windows Resource Protection replaces Windows File Protection (the Windows 2000-era SFC mechanism), whose model was "the OS keeps a hidden catalog of canonical copies and silently replaces tampered system files." WRP is ACL-based instead. Protected files and registry keys are owned by the TrustedInstaller SID; the DACL grants modify rights only to TrustedInstaller. Administrators retain read access and can take ownership, but they cannot modify protected resources directly without that ownership transfer. The protection extends to registry keys, which WFP/SFC did not cover [@s-windows-internals-5e].

Vista's replacement for the Windows 2000 to XP-era Windows File Protection / SFC catalog-and-replace mechanism. WRP is ACL-based: protected files and registry keys are owned by `TrustedInstaller` and the DACL restricts modify access to `TrustedInstaller` itself; administrators can take ownership but cannot modify protected resources directly without that step. The protection also covers registry keys, which the older WFP did not. Note: the acronym "WFP" in this paragraph (Windows File Protection) is unrelated to the "WFP" (Windows Filtering Platform) in section 6.6.

6.6 Windows Filtering Platform

Vista and Server 2008 replace the prior NDIS-IM, TDI, and firewall-hook stack-extension architecture with the Windows Filtering Platform: a kernel-mode framework of filtering layers (transport, network, application-layer enforcement), shims, and callout drivers giving third-party firewalls, IDS/IPS, and content filters a supported extension surface. The Base Filtering Engine in user mode centralises policy. Windows Firewall in Vista and every release thereafter sits on top of WFP.

Forshaw's Project Zero post documents the three-tier architecture directly: "MPSSVC converts its ruleset to the lower-level WFP firewall filters and sends them over RPC to the Base Filtering Engine (BFE) service. These filters are then uploaded to the TCP/IP driver (TCPIP.SYS) in the kernel which is where the firewall processing is handled" [@s-forshaw-projectzero-wfp].

Vista's kernel-mode replacement for the NDIS-IM, TDI, and firewall-hook stack-extension architecture that prior third-party firewalls had hooked into. WFP exposes filtering layers (transport, network, application-layer enforcement) plus a callout-driver API, with the user-mode Base Filtering Engine centralising policy and the Microsoft Protection Service service translating Windows Firewall rules into WFP filters. Note: the acronym "WFP" in this paragraph (Windows Filtering Platform) is unrelated to the "WFP" (Windows File Protection) in section 6.5; they are two unrelated three-letter abbreviations that happen to share initials [@s-forshaw-projectzero-wfp]. flowchart LR A[Windows Firewall policy] --> B[MPSSVC user-mode service] B --> C[Base Filtering Engine BFE user mode] C --> D[TCPIP.SYS kernel-mode filter] E[Third-party firewall or IDS] --> C F[Callout drivers] --> D D --> G[Network packets in or out]

6.7 BitLocker Drive Encryption

BitLocker shipped in Windows Vista Enterprise and Ultimate editions on January 30, 2007, and in Windows Server 2008. Protector modes were TPM-only (seal-to-PCR), TPM+PIN, TPM+startup-key, and recovery-key. The cipher was AES-CBC with the Elephant Diffuser, an additional diffusion layer Niels Ferguson designed specifically for the disk-encryption setting and documented in his August 2006 Microsoft whitepaper "AES-CBC + Elephant Diffuser: A Disk Encryption Algorithm for Windows Vista" [@s-ferguson-bitlocker]. The SKU limitation materially constrained deployment reach -- most Vista consumers ran Home Basic or Home Premium, neither of which included BitLocker at all.

Microsoft's full-volume encryption feature, first shipped in Windows Vista Enterprise and Ultimate (January 30, 2007) and in Windows Server 2008. Original Vista cipher: AES in CBC mode with Niels Ferguson's Elephant Diffuser overlay [@s-ferguson-bitlocker]. Protector modes: TPM-only (seal-to-PCR), TPM+PIN, TPM+startup-key, and recovery-key. The Vista release was edition-gated, which limited deployment reach materially across the consumer Vista base.

The era's load-bearing known weakness for TPM-only mode is the cold-boot attack documented in Halderman et al., "Lest We Remember: Cold Boot Attacks on Encryption Keys," USENIX Security 2008 [@s-halderman-coldboot-jhalderm]. DRAM remanence after power-off plus low-temperature imaging let an attacker reconstruct AES keys from a system whose disk was seal-to-PCR-decrypted at boot. The architectural answer -- TPM+PIN as the configuration for any threat model that includes physical access -- is the same in 2026 as it was in 2008.

6.8 Auxiliary hardening that landed quietly

Several Vista security features did not make front-page reviews but matter for the modern stack. Session-0 isolation moved services out of the interactive user session, closing the cross-session shatter attack on services. Protected Processes for DRM media paths became the precursor of PPL (Protected Process Light), which is the substrate for LSA Protection and Credential Guard.

Windows Defender shipped as built-in antimalware (originally GIANT AntiSpyware, which Microsoft acquired in December 2004) [@s-msft-giant-press-2004]. Network Access Protection (NAP) provided the framework for posture-checking machines before allowing network access -- later superseded by conditional access and never broadly deployed. Cryptography Next Generation (CNG) replaced CryptoAPI and is the substrate every modern Windows crypto operation runs on top of. The Volume Shadow Copy refactor enabled Previous Versions in the file Properties dialog.

The Vista feature table

Vista feature	Attack class defended	Compatibility cost	Status in 2026
UAC + MIC + UIPI	Cross-integrity write, cross-integrity UI injection	Prompt fatigue; admin scripts requiring elevation	ACTIVE (MIC is the substrate of every modern Windows sandbox)
ASLR + DEP refinements	Predictable-address shellcode, stack/heap execution	JIT compilers; non-DYNAMICBASE third-party DLLs	ACTIVE (Force ASLR mandatory in Windows 10)
Inherited PatchGuard + mandatory x64 KMCS	Unsigned-driver rootkits, kernel inline patching	x86/x64 split; test-signing escape hatch	ACTIVE (BYOVD response is post-era; HVCI in Win 10 Anniversary)
Service Hardening	Service-exploit blast radius	LocalSystem-assuming legacy services	ACTIVE
Windows Resource Protection	Direct overwrite of OS files and registry	Administrators cannot directly modify system files	ACTIVE
Windows Filtering Platform	NDIS hooking, unsupported third-party network filters	Third-party firewalls and AV had to port to WFP	ACTIVE (every Windows network filter sits on WFP)
BitLocker Drive Encryption	Data-at-rest exposure on lost / stolen devices	SKU limited to Enterprise + Ultimate; TPM-only is cold-boot-vulnerable	ACTIVE (cipher modernised to AES-XTS in Windows 10)
Session-0 isolation + Protected Processes + Defender + NAP + CNG	Cross-session shatter on services, weak crypto primitives, etc.	Service authors had to handle no-interactive-desktop case	ACTIVE (CNG, Defender); NAP SUPERSEDED-BY conditional access

Eight features. Three audit-mandated corrections. One architectural shift the consumer noticed -- a prompt. The next chapter argues that the prompt the consumer hated is not the breakthrough; the integrity-level stack underneath it is.

7. UAC Is the Surface; MIC Is the Substrate

Every Vista user remembers the prompt. Almost no Vista user can describe what the prompt was actually a prompt for. The prompt is the consumer-visible surface of the integrity-level stack. The integrity-level stack is the architectural achievement -- the first OS-level Windows mechanism to recognise that the discretionary-access-control model of Cutler-era NT could not express the policy that mattered.

Recall the integrity-level SIDs from section 6.1, organised as a small table:

Integrity level	SID	Operational use
Untrusted	`S-1-16-0`	Anonymous, deeply isolated processes (rare in default Windows)
Low	`S-1-16-4096`	Sandboxed processes (IE Protected Mode tab, AppContainer in Windows 8+)
Medium	`S-1-16-8192`	Default for normal user processes
High	`S-1-16-12288`	Elevated processes after UAC consent
System	`S-1-16-16384`	Kernel-mode and the most privileged service hosts

The argument is this. Discretionary access control could not distinguish "Administrator the user" from "Administrator's freshly downloaded script" because both ran with the same access token, and a DACL only encodes which principals can perform which operations. MIC can distinguish them.

The downloaded script runs at Low integrity (web-zone provenance, set by AES and inherited by the spawned process). The user shell runs at Medium or High. The integrity-level check evaluates before the DAC and blocks the cross-integrity write regardless of what the DAC would have permitted. UIPI then closes the second class of cross-integrity attack -- window-message injection -- so the same Low-integrity process cannot use SendMessage to puppet a Medium-integrity window into doing what its DAC would not allow it to do directly.

{` // Illustrative parser. The real PowerShell command is: // whoami /groups /priv // which dumps the SIDs and privileges in the current token. The // "Mandatory Label\\Medium Mandatory Level" line carries the integrity SID.

const sampleWhoamiOutput = ` Mandatory Label\\High Mandatory Level Label S-1-16-12288 BUILTIN\\Administrators Alias S-1-5-32-544 SeLoadDriverPrivilege Load and unload device drivers Enabled SeShutdownPrivilege Shut down the system Enabled `; const intLineRe = /Mandatory Label\\\\(Low|Medium|High|System) Mandatory Level\\s+\\S+\\s+(S-1-16-\\d+)/; const m = sampleWhoamiOutput.match(intLineRe); const elevatedPrivs = ["SeLoadDriverPrivilege","SeTcbPrivilege","SeBackupPrivilege"]; const has = p => sampleWhoamiOutput.includes(p + " ") && sampleWhoamiOutput.includes("Enabled"); if (m) console.log(`Integrity level: ${m[1]} (${m[2]})`); console.log("Likely elevated:", elevatedPrivs.some(has) ? "yes" : "no"); `}

Here is what the Aha lands on. Without MIC, every later Windows containment story -- AppContainer (Windows 8 Modern Apps), the Chromium and Edge browser sandboxes, IE Protected Mode, Office Protected View, Adobe Reader's sandbox, Windows Defender Application Guard, Virtualization-Based Security and Credential Guard -- would have had to invent the per-process trust-level primitive from scratch. Every one of them inherits MIC. The prompt is throwaway; the substrate is permanent. The full integrity-level-stack history through Administrator Protection is traced in the Adminless companion post.

Key idea: UAC is the prompt the user saw. MIC is the substrate every later Windows containment story inherits. The Vista security story is not the UI consent flow most reviewers focused on -- it is the integrity-level SID on every process token and the integrity-level ACE on every securable object, evaluated before the DAC, in the access-check pipeline of every Windows release since.

The prompt the consumer hated is not the breakthrough; the integrity-level stack underneath it is.

If Vista's architecture was right, why was Vista's reception wrong? The answer is not the prompt. The answer is what the prompt interrupted -- the everyday workflow that, on XP, had been a long-uninterrupted sequence of operations the user did not realise required administrative authority. The next chapter is the polish.

8. Windows 7 as the Vista Polish

Windows 7 reached general availability on October 22, 2009. Reviews were positive in a way Vista's never were. The security architecture underneath had barely changed.

The Vista security architecture is preserved almost entirely in Windows 7. UAC, MIC, and UIPI carry forward. BitLocker carries forward, gaining BitLocker To Go for removable drives. Both WFPs (the Filtering Platform and Resource Protection) carry forward. ASLR and DEP carry forward. Service Hardening carries forward, with additional per-service-SID coverage for previously-overlooked service hosts. Mandatory x64 KMCS carries forward. The Security Center is reborn as Action Center with an aggregated maintenance surface alongside the security surface.

Windows 7 did change the integration. UAC gained a four-level slider in Control Panel -- Always Notify, Notify when programs try to make changes (the default), Notify but don't dim the desktop, and Never Notify -- and an "auto-elevate" whitelist for signed Microsoft binaries that the system trusted to elevate themselves without a consent prompt. The slider made the prompt fatigue UI-tunable for the first time. The auto-elevate whitelist, however, is the load-bearing UAC-bypass surface for the next decade.

The auto-elevate whitelist is the surface Leo Davidson's December 2009 essay (sysprep.exe loading CRYPTBASE.dll from %SystemRoot%\System32 after a bind directory redirection) attacked first, and the UACMe catalogue on GitHub maintained an ongoing inventory of roughly 70 distinct UAC-bypass techniques over the following decade. The exact count grows over time -- the GitHub repository is the authoritative reference -- and the order-of-magnitude figure should be read as engineering-folklore shorthand rather than as instrumented telemetry. See the Adminless companion post for the full bypass-technique history and for the 2024 to 2026 Administrator Protection redesign.

AppLocker arrived in Windows 7, replacing the Software Restriction Policies of Windows XP and Server 2003 with a richer rule-collection model: executable rules, MSI rules, script rules, packaged-app rules, and DLL rules, each authorable by path, file hash, or publisher [@s-msft-applocker-overview]. DirectAccess shipped as a pre-VPN seamless remote-access protocol -- ahead of its time and not widely deployed. The reason it was ahead of its time and the reason it failed to deploy widely were the same: DirectAccess required native IPv6 connectivity (with Teredo or 6to4 tunneling as the fallback for IPv4-only networks) and per-machine certificate enrollment for every endpoint and gateway, and in the 2009-to-2014 window most enterprises ran neither IPv6 nor a mature PKI, so the prerequisite stack alone disqualified the protocol from broad rollout.

Microsoft's application-control feature, first shipped in Windows 7 (and Server 2008 R2). AppLocker supersedes Software Restriction Policies with a rule-collection model spanning executables, MSIs, scripts, packaged apps, and DLLs, with each rule authorable by path, file hash, or publisher (Authenticode-signed publisher and product) [@s-msft-applocker-overview].

Vista feature	Windows 7 change	What the change cost or enabled
UAC	Four-level slider; auto-elevate whitelist for signed MS binaries	Less prompt fatigue; new bypass surface via whitelist abuse
MIC + UIPI	Unchanged	--
ASLR + DEP	Loader and policy refinements	Slightly more user-image coverage; not yet mandatory
PatchGuard + KMCS	Unchanged on x64	--
Service Hardening	Coverage extended to additional service hosts	Smaller residual blast radius
Windows Resource Protection	Unchanged	--
Windows Filtering Platform	Refinements for VPN providers	Cleaner third-party integration
BitLocker	BitLocker To Go for removable drives	Encrypted USB sticks become practical
Security Center	Reborn as Action Center	Aggregated maintenance + security surface
(new) AppLocker	Replaces Software Restriction Policies	Richer application control for enterprises

The argument is the obvious one. Windows 7's reception was broadly positive and Vista's reception was broadly negative running on substantially the same security architecture. This is the article's evidence that "user-hostile integration of a correct architecture" is a distinct failure mode from "wrong architecture," and that the integration tax is payable -- if the work is done.

Note: The Vista-era integrity-level architecture is still load-bearing on Windows 11. Every modern sandbox -- browser tab process, AppContainer for a UWP app, the Office Protected View host, the Windows Defender Application Guard container -- builds on the MIC primitive Vista shipped in January 2007. If you maintain a Windows desktop fleet, treat UAC, MIC, and per-service SIDs as the foundational defenses they are, not as legacy artifacts. Companion posts: Adminless on the integrity-level-stack arc through Administrator Protection, and Process Mitigation Policies on the post-era process-mitigations layer.

If Windows 7 proved the architecture, the era's two structural limits proved how much was left to do. The next chapter is humility.

9. Three Operating Systems, Three Answers

Microsoft was not the only operating-system vendor trying to answer the privilege-model question in this window. The same years that produced UAC produced Mac OS X 10.5 Leopard's sandbox and mainlined SELinux on Linux. Each answered the question "which operations get the elevation primitive interposed on them?" with a different default.

macOS 10.5 Leopard, October 2007

Apple shipped Leopard's "seatbelt" sandbox in October 2007, built on Robert Watson's TrustedBSD MAC framework -- the same FreeBSD-derived Mandatory Access Control plumbing that becomes App Sandbox in OS X 10.7 (Lion, 2011) and the sandbox primitive every signed Mac App Store application now runs inside. The sandbox profile language is a Scheme dialect (SBPL); a representative four-line profile reads:

(version 1)
(deny default)
(allow file-read* (subpath "/usr/lib"))
(allow network-outbound (remote tcp "*:443"))

Apple's authopen and Authorization Services APIs are closer to per-operation elevation than Vista's per-process-token model. A typical Authorization Services flow elevates a single file-modification operation -- the canonical example is editing /private/etc/hosts:

authopen -w /private/etc/hosts

The macOS model is "the user is prompted at the moment of the protected operation, the elevation is scoped to that operation, and the rest of the process continues at the user's normal privileges." Vista's model is "the user is prompted at the moment a process needs the high token, the full token is released to the entire process, and the rest of the user session continues under the filtered token."

Linux: SELinux, AppArmor, and sudo

SELinux (originally developed by the U.S. National Security Agency, released to the open-source community in December 2000, mainlined in Linux 2.6.0 in December 2003, and championed downstream by Red Hat in RHEL 4 from February 2005 onwards) is the most thoroughly developed example of Type Enforcement on a mainstream OS. The policy language uses Access Vector rules with security labels:

allow httpd_t httpd_content_t : file { read getattr open };

The semantics are explicit: a process in domain httpd_t may perform read, getattr, and open on a file with label httpd_content_t. The labels travel with the file (extended attributes on disk) and the rules live in a single compiled policy. The model is label-based MAC.

AppArmor (Immunix, then Novell, mainlined in Linux 2.6.36 on October 20, 2010 [@s-linux-2-6-36-kernelnewbies]) takes the opposite philosophical position. A profile is a list of path-based rules:

/usr/sbin/dnsmasq {
  /etc/dnsmasq.conf r,
  /var/lib/misc/dnsmasq.leases rw,
  network inet dgram,
}

The model is path-based MAC: rules apply to filesystem paths rather than to inode labels. sudo persists across both as the practical per-operation elevation primitive, and most production Linux deployments use a mix.

The SELinux-vs-AppArmor distinction is a real architectural disagreement, not a stylistic preference. Label-based MAC ties policy to the data (extended attributes follow the file) but requires that every filesystem operation preserve the labels and that the labels start correct. Path-based MAC ties policy to the file path (a path is a profile lookup key) but means the same data accessed through two different paths can get two different policy verdicts. Both forms ship in mainstream Linux distributions in 2026; the choice is usually a function of which distribution's tooling you started with.

AppArmor's mainline Linux merge is Linux 2.6.36, October 20, 2010 [@s-linux-2-6-36-kernelnewbies]. Upstream secondary references occasionally date the mainline merge to 2009, which is wrong -- 2009 was the announcement-of-intent year; the actual git merge into Linus's tree is October 20, 2010.

Three OSes, three privilege models

OS / year	Primitive	Granularity	Policy authoring	Origin lineage
Vista UAC + MIC + UIPI (Jan 2007)	Per-process token, integrity-level SID	Per-process	Manifest + UAC consent + ACL/MIC ACE	Cutler-era NT access tokens + new MIC layer
Leopard sandbox + Authorization Services (Oct 2007)	Per-operation profile + per-operation auth	Per-operation	SBPL Scheme profile + `authopen` call	TrustedBSD MAC framework
Linux SELinux / AppArmor + sudo (2003 / 2010 / forever)	MAC domain rules + path/label policies	Per-operation via MAC + per-command via sudo	AV rules / profiles / sudoers	NSA / Immunix / BSD-flavour `sudo`

The point is not which model is "better." Vista's UAC is structurally closer to sudo than its critics admitted -- the difference is that sudo is invoked explicitly by the user from a shell, while UAC interposes on operations the user expected to just work. The contrast is about which operations the platform forces through the elevation primitive, and operating systems that pick different answers end up with different reception narratives even when the underlying mechanisms are similar.

If the privilege model is choosable -- if reasonable operating systems pick different answers -- what are the structural limits NONE of the three could escape? That is the next chapter.

10. Theoretical Limits and Era-Specific Lessons

Four structural limits the era revealed. Three of the four were proved in the literature; one was proved by Conficker. None of the four were closed by 2009. Two are closed today; two are not.

Limit 1: The same-privilege paradox

PatchGuard runs at ring 0. Rootkits run at ring 0. PatchGuard is therefore fundamentally bypassable from a sufficiently privileged attacker -- and skape and Skywing's December 1, 2005 Uninformed paper demonstrated three concrete bypass technique classes against the v1 implementation [@s-skape-skywing-patchguard]. PatchGuard v2 (Vista RTM) and v3 (Vista SP1) patched the specific v1 bypasses but could not address the structural issue. The genuine architectural fix waits for Hypervisor-Protected Code Integrity in Windows 10 Anniversary Update (August 2016) and for the VBS, Pluton, and Secured-core PC architectures of Windows 11. All out of era. Part 4 of this series traces them.

Limit 2: The deployment-velocity ceiling (the Conficker bound)

Aggregate installed-base security is bounded by patch-to-field-deployment latency on the slowest cohort, not by patch-release latency. Conficker's 9-to-15-million infections in early 2009 exploited a vulnerability that had been patched for one to four months across the variants [@s-cwg-lessons-learned-2019].

This is the era-closing operational lesson. It motivates Automatic Updates becoming opt-out-by-default (XP SP2, 2004), the mature Patch Tuesday cadence, and -- much later -- the Windows-as-a-Service cumulative-update model of Windows 10 that removes the user's ability to decline updates indefinitely. All-cohort closure remains structurally unattainable as of 2026; this is the era's defining residual.

The structural upper bound on aggregate installed-base security set by patch-to-field-deployment latency on the slowest cohort of machines. A vulnerability becomes safe at population scale only when the patch has propagated to every reachable system, and the slowest cohort's propagation rate dominates the aggregate. Conficker proved that on-by-default architectural mitigations on Vista did not raise the ceiling for the XP and Server 2003 installed base; only patch propagation could. The post-era architectural response is the Windows 10 cumulative-update model.

Limit 3: The compatibility tax on defaults

Every Vista security default that broke an application became a UAC bypass surface (the auto-elevate whitelist), a driver-signing escape hatch (test-signing), or a compatibility shim (DEP OptIn). Defaults that cannot break shipping software cannot be tightened. This is the era's productive failure mode -- it explains why post-Vista security features ship with deprecation runways: mandatory ASLR took until Windows 10 to fully land, mandatory KMCS on x86 never landed at all, and Driver Signature Enforcement on x64 had to coexist with the test-signing escape hatch for the foreseeable future.

Limit 4: The user-hostility tax on correct architecture

UAC was architecturally correct and operationally hated. The Mojave Experiment (July 2008) is the era's confession that the perceptual layer matters as much as the architectural layer. Windows 7's smoothing is the article's evidence that the tax can be paid, if the work is done -- but it has to be paid every time, because the perceptual layer is not learned-once. Windows 8's Modern UI, Windows 11's UAC behaviour adjustments, and the 2024-to-2026 Administrator Protection redesign are all replays of the same question on different sets of users.

Key idea: The era's binding constraints were not the UI. They were architectural -- you cannot defend ring 0 from ring 0, and skape and Skywing proved this in December 2005 -- and operational -- you cannot patch the slowest cohort faster than the worm cadence, and Conficker proved this in late November 2008. The prompt was the symptom. The constraints were the disease. Both were unsolved when Windows 7 shipped.

The Conficker Working Group's June 2010 post-mortem named the binding constraint directly: it is not whether a patch exists, but whether deployment reaches the slowest cohort before the worm does [@s-cwg-lessons-learned-2019].

Era limit	Era-end state (Oct 2009)	2026 state	Forward link
Same-privilege paradox	OPEN	CLOSED for kernel integrity via HVCI / VBS / Pluton	Part 4
Deployment-velocity ceiling	OPEN	NARROWED via Windows-as-a-Service cumulative updates	Part 3
Compatibility tax on defaults	OPEN (per-feature deprecation runways)	OPEN; managed via mitigation slow-ramp deployment	Part 3, Part 4
User-hostility tax on correct architecture	OPEN (Windows 7 smoothed Vista)	RECURRING (re-paid each major release)	Part 6

If the era closed with two structural limits unsolved, what stayed open for the next decade to answer?

11. Open Problems at the End of the Era

Stand at an engineer's desk on Friday, October 23, 2009 -- the day after Windows 7 GA. The previous twelve months had shipped a polished consumer OS, contained Conficker (mostly), and formed an industry-coordination body for the next worm. What does the agenda look like on Monday?

Q1: How do you make the patching cadence faster than the worm cadence?

The era-end answer was a mature Patch Tuesday cadence plus the Microsoft Active Protections Program (MAPP, which gave AV vendors early access to patch details) plus Automatic Updates default-on, but the slowest-cohort lag remained. The post-era answer is the cumulative-update and Windows-as-a-Service model of Windows 10 (July 2015) plus enterprise WSUS scale-out plus the out-of-band cadence the era proved was sometimes necessary. The in-era out-of-band releases were three: the bulletin commonly cited from January 2006 patching the Windows Metafile vulnerability (MS06-001) [@s-msft-ms06-001], the April 2007 out-of-band patching the animated-cursor (.ANI) GDI parsing vulnerability (MS07-017) [@s-msft-ms07-017], and MS08-067 [@s-ms08-067].

The April 2004 LSASS bulletin (the patch that preceded Sasser) was a regular Patch Tuesday release on April 13, 2004 [@s-msft-ms04-011], not an out-of-band release. The in-era out-of-band Microsoft Security Bulletins for wormable-class or actively-exploited-class RCEs are three: the January 2006 Windows Metafile bulletin (MS06-001) [@s-msft-ms06-001], the April 3, 2007 animated-cursor (.ANI) GDI bulletin (MS07-017, patching CVE-2007-0038, which was being actively exploited via drive-by web pages) [@s-msft-ms07-017], and MS08-067 in October 2008 [@s-ms08-067]. The May 8, 2007 Windows DNS RPC RCE bulletin (MS07-029) is sometimes misremembered as an out-of-band release; it shipped on the regular Patch Tuesday cadence [@s-msft-secupdates-index].

The architectural shift the era did not make is the one Windows 10 made: removing the user's ability to indefinitely decline updates on consumer machines. This was politically impossible in 2009 and remains contested in 2026; deferred to Part 3.

Q2: How do you protect kernel integrity from kernel-level attackers?

Era-end answer: PatchGuard runs at the same ring as the attacker; structural bypassability remains. Post-era answer: Hypervisor-Protected Code Integrity in Windows 10 Anniversary Update (August 2016); Virtualization-Based Security and Credential Guard; the Microsoft Vulnerable Driver Block list (2020 onward) for the BYOVD afterlife. Deferred to Part 4.

Q3: How do you separate trust principals more finely than user accounts and integrity levels?

Era-end answer: MIC offered five integrity levels; the granularity is per-process, not per-capability. Post-era answer: AppContainer (Windows 8, which introduces capability SIDs inside a LowBox token so a process can be denied or granted individual platform capabilities such as internetClient independently of its user account); the Modern Apps and Universal Windows Platform manifest-permission model (declarative capability gating at app install time, with the manifest itself authored alongside the app and reviewed at Store submission); and the Windows Subsystem for Linux and Android trust-isolation architectures (per-distribution and per-app isolation contracts that scope filesystem, network, and IPC access to a single guest OS instance). The integrity-level primitive remains the substrate every one of these builds on. Deferred to Part 3 and Part 4.

Q4: How do you ship a security architecture without breaking the user experience?

Era-end answer: Windows 7's polish proves it can be done for one release. Post-era answer: it recurred with Windows 8's Modern UI debacle, the Windows 11 UAC behaviour adjustments, and the 2024 to 2026 Administrator Protection rollout that finally promotes UAC to a security-boundary classification -- traced in the Adminless companion post. The question is recurring -- it is solved per-release, not in principle.

Part 3 picks up the morning after Windows 7 GA with Stuxnet, Operation Aurora, the Enhanced Mitigation Experience Toolkit, and the Process Mitigations era. Part 4 traces the VBS / HVCI / Pluton / Secured-core PC arc that closes the same-privilege paradox. Part 5 covers the credential-theft and Active Directory escalation era (Mimikatz, Pass-the-Hash, the Protected Users group, Credential Guard). Part 6 covers the Administrator Protection redesign and the long arc back to UAC as a security boundary. The shared spine of all five remaining articles is the integrity-level stack Vista shipped.

Four questions on the Monday whiteboard. Three of the four have answers in Parts 3 through 6 of this series. The fourth will outlast the operating system.

12. Reading 2002 to 2008 Windows Documentation in 2026

If you inherit a Vista- or Server 2008-era environment in 2026, or maintain a kernel driver whose support matrix still includes the Vista lineage, or pick up Russinovich, Solomon, and Ionescu's Windows Internals, 5th edition [@s-windows-internals-5e] off the shelf, what should you know that the documentation will not tell you directly?

Reading a `whoami /groups /priv` output on a Vista-or-later machine

The split-token model means the elevated and unelevated tokens differ in their group memberships and privilege lists, not in a single flag. The integrity-level SID line -- Mandatory Label\Medium Mandatory Level or Mandatory Label\High Mandatory Level -- is the right place to look first. Practitioner tip: if the integrity label says High and the privilege list shows SeLoadDriverPrivilege enabled, the token is elevated. If the integrity label says Medium and the privilege list lacks SeBackupPrivilege and SeTakeOwnershipPrivilege, the token is filtered. The Microsoft Learn windows/win32/secauthz/mandatory-integrity-control page is the canonical integrity-level reference [@s-msft-mic-win32].

Reading a Security event-log entry from this era

The Event ID schema changed between XP (5xx range) and Vista (4xxx range); a Vista Event 4624 logon-success entry is not the same as an XP Event 528. The Microsoft Learn windows-security/threat-protection/auditing/ index is the canonical reference for Vista-and-later events. The closest thing to a canonical XP-to-Vista mapping table that Microsoft still publishes is the Appendix L: Events to Monitor page in the Windows Server / Active Directory documentation, whose "Current Windows Event ID" and "Legacy Windows Event ID" columns map post-Vista 4xxx-range identifiers back to their pre-Vista 5xx-range equivalents -- for example, 4624 successful logon mapping to 528/540, 4625 failed logon mapping to 529-537/539, 4634 logoff (kernel-generated when the logon session is destroyed) mapping to 538, 4647 user-initiated logoff mapping to 551, and 1102 audit log cleared mapping to 517 -- for practitioners inheriting mixed XP-and-Vista log estates [@s-msft-events-to-monitor]. Old documentation that uses the 5xx-range numbering is talking about XP and Server 2003.

Reading the MS-bulletin archive

The original microsoft.com/technet/security/bulletin/MS08-067.mspx URL scheme has migrated twice. The current canonical form is learn.microsoft.com/en-us/security-updates/securitybulletins/2008/ms08-067 [@s-ms08-067]. The parent landing URL learn.microsoft.com/en-us/security-updates/ is the working index [@s-msft-secupdates-index]; the legacy /securitybulletins/ URL returns HTTP 404 in 2026 and is one of the reasons cross-references in older books need patient redirection.

Identifying an era-shaped misconfiguration in a modern audit

Three worked examples readers can run on a Windows 10 or 11 fleet today.

A service running as LocalSystem instead of as its per-service SID. The service inventory in sc.exe qc output or Get-Service | ForEach-Object queries should show NT SERVICE\<servicename> in the principal column for any post-Vista service; if it shows LocalSystem, the service is either pre-Vista in its configuration or has been deliberately escalated. Either case warrants explanation.
An unsigned third-party kernel driver loading via the test-signing escape hatch (bcdedit /set testsigning on). Test-signing should never be enabled on production machines; the desktop watermark exists exactly to make this visible. The audit query is bcdedit /enum {current} | findstr testsigning from an elevated prompt.
A BitLocker volume without TPM+PIN protection on a system whose threat model includes physical access. TPM-only mode is vulnerable to the cold-boot attack documented in Halderman et al., USENIX Security 2008 [@s-halderman-coldboot-jhalderm]. The query is manage-bde -protectors -get C: from an elevated prompt; the output should list a numerical password recovery key plus a TPM+PIN protector for any laptop that leaves the office.

Note: bcdedit /set testsigning on is documented for driver development. It is not appropriate for production systems. A production machine with test-signing enabled accepts kernel drivers signed by certificates the system does not normally trust -- exactly the rootkit-installation path Vista x64's mandatory KMCS was designed to close [@s-msft-driver-signing]. Audit for the watermark and for the bcdedit value; if either is present on a server or end-user machine, treat it as a finding.

The reading list

Note: Parts 3 through 6 of this series each pick up where this one ends: - Part 3: Stuxnet, Operation Aurora, the Enhanced Mitigation Experience Toolkit, the cumulative-update model - Part 4: VBS, HVCI, Pluton, Secured-core PC, the closure of the same-privilege paradox - Part 5: Credential theft, Mimikatz, Pass-the-Hash, Credential Guard - Part 6: Administrator Protection and the long arc back to UAC as a security boundary Companion posts: Windows Access Control: 25 Years of Attacks, Adminless, BitLocker on Windows, Beyond BitLocker, Process Mitigation Policies.

Given the line `Mandatory Label\Medium Mandatory Level Label S-1-16-8192` and a privilege list that includes `SeShutdownPrivilege Enabled`, `SeChangeNotifyPrivilege Enabled`, `SeUndockPrivilege Enabled`, `SeTimeZonePrivilege Enabled` -- and that does NOT include `SeLoadDriverPrivilege`, `SeBackupPrivilege`, `SeTakeOwnershipPrivilege`, or `SeDebugPrivilege` -- the token is the filtered standard-user token. The user is an administrator interactively logged on, but the running shell is operating with the filtered token. To verify, open an elevated PowerShell from the same session and re-run `whoami /groups /priv`: the integrity label will read `High Mandatory Level`, the SID will be `S-1-16-12288`, and the elevated privilege set will be present.

The era is closed. The architecture is not.

13. Frequently Asked Questions

Eight common misconceptions about the era, each anchored to a corrected primary source.

No. PatchGuard shipped first in Windows XP Professional x64 Edition and Windows Server 2003 x64 Edition in April 2005 -- twenty months before Vista RTM. Vista x64 inherited PatchGuard v2; Vista SP1 shipped v3. The cite-ready primary is Microsoft Security Advisory 932596, which states explicitly that PatchGuard is "included with x64-based Windows operating systems" and reads back through XP x64 and Server 2003 x64 [@s-msft-adv-932596]. x86 editions of Vista never received PatchGuard at all. No. MS08-067 was patched out-of-band on October 23, 2008 [@s-ms08-067]. Conficker.A was first detected in late November 2008, anchored to November 20, 2008 in SRI International's technical analysis [@s-sri-conficker-c-addendum]. The first in-the-wild MS08-067 exploitation in October 2008 was Gimmiv.A, a narrower non-self-propagating Trojan, per the NVD CVE-2008-4250 entry -- not Conficker [@s-nvd-cve-2008-4250]. The patch-to-weaponisation gap is approximately twenty-nine days and is the article's load-bearing thesis evidence. No. The HTML-comment Mark-of-the-Web (``) shipped in Internet Explorer 6 Service Pack 1 in 2002. The Attachment Execution Service, two years later in XP SP2, is the system-wide enforcement substrate of the `Zone.Identifier` NTFS Alternate Data Stream -- the persistent file-system anchor that downstream tools (Office Protected View, SmartScreen, Microsoft Defender Application Control) consult to gate execution [@s-msft-iattachmentexecute]. Substrate, not ancestor. No. Russinovich's June 2007 *TechNet Magazine* article states explicitly that "elevations were introduced as a convenience" and that this very fact "prevents OTS elevations from being a security boundary" [@s-russinovich-uac-technet]. The chronologically first published Microsoft-principal record of the same disclaimer is the February 12, 2007 Mark's Blog post that anchors the multi-part TechNet blog series on the restricted-token / integrity-level discussion [@s-russinovich-psexec-blog]. The boundary classification arrives with Administrator Protection in the 2024 to 2026 Windows 11 era; see the [Adminless](/blog/adminless-how-windows-finally-made-elevation-a-security-boun/) companion post. No. Vista's ASLR was opt-in for user code via the `/DYNAMICBASE` linker flag; only system images and `/DYNAMICBASE`-linked binaries were randomised. Full mandatory ASLR for all images is a later-Windows feature -- Force ASLR in EMET and Windows 8, mandatory in Windows 10. The Shacham et al. CCS 2004 paper had already established the brute-force bound: with $n$ bits of entropy, an attacker needs expected $2^{n-1}$ attempts against a process that respawns after crash [@s-shacham-asrandom-ccs2004]; on x86 Vista's 8 bits this is roughly 128 attempts, which is why x64 ASLR (qualitatively more entropy) was the more durable defense. No. BitLocker shipped in Windows Vista Enterprise and Ultimate editions only, plus Windows Server 2008. Most Vista consumers ran Home Basic or Home Premium and got no BitLocker at all. The cipher in Vista was AES-CBC with Niels Ferguson's Elephant Diffuser, documented in his August 2006 Microsoft whitepaper [@s-ferguson-bitlocker]; later Windows releases moved to AES-XTS. The SKU limitation materially limited deployment reach for the era. No. KMCS foreclosed the dominant 2003-era unsigned-driver installation path catalogued in Hoglund and Butler [@s-hoglund-butler-rootkits] but did not address the signed-driver-with-vulnerability case. The "Bring Your Own Vulnerable Driver" afterlife became the dominant rootkit-loading path from approximately 2010 onward. Architectural closure waits for the Microsoft Vulnerable Driver Block list (Windows 10 and 11) -- post-era; Part 4 [@s-msft-driver-signing]. Windows ME and Windows 8 have competing claims. The honest framing is that Vista was one of the most poorly received Windows consumer releases of its era, and that the reception was uniquely consequential because the SP1-era enterprise inertia, the consumer-skipping that produced a large XP-to-7 leap, and the marketing problem Windows 7's launch had to solve all compounded each other. The substantive argument of this article -- that Vista's architecture was correct and Vista's integration was not, and that Windows 7 proved the integration tax is payable -- does not depend on the cross-history superlative.

Below the FAQ, a final pointer: this is Part 2 of six. Part 3 picks up the morning after Windows 7 GA with Stuxnet, Operation Aurora, the Enhanced Mitigation Experience Toolkit, and the process-mitigations era. The integrity-level stack Vista shipped in January 2007 is what every Part from here forward is built on top of.