Parag Mali - tag: sandbox

Windows Sandbox vs Windows Defender Application Guard: Two Hyper-V Sandboxes, Different Threat Models

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

**Two Windows features, the same plumbing, opposite fates.** Windows Sandbox (2019) and Windows Defender Application Guard (2017) both spin up a Hyper-V child partition using the Host Compute Service (HCS) API [@learn-microsoft-com-hcs-overview] on top of the same Virtualization-Based Security [@learn-microsoft-com-oem-vbs] substrate. Sandbox is disposable, on-demand, and aimed at running an untrusted executable. WDAG was persistent, automatic, and aimed at rendering an untrusted website inside Microsoft Edge. WDAG was deprecated for Edge [@learn-microsoft-com-application-guard] and then removed entirely in Windows 11 24H2 [@learn-microsoft-com-guard-overview]; Sandbox still ships. The reason is not that one model was wrong -- it is that operational economics and threat models diverged. This article explains the shared substrate, the architectural differences, the deprecation story, and what replaced WDAG in the 2026 Windows isolation stack.

1. The Hyper-V Isolation Layer Both Features Share

Open two Microsoft Learn pages side by side -- the Windows Sandbox architecture page [@learn-microsoft-com-sandbox-architecture] and the Microsoft Defender Application Guard overview [@learn-microsoft-com-guard-overview] -- and the descriptions almost rhyme. The MDAG overview opens by calling its container an "isolated Hyper-V-enabled container"; the Sandbox architecture page describes its guest as a dynamically generated, "kernel-isolated" Windows image that the host can destroy. Two pages, two teams, the same noun and the same verb. The two features are siblings: built by overlapping teams, on top of the exact same compute substrate, and shipped roughly two years apart.

That substrate is named, and worth naming carefully, because the rest of the article rests on it.

The Windows API that creates, starts, configures, queries, and destroys Hyper-V "compute systems" -- the umbrella term Microsoft uses for either a virtual machine or a container with its own kernel. The HCS reference docs [@learn-microsoft-com-reference-apioverview] list functions like `HcsCreateComputeSystem`, `HcsStartComputeSystem`, and `HcsGetComputeSystemProperties` -- a kernel32-shaped surface for child partitions, parameterized by JSON.

When Microsoft first documented HCS publicly, it framed it as a kernel32-equivalent for child partitions. The HCS overview [@learn-microsoft-com-hcs-overview] describes the API in terms of compute systems (the umbrella term for either a virtual machine or a container with its own kernel), with "configurations and properties... stored in a JSON file which will then be passed through the HCS APIs to create the compute system." The API reference [@learn-microsoft-com-reference-apioverview] notes that the DLL "exports a set of C-style Windows API functions, using JSON schema as configuration"; Microsoft's hcsshim repository [@github-com-microsoft-hcsshim] provides the Go binding used by Moby and containerd. The framing matters. HCS is not a sandbox. It is the mechanism a sandbox feature uses to ask Hyper-V for "a kernel of my own, isolated from yours, please." What the consumer does with that kernel -- what it boots, what it shares, when it tears it down -- is the threat model. That is where Sandbox and WDAG diverge.

Underneath HCS sits Hyper-V itself, and underneath Hyper-V sits Virtualization-Based Security (VBS).

A Windows feature that runs the normal Windows kernel as a Hyper-V guest, then uses a second, smaller secure kernel running at a higher Virtual Trust Level (VTL1) to isolate keys, policies, and code-integrity decisions from the main kernel. The OEM VBS guidance [@learn-microsoft-com-oem-vbs] documents the boot path: the hypervisor launches first, then hosts the NT kernel in a child partition.

VBS itself does not run untrusted user code. Its job is to give Windows a hypervisor that ships in the box on every supported SKU and that is anchored by Secure Boot. Once that hypervisor exists, the cost of "spawn a second Windows guest just for this task" stops being "boot a full VM (minutes, gigabytes)" and starts being "ask HCS for a child partition (seconds, hundreds of megabytes)." Hyper-V on Windows [@learn-microsoft-com-windows-about] is the desktop face of that hypervisor; Hyper-V isolation containers [@learn-microsoft-com-hyperv-container] on Windows Server are the server face. Sandbox and WDAG are two desktop-flavored consumers of the same pipe.

flowchart TD HW[Hardware: VT-x/AMD-V, IOMMU, TPM] HV[Hyper-V hypervisor] Root[Root partition: host NT kernel] HCS[Host Compute Service API] WS[Windows Sandbox child partition] WDAG[WDAG child partition] HVC[Hyper-V Windows Container] HW --> HV HV --> Root Root --> HCS HCS --> WS HCS --> WDAG HCS --> HVC

Notice the diagram's most important detail: the host NT kernel is also a Hyper-V guest. It runs in the root partition, which has full physical-device access; the sandbox and WDAG partitions run as L1 guests with no physical-device access at all. The Hyper-V VM boundary -- the membrane between root and L1 -- is what Microsoft commits to defending. That commitment is published: the Microsoft Security Servicing Criteria for Windows [@microsoft-com-servicing-criteria] names the Hyper-V VM as a serviced security boundary, and the Hyper-V Bounty Program [@microsoft-com-hyper-v] pays up to $250,000 for a guest-to-host escape. The boundary has a dollar sign attached to it, which is how you know it counts.

Key idea: The Hyper-V VM boundary is the serviced security boundary. Windows Sandbox and WDAG ride on top of that boundary; neither product is the boundary. Bugs in the host-side broker, the clipboard channel, or the policy engine are not Hyper-V escapes -- they are integration bugs in features that happen to run inside a VM.

This distinction matters operationally. When the Windows Sandbox configuration docs [@learn-microsoft-com-wsb-file] warn that enabling vGPU "can potentially increase the attack surface of the sandbox," they are talking about widening a brokered channel from the L1 guest into the root partition's display stack. That channel runs through the VM boundary; abusing it does not require breaking Hyper-V. The same logic applies to mapped folders, the clipboard, networking, and the Edge-window remoting path WDAG used. Each is a deliberate hole in the boundary, made for a reason, with its own threat model.

With the substrate established, the next question is what Sandbox does on top of it. The answer turns on a single observation: the host already has a Windows image. Why download another one?

2. Windows Sandbox: The Disposable Desktop

Windows Sandbox shipped in Windows 10 1903 [@learn-microsoft-com-sandbox-install], the May 2019 update, as an optional Windows feature named Containers-DisposableClientVM -- the install page documents both the version requirement and the exact PowerShell feature name. The naming is loud about the design goal. A container (rather than a VM you manage with vmconnect), disposable (state is destroyed on close), for client workloads (interactive desktop apps, not server workloads). Microsoft's original Windows Sandbox announcement on the Kernel Internals blog [@web-archive-org-p-301849] (preserved on the Internet Archive after Microsoft retired the canonical URL) frames the use cases plainly: trying out an installer, opening a suspicious download, testing an executable from email -- the same use cases the current Sandbox overview [@learn-microsoft-com-sandbox-overview] still enumerates.

The trick that makes this feel cheap is the dynamic base image.

The disk template Windows Sandbox uses to boot its guest. According to the Windows Sandbox architecture page [@learn-microsoft-com-sandbox-architecture], the on-disk package is approximately 30 MB compressed and expands to about 500 MB when installed. The expansion is mostly *pointers* back to the host's own immutable OS files; pristine private copies exist only for files the guest may legitimately mutate.

A traditional VM ships a 4-8 GB VHDX with its own copy of Windows. The dynamic base image inverts that. Read-only files in the host -- ntdll.dll, the bulk of System32, the side-by-side cache -- are reflected into the guest by reference. The guest sees a complete Windows install at boot. The host barely paid for it.

Memory uses an even sharper trick: direct map.

A Hyper-V memory-sharing optimization, described on the Windows Sandbox architecture page [@learn-microsoft-com-sandbox-architecture], in which immutable physical pages are shared read-only between the host and the sandbox guest. When the guest loads `ntdll.dll`, the same physical RAM that already holds `ntdll.dll` on the host is mapped into the guest's address space rather than duplicated.

The page is read-only from both sides, so a guest exploit cannot scribble into the host's copy. The win is memory pressure: dozens of megabytes for the guest's mutable state instead of hundreds of megabytes for a fresh Windows kernel image. The same architecture page describes the memory model directly: "containers collaborate with the host to dynamically determine how host resources are allocated. This method is similar to how processes normally compete for memory on the host... If the host is under memory pressure, it can reclaim memory from the container much like it would with a process." A sandbox that does little uses little, and a sandbox that does a lot pulls pages from the host the same way a heavy host process would.Direct map is conceptually the same trick Linux uses to share glibc between processes -- the same physical pages of a read-only binary backing many virtual address spaces. The Windows Sandbox application is to use that primitive across a Hyper-V partition boundary, not just across processes inside one kernel.

Graphics use a third mechanism. A vGPU runs the guest's display through WDDM 2.5+, sharing the host GPU much like another process on the host would. When the host GPU lacks a compatible WDDM driver, the guest falls back to WARP, Microsoft's CPU-backed Direct3D rasterizer. The same Sandbox architecture page [@learn-microsoft-com-sandbox-architecture] cited above documents both branches: "a system with a compatible GPU and graphics drivers (WDDM 2.5 or newer) is required. Incompatible systems render apps in Windows Sandbox with Microsoft's CPU-based rendering technology, Windows Advanced Rasterization Platform (WARP)." That fallback is slow but means Sandbox starts on essentially any Pro+ Windows 10/11 install, not only on machines with modern discrete GPUs.

sequenceDiagram participant U as User participant Host as Host (root partition) participant HCS as HCS API participant G as Sandbox guest U->>Host: Launch WindowsSandbox.exe (with optional .wsb) Host->>HCS: HcsCreateComputeSystem(JSON) HCS->>G: Allocate partition, mount dynamic base image HCS->>G: Direct-map immutable host pages HCS->>G: Start guest (boot stripped NT, run LogonCommand) G-->>Host: RDP-style remoting of desktop U->>G: Drop .exe, run, observe U->>Host: Close Sandbox window Host->>HCS: HcsTerminateComputeSystem HCS->>G: Destroy partition, discard all writable state

What the user configures is the small set of seams between guest and host. Configuration lives in a .wsb file, an XML document the user double-clicks to launch a customized sandbox. The Windows Sandbox configuration page [@learn-microsoft-com-wsb-file] enumerates every supported element: <vGPU>, <Networking>, <MappedFolders>, <LogonCommand>, <MemoryInMB>, <AudioInput>, <VideoInput>, <ProtectedClient>, <PrinterRedirection>, <ClipboardRedirection>. Each line is a knob on the boundary.

A minimal hostile-binary harness disables almost every shared channel:

{// Produce a Windows Sandbox configuration that minimizes shared channels. // Run this in Node, save the output as triage.wsb, then double-click it. const sample = "C:\\\\Users\\\\analyst\\\\Samples\\\\suspicious.exe"; const wsb = [ "<Configuration>", " <VGpu>Disable</VGpu>", " <Networking>Disable</Networking>", " <AudioInput>Disable</AudioInput>", " <VideoInput>Disable</VideoInput>", " <PrinterRedirection>Disable</PrinterRedirection>", " <ClipboardRedirection>Disable</ClipboardRedirection>", " <ProtectedClient>Enable</ProtectedClient>", " <MappedFolders>", " <MappedFolder>", " <HostFolder>C:\\\\Users\\\\analyst\\\\Samples</HostFolder>", " <SandboxFolder>C:\\\\Samples</SandboxFolder>", " <ReadOnly>true</ReadOnly>", " </MappedFolder>", " </MappedFolders>", "</Configuration>" ].join("\\n"); console.log(wsb); console.log("\\nSample path inside guest: " + sample.replace("C:\\\\Users\\\\analyst", "C:"));}

Note: The default .wsb-less Windows Sandbox launch enables networking and clipboard redirection. The configuration docs [@learn-microsoft-com-wsb-file] warn that enabled networking "could expose untrusted applications to the internal network." For malware triage, the explicit <Networking>Disable</Networking> form above is the right starting point.

A few cost-of-doing-business limits are worth flagging up front. Only one Sandbox can run at a time, per the Sandbox overview [@learn-microsoft-com-sandbox-overview], which also restricts the feature to Pro/Enterprise/Education SKUs ("Windows Sandbox is currently not supported on Windows Home edition") and inherits the VBS-capable-hardware requirement from the OEM VBS guidance [@learn-microsoft-com-oem-vbs]. And while in-sandbox state survives a shutdown /r inside the guest (a Windows 11 22H2 refinement called out in the same overview page), state still dies when the host UI window closes -- "disposable" is the contract, not a marketing word.

A Containers-DisposableClientVM partition, then, is essentially a Hyper-V container with a desktop bolted on, a shared OS image, a few configurable channels, and a strict "destroy on close" lifecycle. WDAG, the older sibling, took the same building blocks and arranged them around a completely different question: not "run this executable once" but "render this website transparently."

3. WDAG: The Persistent Browser Container

Windows Defender Application Guard shipped in Windows 10 1709 -- the Fall Creators Update [@learn-microsoft-com-build-16299] (Microsoft's UWP what's-new page identifies "Windows 10 build 16299 (also known as the Fall Creators Update or version 1709)"), with a GA start date of October 17, 2017 [@learn-microsoft-com-and-education] per the Microsoft Lifecycle page. The WDAG install guide [@learn-microsoft-com-app-guard] still lists standalone-mode support starting at "Windows 10 Enterprise edition, version 1709 and later." At launch it integrated with the legacy EdgeHTML-based Edge; later it integrated with Chromium-based Edge for Business and, beginning in 2020, with Microsoft 365 Apps for Enterprise to wrap untrusted Office documents -- the MDAG overview [@learn-microsoft-com-guard-overview] explicitly enumerates the file types: "Application Guard helps prevent untrusted Word, PowerPoint, and Excel files from accessing trusted resources." The product was rebranded from "Windows Defender Application Guard" to "Microsoft Defender Application Guard" along the way -- the isolatedapplauncher.h header notes [@learn-microsoft-com-api-isolatedapplauncher] state directly that "Windows Defender Application Guard (WDAG) is now Microsoft Defender Application Guard (MDAG). The WDAG name is deprecated, but it is still used in some APIs." This article uses WDAG for continuity.

The use case was specific and corporate: in a managed enterprise, an employee may need to follow a customer's link, open an inbound attachment, or read a marketing site -- content that originates outside the organization's network perimeter. WDAG's job was to render that content in a partition that cannot talk to the intranet, so that a renderer exploit chained to a kernel LPE inside the guest could not pivot to corporate file shares, Active Directory, or the user's own home directory.

The trust boundary was policy-defined.

The Group Policy mechanism Windows uses to enumerate "what counts as inside the enterprise network," documented under Configure Microsoft Defender Application Guard [@learn-microsoft-com-app-guard-2]. Administrators populate Enterprise Network Domains, Cloud Resources, Internal Proxies, and IPv4/IPv6 Subnets. Anything inside the list is rendered in the host browser; anything outside is reissued inside the WDAG container.

This is the property Windows Sandbox does not have. Sandbox is a manual tool; WDAG was transparent. Click an external link in Outlook, and a separate Edge window opens hosting the rendered page -- the user did not have to know about, configure, or invoke a sandbox. The host-side broker forwarded the navigation; the in-container Edge rendered the page; an RDP-family remoting path relayed pixels back to the host UI. Microsoft has not publicly named the inner protocol, but its visible behavior -- per-window remoting of a single app onto the host desktop -- is the signature of the Remote Applications Integrated Locally (RAIL) virtual channel specified in [MS-RDPERP], the RDP extension that "presents a remote application... as a local user application." The implementation may differ in detail; the architectural shape is the same.

Where Sandbox is "destroy on close," WDAG was "warm at logon."

sequenceDiagram participant U as User participant Logon as Winlogon participant Broker as Host WDAG broker participant Cont as WDAG container participant Edge as Container Edge Logon->>Broker: User signs in Broker->>Cont: HCS pre-warm container (pruned image) Cont->>Edge: Boot, idle, await navigation U->>Broker: Click https://external.example Broker->>Broker: Network Isolation policy check (out of zone) Broker->>Edge: Reissue URL inside container Edge-->>Broker: Render via RDP-family remoting (RAIL-shaped) Broker-->>U: Display container window on host desktop

The configuration surface was correspondingly broader than Sandbox's .wsb. Group Policy settings controlled clipboard direction (upload, download, both, neither), file print to host, microphone and camera access, hardware acceleration, and -- most operationally consequential -- whether downloads escape the container at all. The Microsoft Edge WDAG configuration guidance [@learn-microsoft-com-application-guard] listed knobs like ApplicationGuardUploadBlockingEnabled and ApplicationGuardPassiveModeEnabled for security-versus-usability tuning.

WDAG also exposed a small detection API for applications running inside it, the IsolatedAppLauncher COM interface [@learn-microsoft-com-api-isolatedapplauncher]. The methods IsProcessInWDAGContainer and IsProcessInIsolatedContainer let an app know "am I in the guest?" -- useful for, say, disabling drivers that cannot work inside the partition. The header carries the deprecation notice today.The detection-from-inside API is itself a useful tell about WDAG's threat model. If the guest needed to know it was the guest, that means software running inside it could legitimately do guest-specific things -- license activation, optional installers, telemetry. WDAG was meant to host fully functional applications, not a stripped renderer. That breadth is part of what made its operational cost real.

What it improved over the AppContainer-wrapped Edge of 2016 was substantial. A renderer-to-kernel exploit in the container's stripped Windows guest landed in a throwaway kernel that had no view of the host filesystem, no route to the corporate intranet, no host clipboard write path, and no persistence across reboot. The kernel attack surface of the partition is, in the limit, the Hyper-V VM boundary. That is a serviced Microsoft boundary; an AppContainer-wrapped Edge is not.

So why was WDAG retired and Sandbox kept? Because in the WDAG threat model, the "warm partition for every employee, all day long, on every device" became a tax that the in-browser sandbox could finally outrun.

4. The Lifecycle Divergence

The clearest way to see why two siblings on the same substrate diverged is to put their lifecycles side by side. Sandbox boots on user gesture, runs as long as one window stays open, dies on close. WDAG booted at user logon, stayed resident the entire session, and discarded state only when the user signed out (or, for the persistent variant, never). The same Hyper-V partition primitive, allocated at very different points in the day, for very different durations, was being asked to solve very different problems.

The point at which a security primitive's instance lifetime is anchored. Sandbox is *gesture-bound*: an instance exists because a user explicitly launched it. WDAG was *session-bound*: an instance existed because a user signed in. AppContainer is *process-bound*: an instance exists because a sandboxed binary is running. Each binding implies a different cost model and a different set of failure modes.

Gesture binding is cheap in expectation. Most users open Sandbox seldom -- when a particular file looks suspicious, when an installer wants admin rights for unclear reasons, when an analyst is reproducing a sample. The cost of the partition is paid on demand and only by the user who needed it. The Containers-DisposableClientVM feature in the Sandbox install docs [@learn-microsoft-com-sandbox-install] ships an option: enabled but unused, it costs nothing beyond the dynamic base image on disk.

Session binding has the opposite cost profile. Every employee, on every device, pays for a Hyper-V child partition at every logon, whether or not they ever browse an untrusted URL. The partition holds memory. The host-side broker holds memory. The pre-warmed Edge holds memory. The Network Isolation policy must be evaluated on every navigation. The clipboard, downloads, and print paths require ongoing brokering. Even on a workstation that idles all day in front of an intranet portal, WDAG was a tax line item.

Key idea: A serviced security boundary is cheap when it is allocated by gesture and expensive when it is allocated by session. WDAG bet that the per-session cost would amortize against frequent untrusted browsing; that bet failed for most enterprise users because the marginal extra protection over an in-browser sandbox (Edge ESM + ACG + CET) was small for the typical navigation, even though it remained large for the worst-case navigation.

The threat models also point in opposite directions. Sandbox optimizes for a single, contained interaction with an untrusted artifact: drop the .exe, run it, watch what happens, close the window. Anything the artifact does inside the partition -- registry writes, scheduled-task creation, persistence attempts -- is annihilated when the window closes. WDAG was optimizing for the opposite: many small, transparent interactions with untrusted content (clicks, navigations, document opens), all of which had to feel seamless or the user would route around them.

gantt title Sandbox vs WDAG lifecycle on a typical 8-hour workday dateFormat HH:mm axisFormat %H:%M section Windows Sandbox Idle (no cost) :done, ws1, 09:00, 11:00 Analyst opens suspicious.exe :crit, ws2, 11:00, 11:15 Idle (no cost) :done, ws3, 11:15, 16:00 Test installer :crit, ws4, 16:00, 16:10 Idle (no cost) :done, ws5, 16:10, 17:00 section WDAG (legacy) Pre-warmed partition resident :crit, wd1, 09:00, 17:00

The lifecycle asymmetry also asymmetrically rewards engineering effort. Hardening an in-browser renderer pays off thousands of times per session -- every page load benefits. Hardening a per-employee Hyper-V partition pays off only on the navigations that actually leave the trusted zone, which for most users is a small fraction of clicks. As the in-browser side became dramatically stronger between 2018 and 2023 -- Site Isolation, V8 sandboxing, Arbitrary Code Guard (ACG), Control-flow Enforcement Technology (CET), the new Edge Enhanced Security Mode -- the marginal value of WDAG dropped while its operational cost did not.

That set up the deprecation decision.

5. The Deprecation Decision

The retirement happened in two visible steps and a long invisible runway.

The first visible step was the Edge-side deprecation, announced in 2023. The Microsoft Edge and Microsoft Defender Application Guard [@learn-microsoft-com-application-guard] page now opens with the banner: "Microsoft Defender Application Guard, including the Windows Isolated App Launcher APIs, is deprecated for Microsoft Edge for Business and will no longer be updated." The same page makes the operational substitute explicit: "The additional security features in Edge make it very secure without needing Application Guard," then enumerates Defender SmartScreen, Enhanced Security Mode, website typo protection, and Data Loss Prevention as the replacement set for the WDAG-for-Edge scenario.

The second visible step was the OS-level removal in Windows 11 version 24H2. The MDAG overview banner [@learn-microsoft-com-guard-overview] is unambiguous: "Starting with Windows 11, version 24H2, Microsoft Defender Application Guard, including the Windows Isolated App Launcher APIs, is no longer available." The isolatedapplauncher.h API reference [@learn-microsoft-com-api-isolatedapplauncher] carries the matching deprecation notice for the COM surface. Code paths that called IIsolatedAppLauncher on a 24H2 box now hit a removed feature; the API names remain in the documentation as historical record.

Note: The Edge-side deprecation and the OS-side removal in Windows 11 24H2 are often conflated in coverage. They are different. The Edge-side deprecation stopped updates and the New-Tab-Page entry point; existing fleets on earlier Windows versions retained the underlying feature. The 24H2 removal pulled the kernel-mode plumbing -- the Sandbox install page [@learn-microsoft-com-sandbox-install] even calls out a side-effect: "Beginning in Windows 11, version 24H2, inbox store apps like Calculator, Photos, Notepad and Terminal are not available inside Windows Sandbox," because the underlying app-isolation broker was reworked as part of the same cleanup.

The invisible runway behind those two banners is the more interesting story. Microsoft's Security Servicing Criteria for Windows [@microsoft-com-servicing-criteria] page names "Hyper-V VM" as a serviced security boundary but does not name WDAG or Application Guard. WDAG was always a feature that used the Hyper-V VM boundary; it was never the boundary itself. A bug in the WDAG broker, the Network Isolation policy evaluator, the clipboard channel, or the host-side window remoting was an integration bug, not a Hyper-V escape, and so was never going to attract the kind of bounty payout -- "up to $250,000 USD" per the Hyper-V Bounty Program [@microsoft-com-hyper-v] -- that the underlying boundary attracts. The economic shape of WDAG's bug surface always favored deprecation: it was a complex, brokered feature whose worst plausible CVE was a privilege-escalation inside Edge, not a guest-to-host RCE.

Key idea: WDAG's deprecation was overdetermined. (1) The session-bound cost model could not be amortized for most users. (2) The in-browser mitigations (ACG, CET, Edge ESM, Site Isolation) closed the marginal-security gap on the typical navigation. (3) The integration-bug class -- broker, clipboard, policy -- was never going to be on Microsoft's serviced security boundary list. Each reason alone could have justified retirement; all three together made it inevitable.

What was kept is just as telling. The Hyper-V VM boundary stayed; the bounty program stayed; the HCS API stayed; Windows Sandbox stayed; Hyper-V isolation containers on Windows Server stayed. Microsoft did not retire any of the things that made WDAG technically possible -- only the specific arrangement of those things into a session-bound, transparent, browser-targeted feature. The mechanism was kept; the productization was retired.

6. The WDAG Replacement Stack

There is no single replacement for WDAG. There is a stack of complementary features, each of which absorbs a slice of WDAG's old job. The Edge-deprecation page enumerates the substitute set; what follows pulls each item back to its primary source.

6.1 Edge Enhanced Security Mode (in-browser sandbox)

WDAG-for-Edge is now Microsoft Edge Enhanced Security Mode (ESM). The browse-safer page [@learn-microsoft-com-browse-safer] is explicit about what changed: "Enhanced security mode in Microsoft Edge mitigates memory-related vulnerabilities by disabling just-in-time (JIT) JavaScript compilation and enabling additional operating system protections for the browser. These protections include Hardware-enforced Stack Protection and Arbitrary Code Guard (ACG)."

Functionally, ESM gives up the Hyper-V partition boundary and replaces it with a set of process-mitigation policies that make the in-browser sandbox materially harder to escape. The renderer still runs on the host kernel, but with JIT disabled (closing a large class of write-then-execute primitives), CET enforcing shadow stacks, and ACG blocking dynamic code generation. For unfamiliar sites only, the browser flips into this mode automatically; familiar sites keep JIT on for performance.The trade is explicit on the page: "Developers should be aware that the WebAssembly (WASM) interpreter running in enhanced security mode might not yield the expected level of performance." ESM is consciously slower in exchange for a smaller attack surface, and it concedes that this trade is only worth making on a subset of navigations. WDAG made the same concession at the partition level; ESM makes it at the mitigation level.

6.2 Smart App Control (OS-level binary trust)

For downloads -- the other half of "untrusted content reaches the user" -- the replacement is Smart App Control [@learn-microsoft-com-control-overview]. The Microsoft Learn page describes it as "an app execution control feature that combines Microsoft's app intelligence services and Windows' code integrity features to protect users from untrusted or potentially dangerous code." The Windows 11 Security Book [@learn-microsoft-com-driver-control] clarifies the mechanism: Smart App Control "blocks untrusted or unsigned applications" by predicting safety from a cloud intelligence service, and "blocks unknown script files and macros from the web."

The replacement logic is direct. WDAG protected the host kernel from a malicious download by running the download inside a Hyper-V partition. Smart App Control protects the host kernel from a malicious download by not running it at all unless app intelligence predicts it is safe or it is signed by a trusted CA. The first approach contains the blast radius after execution; the second prevents execution altogether. For the common case -- a user clicking through a suspicious-looking installer -- prevention strictly dominates containment.

6.3 Defender for Endpoint network protection (policy-defined trust boundary)

For the policy-defined "enterprise vs not-enterprise" boundary that the Network Isolation policy used to draw for WDAG, the replacement is Defender for Endpoint's network protection [@learn-microsoft-com-network-protection] feature. The page describes it as "expand[ing] the scope of Microsoft Defender SmartScreen to block all outbound HTTP(S) traffic that attempts to connect to poor-reputation sources (based on the domain or hostname)," operating at the OS level. The same page is precise about which processes it covers on Windows: it enforces against non-Microsoft browsers and non-browser processes (for example, PowerShell), and its own Note states that "on Windows, network protection doesn't monitor Microsoft Edge. For processes other than Microsoft Edge and Internet Explorer, web protection scenarios use network protection for inspection and enforcement." For Microsoft Edge on Windows, the same reputational source feed (SmartScreen) operates inside the browser; Network Protection is the cross-process extension of that feed to the other process classes.

The shift is from isolate, then permit anything inside the isolated zone (WDAG) to enforce a reputational/IOC-based block list at the host network stack (Defender). The replacement gives up the partition boundary in exchange for matching coverage across every process on the device, not just Edge.

6.4 Office Protected View and Office SmartScreen (per-document admission)

The Office slice of WDAG -- the variant that wrapped untrusted Word, PowerPoint, and Excel files in a Hyper-V partition -- was always a layered feature on top of an older, cheaper primitive: Office Protected View [@support-microsoft-com-8e43-2bbcdbcb6653]. The Microsoft Support page describes the primitive directly: "files from these potentially unsafe locations are opened as read only or in Protected View. By using Protected View, you can read a file, see its contents and enable editing while reducing the risks." The page also calls out the WDAG layering explicitly: "If your machine has Application Guard for Microsoft 365 enabled, documents that previously opened in Protected View will now open in Application Guard for Microsoft 365" -- which is exactly the slice that 24H2 removed. Without WDAG, Protected View is the residual primitive: documents from the internet, untrusted senders, or unsafe locations open read-only in a stripped-down Office process until the user opts in to editing.

Around Protected View sits a second admission layer: SmartScreen-derived reputation checks on the artifact itself. The Microsoft 365 Apps internet-macros guidance [@learn-microsoft-com-macros-blocked] sets the policy directly: "VBA macros are a common way for malicious actors to gain access to deploy malware and ransomware. Therefore, to help improve security in Office, we're changing the default behavior of Office applications to block macros in files from the internet." The page describes how Office uses the Mark of the Web -- the same signal SmartScreen uses for binaries -- to decide whether macros in a given document are admitted. Where the WDAG-for-Office configuration would have re-rendered the document inside a Hyper-V partition regardless of macro content, the 2026 replacement turns the question off: macros in internet-origin documents simply do not run.

Together, the two features are the document analog of Smart App Control + Defender network protection: a read-only fallback for the artifact itself (Protected View) and a reputation-driven admission policy for its riskiest payload (macros). Neither replaces a partition; the union covers WDAG's Office slice at the cost of giving up the kernel boundary around the document.

The stack is not a one-for-one swap. Each feature trades the Hyper-V VM boundary for something cheaper to operate. The aggregate covers the WDAG threat model at typical navigation cost; for the unusual case where an enterprise still wants a hard kernel boundary around an untrusted workload, Microsoft's recommended fallback [@learn-microsoft-com-application-guard] is explicit: "If your organization requires container-based isolation, we recommend Windows Sandbox or Azure Virtual Desktop (AVD)." The Hyper-V partition is still there. It just is no longer running every employee's browser, all day, by default.

7. Why Sandbox Survives

If the deprecation reasoning above is right, the natural question is why the same substrate, allocated by the same HCS API, in the same kind of Hyper-V partition, survived as Windows Sandbox. The answer is that everything that made WDAG expensive maps to an operational advantage in Sandbox.

The lifecycle is gesture-bound, not session-bound. The cost is paid by the user who explicitly asked for it, when they asked for it, and not before. The Sandbox install page [@learn-microsoft-com-sandbox-install] ships the feature disabled by default; turning it on costs the dynamic base image on disk and nothing on memory until launch.

The substitute set is empty. For the "run an untrusted executable once" threat model, no in-process mitigation suite plays the role ESM plays for browsing. There is no in-AppContainer answer to "I want to detonate suspicious.exe and observe it"; Smart App Control prevents execution rather than containing it; AppLocker policies refuse the run rather than sandboxing it. The use case Sandbox fills is what is left over when prevention fails or is operationally unacceptable, and there is no cheaper way to fill it.

Key idea: The "run an untrusted executable" threat model lacks a cheaper substitute, so Sandbox's Hyper-V partition cost is the floor. WDAG's "render an untrusted website" threat model gained a cheaper substitute (Edge ESM), so WDAG's same Hyper-V partition cost stopped being the floor and became the ceiling -- and was retired.

The integration surface is also far smaller. Sandbox exposes one launcher binary, one configuration file format, no policy engine, no clipboard direction policies (just on/off), no network zoning, no pre-warmed worker process, no host-side broker for an embedded browser. The host-side attack surface is correspondingly thin: a .wsb parser, an HCS caller, a window-host process. Each WDAG-style integration bug class -- network-isolation evaluator, browser broker, document-routing logic -- has no analog.

A useful contrast: the isolatedapplauncher.h [@learn-microsoft-com-api-isolatedapplauncher] page exposes IIsolatedAppLauncher, IIsolatedProcessLauncher, IsProcessInIsolatedContainer, and IsProcessInWDAGContainer. That is the application surface of a feature that hosts third-party processes and lets them know they are inside it. Sandbox has nothing comparable, because no third-party application is supposed to ship with "behave differently inside Sandbox" logic. The guest is a fresh Windows install, the artifact is whatever the user dropped in, and the host does not need to expose an "am I inside?" predicate.

Sandbox also benefits from the negative space of the deprecation. The replacement stack (Edge ESM, Smart App Control, Defender network protection) collectively pushes the unbearable workloads off the Hyper-V partition: the always-on browser, the heavyweight Office document host, the network-zone enforcer. What is left for Sandbox is the relatively small set of workloads where partition isolation is the right answer: malware triage, installer testing, one-off compatibility checks, isolated developer environments. The feature is now used closer to its design intent than it was in the WDAG era.This is the rare case where deprecating a sibling makes a feature more aligned with its purpose. Before WDAG retirement, the question "should this be in Sandbox or WDAG?" had a complicated answer involving who you were and what you were doing. After 24H2, the question collapses: if you want a partition, you mean Sandbox.

8. The 2026 Isolation Stack

With WDAG gone, the post-24H2 Windows isolation taxonomy is best read as four orthogonal primitives, each answering a different question about an untrusted workload. None alone substitutes for WDAG's combined function; together they cover the ground WDAG used to. The tiers below are numbered for reference; the numbering does not imply a single linear cost/strength axis. Process mitigations live inside AppContainer-wrapped processes (they are not "below" AppContainer on a cost axis, they are within it), and admission primitives (Smart App Control, Defender network protection) are an orthogonal family that decides whether a binary or destination is allowed at all -- a question that runs before capability containment, not above or below it.

A mechanism that answers a specific question about how an untrusted workload is constrained. The four families that the 2026 Windows stack composes are: (1) *process-internal mitigations* that limit what a corrupted-memory exploit can do (ACG, CET, Edge ESM); (2) *capability sandboxes* that limit what a process can name and reach (AppContainer); (3) *admission policies* that decide whether a binary may run or a destination may be contacted at all (Smart App Control, Defender network protection); and (4) *kernel-partition boundaries* that put an entire second NT kernel between the workload and the user's data (Hyper-V VM). Each family has its own cost shape; only the kernel-partition boundary appears on the Microsoft Servicing Criteria for Windows [@microsoft-com-servicing-criteria] as a serviced security boundary.

Tier 1: Process mitigations (Edge ESM, ACG, CET)

The cheapest family runs the workload on the host kernel under a stricter set of process-level controls. Edge Enhanced Security Mode is the visible UI; the underlying primitives are the Hardware-enforced Stack Protection [@techcommunity-microsoft-com-p-2163340] (CET) and Arbitrary Code Guard [@learn-microsoft-com-protection-reference] (ACG) referenced from the browse-safer page [@learn-microsoft-com-browse-safer]. These mitigations apply inside whatever container the binary already runs in -- an AppContainer-wrapped Edge renderer, or a non-AppContainer process -- and limit the privileges a corrupted-memory exploit can give itself. They are sufficient for the vast majority of untrusted navigations after the JIT-disabling trade is made.

Tier 2: AppContainer (capability-bound sandbox)

The capability sandbox is the AppContainer [@learn-microsoft-com-appcontainer-isolation] primitive. The MSDN page enumerates the isolation slices under six section headings -- Credential isolation, Device isolation, File isolation, Network isolation, Process isolation, and Window isolation -- all enforced at the OS, none requiring a partition. AppContainer is the wrapper around Edge's renderer, around UWP apps, around modern app-isolation packages. It is the cheap container that scales to every process on the device. Inside an AppContainer, Tier 1 mitigations still apply; AppContainer constrains what the process can name, Tier 1 constrains what a corrupted process can do. They are complementary, not stacked.

Tier 3: Smart App Control + Defender network protection (policy at the OS edge)

Adjacent to the process tiers, the policy tier decides what binaries and what destinations are allowed at all. Smart App Control governs what runs; Defender network protection governs what the device talks to. These are not isolation primitives in the strict sense -- they are admission primitives. They turn off the question before the partition has to answer it.

Tier 4: Hyper-V VM (Windows Sandbox, Windows Server Hyper-V isolation containers)

At the top of the cost curve sits the Hyper-V VM boundary -- the only tier whose worst-case escape pays the $250,000 bounty [@microsoft-com-hyper-v]. Windows Sandbox is the desktop face; Hyper-V isolation containers [@learn-microsoft-com-hyperv-container] on Windows Server ("each container runs inside of a highly optimized virtual machine and effectively gets its own kernel") are the server face. The 2026 stack uses this tier sparingly, on user gesture, for workloads where the cheaper tiers are not enough.

flowchart TD T1[Tier 1: Process mitigations
ACG, CET, Edge ESM] T2[Tier 2: AppContainer
Capability-bound process sandbox] T3[Tier 3: Policy admission
Smart App Control + Defender network protection] T4[Tier 4: Hyper-V VM
Windows Sandbox / HV isolation containers] T1 ~~~ T2 ~~~ T3 ~~~ T4 T1 -.->|untrusted browsing| ESM2[Edge ESM] T2 -.->|modern apps| UWP[UWP / packaged apps] T3 -.->|admit/deny| SAC2[SAC + DNP] T4 -.->|on-demand detonation| WS2[Windows Sandbox]

The taxonomy is layered without being strictly linear. Read it as a four-question pipeline rather than a four-rung ladder. Tier 3 (Smart App Control + Defender network protection) decides what runs and what the device talks to -- admission, not containment. Whatever Tier 3 admits then lands inside Tier 2 (AppContainer), which constrains the binary's capabilities -- file, network, device, window, credential, and process scope. Inside that AppContainer-wrapped process, Tier 1 (ACG, CET, Edge ESM) applies process-internal mitigations that limit what a corrupted-memory exploit can do. Tier 4 (Hyper-V VM) is the last-resort kernel boundary: when the workload is hostile enough that the host kernel itself must be assumed reachable from the renderer, Windows Sandbox or a Hyper-V isolation container puts an entire NT kernel between the artifact and the user's data. WDAG used to plug a session-bound, transparent variant of Tier 4 underneath every Edge navigation; once Tier 1 hardening (ACG, CET, ESM) closed the marginal-security gap on the typical navigation, that session-bound Tier 4 paid more than it saved, and was deleted.

9. Engineering Takeaways

A few rules of thumb fall out of the architectural comparison.

Use the lowest tier whose boundary you actually need. If your threat is "this binary may try to escape the renderer," AppContainer + process mitigations suffice. If your threat is "this binary may try to escape the kernel," you need a Hyper-V partition; that means Sandbox or, for production, an isolation container. The Microsoft Servicing Criteria for Windows [@microsoft-com-servicing-criteria] lists which boundaries Microsoft commits to defending; anything not on that list is best treated as a depth-in-defense layer, not a primary boundary.

Disable shared channels first; renegotiate them only when forced. The default .wsb-less Sandbox enables networking and clipboard redirection -- per the configuration docs [@learn-microsoft-com-wsb-file], enabled networking "can expose untrusted applications to the internal network." For malware triage, build the paranoid .wsb from the snippet in section 2 and only loosen it when a specific analysis step requires it.

{` // A naive but useful decision tree. Print the recommended tier for a workload. function pickTier(workload) { const w = workload.toLowerCase(); if (w.includes("untrusted exe") || w.includes("malware")) { return "Tier 4: Windows Sandbox (on-demand, gesture-bound)"; } if (w.includes("untrusted website") || w.includes("unfamiliar site")) { return "Tier 1: Edge Enhanced Security Mode + Tier 3: Defender network protection"; } if (w.includes("untrusted document") || w.includes("office")) { return "Tier 3: Smart App Control + Office Protected View"; } if (w.includes("third-party app") || w.includes("uwp")) { return "Tier 2: AppContainer"; } return "Default: ship the workload under Tier 2 AppContainer; escalate if the threat model justifies it."; }

[ "Detonate untrusted exe from email", "Open an unfamiliar site for research", "Open an untrusted Office document", "Run a third-party packaged app" ].forEach(w => console.log(w + " -> " + pickTier(w))); `}

Avoid features whose own boundary is not a serviced boundary. A useful litmus test is to read the Microsoft Security Servicing Criteria for Windows [@microsoft-com-servicing-criteria] and ask whether the feature's own claimed isolation appears there. WDAG didn't; Hyper-V VM did. Designs that rely on a non-serviced isolation are more brittle, both technically (no bounty pressure on the boundary) and operationally (no commitment to fix integration bugs out-of-band).

Plan for deprecation of integration features, not of primitives. Microsoft retired WDAG; it did not retire HCS, Hyper-V isolation containers, or AppContainer. The primitives outlast the productizations. A codebase that depends on the primitives (calling HCS directly, wrapping a workload in AppContainer) is more durable than one that depends on a packaged feature (calling IIsolatedAppLauncher, relying on Network Isolation policy semantics) whose lifecycle is set by product economics.

Note: Workloads that traverse a Sandbox boundary leave specific telemetry. The host event log records Containers-DisposableClientVM start/stop events; HCS partition allocations are visible to ETW; mapped-folder access from inside the guest crosses a brokered channel that surfaces in host file-system filters. If an incident response playbook expects to see "Hyper-V partition created" or "container-disposable-client-vm started," those are the canonical signals from the substrate, not from Sandbox-specific telemetry.

10. Open Problems and Future Direction

The 2026 stack is good. It is not finished. Several open problems remain visible at the seams.

Transparent, gesture-priced isolation. WDAG's session-bound model failed; Sandbox's gesture-bound model is too explicit for everyday use. There is no current Windows feature that combines (a) automatic, policy-driven launch ("this URL is outside the trust zone, isolate it"), (b) Sandbox-style on-demand allocation, and (c) sub-second cold start. Each pair of those three is achievable -- WDAG had (a) and (b) but not (c); Sandbox has (b) and (c) but not (a); ESM has (a) and (c) but gives up the partition boundary. Closing all three simultaneously is the standing open problem.

Hardware-rooted attestation of the partition. Today's Hyper-V partition is anchored by VBS, which is anchored by Secure Boot, which is anchored by the platform firmware. Microsoft Pluton [@learn-microsoft-com-security-processor] -- "a secure crypto-processor built into the CPU... designed to provide the functionality of the Trusted Platform Module (TPM) and deliver other security functionality beyond what is possible with the TPM 2.0 specification" -- raises the floor on what a guest can attest about, opening a path to confidential-VM-style guarantees on the client. The shape of that integration with Sandbox is not yet public.

Confidential client VMs. On the server, Azure confidential VMs [@learn-microsoft-com-vm-overview] provide a "hardware-enforced boundary between your application and the virtualization stack" via AMD SEV-SNP and Intel TDX, with "secure key release with cryptographic binding between the platform's successful attestation and the VM's encryption keys." Whether that boundary -- guest memory unreadable by the host kernel -- ever shows up under client Windows Sandbox or Hyper-V is an open architectural question. If it does, it changes the Hyper-V VM threat model: a malicious host (or compromised host kernel) could no longer read guest memory, which would close a category of risk that currently sits outside the bounty scope.

AI-agent action containment. WDAG's specific shape -- a session-bound partition that transparently absorbed risky actions on behalf of a user -- is suggestive of an emerging problem: containing the actions of AI agents that take tool-using steps inside a user's session. Today's stack does not have a feature shaped quite like this. Sandbox is too explicit; AppContainer is too process-bound; ESM is browser-only; Smart App Control is admit/deny, not contain/observe. An "AI-agent action sandbox" would need WDAG's transparency without WDAG's resident-per-employee cost. The architectural question is whether the lessons of WDAG's retirement should make the next attempt look like Sandbox-with-a-policy-trigger or like AppContainer-with-a-stronger-boundary.

Shared-microarchitectural-state side channels. The Hyper-V VM boundary is a logical boundary. The CPU caches, branch predictors, and prefetch units are still shared with the host. Spectre-class side channels survive partition boundaries and survive confidential-VM boundaries; the canonical Meltdown/Spectre disclosure [@meltdownattack-com] frames the primitive as a class of transient-execution attacks against the shared microarchitectural state itself, and Microsoft's KB4072698 guidance for speculative-execution side-channel vulnerabilities [@support-microsoft-com-b632-0d96f30c8c8e] catalogs a long succession of advisories (ADV180002, ADV180012, ADV180018 L1TF, ADV190013 MDS, ADV220002 MMIO Stale Data, CVE-2022-23825 Branch Type Confusion, CVE-2022-0001 Branch History Injection, CVE-2023-20569 AMD Return Address Predictor) that each required Hyper-V-host mitigation to keep the partition boundary effective. Mitigations close known variants at the cost of performance, but the underlying primitive -- one core, two security domains -- does not change. The ideal sandbox -- sub-second cold start, single-digit-MB resident overhead, transparent policy launch, and a partition boundary that closes all microarchitectural channels -- remains unachievable on shared silicon. This is not a Windows-specific problem; it is the lower bound on what any client-side sandbox can deliver.

Key idea: The 2026 isolation stack is the right shape for the threats it was designed against: a malicious binary, an unfamiliar website, an untrusted document, a third-party app. It is not yet shaped for the threats that will dominate 2027 and beyond: confidential client compute, agent action containment, hardware-rooted attestation. Watching where the next partition-shaped primitive appears -- or fails to -- is how the architecture will continue to evolve.

Windows Sandbox and WDAG are the cleanest natural experiment Windows has run on Hyper-V isolation as a product. Same substrate, same partition primitive, same bounty-protected boundary; opposite lifecycle bindings, opposite threat models, opposite outcomes. The substrate survives because the substrate is the boundary; the productizations come and go because they are bets on how to spend that boundary's budget. WDAG bet on session-bound transparency and lost to a cheaper process-mitigation stack; Sandbox bet on gesture-bound disposability and remains the right answer for the workload it was designed for. The story is less about Hyper-V and more about lifecycle: when you allocate isolation matters as much as how much isolation you allocate.

AppContainer and LowBox Tokens: Windows's Capability Sandbox

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

Windows's modern application sandbox rests on a single kernel primitive (*AppContainer / LowBox*) that Microsoft preserved under two names: *LowBox* inside the kernel and the `NtCreateLowBoxToken` syscall, *AppContainer* in the public API. One bit in `_TOKEN.Flags`, two new SID alphabets (`S-1-15-2-*` for packages, `S-1-15-3-*` for capabilities), and a per-package partition of the Object Manager namespace let `SeAccessCheck` give two co-tenanted processes opposite verdicts. UWP apps, MSIX-packaged desktop apps, Microsoft Edge LPAC renderers, and Windows Sandbox all rest on this primitive. James Forshaw's twelve-year exploit-research line shaped its current hardening.

1. Two Calculators

Open calc.exe on a stock Windows 11 25H2 installation. It is the Microsoft Store calculator, the UWP one, the one Windows ships in the default Start menu. Now download the legacy win32calc.exe from a Windows 7 image and run it side by side. Same user. Same machine. Same disk, same DACLs on every file in your profile. The Mandatory Integrity Control label on %USERPROFILE%\.ssh\id_ed25519 is the default Medium for both processes' access checks.

Yet win32calc.exe can read the SSH private key, and calc.exe cannot. If you open both processes in Sysinternals Process Explorer and compare the Security tab side by side, every field that the classic Windows NT token model exposes looks identical. User SID: identical. Logon ID: identical. Primary group: identical. Privileges: identical. Even the integrity level, by the read path, looks the same on the user's profile files.

The difference is one bit. In the kernel's _TOKEN structure, the TOKEN_LOWBOX flag (SDK constant value 0x4000, the 15th bit of the TokenFlags word) is set on the UWP calc.exe token and clear on win32calc.exe [@nostarch-wsi]. Microsoft's documentation calls the resulting token an AppContainer token; the kernel call that creates it preserved the older marketing name. "AppContainer was originally named LowBox (prior to the release of Windows 8). That legacy name can be seen in API names such as NtCreateLowBoxToken" [@ms-learn-legacy].

AppContainer was originally named _LowBox_ (prior to the release of Windows 8). That legacy name can be seen in API names such as **NtCreateLowBoxToken**. -- Microsoft Learn The public-API name for a kernel-enforced per-application sandbox introduced in Windows 8 [@ms-learn-legacy]. An AppContainer process runs under a *LowBox token*, a special access token whose `LowBoxToken` flag, package SID, capability SIDs, and per-instance number cause the Security Reference Monitor to apply additional access-check rules beyond the classic user-and-groups DACL walk. The kernel-internal name *LowBox* is preserved in `NtCreateLowBoxToken` and several adjacent symbol names [@ms-learn-ntcreatelowboxtoken].

If you read the eight sub-authorities of the Calculator's package SID -- something like S-1-15-2-466767348-3739614953-2700836392-... (the trailing five sub-authorities are elided here) -- you are reading a deterministic SHA-256 hash of the package family name, sliced into eight 4-byte 32-bit sub-authorities [@ms-learn-derivesid] [@nostarch-wsi]. Every Windows 11 machine in the world derives the same SID for Microsoft.WindowsCalculator_8wekyb3d8bbwe, and DACLs on the per-package data directories name precisely that SID. Section 5 will walk this in detail; for now, notice that the SID alphabet starts with S-1-15-2, not the familiar S-1-5-21 of user SIDs. Microsoft introduced two new SID prefixes in Windows 8: S-1-15-2-* for packages and S-1-15-3-* for capabilities. Both live in identifier authority 15, the App Package Authority [@ms-learn-well-known-sids].

flowchart TD A[User Alice opens id_ed25519] --> B{"Is _TOKEN.Flags.LowBoxToken set?"} B -->|"No (win32calc.exe)"| C[Classic SeAccessCheck
against user + groups] B -->|"Yes (UWP calc.exe)"| D[LowBox access path
add Package SID and
Capability claims to check] C --> E[Read allowed] D --> F[Read denied:
no fs:documentsLibrary capability]

The question that opens this article is the same one Windows NT 3.1 could not ask in July 1993: two processes, same user, same DACLs, how does the kernel give them different verdicts? For nineteen years it could not. The answer Microsoft shipped on October 26, 2012 is the LowBox token, and we will trace one coherent primitive from its Vista-era ancestors through the four production deployments that exercise it on every Windows 11 machine in 2026. We will end with the exploit history that shaped its current hardening. The story starts on January 30, 2007, with a single browser, a single bit, and a structural defect Microsoft spent the next fourteen years repairing.

2. The Internet Explorer 7 Protected Mode Era

By the time Windows Vista went generally available on January 30, 2007 [@wiki-vista], a large majority of home Windows installs ran day-to-day under administrator accounts. The Wikipedia summary of User Account Control captures the pre-Vista status quo plainly: in Windows 1.0 through Windows 9x, "all applications had privileges equivalent to the operating system" [@wiki-uac]. One browser exploit equalled total compromise of the user profile, and Internet Explorer 6 from 2001 was the single largest pathway between hostile content and the desktop.

Vista's response had two halves. The first was User Account Control, the split-token model that asks the user to consent before promoting a Medium-integrity process to High. The second was Mandatory Integrity Control (MIC), the labelling primitive UAC depended on. MIC defined four integrity levels with their own SIDs: Low (S-1-16-4096), Medium (S-1-16-8192), High (S-1-16-12288), and System (S-1-16-16384) [@wiki-mic]. The Security Reference Monitor checks the label before the DACL; a label deny short-circuits the access check.

A Windows Vista security mechanism that adds an *integrity level* to every process and every securable object [@ms-learn-mic]. Levels are System, High, Medium, and Low; objects carry a `SYSTEM_MANDATORY_LABEL_ACE` in their SACL declaring a minimum integrity level for access. By default the system creates every object with an access mask of `SYSTEM_MANDATORY_LABEL_NO_WRITE_UP`, which prevents lower-IL writers from modifying higher-IL objects but does not block reads.

The four MIC integrity-level SIDs are spaced at 0x1000-unit increments, the consecutive SECURITY_MANDATORY_*_RID constants in winnt.h: Low S-1-16-4096 (0x1000), Medium S-1-16-8192 (0x2000), High S-1-16-12288 (0x3000), System S-1-16-16384 (0x4000) [@wiki-mic]. They are in identifier authority 16, the Mandatory Label Authority.

Internet Explorer 7, which had shipped on October 18, 2006 [@wiki-ie7], became MIC's first marquee consumer. IE 7's Protected Mode launched the renderer at Low integrity, where it could not write to %USERPROFILE% (Medium IL by default) or to HKLM. A separate Medium-IL broker process named ieuser.exe accepted COM requests from the renderer and performed privileged work on its behalf -- saving downloads, writing to non-Low locations -- only for operations the policy allowed. The renderer's private workspace lived at %USERPROFILE%\AppData\LocalLow\ and the corresponding Low-IL temporary internet files [@ie7-protected-mode-mirror]. Marc Silbey and Peter Brundrett documented the design on MSDN. The MSDN article is preserved at a third-party mirror today; the original Microsoft path retired with the IE developer area.

The structural pattern was complete. A sandboxed worker process and a higher-privilege broker that re-elevates only the operations the policy permits is the topology of every later Windows-side capability sandbox.The same broker / target pattern reappears under several names: RuntimeBroker.exe for UWP, AppInfo for UAC consent prompts, PrintWorkflowUserSvc for print, and the WebAuthn and voice-activation brokers for those WinRT capabilities. Each is structurally ieuser.exe for a different resource. AppContainer's RuntimeBroker.exe is structurally the same idea as ieuser.exe. AppInfo (the UAC consent broker), the Print broker, the WebAuthn broker, and the voice-activation broker all share the lineage. Chromium's own broker / target sandbox, which we will meet in §3, was published less than two years later on the same conceptual base.

So far so good. But Protected Mode had three structural defects, and each one mapped one-to-one to a specific Windows 8 fix five years later.

Defect one: read-up was not blocked by default. The default mandatory-label ACE was SYSTEM_MANDATORY_LABEL_NO_WRITE_UP. A Low-IL process could not write to Medium-IL objects, but it could read them. The Microsoft Learn page on MIC is explicit: "the system creates every object with an access mask of SYSTEM_MANDATORY_LABEL_NO_WRITE_UP" [@ms-learn-mic]. Unless the object explicitly carried a NO_READ_UP mandatory ACE -- which %USERPROFILE%\.ssh\id_ed25519 did not -- a compromised Low-IL IE could read the user's SSH keys, browser passwords, OAuth refresh tokens, and any other Medium-IL secret. The Chromium sandbox FAQ flags the same observation: Vista's integrity levels were the only user-mode separation primitive available, and Chromium built a layered user-mode sandbox on top precisely because Vista's separation was insufficient [@chromium-sandbox-faq].

Note: A NO_WRITE_UP boundary is an integrity boundary, not a confidentiality boundary. It stops a low-trust process from corrupting your data, but it does not stop it from reading your data. For a browser renderer that processes hostile content, confidentiality is the load-bearing axis: the attacker's goal is exfiltration, not corruption. Without NO_READ_UP, MIC alone could not contain a renderer compromise [@ms-learn-mic].

Defect two: identity was shared across instances. Two Low-IL IE renderers ran with the same Low-IL SID and the same user SID. They could open handles to each other's named objects, shared memory sections, and process tokens. Integrity level is an axis; it is not a per-instance principal.

Defect three: network access was unconstrained. A Low-IL process could open any socket to any host. The Vista firewall was the freshly-introduced Windows Filtering Platform, but WFP had no notion of "which app is this" at all. As James Forshaw later put it on the Project Zero blog, "Prior to XP SP2 Windows didn't have a built-in firewall... While XP SP2 introduced the built-in firewall, the basis for the one used in modern versions of Windows was introduced in Vista as the Windows Filtering Platform (WFP)" [@p0-network]. WFP's per-application-package callout came years later, and the corresponding condition value FWPM_CONDITION_ALE_PACKAGE_ID did not exist in 2007.

Each defect became a specific Windows 8 mechanism. Defect one became the per-package namespace redirect plus the LowBox flag's NO_READ_UP-by-construction effect on cross-package reads. Defect two became the AppContainerNumber per-instance key. Defect three became the WFP capability gate. Microsoft and Google looked at the same Vista primitives and reached opposite conclusions. Google built a user-mode sandbox on top of NT. Microsoft built a per-app principal inside the NT token. The next two sections walk both branches.

3. Same Idea, Four Directions

Between January 2007 and October 2012, four different teams reached the same conclusion from four different starting points: the kernel needs a per-application principal, not just a per-user one. They built it in four different places.

Chromium sandbox, December 2008. When Chrome 1.0 shipped on Windows in December 2008, it carried a layered user-mode sandbox: a broker process plus a target process, a restricted token derived from the user's token, a job object that limited the target's syscall surface, and (on Vista and later) the Low integrity level on the target. The Chromium sandbox design document spells out the rule that defined the choice. "Do not re-invent the wheel: It is tempting to extend the OS kernel with a better security model. Don't. Let the operating system apply its security to the objects it controls" [@chromium-sandbox]. The reasoning continues in the FAQ. "the sandbox cannot provide any protection against bugs in system components such as the kernel it is running on" [@chromium-sandbox-faq]. The Chromium design was a user-mode-only sandbox, layered on top of NT primitives that already existed.

Google Native Client, 2009. Bennet Yee and co-authors at Google published Native Client: A Sandbox for Portable, Untrusted x86 Native Code at IEEE S&P 2009 [@nacl-ieee]. NaCl declared its capabilities at launch and structurally inverted the question: rather than retrofit a sandbox onto an application, run untrusted code only with capabilities the host has explicitly granted. The Wikipedia retrospective records NaCl's eventual replacement by WebAssembly [@wiki-nacl], but the design idea -- capability-declared-at-launch -- prefigured what Microsoft would call SECURITY_CAPABILITIES.Capabilities[] three years later.

Apple iOS application sandbox, 2007 onward. iPhone OS 1.0 (June 29, 2007) shipped with a kernel-side TrustedBSD-derived MAC sandbox that confined Apple's own built-in apps [@apple-platform-security-app]. The developer-facing surface -- third-party apps, Bundle IDs, Team IDs, and the entitlements dictionary -- arrived with iPhone OS 2.0 in July 2008 alongside the public App Store [@apple-platform-security-app]. From 2008 onward the per-app principal had two halves: a Bundle ID (a string the developer picks, structurally like a Windows Package Family Name) and a Team ID (the signer). Each app's profile lived at Containers/Data/Application/<bundle-uuid>/, structurally similar to Windows's later %LOCALAPPDATA%\Packages\<PFN>\. The capability set was an *entitlements dictionary* signed into the app bundle, structurally similar to Windows's later <Capabilities> element.

Android per-app UID, September 23, 2008. When Android 1.0 shipped on the T-Mobile G1 on September 23, 2008 [@wiki-android], it carried the most parsimonious solution: each app got its own UNIX UID. Classical Unix discretionary access control did the rest. Where Windows extended the SID alphabet, Android extended the UID allocation policy. The Android Application Sandbox page records the additional MAC layers Android added in later releases -- SELinux from Android 5.0 onward, seccomp-bpf from Android 8.0 onward, and per-physical-user partitions [@android-app-sandbox]. The kernel principal stayed a Unix UID.

Crispin Cowan, Jan 17, 2008. Between the Vista release and the eventual Windows 8 ship, the person who would write Microsoft's answer arrived on the security team. Crispin Cowan, the StackGuard co-author whose 1998 USENIX paper coined the term stack canary [@stackguard], joined the Microsoft Windows security team in January 2008. ZDNet's coverage of the hire reads: "Crispin Cowan, the Linux security expert behind StackGard [sic], the Immunix Linux distro and AppArmor, has joined the Windows security team... Crispin will join the team that worked on User Account Control" [@zdnet-cowan]. Cowan's later USENIX Security 2013 keynote Windows 8 Security: Supporting User Confidence credits him with the AppContainer design [@cowan-usenix13], and his University of Waterloo speaker page makes the attribution explicit: "From 2008 to 2017, Dr. Cowan was with Microsoft, where he designed the App Container sandbox that is used by the Edge and Chrome web browsers, Microsoft Office, and Windows 10 to contain Universal Windows Apps" [@crysp-cowan].

The four mechanisms compare like this:

Year	Operating system	Principal name	How it is named	How it is enforced
2007	iOS	Bundle ID + Team ID (from 2008)	Developer string + signer	Mandatory per-app MAC + entitlements
2008	Chromium on Windows	(none, user UID only)	User SID + restricted token	User-mode broker + job object + IL
2008	Android	Per-app UNIX UID	UID allocated at install	Classical Unix DAC + SELinux + seccomp
2012	Windows 8	Package SID + Capability SIDs	Deterministic SHA-2 of moniker	Kernel access token + WFP + Object Manager

Each design carries the same *intent* -- give the kernel a per-application principal -- and locates it differently. iOS keeps the per-app *policy data* (entitlements plus `.sb` profiles) in the code-signed bundle and enforces it mandatorily in the kernel via the TrustedBSD-derived `Sandbox.kext`, with no opt-out. Android puts the principal in the UID space the Unix kernel already understood, so existing DAC plumbing did the work. Chromium kept the principal *outside* the kernel entirely, layering a user-mode policy on top of the existing user-keyed access check. Microsoft did the structurally rarest thing: it extended the kernel's access token data structure. The other three retrofitted the principal on top of an existing access-check pipeline; Windows extended the pipeline itself. The next section walks why Microsoft picked option four.

The name LowBox is itself a vestige of Microsoft's internal marketing process. The Win32 surface chose AppContainer in time for Windows 8's general availability; the kernel surface had already shipped under the older name. Microsoft Learn confirms the lineage in plain prose [@ms-learn-legacy], and the syscall NtCreateLowBoxToken preserves it.

Microsoft had a choice: build a user-mode policy daemon like Apple, extend the user-keyed principal like Android, or keep everything in user mode like Chromium. The team chose the fourth option and extended the kernel access token. The next section walks how, year by year, that decision matured.

4. The Evolution, Generation by Generation

The Windows 8 ship on October 26, 2012 [@wiki-win8] [@win8-rtm] was not the end of the story. It was the start of a six-generation refinement that continues into 2026 Windows 11 25H2. The seven generations look like this on a timeline.

gantt title Per-application sandbox primitives in Windows dateFormat YYYY-MM axisFormat %Y section Gen 0 Classic NT user-token model :done, g0, 1993-07, 33y section Gen 1 MIC plus IE 7 Protected Mode :done, g1, 2007-01, 19y section Gen 2 Chromium broker target sandbox :done, g2, 2008-12, 18y section Gen 3 AppContainer LowBox token :done, g3, 2012-10, 14y section Gen 4 Less Privileged AppContainer :done, g4, 2016-08, 10y section Gen 5 MSIX TrustLevel appContainer :done, g5, 2018-11, 8y section Gen 6 Windows Sandbox plus Hyper-V :done, g6, 2019-05, 7y

4.1 Generation 0: The classic NT user-token model (1993)

Dave Cutler's Windows NT 3.1 shipped in July 1993 with a security model that is still the foundation in 2026. Every process has an access token. The token carries User, Groups[], Privileges[], and a DefaultDacl. Every securable object has a security descriptor with a DACL. SeAccessCheck walks the DACL access control entry by access control entry against the caller's user and group SIDs. Identity equals authority: if process A and process B both run as Alice, they are the same principal to the kernel. Whatever Alice can do, both of them can do. Chapter 7 of the seventh-edition Windows Internals [@ms-press-wi7] gives the canonical post-LowBox reference for this data structure.

This model has no answer to the single-user, multi-application threat. A user's text editor and a user's browser are indistinguishable principals. Bridge: the next generation tried to fix that by adding an axis, not a principal.

4.2 Generation 1: IE 7 Protected Mode plus MIC (Vista, 2007)

We already walked the mechanism in §2. Mandatory Integrity Control shipped with Vista's general availability on January 30, 2007 [@wiki-vista] [@wiki-mic]. Internet Explorer 7's Protected Mode launched its renderer at Low integrity with a Medium-IL ieuser.exe broker [@wiki-uac] [@ie7-protected-mode-mirror]. The Wikipedia article on MIC names IE 7 as the marquee consumer: "Internet Explorer 7 introduces a MIC-based 'Protected Mode' setting" [@wiki-mic]. Bridge: integrity level is an axis, not a principal. Two Low-IL processes share identity.

4.3 Generation 2: The Chromium broker / target sandbox (Chrome, 2008)

The parallel path Microsoft did not take. Chromium's design document calls the architecture explicitly: "The Windows sandbox is a user-mode only sandbox" [@chromium-sandbox]. The two-process structure is named: "The minimal sandbox configuration has two processes: one that is a privileged controller known as the broker, and one or more sandboxed processes known as the target" [@chromium-sandbox]. The FAQ adds the integrity-level note: the sandbox "uses integrity levels" on Vista and later, and the only Vista-era application the FAQ knows about that used them was Internet Explorer 7 [@chromium-sandbox-faq]. Bridge: who is this app? remains unanswered in any user-mode-only design.

Do not re-invent the wheel: It is tempting to extend the OS kernel with a better security model. Don't. Let the operating system apply its security to the objects it controls. -- Chromium sandbox design document [@chromium-sandbox]

The pull quote is the most interesting sentence in the article so far, because Microsoft -- which was the operating system vendor -- did exactly the opposite four years later, and shipped AppContainer the same year (2012) Chrome 22 hit the desktop with its user-mode-only sandbox. The two browsers' modern descendants now run both designs simultaneously, but we are getting ahead of ourselves.

4.4 Generation 3: AppContainer / LowBox token (Windows 8, October 26, 2012)

This is the keystone. Microsoft made three structural extensions to the NT access-token model.

First, two new SID alphabets. The App Package Authority (identifier authority 15) carries Package SIDs at S-1-15-2-* and Capability SIDs at S-1-15-3-* [@ms-learn-well-known-sids]. A Package SID is a deterministic SHA-2-derived identifier for a specific package; a Capability SID names a permission the package declared in its manifest. Microsoft's DeriveAppContainerSidFromAppContainerName API takes a moniker string and returns the corresponding Package SID [@ms-learn-derivesid], which means every Windows 11 machine derives the same S-1-15-2-* for Microsoft.WindowsCalculator_8wekyb3d8bbwe.

Second, a per-package partition of the Object Manager namespace. Every LowBox process's references to global named objects under \BaseNamedObjects are rewritten by the Object Manager to land in \Sessions\<n>\AppContainerNamedObjects\<package-sid>\ and its RPC Control sub-directory. The kernel captures handles to these directories at token-creation time and uses them at name-lookup time; the rewrite is invisible to the application code. We will name the exact field that holds the handles in §5.

Third, an always-Low integrity level. Microsoft Learn states the rule plainly: "if you are in an app container, then the integrity level (IL) is always low" [@ms-learn-legacy]. The AppContainer flag is orthogonal to integrity level, but AppContainer membership forces the integrity level to Low. Two co-tenanted AppContainer processes can therefore both write to \Sessions\<n>\AppContainerNamedObjects\<package-sid>\ (their per-package directory is owned by the package SID) but neither can write to a Medium-IL object outside.

The kernel surface is NtCreateLowBoxToken [@ms-learn-ntcreatelowboxtoken]. Its nine-parameter signature -- the existing token, the desired access, an OBJECT_ATTRIBUTES parameter, the package SID, a capability count and array, a handle count and array -- is the literal data plane for everything we just described. The Win32 surface is CreateAppContainerProfile [@ms-learn-createprofile], DeriveAppContainerSidFromAppContainerName [@ms-learn-derivesid], the SECURITY_CAPABILITIES struct [@ms-learn-security-capabilities], and the PROC_THREAD_ATTRIBUTE_SECURITY_CAPABILITIES attribute key that UpdateProcThreadAttribute accepts [@ms-learn-updateprocthread]. All five APIs share the same minimum supported client: Windows 8 desktop applications [@ms-learn-ntcreatelowboxtoken] [@ms-learn-createprofile] [@ms-learn-security-capabilities].

The corresponding access-check rule is also explicit. Microsoft Learn formalises the dual-principal intersection: "the permitted access is the intersection of that granted by the user/group SIDs and AppContainer SIDs" [@ms-learn-implementing]. We will walk this five-step check field by field in §5.

sequenceDiagram participant App as Launcher (Medium IL) participant W32 as Win32 surface participant K as Kernel App->>W32: CreateAppContainerProfile(name, caps) W32-->>App: package SID, profile root App->>W32: InitializeProcThreadAttributeList App->>W32: UpdateProcThreadAttribute (PROC_THREAD_ATTRIBUTE_SECURITY_CAPABILITIES) App->>W32: CreateProcess(STARTUPINFOEX) W32->>K: NtCreateLowBoxToken(parent, caps, handles) K-->>K: set _TOKEN.Flags.LowBoxToken, stamp PackageSid, Capabilities, assign AppContainerNumber K-->>W32: new token handle W32-->>App: PROCESS_INFORMATION Note over K: Every later SeAccessCheck consults the new flag and fields.

Three motivations drive the next three generations. The ALL_APP_PACKAGES group SID grants every AppContainer ambient access to a broad default-installed surface; tighter deny-by-default needs the LPAC variant. Win32 applications cannot opt in without source changes; MSIX brings them in via manifest. Kernel exploits bypass the boundary entirely; Windows Sandbox wraps the boundary in Hyper-V.

The implementation correctness motivations are equally specific. James Forshaw's Raising the Dead post on Project Zero in January 2016 walked an issue (P0 Issue 483) in the original NtCreateLowBoxToken plumbing that, in his own words, looked "on the surface" like at best a local denial of service but turned out to be an elevation of privilege [@p0-raising-dead]. "The root cause of the vulnerability is the NtCreateLowBoxToken system call introduced in Windows 8 to support the creation of locked down tokens for Immersive Applications (formerly known as Metro) as well as IE11's Enhanced Protected Mode" [@p0-raising-dead]. Microsoft patched the issue in bulletin MS15-111 on October 13, 2015. NVD records the specific CVE within MS15-111 that mapped to Forshaw's writeup as CVE-2015-2554, "Windows Object Reference Elevation of Privilege Vulnerability" [@nvd-cve-2015-2554]. Three years later, Forshaw's Windows Exploitation Tricks: Exploiting Arbitrary Object Directory Creation post (P0 Issue 1550, August 2018) found a related bug in the AppInfo service's helper API: "The AppInfo service, which is responsible for creating the new application, calls the undocumented API CreateAppContainerToken to do some internal housekeeping. Unfortunately this API creates object directories under the user's AppContainerNamedObjects object directory to support redirecting BaseNamedObjects and RPC endpoints by the OS" [@p0-1550]. The directory was created "with an explicit security descriptor which allows the user full access" [@p0-1550], and a user-controlled symbolic link in the target could redirect the directory creation almost anywhere in the namespace.

Forshaw's two P0 writeups in 2016 and 2018 are textbook cases of *correct primitive, incorrect implementation*. The LowBox flag, the package SID, and the namespace partition are sound. The bugs were in adjacent code -- the kernel's reference-counting on handles passed to `NtCreateLowBoxToken` (Issue 483, fixed in MS15-111 as CVE-2015-2554 [@nvd-cve-2015-2554]) and the AppInfo service's overly permissive directory creation under `\AppContainerNamedObjects` (Issue 1550 [@p0-1550]). The lesson is that being *in the kernel* is not the same as being *correct in the kernel*. Forshaw's parallel work on the Diagnostics Hub Standard Collector Service -- "we'll call it DiagHub for short" [@p0-arbitrary-write-2018] -- belongs to the same class: brokers and helpers near the AppContainer boundary have repeatedly been the exploitable seams.

Bridge: ambient access via ALL_APP_PACKAGES motivates the next generation.

4.5 Generation 4: Less Privileged AppContainer (LPAC) (Windows 10 1607, August 2, 2016)

LPAC is one of the most parsimonious changes in the AppContainer chain. Microsoft introduced a synthetic capability with the SID prefix WIN://NOALLAPPPKG; when this capability is present in the new token's Capabilities[] array, the kernel omits the ALL_APP_PACKAGES group SID from the new token. The Windows 10 1607 Anniversary Update was where the mechanism shipped [@wiki-win10-versions]. Microsoft Learn defines LPAC plainly: "Less Privileged AppContainers (LPAC) are even more isolated than regular AppContainers and require further capabilities to gain access to resources that regular AppContainers already have access to such as the registry, files, and others. For example, LPAC cannot open any keys in the registry unless it has the registryRead capability and cannot use COM unless it has the lpacCom capability" [@ms-learn-implementing].

The Chromium repository carries the most explicit user of this surface today. sandbox/policy/win/lpac_capability.h enumerates the LPAC capability constants Chromium passes to its renderer / utility / network-service / GPU process tokens: kLpacChromeInstallFiles, kLpacAppExperience, kLpacCom, kLpacCryptoServices, kLpacEnterprisePolicyChangeNotifications, kLpacIdentityServices, kLpacInstrumentation, kLpacMedia, kLpacPnPNotifications, kLpacPnpNotifications, kLpacServicesManagement, kLpacSessionManagement, kRegistryRead, and several Media Foundation-specific constants [@chromium-lpac]. Microsoft Edge, the Chromium-based rebase Microsoft published on January 15, 2020 [@edge-chromium-ga], inherited all of them. The policy RendererAppContainerEnabled documents the Edge consumer specifically: "Launches Renderer processes into an App Container for more security benefits... If you enable this policy, Microsoft Edge launches the renderer process in an app container", available on Windows ≥ 96 [@ms-learn-edge-lpac].

Bridge: LPAC is still a user-mode boundary. A kernel exploit still bypasses it.

4.6 Generation 5: MSIX TrustLevel = appContainer (Windows 10 1809, November 13, 2018)

The Windows 10 October 2018 Update [@wiki-win10-versions] shipped MSIX with an explicit manifest opt-in for AppContainer. The MSIX schema page documents the two values uap10:TrustLevel may take: "mediumIL" and "appContainer" [@ms-learn-manifest-app]. There are exactly two trust levels, not three. The widely-stated "third trust level" of runFullTrust is in fact a restricted capability that a mediumIL package may declare under its <Capabilities> element to register out-of-process COM and similar legacy-Win32 mechanisms [@ms-learn-capabilities]. Microsoft Learn's MSIX container migration page walks the conversion explicitly, showing the manifest going from <rescap:Capability Name="runFullTrust" /> to uap10:TrustLevel="appContainer" [@ms-learn-msix-container]. The Wikipedia article on App Installer (which MSIX redirects to) records the App Installer tool's introduction in the Windows 10 1607 Anniversary Update; the MSIX format itself debuted with Windows 10 1809 in 2018 [@wiki-msix].

For developers, the win is that the MSIX deployment stack does all the LowBox plumbing on the application's behalf at install. The application binary itself does not change; the manifest changes, and the App Installer pipeline derives the package SID, creates the profile, and registers the per-package directories.

Bridge: still a user-mode boundary; many packaged apps stay at mediumIL plus runFullTrust.

4.7 Generation 6: Windows Sandbox = AppContainer + Hyper-V (Windows 10 1903, May 21, 2019)

Microsoft announced Windows Sandbox on the Tech Community blog as "a new lightweight desktop environment tailored for safely running applications in isolation" [@windows-sandbox-announce]. It shipped in the Windows 10 May 2019 Update [@win10-1903-ga] [@wiki-win10-versions]. Three architectural primitives carry the design.

The first is the Dynamic Base Image, the pristine read-only file set the sandbox's guest kernel boots from. Microsoft Learn describes its character: "Most OS files are immutable and can be freely shared with Windows Sandbox. A small subset of operating system files are mutable and can't be shared, so the sandbox base image contains pristine copies of them" [@ms-learn-sandbox-arch]. Footprint figures from the same page: "Before Windows Sandbox is installed, the dynamic base image package is stored as a compressed 30-MB package. Once installed, the dynamic base image occupies about 500 MB of disk space" [@ms-learn-sandbox-arch].

The second is direct-map memory sharing. "when ntdll.dll is loaded into memory in the sandbox, it uses the same physical pages as those pages of the binary when loaded on the host" [@ms-learn-sandbox-arch]. Read-only host code does not get re-paged into guest memory; the guest's virtual address space simply maps to the same physical frames.

The third is the host-side AppContainer wrap. The host-side container manager has been reported in security-research write-ups to itself run in a LowBox token, though Microsoft's published Windows Sandbox architecture documentation describes only the Hyper-V partition boundary. The actual containment boundary is the Hyper-V partition: Microsoft Learn's overview is explicit. The sandbox "relies on the Microsoft hypervisor to run a separate kernel that isolates Windows Sandbox from the host" [@ms-learn-sandbox-overview]. A kernel exploit inside the sandbox kernel does not reach the host kernel, because the host kernel is on the other side of the Type-1 hypervisor partition.The 30 MB compressed / 500 MB installed Dynamic Base Image figures come from the Microsoft Learn architecture page [@ms-learn-sandbox-arch]; the "few seconds to launch" wall-clock figure and the "data persists through restarts initiated within the sandbox" Windows 11 22H2 persistence behaviour are from the overview page [@ms-learn-sandbox-overview]. The persistence behaviour explicitly excludes Windows Home edition.

Bridge: WDAG (the per-tab Edge variant of Hyper-V isolation) was retired in Windows 11 24H2. Per-app Hyper-V isolation is no longer the Microsoft direction. Microsoft Defender Application Guard's overview page documents the retirement: "Microsoft Defender Application Guard, including the Windows Isolated App Launcher APIs, is deprecated for Microsoft Edge for Business and will no longer be updated"; "Starting with Windows 11, version 24H2, Microsoft Defender Application Guard, including the Windows Isolated App Launcher APIs, is no longer available" [@ms-learn-mdag].

Gen	Year	Key idea	What it added	Failure that motivated the next
0	1993	Identity equals authority	Classic NT access token	Cannot distinguish two apps as same user
1	2007	Add a mandatory label	Integrity levels, broker pattern	NO_READ_UP missing; shared identity
2	2008	Sandbox in user mode	Broker / target, restricted token	No per-app principal in the kernel
3	2012	Per-app SID alphabets	LowBox flag, package and capability SIDs	ALL_APP_PACKAGES is broad; Win32 cannot opt in
4	2016	Deny-by-default	WIN://NOALLAPPPKG strips ALL_APP_PACKAGES	Still user-mode; not auto-applied to Win32
5	2018	Manifest opt-in for Win32	MSIX TrustLevel="appContainer"	Still user-mode; kernel exploit bypasses
6	2019	Hyper-V isolation wrap	Dynamic Base Image + direct-map	Per-app HV not the direction (WDAG retired)

By 2026 a single Edge browser instance runs the host UI at Medium IL (Gen 0), uses MIC labels (Gen 1), runs a broker / target architecture (Gen 2), launches renderers as LowBox tokens (Gen 3) with WIN://NOALLAPPPKG (Gen 4), is itself an MSIX-packaged app (Gen 5), and can be invoked inside Windows Sandbox (Gen 6). The chain is layered, not successive. The next section opens the LowBox token in WinDbg and walks the five token-level fields that produce these behaviours.

5. The Five Token-Level Fields

If you load WinDbg on a Windows 11 25H2 kernel debugging session and inspect the access token of a UWP calc.exe process with !token, then do the same for a plain notepad.exe, the differences cluster in five fields. Four of them are pointer-valued; one of them is a single bit. Three of them are public in Microsoft's winnt.h-adjacent surface. Two are internal field names that Alex Ionescu reverse-engineered in his Black Hat USA 2015 talk Battle of SKM and IUM: How Windows 10 Rewrites OS Architecture [@ionescu-bh15], and that James Forshaw walks systematically in his 2024 No Starch Press book Windows Security Internals [@nostarch-wsi].

5.1 `_TOKEN.Flags.LowBoxToken` -- the bit

The bit. The kernel's _TOKEN.Flags word carries a LowBoxToken bit that NtCreateLowBoxToken sets and that no later operation modifies [@nostarch-wsi]. Every kernel access-check path consults this bit when deciding which evaluation rules to apply. If the bit is clear, the token is a classic NT user token and SeAccessCheck proceeds in the 1993 way. If the bit is set, the kernel adds the package-SID claim check, the capability-claim check, and the namespace redirect that we will walk in §5.2 through §5.5.

Key idea: The bit in _TOKEN.Flags.LowBoxToken is what tells the kernel to evaluate the per-app principal alongside the per-user principal. Everything else in the LowBox token is bookkeeping for that decision.

The other four fields are the bookkeeping.

5.2 `_TOKEN.PackageSid` -- the package principal

PackageSid is a PSID field in the kernel token structure that carries the S-1-15-2-* SID for the package. The Microsoft surface calls it the AppContainer SID. It is the per-application principal the kernel's access-check path checks DACL entries against. When you mount a per-package ACL like the one in %LOCALAPPDATA%\Packages\Microsoft.WindowsCalculator_8wekyb3d8bbwe\ and find an access control entry naming S-1-15-2-466767348-3739614953-2700836392-..., that ACE is allowing or denying exactly the LowBox process whose PackageSid matches.

A `PSID` value with the prefix `S-1-15-2-` derived deterministically by SHA-2 hash from the package's family name and used as the *per-application principal* in DACL evaluations against AppContainer processes [@ms-learn-derivesid]. The same package family name produces the same Package SID on every Windows 8 or later machine, which is why per-package directories on disk can be ACL'd to a known SID at install time. The 32-bit sub-authorities are sequential 4-byte slices of the underlying hash.

The signature of DeriveAppContainerSidFromAppContainerName confirms the derivation is intended to be deterministic and reproducible [@ms-learn-derivesid]: "Gets the SID of the specified profile", with a Windows 8 minimum supported client. The reverse direction -- start from a Package SID and recover the moniker -- is not feasible without the inverse hash, which is by construction infeasible.

5.3 `_TOKEN.Capabilities[]` -- the per-capability claim array

Capabilities[] is a kernel array of SID_AND_ATTRIBUTES structures, populated by NtCreateLowBoxToken from the Capabilities parameter the caller passes [@ms-learn-ntcreatelowboxtoken]. Each capability SID lives in the S-1-15-3-* alphabet [@ms-learn-well-known-sids] and represents a specific permission the package declared in its manifest [@ms-learn-capabilities]. Each capability is checked by the relevant resource manager: the Windows Filtering Platform checks the internetClient capability SID for outbound network packets, the Object Manager checks namespace capabilities for the per-package directories, the contacts WinRT broker checks the contactsLibrary capability SID against the contacts ACL.

A `PSID` value with the prefix `S-1-15-3-` representing a per-package permission [@ms-learn-well-known-sids]. Capability SIDs are stamped into a LowBox token's `Capabilities[]` array at process creation and consulted by the kernel callout, broker, or kernel access-check path that gates the corresponding resource [@ms-learn-implementing]. The capability vocabulary is open-ended: standard Microsoft-defined capabilities such as `internetClient` coexist with developer-defined custom capabilities and Chromium's `Lpac*` synthetic constants.

Microsoft Learn's AppContainer-implementation page formalises the dual-principal access rule for these fields with the same intersection wording quoted in §4.4: the granted access is the intersection of what the user / group SIDs allow and what the AppContainer SIDs allow [@ms-learn-implementing]. The capability-claim check fails closed: a capability the manifest did not declare is not in Capabilities[], the kernel callout does not find a matching claim, and the access fails.

Selected capability SIDs and the resources they gate look like this.

Capability	What it gates	Source
`internetClient`	Outbound TCP/UDP via WFP callout	[@ms-learn-capabilities]
`internetClientServer`	Inbound + outbound network	[@ms-learn-capabilities]
`picturesLibrary`	Read access to user's Pictures library	[@ms-learn-capabilities]
`documentsLibrary`	Restricted; access to user Documents	[@ms-learn-capabilities]
`enterpriseAuthentication`	Restricted; Kerberos authentication	[@ms-learn-capabilities]
`microphone`	Audio input device	[@ms-learn-capabilities]
`webcam`	Video input device	[@ms-learn-capabilities]
`location`	Geolocation API	[@ms-learn-capabilities]
`runFullTrust`	Restricted; opt-out of AppContainer for mediumIL packages	[@ms-learn-capabilities]
`WIN://NOALLAPPPKG`	Strip ALL_APP_PACKAGES from token (LPAC)	[@ms-learn-implementing] [@chromium-lpac]
`lpacCom`	LPAC needs this to use COM	[@ms-learn-implementing]
`registryRead`	LPAC needs this to open registry keys	[@ms-learn-implementing]

Several rows here have a restricted capability designation in the manifest schema; Microsoft Learn's note on runFullTrust is that "a Medium IL app needs to declare the runFullTrust restricted capability" before it can register out-of-process COM [@ms-learn-capabilities]. The same page gives the structural advice every developer should treat as default: "be sure to declare only the capabilities that your app needs" [@ms-learn-capabilities].

5.4 `_TOKEN.LowboxNumberEntry` -- the per-instance number

Two simultaneous Microsoft Calculator processes both carry the same Package SID and the same Capabilities array. What makes them distinct principals to the kernel is the AppContainerNumber -- a per-instance integer assigned by NtCreateLowBoxToken at token-creation time. The kernel maintains a session-scoped AVL tree keyed by this number. Ionescu named the corresponding kernel data structure in his 2015 reverse engineering [@ionescu-bh15]; the public-facing reference is Forshaw's 2024 book [@nostarch-wsi].

A per-instance integer assigned by `NtCreateLowBoxToken` to each LowBox token at creation time and used as the key into the kernel's session-scoped AVL trees that hold the per-instance named-object handles and the per-instance namespace state [@nostarch-wsi]. Two simultaneously running processes of the same package have the *same* Package SID but *different* `AppContainerNumber` values. This is the field that makes two co-tenanted calculator processes opaque to each other.

The internal field names _TOKEN.Flags.LowBoxToken, the AVL tree at nt!SepLowBoxNumberTable, and the AppContainerNumber are not in any official Microsoft document. The canonical primary sources for them are Ionescu's Black Hat 2015 reverse engineering [@ionescu-bh15] and Forshaw's 2024 book Windows Security Internals [@nostarch-wsi]. Microsoft's own NtCreateLowBoxToken page documents the behaviour but does not name the internal fields [@ms-learn-ntcreatelowboxtoken].

5.5 `_TOKEN.LowboxHandlesEntry` -- the saved namespace handles

LowboxHandlesEntry points into a second AVL tree, keyed by the same AppContainerNumber. The entry carries kernel handles to the per-package directory at \Sessions\<n>\AppContainerNamedObjects\<package-sid>\ and to its RPC Control sub-directory. The handles are captured by NtCreateLowBoxToken (the syscall's last two parameters are HandleCount and Handles[] [@ms-learn-ntcreatelowboxtoken]) and stored in the AVL tree for later lookups.

When a LowBox process calls NtCreateMutant("\\Global\\Foo"), the Object Manager's path-walker (ObpLookupObjectName) consults LowboxHandlesEntry to substitute the rewrite. The lookup proceeds against the per-package directory rather than the global \BaseNamedObjects. The application's request for "Global\Foo" silently resolves to "\Sessions\1\AppContainerNamedObjects\S-1-15-2-...\Foo" -- which is invisible to any other package, because every other package has a different per-instance handle pointing to a different directory.

This is the mechanism Forshaw's Project Zero Issue 1550 attacked in 2018. Forshaw's writeup names the surface: "this API creates object directories under the user's AppContainerNamedObjects object directory to support redirecting BaseNamedObjects and RPC endpoints by the OS" [@p0-1550]. The implementation bug was in the helper (the AppInfo service's CreateAppContainerToken); the primitive itself is structurally sound.

The five-step LowBox access check

Putting the five fields together, every access decision from a LowBox process runs through this five-step sequence.

flowchart TD A[Access requested by LowBox process] --> B["Step 1: Classic DACL walk
SeAccessCheck against user + groups"] B --> C["Step 2: MIC label check
NO_WRITE_UP (default)
against IL=Low"] C --> D["Step 3: Package SID claim
does object's DACL name PackageSid?"] D --> E["Step 4: Capability claim
WFP / broker / kernel callout
checks Capabilities array"] E --> F["Step 5: Namespace redirect
ObpLookupObjectName rewrites
BaseNamedObjects path"] F --> G[Allow] F --> H[Deny]

Classic DACL check. SeAccessCheck walks the object's DACL exactly as if the caller were a normal user. The user SID and group SIDs in the token contribute to the granted-access mask.
MIC label check. The SACL's mandatory-integrity ACE is compared against the token's IntegrityLevel. AppContainer tokens are always Low [@ms-learn-legacy]; if the object's mandatory ACE says NO_WRITE_UP and the request is a write, the access is denied here. The default NO_WRITE_UP-only policy from Vista [@ms-learn-mic] means a Low-IL LowBox process still cannot write to a default-ACL Medium object.
Package SID claim check. The object's DACL may grant access specifically to the Package SID. If matched, the package SID claim contributes to the granted mask. This is the channel by which per-package data directories are made accessible to the package and only the package.
Capability claim check. A WFP callout, a broker, or a kernel callout checks whether the requested resource maps onto a declared capability. The Windows Filtering Platform compares the outbound socket's destination against the firewall callout's allow list; if the package did not declare internetClient, no S-1-15-3-* capability matches and the connection fails.
Named-object namespace redirect. References to objects under \BaseNamedObjects (mutants, events, sections, RPC endpoints) are rewritten by the Object Manager to \Sessions\<n>\AppContainerNamedObjects\<package-sid>\ before lookup. This is what makes "Global\Foo" mean a per-package object for the LowBox process.

Microsoft Learn's intersection rule is the canonical articulation: "the permitted access is the intersection of that granted by the user/group SIDs and AppContainer SIDs" [@ms-learn-implementing]. A user / group ACE that grants FILE_READ_DATA and a package SID ACE that grants FILE_READ_DATA | FILE_WRITE_DATA together produce FILE_READ_DATA, because the intersection is the smaller set.

flowchart LR T["_TOKEN structure"] --> U["User
S-1-5-21-..."] T --> G["Groups[]"] T --> P["Privileges[]"] T --> I["IntegrityLevel
(always Low for LowBox)"] T --> F["Flags
(LowBoxToken bit)"] T --> PK["PackageSid
S-1-15-2-..."] T --> CA["Capabilities[]
SID_AND_ATTRIBUTES"] T --> LN["LowboxNumberEntry"] T --> LH["LowboxHandlesEntry"] LN -.->|"keyed lookup"| AVL1["nt!SepLowBoxNumberTable
AVL tree by AppContainerNumber"] LH -.->|"keyed lookup"| AVL2["nt!SepLowBoxHandlesTable
AVL tree of saved directory handles"]

The Win32 launch surface

The minimum production launch sequence has four moving parts. CreateAppContainerProfile derives the Package SID, lays down the per-package profile on disk, and returns the SID and the profile root [@ms-learn-createprofile]. InitializeProcThreadAttributeList allocates a process-attribute list. UpdateProcThreadAttribute installs the PROC_THREAD_ATTRIBUTE_SECURITY_CAPABILITIES attribute, whose payload is a SECURITY_CAPABILITIES struct carrying the AppContainer SID, the capability array, and a count [@ms-learn-updateprocthread] [@ms-learn-security-capabilities]. CreateProcess (or CreateProcessAsUser) with STARTUPINFOEX carrying the attribute list launches the new process. Inside the kernel, NtCreateLowBoxToken does the work [@ms-learn-ntcreatelowboxtoken]: it sets _TOKEN.Flags.LowBoxToken, stamps PackageSid, populates Capabilities[], assigns the AppContainerNumber, and saves the directory handles into LowboxHandlesEntry.

{` // This sketches the shape of the Win32 launch surface, not real P/Invoke. // Real callers go through Win32 from C/C++/Rust or via interop.

type PSID = string; // S-1-15-2-... package SIDs type SECURITY_CAPABILITIES = { AppContainerSid: PSID; Capabilities: { Sid: PSID; Attributes: number }[]; };

function createSandboxedProcess(packageName: string, exe: string) { // Step 1: derive Package SID, create per-package profile on disk. const packageSid = createAppContainerProfile(packageName, { displayName: packageName, description: "Sandboxed worker", capabilities: ["internetClient"], });

// Step 2: build the capabilities payload. const caps: SECURITY_CAPABILITIES = { AppContainerSid: packageSid, Capabilities: [ { Sid: "S-1-15-3-1", Attributes: 0 }, // internetClient capability SID ], };

// Step 3: install PROC_THREAD_ATTRIBUTE_SECURITY_CAPABILITIES. const attrList = initializeProcThreadAttributeList(1); updateProcThreadAttribute( attrList, "PROC_THREAD_ATTRIBUTE_SECURITY_CAPABILITIES", caps, );

// Step 4: launch. Kernel calls NtCreateLowBoxToken under the hood. return createProcess(exe, { startupInfoEx: { attributeList: attrList } }); }

// Demonstration only: const info = createSandboxedProcess("contoso.WidgetApp_8wekyb3d8bbwe", "widget.exe"); console.log("Launched LowBox PID", info.pid); console.log("Package SID:", info.packageSid); console.log("Capabilities granted:", info.caps); `}

LPAC: one synthetic capability

A LowBox token whose Capabilities[] includes the synthetic WIN://NOALLAPPPKG capability causes the kernel to omit the ALL_APP_PACKAGES group SID from the new token entirely. The token's groups become strictly the package's own derivations, plus the declared capabilities, plus the universal SIDs. Microsoft Learn's wording: "Less Privileged AppContainers (LPAC) are even more isolated than regular AppContainers and require further capabilities to gain access to resources that regular AppContainers already have access to such as the registry, files, and others. For example, LPAC cannot open any keys in the registry unless it has the registryRead capability and cannot use COM unless it has the lpacCom capability" [@ms-learn-implementing]. The Chromium source's lpac_capability.h enumerates the full set Microsoft Edge inherits at renderer launch [@chromium-lpac]. Section 6.3 walks the practical consequences.

These five fields and five steps are everything AppContainer is. The next section walks the four places they are exercised at production scale on a 2026 Windows 11 machine: every UWP app, every MSIX-packaged Win32 app, every Edge renderer, and every Windows Sandbox launch.

6. The Four 2026 Production Deployments

AppContainer is not a demonstration primitive. It is the principal mechanism behind every piece of trustworthy code execution on a modern Windows desktop. Four populations exercise it at production scale on a Windows 11 25H2 machine.

6.1 UWP apps

The Microsoft Calculator (Microsoft.WindowsCalculator), the Mail and Calendar apps, Photos, Xbox, Settings, the modern Notepad, and the rest of the Windows-bundled Universal Windows Platform applications are MSIX packages whose manifest declares uap10:TrustLevel="appContainer" [@ms-learn-manifest-app]. Capabilities are declared explicitly in each manifest's <Capabilities> element [@ms-learn-capabilities]. A typical UWP capabilities profile is small: internetClient for a mail client; picturesLibrary for Photos; userAccountInformation for an app that wants the user's display name. The LowBox token is the only principal that ACLs in the per-package data directory at %LOCALAPPDATA%\Packages\<PFN>\ name. The six AppContainer isolation axes -- credential, device, file, network, process, and window isolation -- are listed on Microsoft Learn's AppContainer Isolation page [@ms-learn-isolation], and every UWP app exercises all six. Process isolation is AppContainer-only; UWP apps do not run inside Hyper-V.

6.2 MSIX-packaged desktop apps

The new File Explorer (in 25H2), the new Outlook, Power Automate Desktop, the modernised Snipping Tool, and a growing catalogue of third-party MSIX packages live in a different population. They are packaged using MSIX, and their manifest declares either uap10:TrustLevel="mediumIL" (with <rescap:Capability Name="runFullTrust" />) or uap10:TrustLevel="appContainer" [@ms-learn-msix-container] [@ms-learn-manifest-app]. Many start at mediumIL for legacy interop reasons and gradually migrate as the application drops dependencies on HKLM writes, on absolute file paths, and on registering arbitrary out-of-process COM. Microsoft Learn's MSIX page shows the migration shape: change the manifest from <rescap:Capability Name="runFullTrust" /> to uap10:TrustLevel="appContainer", and the MSIX deployment stack does the LowBox plumbing on the application's behalf at install [@ms-learn-msix-container]. The App Installer component is the surface that performs the install [@wiki-msix].

6.3 Microsoft Edge: LPAC renderers

Every Microsoft Edge renderer process on Windows 10 RS5 and later runs as a LowBox token with WIN://NOALLAPPPKG set. The browser is Chromium-based -- "A little over a year ago, we announced our intention to rebuild Microsoft Edge on the Chromium open source project" said the Windows Experience Blog on January 15, 2020 [@edge-chromium-ga] -- and inherits Chromium's broker / target architecture and job-object lockdown [@chromium-sandbox]. The LPAC layer is the Windows-specific addition. Chromium's lpac_capability.h defines the synthetic capabilities the renderer needs to function with ALL_APP_PACKAGES stripped: kLpacChromeInstallFiles, kLpacCom, kLpacCryptoServices, kLpacIdentityServices, kLpacMedia, kRegistryRead, and the rest [@chromium-lpac]. Microsoft's RendererAppContainerEnabled policy documents the customer-facing surface: "Launches Renderer processes into an App Container for more security benefits"; "This policy will only take effect on Windows 10 RS5 and above"; "Windows: ≥ 96"; "If you enable this policy, Microsoft Edge launches the renderer process in an app container" [@ms-learn-edge-lpac]. The policy is rolled out broadly on current Edge channels; the documentation itself notes the unconfigured default will move to in-app-container in a future update [@ms-learn-edge-lpac].

A renderer process has no reason to access the registry, no reason to open arbitrary COM classes, no reason to read most of the per-package directories under `%LOCALAPPDATA%\Packages\`. LPAC strips the ambient access by removing `ALL_APP_PACKAGES` from the token, and the renderer adds back only the synthetic capabilities Chromium needs to function (font cache reads, media foundation handles, the install-files capability). The combination -- *Chromium broker / target* outside the kernel plus *LPAC* inside the kernel -- is the most defended browser configuration on any current desktop OS. The Chromium sandbox document says the design intent: "Sandbox operates at process-level granularity. Anything that needs to be sandboxed needs to live on a separate process" [@chromium-sandbox]. LPAC is the Windows-side answer to *how* a separate process gets the smallest possible authority.

This is the second insight to keep. Modern Microsoft Edge runs all six post-Gen-0 mechanisms simultaneously: Medium IL host UI (Gen 0 baseline), MIC labels on objects (Gen 1), Chromium broker / target architecture (Gen 2), LowBox token on renderers (Gen 3), WIN://NOALLAPPPKG LPAC (Gen 4), MSIX-packaged Edge (Gen 5), and optionally Windows Sandbox (Gen 6). Microsoft and Google reached the same browser-sandbox design from opposite directions, and the production browser uses both. The right question is not "AppContainer or Chromium sandbox?" but "where in the stack does each layer belong?"

6.4 Windows Sandbox

WindowsSandbox.exe -- available on Pro, Enterprise, and Education editions of Windows 10 1903 and later [@ms-learn-sandbox-overview] -- launches the most isolated of the four populations. Three layers carry the design. The Hyper-V partition isolates a separate kernel from the host: "It relies on the Microsoft hypervisor to run a separate kernel that isolates Windows Sandbox from the host" [@ms-learn-sandbox-overview]. The Dynamic Base Image is the read-only file set the guest kernel boots from, stored as a 30 MB compressed package and unpacked to 500 MB on disk [@ms-learn-sandbox-arch]. Direct-map memory sharing means the host's read-only binaries (such as ntdll.dll) "use the same physical pages as those pages of the binary when loaded on the host" [@ms-learn-sandbox-arch]. Security-research write-ups report that the host-side container manager that orchestrates this runs in an AppContainer; Microsoft's published architecture page does not document the host-side container-manager token type directly, so the load-bearing isolation property remains the Hyper-V partition itself.

Starting with Windows 11 22H2, in-sandbox restarts persist data: "data persists through restarts initiated within the sandbox" [@ms-learn-sandbox-overview]. The persistence is bounded by the sandbox lifecycle; closing the sandbox window discards the guest entirely.

Note: On a running Windows 11 machine you can confirm the AppContainer status of any process two ways. Sysinternals Process Explorer's Security tab on a UWP process shows the package SID, the AppContainer group, and the integrity level Low (S-1-16-4096). James Forshaw's NtObjectManager PowerShell module exposes Get-NtToken and Get-AccessibleObject -ProcessId <pid> which enumerate the kernel-visible token fields and the objects the process can reach [@sandboxsecuritytools]. Microsoft's own SandboxSecurityTools repository on GitHub publishes LaunchAppContainer: "The LaunchAppContainer tool can be used to run applications in AppContainer or Less Privileged AppContainer (LPAC) sandboxes" [@sandboxsecuritytools].

A comparison table for the four populations:

Deployment	Year of ship	Trust boundary	Capabilities typical	Kernel-exploit defence	Hyper-V wrap
UWP apps	2012	AppContainer	1-5, declared in manifest	No	No
MSIX-packaged desktop apps	2018	AppContainer or mediumIL	Varies; many declare runFullTrust	No	No
Microsoft Edge LPAC renderers	2020 (Edge Chromium GA)	LPAC inside Chromium target	Synthetic Lpac* set	No	Optional via Windows Sandbox
Windows Sandbox	2019	Hyper-V partition + AppContainer	Implicit	Yes (separate kernel)	Yes

Microsoft Defender Application Guard, the per-tab Hyper-V isolation for Edge that shipped in Windows 10 1709, was retired in Windows 11 24H2 [@ms-learn-mdag]. The replacement is Microsoft Defender SmartScreen plus the Edge Management Service; the per-tab Hyper-V boundary is gone. Per-application hypervisor isolation is no longer the Microsoft direction; Windows Sandbox is the surviving Hyper-V-wrapped variant.

On the same machine, the same kernel, the same SeAccessCheck runs the same five-step LowBox path millions of times a second across these four populations. Yet the LowBox token is not what every OS does. The next section asks: how do macOS, iOS, Android, and Linux solve the same problem -- and what do the differences teach us about kernel-token-side enforcement versus user-mode-policy-side enforcement?

7. Competing Approaches Across Operating Systems

Apple, Google, and the Linux distributions solved the same problem -- how does the kernel give two co-tenanted applications different verdicts? -- with four structurally different answers. Each trade-off is a different bet on where in the system the per-app principal should live.

iOS and iPadOS application sandbox. Apple ships a mandatory per-app sandbox on every device since iPhone OS 1 in 2007 [@apple-platform-security-app]. From iPhone OS 2.0 / the 2008 App Store launch onward, the developer-facing principal is two-valued: a Bundle ID (developer-chosen string) and a Team ID (signer identity). Per-app entitlements declared in the signed bundle are the capability vocabulary. Enforcement is mandatory -- there is no opt-out. The per-app filesystem container at Containers/Data/Application/<bundle-uuid>/ is the iOS analogue of %LOCALAPPDATA%\Packages\<PFN>\. Where Windows extends the kernel token, iOS keeps the per-app profile in a TrustedBSD-derived MAC framework and consults it from kernel mode at every relevant resource manager.

macOS App Sandbox. macOS uses the same entitlement primitive Apple developed for iOS, plus a user-mode policy daemon (sandboxd) that holds the per-app profile [@apple-app-sandbox]. The trade-off is that more decisions are made in user mode than on iOS, with corresponding flexibility costs. App Sandbox is optional on macOS for non-App-Store distribution, in contrast to iOS, where it is mandatory.

Android per-app UID plus SELinux plus seccomp-bpf. Android's Application Sandbox page on the AOSP documents the layered model: every app receives a distinct UNIX UID; classical UNIX discretionary access control enforces per-app isolation; SELinux mandatory access control is layered on top from Android 5.0 onward; per-physical-user partitions arrived in Android 6.0; the seccomp-bpf system-call filter is required from Android 8.0; per-app SELinux sandboxes apply for targetSdkVersion >= 28 (Android 9); and path-based file restrictions tightened in Android 10 [@android-app-sandbox]. The kernel-side per-app principal is the UNIX UID. The MAC layers above add additional confinement.

Linux unprivileged namespaces plus seccomp plus AppArmor / SELinux plus Flatpak / Snap. Linux's per-application sandbox is composable. No first-class per-app principal lives in the kernel. The application sandboxes are layered above the user-keyed DAC: Flatpak and Snap build on unprivileged user namespaces and seccomp filters; Chromium on Linux uses the same kit. The Chromium FAQ's kernel-bugs caveat from §3 applies in every cross-OS configuration: a user-mode sandbox cannot defend against bugs in the kernel it runs on [@chromium-sandbox-faq].

The structural axis falls out cleanly. macOS keeps the per-app profile in user-mode outside the kernel token; iOS keeps it in user-mode but enforces mandatorily; Android allocates a real UNIX UID; Windows extends the kernel-token SID alphabet. Windows is the only one of the four that partitions the kernel data structure.

Operating system	Primitive	Year	Where the principal lives	Per-call cost model	Kernel-exploit containment	Mandatory?
Windows 8+	LowBox token (AppContainer)	2012	Inside the access token (kernel)	Inline in `SeAccessCheck`	No	Opt-in via manifest / SDK
macOS	App Sandbox + entitlements	2011 (Mac App Store)	User-mode `sandboxd` profile	IPC for some decisions	No	Opt-in (Mac App Store: yes)
iOS / iPadOS	App Sandbox + entitlements	2007	TrustedBSD MAC framework	Inline kernel check	No (Pegasus class proves)	Yes, mandatory
Android	UID + SELinux + seccomp	2008	UID space (kernel) + MAC	Four checks per syscall	No	Yes, mandatory
Linux	Namespaces + seccomp + Flatpak / Snap	2014 (Flatpak)	Composable user-mode + kernel	Variable per layer	No	Opt-in per app

The sandbox is not a security silver bullet, but it is a strong last defense against nasty exploits. -- Chromium sandbox FAQ [@chromium-sandbox-faq]

The Chromium project itself ports its broker / target sandbox across all four families. On Windows it sits on top of AppContainer and LPAC. On macOS it uses seatbelt. On Linux it uses seccomp filters plus unprivileged user namespaces. On ChromeOS the same code talks to ChromeOS's own kernel-side enforcement. The broker / target pattern is operating-system-independent; what differs is the per-OS capability vocabulary the broker negotiates with [@chromium-sandbox].

Putting the principal in the kernel access token is fast and elegant. The amortised cost of the LowBox path is one extra DACL pass plus the capability-claim check, all running inline in SeAccessCheck with no IPC round-trip. But the kernel-side bet has a brittle edge: it is brittle exactly where putting it in the kernel is not enough. The next section asks what the LowBox token cannot prove.

8. Theoretical Limits: What the LowBox Token Cannot Prove

Every security primitive has a perimeter beyond which it can no longer reason. The LowBox token has five.

Limit 1: Kernel exploits. Once the attacker is in kernel mode, they rewrite their own token. The LowBox bit becomes irrelevant. The Chromium sandbox FAQ states the principle plainly: "the sandbox cannot provide any protection against bugs in system components such as the kernel it is running on" [@chromium-sandbox-faq]. This is the load-bearing argument for Windows Sandbox's Hyper-V wrap (§4.7, §6.4). It is the third insight to keep.

Note: The LowBox token is a runtime sandbox, not a privilege ceiling. To the rest of user mode a LowBox process is opaque and bounded; to the kernel it is a small extension of the access-check pipeline. A kernel-mode arbitrary write -- of which Windows has had a steady but small supply across its history -- gives the attacker the ability to set or clear _TOKEN.Flags.LowBoxToken, swap out PackageSid, append entries to Capabilities[], or simply impersonate a different token. The structural answer is hypervisor isolation, not better in-token checks. Windows Sandbox is the production implementation [@ms-learn-sandbox-overview].

Limit 2: Confused-deputy brokers. A broker process outside the AppContainer is, by design, the bridge back to user-scoped resources. If the broker honours requests it should not have honoured, the AppContainer's caller succeeds in doing something it could not have done directly. The canonical class on Windows is RuntimeBroker, AppInfo (the UAC consent broker), Print, WebAuthn, voice activation, and the Microsoft (R) Diagnostics Hub Standard Collector Service that Forshaw called "DiagHub for short" in his 2018 arbitrary-file-write writeup [@p0-arbitrary-write-2018]. The 1988 Confused Deputy paper from the capability-systems literature [@hardy-confused-deputy] is the literature anchor for this whole class.

Limit 3: Token-stealing. An attacker who can duplicate a higher-privilege token via NtDuplicateToken, NtOpenProcessTokenEx, or any of the SeImpersonatePrivilege-stealing Potato-family attacks steps out of the AppContainer by impersonating a non-LowBox user. Siloscape is the most-publicised Windows container escape: Daniel Prizmant's Unit 42 writeup characterises it as "the first known malware targeting Windows containers", and records Microsoft's initial position that "Windows Server containers are not a security boundary" before later reclassifying that "an escape from a Windows container to the host, when executed without administrator permissions inside the container, will in fact be considered a vulnerability" [@siloscape]. Token-stealing is the same class one rung down: an AppContainer escape via impersonation.

Limit 4: Capability granularity. internetClient is "the application can speak to the public internet" with no per-host granularity. Each Windows capability is approximately as fine-grained as a Linux CAP_*, not as fine-grained as an iOS entitlement key. There is no AppContainer-native equivalent of "this app can connect to api.example.com:443 but nowhere else." The Microsoft Learn capabilities page enumerates the capability vocabulary [@ms-learn-capabilities]; the cardinality is in the dozens of standard capabilities plus custom ones, not in the millions.

Limit 5: In-process side channels. Once data is in the AppContainer process's address space, the AppContainer model has nothing to say about it. Hardware side channels (Spectre, MDS, Downfall), explicit channels (clipboard, WebRTC, browser-tab side channels in Edge), and out-of-band exfiltration via broker calls are all out of model. AppContainer is a boundary primitive; once you are inside the boundary, the primitive does not constrain in-process behaviour.

The Windows Sandbox architecture page is explicit about the chain of reasoning [@ms-learn-sandbox-arch]. The host's read-only OS files can be shared with the sandbox without compromise (immutable; "Most OS files are immutable and can be freely shared"). The host's writable state cannot be shared (mutable; "A small subset of operating system files are mutable and can't be shared"). The remaining isolation question -- can a kernel exploit inside the guest reach the host? -- is answered structurally: the guest runs on a separate Microsoft hypervisor partition with a separate kernel. A guest-side kernel exploit gives the attacker control of the guest's `_TOKEN.Flags.LowBoxToken` field, but the host's kernel is untouched on the other side of the partition.

These five limits define the research surface post-2024. The next section catalogues what is still open.

9. Open Problems

Six open problem classes are actively investigated in 2024-2026 research.

The ALL_APP_PACKAGES ambient-access surface. Even with LPAC, many default-installed resources are ACL'd to the ALL_APP_PACKAGES group; non-LPAC AppContainers inherit access to all of them. The research class is to enumerate the union of all ALL_APP_PACKAGES-readable surfaces on a default Windows install and classify which leak cross-package data.
Capability-SID collisions and over-grant. Third-party custom capability SIDs are derived from a string in the manifest; the collision resistance of the hash construction under adversarial choice of input string is an open question. A malicious manifest that produces a capability SID colliding with a privileged Microsoft-defined capability would be a structural break.
LPAC capability-injection at process creation. The capability list is supplied by the creator of the AppContainer process; tightening which caller can ask for which capability has been a recurring servicing-bulletin theme. Forshaw's Raising the Dead writeup (P0 Issue 483, fixed in MS15-111 as CVE-2015-2554 [@p0-raising-dead] [@nvd-cve-2015-2554]) and the 2018 Arbitrary Object Directory Creation writeup (P0 Issue 1550 [@p0-1550]) are the canonical examples of bugs in this class.
Hyper-V-per-AppContainer ("HVCI for AppContainers"). WDAG's 2024 retirement [@ms-learn-mdag] leaves a gap: there is no production direction for per-application hypervisor isolation. Windows Sandbox is the surviving Hyper-V-wrapped sandbox; per-tab or per-app HV isolation in Edge is not coming back. The research question is whether per-app Hyper-V can be reintroduced in a form that does not have WDAG's adoption problems.
Cross-package AppContainer-to-AppContainer attacks. As third-party MSIX adoption grows, the cross-package attack surface (one third-party package abusing another's \AppContainerNamedObjects\<other-package-sid>\ ACL) grows. The 2018 P0 1550 writeup [@p0-1550] is the canonical example of a kernel-side variant; user-mode variants in third-party MSIX brokers are the next class.
Post-CrowdStrike user-mode EDR runtime. After the July 2024 incident, Microsoft convened a multi-vendor endpoint-security summit and committed to a more isolated EDR / AV runtime in user mode. AppContainer or LPAC is one of the candidate runtimes for the new platform; architectural details are still being published.For Problem 1 specifically, the standard tool for enumerating the ALL_APP_PACKAGES-readable surface is Forshaw's NtObjectManager PowerShell module's Get-AccessibleObject -ProcessId <pid> cmdlet -- it enumerates every kernel object a given process can reach, which is the right primitive for asking "what does an ALL_APP_PACKAGES member actually see?" The companion Microsoft tool is LaunchAppContainer from the official SandboxSecurityTools repository on GitHub [@sandboxsecuritytools].

Note: Microsoft's decision to retire WDAG in Windows 11 24H2 [@ms-learn-mdag] is the proximate signal that per-application hypervisor isolation is not the Microsoft direction. The 2024+ answer is "harden the in-token AppContainer surface" and "reduce the broker attack surface" rather than "wrap every app in Hyper-V." The single shipping Hyper-V-wrapped sandbox is Windows Sandbox, and it is a user-launched primitive, not an OS-default for browsers.

The unresolved problems share a structural property: they sit between the token-level guarantee AppContainer makes and the resource managers that implement the consequences. The next section gives practical guidance for developers and practitioners working within these limits today.

10. Practical Guide

Two audiences need different answers. Developers need to know how to opt their code in. Practitioners need to know how to audit the deployment.

For developers

Package your Win32 app with MSIX and set uap10:TrustLevel="appContainer" in the manifest's <Application> element [@ms-learn-manifest-app]. Stop adding runFullTrust as a restricted capability by default; the manifest is a budget, and every restricted capability is a lifetime ACL on your package SID [@ms-learn-capabilities] [@ms-learn-msix-container].

Declare only the capabilities your app needs in <Capabilities>. Microsoft Learn's wording is exactly this: "be sure to declare only the capabilities that your app needs" [@ms-learn-capabilities]. Each extra internetClient or picturesLibrary is a lifetime allow ACE on the corresponding Capability SID.

Use LPAC for any process that does not need cross-package or cross-user resource access. The mechanism is the synthetic WIN://NOALLAPPPKG capability in SECURITY_CAPABILITIES.Capabilities[] at process creation [@ms-learn-implementing] [@chromium-lpac]. The Chromium tree's lpac_capability.h is the canonical reference for which LPAC capabilities each kind of worker process needs [@chromium-lpac].

Test your sandbox with Forshaw's NtObjectManager PowerShell module's Get-AccessibleObject -ProcessId <pid> cmdlet, which enumerates every kernel object your process can actually reach [@sandboxsecuritytools]. Tighten capabilities until the enumerated list matches your expectations. Microsoft's own SandboxSecurityTools repository ships LaunchAppContainer for the same kind of testing in the Insider bounty programme [@sandboxsecuritytools].

For practitioners

Identify which high-risk applications on your managed fleet can be MSIX-packaged and migrated to uap10:TrustLevel="appContainer". Browsers, PDF viewers, and email clients are highest payoff because hostile content reaches them most often.

Audit the per-package directory permissions in %LOCALAPPDATA%\Packages\<PFN>\. The LocalState, RoamingState, and AC subdirectories are the load-bearing entries; each should grant access to the package SID, not to broad groups.

Use Windows Sandbox (WindowsSandbox.exe) for Hyper-V-isolated execution of untrusted programs on Pro, Enterprise, or Education editions [@ms-learn-sandbox-overview]. Configurations are described in a .wsb file: a 30 MB Dynamic Base Image launches in a few seconds, and Windows 11 22H2 onward preserves data through in-sandbox restarts.

Monitor the Microsoft-Windows-AppxPackaging/Operational and Microsoft-Windows-AppXDeploymentServer/Operational event logs for unexpected CreateAppContainerToken failures and capability mismatches. Microsoft Learn's AppX troubleshooting page names these two channels verbatim and walks the diagnostic surface they expose [@ms-learn-appx-troubleshooting].

Note: Five commands a defender can run today to inventory AppContainer adoption on a managed endpoint: 1. Get-AppxPackage -AllUsers | Select-Object Name, PackageFullName, PackageFamilyName -- enumerate installed MSIX packages. 2. (Get-AppxPackage -Name Microsoft.MicrosoftEdge.Stable).Manifest -- inspect a specific package's manifest. 3. Get-Process | Where-Object { $_.Path -like "*WindowsApps*" } | Select-Object Id, ProcessName, Path -- find running UWP / packaged processes. 4. From an elevated PowerShell with NtObjectManager installed: Get-NtToken -ProcessId <pid> to see the LowBoxToken flag, Package SID, and capability list. 5. Get-AppxLog | Where-Object { $_.LevelDisplayName -eq "Error" } -- review AppX deployment errors for clues to broken AppContainer launches.

Once `NtObjectManager` is installed (from PowerShell Gallery), a defender can dump the *complete* reachable kernel-object set for a running LowBox process:

Install-Module NtObjectManager -Scope CurrentUser
$pid = (Get-Process -Name calc).Id
Get-AccessibleObject -ProcessId $pid -TypeFilter Mutant,Section,Event,Directory |
  Sort-Object Path | Format-Table -Property TypeName, Path, GrantedAccess

The output enumerates every named kernel object the LowBox token can open, with the access mask the kernel would grant on each request. Any path that resolves outside \Sessions\<n>\AppContainerNamedObjects\<package-sid>\ is a candidate for cross-package leakage or an over-permissive capability. This is the same surface §9 problem 1 catalogues [@sandboxsecuritytools].

Converting a `mediumIL` packaged Win32 app to `appContainer` is structurally easier than it sounds and operationally harder than it sounds. Structurally, the manifest change is one line: drop `` and set `uap10:TrustLevel="appContainer"` [@ms-learn-msix-container]. Operationally, you must remove every HKLM write the app does, every assumption that absolute file paths outside the per-package directory will succeed, and every dependency on registering out-of-process COM. Legacy desktop apps tend to violate all three in plumbing that nobody documented. This is why `runFullTrust` is so widespread in third-party MSIX packages despite Microsoft's clear guidance to stop adding it.

The practical guidance only matters if the deployment is correctly understood. The next section addresses the most common misconceptions.

11. Frequently Asked Questions

No. AppContainer and integrity level are orthogonal axes. AppContainer is a per-application principal in the access token; integrity level is a mandatory label. Microsoft Learn states the relationship plainly: "if you _are_ in an app container, then the integrity level (IL) is always _low_" -- but the converse is *not* true. Plenty of Low-IL tokens are not AppContainer tokens (the IE 7 Protected Mode renderer was the historical example; the LocalLow workspace and the Low-IL Chromium target are modern examples) [@ms-learn-legacy]. Because the LowBox process's Object Manager namespace is partitioned at `\Sessions\\AppContainerNamedObjects\\`, and the WinRT API the UWP app uses for `Windows.Storage.TempFolder` resolves a per-package temporary directory under `%LOCALAPPDATA%\Packages\\AC\Temp\` instead of the global `\BaseNamedObjects`-anchored `C:\Windows\Temp`. The kernel handles for the rewrite live in the `LowboxHandlesEntry` AVL-tree slot keyed by your process's `AppContainerNumber`. *LowBox* is the kernel-internal name preserved in `NtCreateLowBoxToken` and the `_TOKEN.Flags.LowBoxToken` bit [@ms-learn-legacy] [@ms-learn-ntcreatelowboxtoken]. *AppContainer* is the public Win32 / WinRT API name for the same kernel object. *LPAC* (*Less Privileged AppContainer*) is the variant where the synthetic `WIN://NOALLAPPPKG` capability strips the implicit `ALL_APP_PACKAGES` group SID from the new token, requiring the package to declare each access (`registryRead`, `lpacCom`, and others) explicitly [@ms-learn-implementing]. Because the Package SID is a deterministic hash of the Package Family Name (which is itself a hash of the publisher distinguished name plus the package moniker). Each of the eight 32-bit sub-authorities is a 4-byte slice of the underlying SHA-256 hash (8 × 4 bytes = 32 bytes = 256 bits). The point of the construction is that every Windows 8 or later machine derives the *same* Package SID for the same Package Family Name, so per-package directory DACLs can be ACL'd at install time to a known SID [@ms-learn-derivesid] [@nostarch-wsi]. No. The kernel's `AppContainerNumber` per-instance counter keys each instance into its own slot in `nt!SepLowBoxHandlesTable`, and the Object Manager rewrites `\BaseNamedObjects` references against the per-instance saved-handle directory before name lookup [@nostarch-wsi]. Two Calculator processes share a Package SID and a Capabilities array but have *different* AppContainerNumbers; the named objects each one creates land in different directories. Yes -- unless the AppContainer has `WIN://NOALLAPPPKG`, in which case it is LPAC and `ALL_APP_PACKAGES` is omitted from its token [@ms-learn-implementing] [@chromium-lpac]. The `ALL_APP_PACKAGES` ambient-access surface is the §9 problem-1 research class. The standard tool for enumerating what an `ALL_APP_PACKAGES` member can reach on a given system is the `Get-AccessibleObject` cmdlet in Forshaw's `NtObjectManager` PowerShell module, and Microsoft publishes its own `LaunchAppContainer` testing tool in `SandboxSecurityTools` [@sandboxsecuritytools]. No. Windows Sandbox combines a *separate* Hyper-V partition running a pristine Windows kernel from the Dynamic Base Image [@ms-learn-sandbox-arch] with -- according to security-research reverse-engineering write-ups -- an AppContainer wrap on the host-side container manager. The Hyper-V layer is the only documented structural defence against kernel exploits inside the sandbox; pure AppContainer cannot defend against a kernel exploit. Inside the sandbox you still see the LowBox plumbing (it is a Windows guest, after all), but the meaningful trust boundary is the hypervisor partition.

12. Where This Plane Connects to the Others

AppContainer is the principal layer of the modern Windows sandbox stack. It is not the whole stack. A correct modern Windows app launch crosses four single-purpose layers in the kernel and in the deployment pipeline, and each layer carries a separate guarantee.

Code identity. Who is this code? Authenticode signatures, kernel-mode code signing, the MSIX signing pipeline, and the Package Family Name derivation answer that question [@ms-learn-derivesid].
AppContainer / LowBox token. What principal is the running instance? NtCreateLowBoxToken sets the LowBox flag, stamps the Package SID, and populates Capabilities[] [@ms-learn-ntcreatelowboxtoken].
Object Manager namespace partition. What names can the principal resolve? LowboxHandlesEntry directs the path-walker to the per-package \AppContainerNamedObjects\<package-sid>\ directory [@nostarch-wsi].
Process mitigation policies. What is the principal allowed to do inside its own address space? Arbitrary Code Guard, Code Integrity Guard, Control Flow Guard, Extended Flow Guard, Hardware-enforced Stack Protection (CET), and ImageLoadPolicy are the in-process mitigations Windows applies on top of the per-app principal, exposed via the PROCESS_MITIGATION_POLICY enumeration that SetProcessMitigationPolicy accepts [@ms-learn-process-mitigation-policy].

Walk a modern Windows app boot. Authenticode and the MSIX signing pipeline verify the binaries. The MSIX deployment stack derives the Package SID from the Package Family Name and writes the per-package profile under %LOCALAPPDATA%\Packages\<PFN>\. The launcher calls CreateProcess with a SECURITY_CAPABILITIES payload, which calls NtCreateLowBoxToken in the kernel. NtCreateLowBoxToken sets the LowBox flag and the per-instance fields. From that point every later SeAccessCheck against any object the process opens consults the new token's per-app fields alongside the classic user / groups walk. The Object Manager namespace gets partitioned in the kernel's hash table by the AppContainerNumber. The in-process mitigation policies decide what code may execute and which DLLs may load.

flowchart LR A[Authenticode / KMCS
code identity] --> B[NtCreateLowBoxToken
per-app principal] B --> C[Object Manager
namespace partition] C --> D[Mitigation policies
ACG / CIG / CFG / XFG / CET] D --> E[Running LowBox process]

Each layer is single-purpose. Together they cover the four-axis system the classic NT token model could not.

The LowBox bit is the answer to the question Windows NT 3.1 couldn't ask. Everything else is bookkeeping.

Two calculators on the same Windows 11 machine give the kernel a single question with two verdicts. The bit in _TOKEN.Flags.LowBoxToken is the one-line answer Windows took fourteen years to ship -- and the work Microsoft did in the years between January 30, 2007 and October 26, 2012 is what made it possible to ask the question at all.

The Object Manager Namespace: The Hierarchical Filesystem Underneath Every Windows Security Boundary

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

**The Windows Object Manager namespace is the kernel-resident, filesystem-shaped tree that every Windows security boundary quietly assumes.** Every named kernel object -- processes, threads, sections, files, registry keys, tokens, mutants, semaphores, ALPC ports, devices, drivers, jobs, silos -- lives somewhere under `\`. Six generations of isolation primitives (Session 0 isolation, AppContainer lowbox, integrity levels, VBS trustlets, Server Silos, and the `ObRegisterCallbacks` EDR sensor surface) are all path rewrites, per-directory ACLs, or kernel callbacks layered on the same 1993 Cutler-era four-piece structure. This article builds the namespace bottom-up -- `OBJECT_HEADER`, `OBJECT_TYPE`, `ParseProcedure`, `OBJECT_DIRECTORY` -- walks the 2026 top-level directory atlas on Windows 11 25H2, surveys the exploit tradition (symbolic-link redirection, namespace squatting, bait-and-switch on `\??` and `\Device`, arbitrary directory creation), and closes on the EDR pivot in `ObRegisterCallbacks`.

1. The path that isn't a path

Open WinObj.exe as administrator on any Windows 11 25H2 machine (Windows 11 version history). For about ten seconds the screen looks like a filesystem. The root is named \. Below it sit folders called \Device, \BaseNamedObjects, \Sessions, \RPC Control, \KnownDlls, and \ObjectTypes. Double-click any of them and you see children. Right-click any node and you can read a security descriptor. This is essentially the same UI a 1996 SysAdmin would have recognised; the tool first shipped that year as part of Mark Russinovich and Bryce Cogswell's Winternals [@en-wikipedia-mark-russinovich], and the current build is a Microsoft-signed Sysinternals binary whose navigation surface has not been redesigned in three decades [@ms-winobj].

Navigate to \Sessions\1\AppContainerNamedObjects and the picture starts to fracture. Inside that directory you will find one subdirectory per running AppContainer-sandboxed app, each named after a long Security Identifier of the form S-1-15-2-.... Pick the one belonging to the Microsoft Edge renderer process you are reading this article in. Every named mutant, event, section, semaphore, and ALPC port the renderer can ever name lives inside that one subdirectory. The renderer cannot escape it. Not because of a permission check that comes second, but because the kernel rewrites every name the renderer asks for, transparently, before path resolution begins. Microsoft's AppContainer Isolation documentation [@ms-appcontainer-isolation] calls this "sandboxing the application kernel objects."

This tree is not a filesystem. There is no disk persistence; nothing under \ survives a reboot. It is not the Windows registry either; the registry is a separate subsystem with its own hive format that hangs off the namespace only through a parse procedure on the Key object type. What this tree is, instead, is the Object Manager namespace: the in-memory, kernel-resident, hierarchical name service that the Windows kernel uses to locate every nameable kernel object [@ms-managing-kernel-objects]. Its top-level directories are catalogued in the driver kit's Object Directories reference [@ms-object-directories].

The Windows Object Manager, internally called `Ob`, is a kernel-mode subsystem of the Windows Executive that manages the lifetime, naming, security, and accounting of every resource the kernel exposes to user mode as a named object. Wikipedia summarises it as a "subsystem implemented as part of the Windows Executive which manages Windows resources... each [resource] reside[s] in a namespace for categorization" [@en-wikipedia-object-manager].

Here is the thesis the rest of this article spends nine thousand words unpacking. Every Windows security boundary you have read about -- Session 0 isolation, Mandatory Integrity Control, AppContainer, the Virtualization-Based Security trustlets, Server Silos and Windows containers, the EDR sensor surface that fires when something opens a handle to lsass.exe -- is physically realised in this tree. Each boundary is either a path rewrite at lookup time, a per-directory ACL, a token-keyed name substitution, or a kernel callback registered against an OBJECT_TYPE. The boundaries you read about elsewhere are the policies; this tree is the mechanism.

The Object Manager has shipped without architectural change for thirty-three years. Whose decision was that? And why did a 1993 data structure survive untouched while the GUI, the driver model, the security subsystem, and the boot path around it were rewritten more than once?

2. Where the namespace came from

The decision belongs to Dave Cutler. In 1988 Microsoft hired Cutler away from Digital Equipment Corporation. The Wikipedia biography records the line of operating systems Cutler had developed at DEC: "RSX-11M, VAXELN, VMS, and MICA" [@en-wikipedia-dave-cutler]. Three of those shipped commercially; the fourth, MICA, was cancelled with the Prism RISC program. Cutler walked out, and Microsoft signed him with a charter from Bill Gates to build a portable next-generation kernel that could host the existing Windows API on top of a 32-bit, multi-architecture base [@en-wikipedia-architecture-of-windows-nt]. Cutler brought a small team of DEC veterans with him.

The Object Manager is one of that team's earliest design decisions. The architectural bet was to unify every named kernel object under one filesystem-shaped tree, with each type carrying a parse procedure so a single family of syscalls (NtCreateFile, NtOpenSection, NtOpenProcess, and so on) could address files, registry keys, processes, ports, sections, drivers, devices, jobs, and synchronization primitives using the same path-walk algorithm. That was an unusual choice in 1989. VMS had a more typed, less unified resource broker. Mach treated kernel objects as capability-style port rights and never gave them a hierarchical name. Cutler's choice was, at heart, a Plan-9-style "every named resource is a filesystem path" idea, imported into a Windows shell.Plan 9 from Bell Labs (Pike, Thompson, et al.) was the academic articulation of the "everything is a path" property: every kernel-named resource, including processes and network connections, surfaced as a file under a 9P-served namespace. Plan 9 never reached commercial scale, but its design idea reached production through NT, and through Linux's /proc, /sys, and FUSE.

Windows NT 3.1 shipped on July 27, 1993. It was "Microsoft's first 32-bit operating system," supported on IA-32, DEC Alpha, and MIPS [@en-wikipedia-windows-nt-3-1]. The Object Manager was already one of its executive subsystems, sitting alongside the I/O Manager, the Memory Manager, the Process Manager, the Security Reference Monitor, and the Local Procedure Call subsystem [@en-wikipedia-architecture-of-windows-nt]. The four pieces this article will rebuild from scratch -- the OBJECT_HEADER that prefixes every object in memory, the OBJECT_TYPE singleton that owns each type's method table, the ParseProcedure that delegates path resolution to the owning subsystem, and the OBJECT_DIRECTORY hash table that maps names to objects -- were all in the NT 3.1 kernel. None of them has been rearchitected since.

That same year, Microsoft Press published Inside Windows NT, written by technical writer Helen Custer with a Foreword by Cutler himself. The book's Object Manager chapter is the canonical pre-2000 description of the namespace, cited on the Sysinternals WinObj page [@ms-winobj] as "Helen Custer's Inside Windows NT provides a good overview of the Object Manager namespace." Custer's book has been out of print for two decades, but the citation chain through Russinovich's tool is durable.

Three years later, in 1996, Russinovich and Cogswell co-founded Winternals and released WinObj 1.0 [@en-wikipedia-mark-russinovich]. WinObj was the first publicly distributed tool to walk \ from user mode, using the native NtOpenDirectoryObject and NtQueryDirectoryObject syscalls that the Object Manager exposed through NTDLL [@ms-winobj]. The following year, Russinovich's October 1997 Windows IT Pro column "Inside the Object Manager" gave the namespace its first treatment in the trade press. The original URL did not survive changes to TechTarget's web property portfolio in 2025 (TechTarget was acquired by Informa PLC in 2025), but the WinObj page still cites the column by name as "Mark's October 1997 [WindowsITPro Magazine] column, 'Inside the Object Manager'."The Russinovich 1997 column has no surviving direct URL because the URL did not survive changes to TechTarget's web property portfolio in 2025. The most accessible surviving citation is through the WinObj page itself. The same archive failure also explains why Helen Custer's 1993 biography returns HTTP 404 on Wikipedia in 2026; the book (ISBN 1-55615-481-X) survives in used-book channels only.

The line of book-length internals references that began with Custer continued through Inside Windows 2000 (third edition) and the Windows Internals series that succeeded it. The 7th edition Part 1 was published by Microsoft Press in May 2017, authored by Russinovich, Alex Ionescu, and David A. Solomon [@microsoftpressstore-wininternals7-part1]; its Chapter 8 is the current canonical reference for the Object Manager. James Forshaw's April 2024 Windows Security Internals [@nostarch-windows-security-internals] is the contemporary companion that ties the namespace into the access-check pipeline.

The 1993 design assumed a single global namespace. One process tree, one \BaseNamedObjects, one \Windows\WindowStations\WinSta0, one \?? view of DOS device letters. Everyone shared everything. Did that assumption survive the Internet?

3. The pre-Vista namespace and how it broke

It did not. By the late 1990s every interactive Windows user was sharing a name service with every running service. The single-global-namespace assumption produced three distinct exploit classes, each rediscovered repeatedly between 1996 and 2007, and each ultimately closed only by architectural change.

The most public failure was the shatter attack. In August 2002 a researcher named Chris Paget published a paper titled "Exploiting design flaws in the Win32 API for privilege escalation." Wikipedia's article on the disclosure preserves the chronology: "Shatter attacks became a topic of intense conversation in the security community in August 2002 after the publication of Chris Paget's paper" [@en-wikipedia-shatter-attack]. The proof-of-concept was about thirty lines. As an unprivileged interactive user, Paget sent a WM_TIMER window message to a service's hidden window in the same \Windows\WindowStations\WinSta0 (which all services and all interactive users shared in pre-Vista Windows), with a callback parameter pointing to attacker-placed shellcode. The shellcode ran as SYSTEM.

Microsoft's initial response, preserved in the Wikipedia article, was that "the flaw lies in the specific, highly privileged service": a per-service bug, patch the services. That stance did not survive the structural-class argument. The exploit was not a bug in one service. It was a property of the namespace: as long as services and users shared a window station and a \BaseNamedObjects, any service that ever called a Windows API processing a message from its message queue was reachable from any logged-in user.

Note: A second class of pre-Vista failure was named-object squatting. A low-privilege user pre-creates \BaseNamedObjects\Some_Global_Event with a permissive DACL. A privileged service later calls CreateEvent("Some_Global_Event") with default open-or-create semantics and ends up inheriting the squatter's object, security descriptor and all. This is not one service-author's bug; it is the consequence of every service-author trusting that names in a shared namespace would resolve to objects they themselves created. The pattern has been rediscovered approximately once a year for two decades. James Forshaw documents the contemporary named-pipe analog in his 2017 "Named Pipe Secure Prefixes" post [@tiraniddo-named-pipe-secure-prefixes], where the SMSS-created prefixes \Device\NamedPipe\ProtectedPrefix\Administrators, \Device\NamedPipe\ProtectedPrefix\LocalService, and \Device\NamedPipe\ProtectedPrefix\NetworkService are TCB-privilege-gated -- only smss.exe can create sibling protected prefixes, so a service that publishes its pipe below one of these prefixes inherits a DACL that low-privilege squatters cannot reach.

The third class was symbolic-link redirection. The pre-Vista Object Manager exposed two kinds of user-creatable symbolic link: object-manager symbolic links inside \?? (the per-session DOS-devices view) and NTFS mount points on disk. The attack pattern was the same in both. A privileged process is asked to open a path the user controls part of. The user has pre-planted a symbolic link partway through the path that redirects the residual walk into a target the user could not otherwise write. The privileged process opens the redirected file and treats it as if it were the original.

Forshaw's 2015 Project Zero post on the symbolic-link hardening generation is the canonical taxonomy: "There are three types of symbolic links you can access from a low privileged user, Object Manager Symbolic Links, Registry Key Symbolic Links and NTFS Mount Points" [@p0-symlink-mitigations]. His worked example for the Internet Explorer 11 EPM sandbox is CVE-2015-0055 [@nvd-cve-2015-0055], described in the post as "an information disclosure issue in the IE EPM sandbox which abused symbolic links to bypass a security check."

The aha moment from this section is the one Microsoft eventually conceded. The pre-Vista failure mode was not three independent bug families. It was one structural problem -- a single global namespace shared by every principal -- with three faces. No amount of per-service patching could close it. The fix had to be architectural: the namespace itself had to be partitioned.The Interactive Services Detection Service (ISDS) was Vista's backward-compatibility hack for legacy services that drew GUIs into Session 0. ISDS displayed a "An interactive service has requested attention" prompt that let the user switch to Session 0 long enough to dismiss the dialog. It was deprecated in Windows 10 1803 and is the historical artifact of just how much pre-Vista code assumed services and users would share a window station.

That fix took five years to ship. Windows Vista RTM was released on November 8, 2006 and General Availability arrived on January 30, 2007 [@en-wikipedia-windows-vista]. Vista did not ship one fix; it shipped three independent partition mechanisms in the same release window, because the structural failure had three faces and each face needed its own mechanism. The next section catalogues those mechanisms and the four additional generations of additive isolation that have built on them since.

4. Six generations of namespace isolation

The namespace itself has not been rearchitected since 1993. What has evolved, in six discrete generations between 1993 and 2026, is the set of partition primitives layered on top: the mechanisms that let the kernel hide subtrees from particular callers, rewrite paths transparently for particular tokens, or invoke a registered watcher when a particular handle is created. Each generation closes a structural class. None has rendered its predecessor obsolete. On 2026 Windows 11 25H2 all six are simultaneously load-bearing.

flowchart LR G1["Gen 1
NT 3.1, Jul 1993
Single global namespace"] --> G2 G2["Gen 2
Vista, Jan 2007 / SP1, Feb 2008
Session 0 + MIC + ObRegisterCallbacks"] --> G3 G3["Gen 3
Windows 8, Oct 2012
AppContainer / Lowbox / per-package directory"] --> G4 G4["Gen 4
Windows 10 RTM, Jul 2015
VBS / IUM secure-kernel namespace"] --> G5 G5["Gen 5
Windows Server 2016, Oct 2016
Server Silos / silo-scoped views"] --> G6 G6["Gen 6
MS15-090, Aug 2015 ->
symbolic-link class hardening"]

Generation numbering is thematic (by isolation capability introduced) rather than strictly chronological. Gen 6 (MS15-090, August 11, 2015) predates Gen 5 (Windows Server 2016, October 12, 2016) by 14 months; the numbering reflects the logical layering of isolation mechanisms, not their calendar sequence.

4.1 Generation 2 -- Session 0 isolation, integrity levels, ObRegisterCallbacks

Vista shipped three mechanisms in one release window because the structural failure had three faces.

The first was Session 0 isolation. From Vista forward, services run in Session 0 alone; the first interactive logon starts at Session 1. Each session gets its own subtree at \Sessions\<n>\BaseNamedObjects, \Sessions\<n>\Windows\WindowStations, and \Sessions\<n>\DosDevices. The Win32 Local\ prefix routes through kernel32!BaseGetNamedObjectDirectory into the per-session BNO; Global\ routes into the shared \BaseNamedObjects [@ms-termserv-kernel-object-namespaces]. The Wikipedia Shatter article preserves the architectural fix verbatim: "Local user logins were moved from Session 0 to Session 1, thus separating the user's processes from system services that could be vulnerable" [@en-wikipedia-shatter-attack]. After Vista an interactive user could no longer SendMessage(WM_TIMER) into a service's hidden window because the user and the service no longer shared a window station.

The second mechanism was Mandatory Integrity Control. Vista introduced a new ACE type, SYSTEM_MANDATORY_LABEL_ACE, attached to every object's security descriptor. Each token carries one of four integrity levels (Low S-1-16-4096, Medium S-1-16-8192, High S-1-16-12288, or System S-1-16-16384), and the Security Reference Monitor compares the requester's level against the object's level after path resolution succeeds [@en-wikipedia-mandatory-integrity-control]. MIC is not a namespace partition. A Low-IL process and a Medium-IL process resolve the same \BaseNamedObjects directory; only the open is denied at the leaf. The structural property MIC adds is that the leaf check is unbypassable from user mode; the check fires regardless of which DACL the object carries.

The third mechanism was ObRegisterCallbacks. Microsoft's wdm.h documentation records the API's first ship date verbatim: "Available starting with Windows Vista with Service Pack 1 (SP1) and Windows Server 2008" [@ms-obregistercallbacks]. The API lets a KMCS-signed driver intercept handle creation and handle duplication on PsProcessType, PsThreadType, and the desktop object type. The registration carries an Altitude (a FltMgr-style collision key) and an array of OB_OPERATION_REGISTRATION records [@ms-ob-callback-registration]. Pre-operation callbacks can strip access-mask bits before the handle is granted; post-operation callbacks fire for logging. The parallel API PsSetCreateProcessNotifyRoutineEx [@ms-pssetcreateprocessnotifyroutineex] covers process creation. Together, these are the kernel-mode primitives every modern EDR product depends on; they ship inside the Object Manager itself and they are the reason an EDR knows when something opens a handle to lsass.exe.

4.2 Generation 3 -- AppContainer and the lowbox token

Windows 8 shipped on October 26, 2012 [@en-wikipedia-windows-8]. Modern / UWP apps downloaded from the Microsoft Store needed a sandbox finer-grained than per-session BNO. The Vista path rewriting in kernel32!BaseGetNamedObjectDirectory happened in user mode, which made it the wrong layer for a sandbox: a hostile renderer could in principle bypass the user-mode rewrite. The new layer moved into the kernel.

Each UWP / MSIX process runs under a special token type, the AppContainer / LowBox token (referred to in kernel code as the lowbox token), created by NtCreateLowBoxToken. The token carries a TOKEN_APPCONTAINER_INFORMATION block that names the process's package SID (S-1-15-2-...) and an AppContainerNumber. Inside ObpLookupObjectName, before the path is walked, the kernel checks whether the caller's token is a lowbox token; if it is, lookups of \BaseNamedObjects\X, \RPC Control\X, and other rewriteable paths get redirected into \Sessions\<n>\AppContainerNamedObjects\<package-sid>\X. The user-mode caller never sees the rewrite. The package-SID directory is created by SYSTEM at process-creation time with a security descriptor that grants the package SID, and only the package SID, full access. Microsoft's wording is precise: AppContainer works by "sandboxing the application kernel objects, the AppContainer environment prevents the application from influencing, or being influenced by, other application processes" [@ms-appcontainer-isolation].

The AppInfo service, which is responsible for creating the new application, calls the undocumented API CreateAppContainerToken to do some internal housekeeping. Unfortunately this API creates object directories under the user's AppContainerNamedObjects object directory to support redirecting BaseNamedObjects and RPC endpoints by the OS. -- James Forshaw, Project Zero Issue 1550 [@p0-issue1550]

The residual class the AppContainer model has not closed is the one Forshaw's August 30, 2018 Project Zero post [@p0-issue1550] documents: because the SYSTEM-side AppInfo service has to write into the user's AppContainerNamedObjects subtree to set up redirection, an unprivileged caller can race the directory creation and end up planting a symbolic link the SYSTEM service then follows. The class -- "SYSTEM-privileged directory creation in user-controllable territory" -- is the worked example of why "the kernel rewrites the name" is an isolation property only when the SYSTEM helpers also use the rewrite.

4.3 Generation 4 -- VBS trustlets and the IUM secure-kernel namespace

Windows 10 RTM shipped on July 29, 2015 [@en-wikipedia-windows-10-version-history]. The Virtualization-Based Security (VBS) feature set introduced a parallel object-manager-shaped namespace that lives in Virtual Trust Level 1 (VTL1) and is inaccessible to the VTL0 NT kernel. Inside VTL1 the Secure Kernel (securekernel.exe) maintains its own root, its own type registry, and its own handle-table machinery. The VTL0 NT kernel can see trustlet processes -- the per-trustlet user-mode containers running in Isolated User Mode (IUM) -- but it cannot reach into their secure-side state.

Alex Ionescu's Black Hat USA 2015 talk Battle of SKM and IUM [@ionescu-bh2015-pdf] is the canonical inventory of the inbox Trustlet IDs at ship: Trustlet 0 is the Secure Kernel Process hosting Device Guard; Trustlet 1 is LSAISO.EXE for Credential Guard; Trustlet 2 is VMSP.EXE hosting the virtual TPM; Trustlet 3 is the vTPM provisioning trustlet. Each is identified by a Trustlet ID and reachable only through narrow Secure Kernel ALPC ports. The VBS Trustlets piece in this series unpacks the threat model.

4.4 Generation 5 -- Server Silos and the silo-scoped namespace

Windows Server 2016 shipped on October 12, 2016 [@en-wikipedia-windows-server-2016]. Microsoft needed a Linux-namespaces equivalent so that container runtimes -- Docker, containerd, and the Azure Kubernetes Service Windows-node pods that followed -- could host adjacent workloads on one kernel. The answer was Server Silo: a new OBJECT_TYPE registered alongside Job, Process, and Thread, that carries its own RootDirectory, DosDevicesDirectory, and ServerSiloGlobals. A process attached to a silo via PsAttachSiloToCurrentThread sees the silo's namespace as its root; the silo's \GLOBAL??\C: resolves to the silo's \Device\HarddiskVolume*, which is a different Device object from the host's. Job objects [@ms-job-objects] provide the cgroups-equivalent resource-accounting dimension; the Silo type builds on top.

The canonical reverse-engineering reference is Daniel Prizmant's July 2020 Unit 42 writeup, which spells out the architecture: "job objects are used in a similar way control groups (cgroups) are used in Linux, and... server silo objects were used as a replacement for namespaces support in the kernel" [@unit42-rev-eng-windows-containers].

The companion piece, Prizmant's June 2021 Siloscape [@unit42-siloscape], is the first known malware family that escapes the silo boundary: Prizmant named the malware "Siloscape (sounds like silo escape) because its primary goal is to escape the container, and in Windows this is implemented mainly by a server silo." James Forshaw's April 2021 Project Zero post Who Contains the Containers? [@p0-who-contains-containers] is the four-LPE companion disclosure. Microsoft's standing position is that Server Silo is not a security boundary; the Hyper-V Container, which adds a Hyper-V VM around the container's silo, is the security-boundary product.

4.5 Generation 6 -- the symbolic-link hardening continuum

The cross-cutting hardening generation closes the symlink subclass that recurred in Generations 1, 3, and 5. MS15-090 shipped on August 11, 2015 [@ms-ms15-090] and "corrects how Windows Object Manager handles object symbolic links created by a sandbox process, by preventing improper interaction with the registry by sandboxed applications, and by preventing improper interaction with the filesystem by sandboxed applications." The bulletin's canonical Object Manager CVE is CVE-2015-2428 [@nvd-cve-2015-2428], described verbatim as the case where the "Object Manager in Microsoft Windows... does not properly constrain impersonation levels during interaction with object symbolic links that originated in a sandboxed process." Subsequent Windows 10 builds added OBJ_DONT_REPARSE, an open-time flag that disables symbolic-link substitution for callers willing to opt in, and post-Siloscape patches in 2021 closed NtSetInformationSymbolicLink retargeting from inside a silo.

The scope document for this article originally attributed MS15-090 to CVE-2015-2528 and CVE-2015-1463. Independent NVD verification confirmed neither is correct: CVE-2015-2528 [@nvd-cve-2015-2528] is the MS15-102 Task Management EoP, and CVE-2015-1463 [@nvd-cve-2015-1463] is a ClamAV denial-of-service crash. The canonical MS15-090 OM-symlink CVE is CVE-2015-2428. Separately, CVE-2018-0824 [@nvd-cve-2018-0824] is a CWE-502 COM deserialization issue that joined the CISA KEV catalog on 2024-08-05, not a namespace-squatting CVE.

The residual subclass MS15-090 did not close was the per-session \?? DosDevices remapping path under impersonation. A low-privileged process whose token is impersonated by a SYSTEM service can plant a DefineDosDevice remapping that survives into the impersonation-time \?? view, and the SYSTEM-side activation-context resolver then opens the redirected path while running with elevated privileges. The canonical 2023 worked example is HackSys's Activation Context Hell -- DosDevices Remapping Attack under Impersonation [@hacksys-activation-context-hell], which targets the CSRSS / SxS activation-context resolver and shipped as CVE-2023-35359 [@nvd-cve-2023-35359], with the closely-related CVE-2022-22047 [@nvd-cve-2022-22047] covering the underlying CSRSS surface. The mitigation has to live inside the impersonation-aware \?? resolver in the SYSTEM caller, not at the symlink-creation gate.

Note: Every generation since Generation 1 has layered a new isolation primitive on top of the prior generation. None has rendered its predecessor obsolete. On 2026 Windows 11 25H2 all six generations coexist simultaneously: a UWP / MSIX app inside a Server Silo on a VBS-enabled host is session-partitioned, lowbox-rewritten, silo-scoped, VTL0-confined, integrity-gated, and watched by every loaded EDR's ObRegisterCallbacks filter. Each layer adds an independent enforcement point at ObpLookupObjectName time.

Six generations of isolation primitives is a tidy story, but it has glossed the most important question. What is the actual kernel data structure all six generations parameterize? What does the path-walk algorithm look like, what is the type registry, and where does the hash table live?

5. The four load-bearing primitives

If you remember one paragraph from this article, make it this one. The Object Manager namespace is built out of four kernel data structures: an OBJECT_HEADER that prefixes every named object in memory, an OBJECT_TYPE singleton that owns each type's method table, a ParseProcedure that delegates path resolution to the owning subsystem when needed, and an OBJECT_DIRECTORY hash table that maps names to objects. Every Windows security boundary you have read about is a parameter to one of these four pieces. The next eight subsections rebuild them one at a time.

flowchart TB OD["OBJECT_DIRECTORY
(37-bucket hash table)"] -->|"hash(name) % 37"| OH OH["OBJECT_HEADER
(PointerCount, HandleCount,
TypeIndex, InfoMask,
SecurityDescriptor, Body offset)"] -->|"TypeIndex XOR
ObHeaderCookie"| OT OT["OBJECT_TYPE singleton
(in nt!ObTypeIndexTable)"] -->|"TypeInfo"| TI TI["TYPE_INFO method table
(Dump, Open, Close, Delete,
ParseProcedure,
Security, QueryName, ...)"] OH -->|"Body[]"| BODY["Type-specific body
(EPROCESS, FILE_OBJECT,
SECTION_OBJECT, ...)"]

5.1 OBJECT_HEADER

Every named kernel object lives in non-paged pool. Immediately before each object's typed body sits an OBJECT_HEADER, a 0x30-byte (48-byte on x64) structure that the Object Manager owns. PointerCount and HandleCount are the two reference counts: the former tracks raw kernel-mode pointer references, the latter tracks user-mode handles. TypeIndex is a single byte that indexes into the nt!ObTypeIndexTable to find the object's type singleton; since Windows 10 1709, the byte is XOR-obfuscated against the per-boot nt!ObHeaderCookie so that simple type confusion is non-trivial.

InfoMask is a bitmap of optional sub-headers that may precede the main header: OBJECT_HEADER_NAME_INFO for named objects, OBJECT_HEADER_QUOTA_INFO for objects that charge a quota block, OBJECT_HEADER_HANDLE_INFO for objects that need per-process handle accounting. SecurityDescriptor is a tagged pointer to the object's DACL/SACL. Body[] is the offset at which the type-specific payload begins; for a process object that payload is an EPROCESS, for a file it is a FILE_OBJECT, and so on. The canonical reference is Chapter 8 of Windows Internals 7th Edition Part 1 [@microsoftpressstore-wininternals7-part1].

The per-object header (`nt!_OBJECT_HEADER`) that precedes every named kernel object in non-paged pool. Carries reference counts (`PointerCount`, `HandleCount`), a `TypeIndex` byte that points into `nt!ObTypeIndexTable` (XOR-obfuscated against `nt!ObHeaderCookie` since Windows 10 1709), an `InfoMask` describing optional sub-headers, a `SecurityDescriptor` pointer, and the offset to the typed `Body[]`.

The TypeIndex XOR-with-cookie is one of the smallest kernel hardening changes Microsoft has shipped: a single byte that prevents a poisoned OBJECT_HEADER from naming an arbitrary type after a heap-corruption primitive. The cookie is per-boot and lives in nt!ObHeaderCookie. The hardening is documented in Windows Internals 7th Edition Chapter 8 [@microsoftpressstore-wininternals7-part1] and in Geoff Chappell's reverse-engineering studies; Microsoft has not, as of 2026, published a Learn-hosted reference for the cookie itself.

5.2 OBJECT_TYPE

OBJECT_TYPE is the per-type singleton. There is exactly one OBJECT_TYPE per registered kernel type, and they live in \ObjectTypes. On Windows 11 25H2 the count sits at roughly seventy-five: Type, Directory, SymbolicLink, Token, Job, Process, Thread, Section, Key, File, Event, Mutant, Semaphore, Timer, WindowStation, Desktop, Device, Driver, IoCompletion, ALPC Port, EtwRegistration, Silo, and dozens more.

The per-type singleton (`nt!_OBJECT_TYPE`) that owns each kernel type's method table. The `TypeInfo` field carries eight procedure pointers and one offset field (WaitObjectFlagOffset): `DumpProcedure`, `OpenProcedure`, `CloseProcedure`, `DeleteProcedure`, `ParseProcedure` (the path-resolution callback), `SecurityProcedure`, `QueryNameProcedure`, `OkayToCloseProcedure`, and a `WaitObjectFlagOffset` offset for waitable types. Every `OBJECT_TYPE` instance is reachable through `\ObjectTypes`.

The TypeInfo field on each OBJECT_TYPE carries eight procedure pointers and one offset field (WaitObjectFlagOffset). The most consequential is the ParseProcedure. When ObpLookupObjectName is walking a path component-by-component, and a step lands on an object whose OBJECT_TYPE defines a ParseProcedure, the OM hands the residual path and the desired access to that procedure, which becomes the namespace authority below that point. That is how the registry's Key type, the I/O Manager's Device type, and the various WMI / Volume-Manager subsystems insert themselves into the namespace without the Object Manager having to know any of their internal structure [@en-wikipedia-object-manager].

5.3 The parse procedure

ObpLookupObjectName walks \Foo\Bar\Baz\...\Leaf left-to-right. At each component the walker does one of three things. The common case is a hash-table lookup in the current OBJECT_DIRECTORY's 37 buckets to find the child object by name. The second case is SymbolicLink substitution: if the child object's type is SymbolicLink, the walker substitutes the link target and re-enters the walk at the substitution. The third and most consequential case is parse-procedure handoff. If the child object's OBJECT_TYPE has a non-null ParseProcedure, the walker stops, hands the residual path string to that procedure, and lets it decide what to do.

The load-bearing method pointer on each `OBJECT_TYPE`'s `TypeInfo` field. When `ObpLookupObjectName` encounters an object whose type defines a `ParseProcedure`, the residual path is handed to that procedure for resolution. The two canonical parse procedures are `IopParseDevice` (for the `Device` type, which delegates further resolution to the device's owning driver via `IRP_MJ_CREATE`) and `CmpParseKey` (for the `Key` type, which walks the registry hive).

IopParseDevice is the parse procedure for the Device type. When the walker reaches \Device\HarddiskVolume1 and is asked to continue with \Users\me\file.txt, the I/O Manager builds an IRP_MJ_CREATE packet, dispatches it to the filesystem driver that owns the volume (NTFS, ReFS, ExFAT, FAT32, or one of several others), and lets that driver walk the rest of the path inside its own on-disk structures. The driver returns a FILE_OBJECT, which the Object Manager packages into a handle.

CmpParseKey is the parse procedure for the Key type. When the walker reaches \REGISTRY and is asked to continue with \MACHINE\Software\Microsoft\Windows, the Configuration Manager takes over and walks the in-memory hive structures.

The structural consequence is profound. Every named file in Windows is, technically, a leaf in the Object Manager namespace. NTFS, ReFS, ExFAT, and the registry are not separate naming systems; they are parse-procedure callbacks that hand FILE_OBJECT or KEY bodies back to the OM.

sequenceDiagram participant User as User Process participant OM as ObpLookupObjectName participant Dir as \GLOBAL?? OBJECT_DIRECTORY participant Dev as \Device\HarddiskVolume1 (Device type) participant Drv as NTFS Driver User->>OM: NtCreateFile("\??\C:\Users\me\file.txt") OM->>OM: rewrite \??\ -> \Sessions\\DosDevices\ OM->>Dir: lookup "C:" Dir-->>OM: SymbolicLink -> \Device\HarddiskVolume1 OM->>OM: substitute, re-enter walk OM->>Dev: lookup \Device\HarddiskVolume1 Dev-->>OM: type=Device, has ParseProcedure OM->>Drv: IopParseDevice with "\Users\me\file.txt" Drv->>Drv: IRP_MJ_CREATE: walk MFT, find file Drv-->>OM: FILE_OBJECT OM-->>User: HANDLE

5.4 The 37-bucket directory hash

OBJECT_DIRECTORY is a 37-bucket open-hash table. The hash function is RtlHashUnicodeString, applied to each component name. Thirty-seven was the prime Cutler picked in 1993; the constant has not changed in thirty-three years. The folk-knowledge corroboration is in Chapter 8 of Windows Internals 7th Edition Part 1 and in Forshaw's Windows Security Internals Chapter 8; Microsoft has never published a Learn-hosted spec for the constant [@nostarch-windows-security-internals].

The 37-bucket open-hash table (`nt!_OBJECT_DIRECTORY`) that lives at every interior node of the Object Manager tree. Keys are `UNICODE_STRING` component names; the hash is `RtlHashUnicodeString` modulo 37. Each bucket is a linked list of `OBJECT_DIRECTORY_ENTRY` records that point at the next-level `OBJECT_HEADER`. Reading the tree requires `Directory`-`TRAVERSE` rights on the parent.

The 37-bucket constant from 1993 has not changed in thirty-three years. On a 2026 Windows 11 25H2 box with several hundred MSIX packages each owning an \AppContainerNamedObjects\<package-sid>\ subtree, average bucket chains run several entries deep. Collision pressure on the constant is the open problem returned to in Section 9.

5.5 The lowbox redirect inside ObpLookupObjectName

This is the subsection that earns the second aha moment of the article.

When the calling thread's primary token is a lowbox token, ObpLookupObjectName consults the token's AppContainerNumber and package SID before it begins the walk. Lookups that would otherwise resolve into \BaseNamedObjects or \RPC Control are rewritten into \Sessions\<n>\AppContainerNamedObjects\<package-sid>\. The rewrite happens transparently to the user-mode Win32 caller, which still thinks it asked for \BaseNamedObjects\X.

A specialised token type produced by `NtCreateLowBoxToken` that carries a `TOKEN_APPCONTAINER_INFORMATION` block (with a package SID `S-1-15-2-...` and an `AppContainerNumber`). When a process runs under a lowbox token, `ObpLookupObjectName` rewrites every named-object lookup into the per-package directory `\Sessions\\AppContainerNamedObjects\\` before path walking begins. The user-facing brand for the lowbox-token mechanism. Every UWP / MSIX / Windows Store app runs in an AppContainer. The Windows API surface is unchanged for the app; the Object Manager rewrites every named-object name into a per-package subtree, gating cross-package coordination at the namespace layer. The Microsoft Learn page describes this as "Sandboxing the application kernel objects, the AppContainer environment prevents the application from influencing, or being influenced by, other application processes" [@ms-appcontainer-isolation].

The aha moment is structural. AppContainer is not a containment mechanism the way you might first picture it. It is a name-translation mechanism. The lowbox token tells the kernel which directory to rewrite every name into; the sandbox is, at root, a hash-table indirection inside the kernel's path-walk function. The Edge renderer process cannot name \BaseNamedObjects\GlobalEvent_Foo because the kernel rewrites that name into \Sessions\1\AppContainerNamedObjects\S-1-15-2-...\Global\GlobalEvent_Foo before lookup even begins. The "sandbox" is a hash-table redirect.

5.6 The Silo OBJECT_TYPE and silo-scoped views

Silo is itself a registered OBJECT_TYPE. Each silo instance carries a silo-scoped RootDirectory, DosDevicesDirectory, and ServerSiloGlobals (with the silo's own registry-hive root and per-silo BaseNamedObjects root). PsAttachSiloToCurrentThread switches the thread's namespace view; once attached, every Object Manager lookup runs through the silo's roots instead of the host's. Job objects, which provide the cgroups-equivalent resource-accounting substrate, are the underlying primitive the Silo type extends [@ms-job-objects]. The structural design history is in Prizmant's reverse-engineering writeup [@unit42-rev-eng-windows-containers].

A specialised `Job`-derived kernel object (`OBJECT_TYPE` Silo) introduced in Windows Server 2016 that carries silo-scoped `RootDirectory`, `DosDevicesDirectory`, and `ServerSiloGlobals` fields. A thread attached to a silo via `PsAttachSiloToCurrentThread` sees the silo's namespace as its root; the silo's `\GLOBAL??\C:` resolves to the silo's `\Device\HarddiskVolume*`, which is a different `Device` object from the host's. Server Silo is the substrate underneath Windows Server Containers and WSL1.

5.7 The Secure Kernel's parallel namespace

Inside VTL1, the Secure Kernel maintains a separate Object Manager tree with its own root, its own type registry, and its own handle-table machinery. The VTL0 NT kernel cannot enumerate this tree; the only cross-VTL traffic is the narrow ALPC interface each trustlet publishes. Ionescu's BH2015 inventory (Trustlet IDs 0 through 3 at ship, growing in subsequent releases) is the canonical primary [@ionescu-bh2015-pdf].

A user-mode process running in Isolated User Mode under the VTL1 Secure Kernel. Each trustlet is signed with both the Windows System Component Verification EKU (1.3.6.1.4.1.311.10.3.6) and the IUM EKU (1.3.6.1.4.1.311.10.3.37), runs at Signature Level 12, and is reachable from VTL0 only through narrow ALPC ports. LSAISO.EXE (Credential Guard), VMSP.EXE (virtual TPM host), and the vTPM provisioning trustlet are the inbox examples.

5.8 The handle table

The namespace is the name side; the per-process HANDLE_TABLE is the access side. Once a handle exists in a process, no name lookup happens on subsequent use; the kernel dereferences the handle through a three-level radix tree indexed by the 32-bit handle value, lands on an OBJECT_HEADER, and operates on the body. This is why ObRegisterCallbacks fires on handle creation and duplication rather than on every use, and why an inherited handle bypasses the callback entirely. The structural consequence -- that the Object Manager is the gate at name resolution but not at every operation -- comes back in Section 8.

Now you know the data structure. But what does the actual tree look like in 2026? What does \ contain on a Windows 11 25H2 box, and which security boundary lives in each top-level directory?

6. The 2026 top-level directory atlas

Open WinObj.exe as administrator on a Windows 11 25H2 machine and the root directory at \ carries roughly twenty entries. The table below catalogues the load-bearing ones. Each row names the directory, the security boundary it physically realises, and a representative exploit class that has been thrown at it. The driver kit's Object Directories reference [@ms-object-directories] is Microsoft's canonical inventory.

Top-level directory	What it contains	Which boundary it enforces	Exploit class
`\ObjectTypes`	The ~75 `OBJECT_TYPE` singletons (`Process`, `Thread`, `Section`, `Key`, `File`, `Token`, `Job`, `Silo`, etc.)	Meta -- the type registry the rest of the namespace depends on	Type confusion (mitigated by `ObHeaderCookie` since Windows 10 1709)
`\Device`	Driver-published device objects (`\Device\HarddiskVolume*`, `\Device\Tcp`, `\Device\Tpm`, `\Device\NamedPipe`, `\Device\Mailslot`, `\Device\Vmbus`, `\Device\KsecDD`, `\Device\CNG`)	The I/O Manager's surface; each driver's parse procedure consumes residual paths	Bait-and-switch on `\Device` (a low-privilege user redirects a privileged opener through a planted symbolic link)
`\Driver`, `\FileSystem`	Loaded `DRIVER_OBJECT` registries	KMCS / HVCI driver-load gate	Vulnerable signed-driver class (BYOVD)
`\GLOBAL??`	The machine-wide DosDevices view -- where `C:` and `D:` are symlinks to `\Device\HarddiskVolume*`	Cross-session drive-letter map	Symlink redirect across session boundary
`\??`	The per-session DosDevices alias, falling through to `\GLOBAL??`	Session-scoped drive-letter map	The HackSys / CVE-2023-35359 worked example: a low-privilege caller plants a `DefineDosDevice` remapping that survives into the impersonation-time `\??` view, and the SYSTEM-side activation-context resolver opens the redirected path
`\BaseNamedObjects`	The global / `Global\`-prefixed-only BNO	Cross-session named-object visibility	Pre-Vista squatting class (closed by Generation 2)
`\Sessions\<n>\`	Per-session subtrees (BNO, DosDevices, WindowStations, AppContainerNamedObjects)	Session boundary (Generation 2)	Shatter attacks (closed by Generation 2)
`\Sessions\<n>\AppContainerNamedObjects\<package-sid>\`	Per-package UWP / MSIX lowbox namespace	AppContainer / lowbox boundary (Generation 3)	Forshaw P0 Issue 1550 arbitrary-directory creation race
`\RPC Control`	Every named LRPC ALPC port (every COM call lands here)	RPC endpoint visibility	Endpoint squatting against named LRPC ports
`\KnownDlls`, `\KnownDlls32`	Pre-mapped `Section` objects for system DLLs	Loader supply-chain	`DefineDosDevice` + `\??` symlink-plant trick (closed in NTDLL July 2022, build 19044.1826)
`\KernelObjects`	System-defined events (`LowMemoryCondition`, `HighMemoryCondition`, etc.)	Kernel-internal visibility	None public
`\Callback`	System-defined `Callback` objects (`ExCallback` slots drivers register against)	Kernel API extension surface	Driver-callback abuse
`\Security`	LSA-private endpoints	LSA / authentication isolation	Credential-theft (the LSAISO trustlet via Generation 4)
`\Windows`	BNO-redirect surface and `SharedSection`	Win32 subsystem shared state	Cross-session Win32 state leakage
`\Silos\<id>`	Per-container silo subroots on Server SKUs	Server Silo boundary (Generation 5)	Siloscape -- symlink retarget out of the silo
`\BNOLINKS`	The boundary-keyed private-namespace index	`CreatePrivateNamespace` cross-session/cross-package IPC	None public; the directory itself is RE-derived

flowchart LR subgraph EdgeRenderer["Microsoft Edge Renderer (lowbox token)"] K32["CreateMutexW(L'Global\\Foo')"] end K32 -->|"NtCreateMutant, OBJECT_ATTRIBUTES"| OB subgraph KernelOb["ObpLookupObjectName"] OB["Read caller token
token.AppContainerNumber
token.PackageSid"] OB -->|"rewrite name"| RW["Rewrite '\\BaseNamedObjects\\Global\\Foo'
to
'\\Sessions\\1\\AppContainerNamedObjects\\
S-1-15-2-...\\Global\\Foo'"] RW --> WALK["walk the rewritten path"] end WALK --> Dir["\\Sessions\\1\\AppContainerNamedObjects\\
S-1-15-2-...\\Global\\
(per-package OBJECT_DIRECTORY,
DACL allows only package SID)"]

The \BNOLINKS directory deserves a separate paragraph because it is not on Microsoft Learn. NtCreatePrivateNamespace is the kernel-side syscall behind the Win32 CreatePrivateNamespace API [@ms-createprivatenamespacew]; the caller passes a boundary descriptor built by CreateBoundaryDescriptor [@ms-createboundarydescriptorw] plus one or more SIDs added via AddSIDToBoundaryDescriptor [@ms-addsidtoboundarydescriptor]. The kernel materialises one \BNOLINKS entry per (alias_prefix, boundary_descriptor_hash) tuple; two callers that pass the same lpAliasPrefix but different boundary descriptors land on different directories. The native signature is documented in the PHNT-derived NtDoc mirror [@ntdoc-ntcreateprivatenamespace], and the OBJECT_BOUNDARY_DESCRIPTOR structure layout is at ntdoc.m417z.com/object_boundary_descriptor [@ntdoc-object-boundary-descriptor]. The Win32 Object Namespaces overview [@ms-object-namespaces] is Microsoft's only published user-mode reference; the \BNOLINKS directory name itself is reverse-engineering-derived.The \BNOLINKS directory is documented only through reverse engineering of ntoskrnl.exe -- via Forshaw's NtObjectManager and System Informer's PHNT headers -- not on Microsoft Learn. The user-mode API surface (CreatePrivateNamespace, CreateBoundaryDescriptor, AddSIDToBoundaryDescriptor) is fully documented. The provenance gap is worth flagging when you cite the directory by name.The \KnownDlls LPE class was, for a decade, the canonical example of how a DACL plus loader-side validation could lock down a supply-chain anchor. Forshaw's August 2018 P0 post first sketched a DefineDosDevice + \?? symlink-plant chain that could land a forged Section object into \KnownDlls; Clement Labro (itm4n) implemented the attack as the PPLdump tool and wrote companion posts on both itm4n.github.io [@itm4n-lsass-runasppl] and the SCRT team blog [@blog-scrt-bypassing-lsa-protection-in-userland]. The class was closed in NTDLL by Windows 10 21H2 build 19044.1826; itm4n confirms the patch in The End of PPLdump [@itm4n-the-end-of-ppldump]: "A patch in NTDLL now prevents PPLs from loading Known DLLs."

{` const MAX_DIRECTORY_BUCKETS = 37;

function rtlHashUnicodeString(name) { let h = 0; for (const ch of name.toUpperCase()) { h = (h * 31 + ch.charCodeAt(0)) >>> 0; } return h % MAX_DIRECTORY_BUCKETS; }

function makeDir() { return { buckets: Array(MAX_DIRECTORY_BUCKETS).fill(null).map(() => []) }; }

function addChild(dir, name, child) { dir.buckets[rtlHashUnicodeString(name)].push({ name, child }); }

const root = makeDir(); const device = makeDir(); device.parseProcedure = true; device.type = 'Device'; const sessions = makeDir(); addChild(root, 'Device', device); addChild(root, 'Sessions', sessions); addChild(root, 'BaseNamedObjects', makeDir());

lookupObjectName('\\Device\\HarddiskVolume1\\Users\\me\\file.txt', root); `}

The walk is the algorithm. The 37 is the bucket count Cutler picked in 1993. The parse-procedure handoff is where the I/O Manager and the Configuration Manager and dozens of other subsystems insert themselves into the tree. Now turn the question around: Windows bet on one tree. What did the kernels that did not bet on one tree do, and why?

7. How other kernels name kernel objects

Three kernels, three different bets. Linux took the namespace and split it into per-resource-class clones -- one for mounts, one for PIDs, one for IPC, one for the network stack, one for users, one for hostnames, one for cgroups, one for time -- and never built a unified tree. macOS / Darwin gave each task its own Mach port-right namespace and let launchd broker named-service lookups. Plan 9 from Bell Labs was the academic ancestor of "every named OS resource is a filesystem path," and the design Cutler imported into NT.

7.1 Linux: per-resource namespaces

Linux ships eight namespace types, each governed by a CLONE_NEW* flag passed to clone(), unshare(), or setns(): mount, PID, network, IPC, user, UTS, cgroup, and time. The namespaces(7) man page is precise: "A namespace wraps a global system resource in an abstraction that makes it appear to the processes within the namespace that they have their own isolated instance of the global resource" [@man7-namespaces]. Docker, containerd, runc, Kubernetes pods, LXC, and systemd-nspawn all compose these eight flags into a Linux container.

The strength of the Linux design is per-class composability. A process can be in a fresh mount namespace, a fresh PID namespace, and the host's network namespace, all at once. The weakness is the absence of a unified type registry: Linux has no equivalent of \ObjectTypes, no equivalent of the OBJECT_HEADER reference counting that the kernel applies uniformly to every named object. Each resource class has its own lookup function, its own permission model, and its own ownership story. A bug in any one of them is bounded to that one resource class but is also not shared mitigation across the others.

7.2 macOS / Darwin: Mach ports and the bootstrap server

Darwin's kernel-object naming is capability-style. Apple's archive documentation describes the model directly: "each task consists of a virtual address space, a port right namespace, and one or more threads" [@apple-mach-kernel]. Tasks send messages by holding a port right -- a per-task index into a kernel-managed table of Mach ports. There is no single hierarchical namespace; ports are sent over Mach messages, and launchd operates as the bootstrap-server name broker for services that need a stable rendezvous. A separate I/O Registry tree carries device objects.

The strength of the Mach design is that capabilities cannot be forged; you cannot synthesise a port right out of a string the way you can synthesise a path string under Windows. The weakness is the split namespace: device objects live in the I/O Registry, services live behind launchd, and the kernel itself has no equivalent of \BaseNamedObjects as a one-stop shop.

7.3 Plan 9 from Bell Labs

Plan 9 is the design lineage Cutler imported. In Plan 9, every named operating-system resource -- including processes, network connections, devices, and the window system -- surfaces as a path served over 9P. The single hierarchical namespace was the central claim. Plan 9 never reached commercial scale, but its design idea reached production in three places: NT (1993, via Cutler), Linux's /proc, /sys, and FUSE (the 1990s onward), and the various capability-OS research projects (KeyKOS, EROS, seL4) that took the lessons in a different direction.

Primitive	Granularity	Enforcement point	Structural / opt-in	Bypass by privilege	Inheritance gap
Per-Session (NT)	Logon session	`ObpLookupObjectName` + DACL	Structural	`SeDebugPrivilege` short-circuit	Inherited handles cross sessions
AppContainer Lowbox (NT)	Package SID	`ObpLookupObjectName` rewrite	Structural	TCB privileges only	Brokered handles enter
Server Silo (NT)	Container	Process->Silo indirection	Structural	KMCS-signed driver	Host handles cross silos
VBS / IUM Trustlet (NT)	Trust level (VTL)	Hypervisor	Structural	Hypervisor compromise	Cross-VTL ALPC only
Mandatory Integrity Control (NT)	IL band	`SeAccessCheckByType`	Opt-in (per-object SACL)	`SeRelabelPrivilege`	Inherited handles bypass
`ObRegisterCallbacks` (NT)	Per-type, per-driver	Object Manager pre-op callback	Mediation, not partition	KMCS-signed driver	Inheritance bypasses callback
Private Namespace (NT)	Boundary SID-list	`NtCreatePrivateNamespace`	Structural	All SIDs in caller's token	Boundary-keyed
Linux Namespace	Per-resource clone	`setns`/`unshare`/`clone`	Structural	`CAP_SYS_ADMIN`	Fork inherits namespace set
Mach Port Right	Per-task	Capability check on send	Structural (capabilities)	`host_priv` / kernel	Inherited rights on fork

The Object Manager namespace is not a filesystem. There is no disk persistence, no journal, no FAT or MFT, no inode allocator, no per-file DACL in the filesystem sense. Nothing under `\` survives a reboot. Files-on-disk, registry-keys-in-a-hive, and named pipes are leaves in the OM tree, but the actual filesystem implementation lives in NTFS / ReFS / ExFAT drivers reached through the `Device` type's parse procedure.

What the OM namespace shares with filesystems is exactly three things: the path-walk algorithm (left-to-right, component-by-component, with one hash-table lookup per component), the per-directory hash table (analogous to the directory-entry hash filesystems use), and the per-object security descriptor (which the SRM enforces at the same point a filesystem would enforce its DACL).

When you read or write the phrase "Object Manager namespace," the metaphor that is doing real work is "in-memory directory tree the kernel uses to find named objects," not "filesystem in the disk-format sense."

The Windows 2000-era `CreateRestrictedToken` primitive was the wrong layer in 2000 as a standalone sandboxing mechanism -- it could not partition the namespace; it only filtered the caller's SID set against per-object DACLs. Chromium revived it in 2008 as one of four cooperating layers, and that pattern is the canonical 2026 production sandbox shape. The Chromium design document captures the constraints: "The Windows sandbox is a user-mode only sandbox. There are no special kernel mode drivers... The sandbox is provided as a static library that must be linked to both the broker and the target executables" (Chromium Sandbox Design [@chromium-sandbox-md], FAQ [@chromium-sandbox-faq]).

The four layers compose pairwise-orthogonally. The token gates which DACLs the renderer can satisfy at SeAccessCheck time; the job object gates which kernel API surface the renderer can call (UI exceptions, process creation, etc.); the integrity level gates which writes the renderer can perform across MIC label boundaries; the AppContainer lowbox-rewrites every named-object lookup into the per-package directory inside ObpLookupObjectName. A handle that survives all four checks is the only object the renderer can usefully touch. The load-bearing header is sandbox_policy.h, which declares TargetConfig::SetTokenLevel(TokenLevel initial, TokenLevel lockdown), SetJobLevel, SetIntegrityLevel, SetDelayedIntegrityLevel, and SetAppContainerSid, with one verbatim mutual-exclusion note: "Using an initial token is not compatible with AppContainer" [@chromium-sandbox-policy-h].

This is the 2026 production sandbox shape every Chromium-based browser inherits (Edge, Chrome, Brave, Vivaldi, Opera), as do Electron-based apps like Visual Studio Code's renderer processes.

The cross-VTL ALPC ports through which a VTL0 process talks to a VTL1 trustlet are still located in VTL0's `\RPC Control`. An attacker who controls VTL0 can *send* messages to LsaIso even though they cannot *read* LsaIso's internal state. Oliver Lyak's December 2022 *Pass-the-Challenge* result is the canonical worked example ([GitHub: ly4k/PassTheChallenge](https://github.com/ly4k/PassTheChallenge)): the trustlet's pages are never read, but the trustlet's RPC output exfiltrates the secret. The lesson is that VTL1 isolation is a *page-level* read barrier, not a *protocol-level* containment property. The VBS Trustlets piece in this corpus carries the deeper walkthrough.

Windows bet on one tree; Linux bet on eight clone-flag dimensions; Darwin bet on capability-style port-right tables. Each bet has theoretical limits. What are they?

8. What the namespace cannot do

The frame for this section comes from James P. Anderson's 1972 USAF technical report Computer Security Technology Planning Study (ESD-TR-73-51), Section 4.1.1. Anderson is the named originator of the reference-monitor concept and of the four properties such a monitor must satisfy. Wikipedia preserves the modern acronym verbatim: the reference-validation mechanism must be "Non-bypassable... Evaluable... Always invoked... Tamper-proof," and "according to Ross Anderson, the reference monitor concept was introduced by James Anderson in an influential 1972 paper" [@wikipedia-reference-monitor]. The NIST CSRC mirror hosts the original PDF [@csrc-nist-ande72].

Saltzer and Schroeder's 1975 paper The Protection of Information in Computer Systems [@cs-virginia-saltzer-schroeder] added the complete-mediation principle -- "every access to every object must be checked for authority" -- and seven other design principles the reference-validation mechanism must satisfy (economy of mechanism, fail-safe defaults, open design, separation of privilege, least privilege, least common mechanism, psychological acceptability).

Map the Windows Object Manager against the four NEAT properties and the answer is uncomfortable. The namespace partially achieves two (Always-invoked and Tamper-proof), fails Non-bypassable outright, and falls one to two orders of magnitude short of Evaluable.

8.1 Always-invoked: provably gapped

The namespace achieves always-invoked for name-based opens. Every Nt*OpenObject* syscall walks ObpLookupObjectName; there is no path that returns a handle to a named object without going through the lookup. But the namespace cannot achieve always-invoked for handle inheritance. A child process inherits handles from CreateProcess(bInheritHandles=TRUE) without going through the OM at all. The handles already exist in the parent's HANDLE_TABLE; the kernel walks the parent's table, duplicates the entries into the child's table, and the child has live access. No name-lookup, no ObRegisterCallbacks callback, no SRM check. As long as the OS API exposes handle inheritance -- and it is too deeply embedded in 33 years of shipping Windows code to remove -- the Object Manager cannot be the sole reference monitor.

8.2 Tamper-proof: bounded, not absolute

The Object Manager runs in ring 0, under Kernel-Mode Code Signing (KMCS), and -- on machines with Virtualization-Based Security and Hypervisor-protected Code Integrity (HVCI) enabled -- inside a Hyper-V-enforced code-integrity policy. Any kernel-mode adversary who can load a driver bypasses the OM. KMCS and HVCI raise the cost; they do not eliminate the surface. The Bring-Your-Own-Vulnerable-Driver class of attacks (signed but exploitable drivers) is the running residual class, and the historical pattern is that one or two new vulnerable signed drivers surface every quarter.

8.3 Evaluable: provably above threshold

A small enough TCB can be machine-verified. The seL4 microkernel is the canonical demonstration: roughly 9,000 lines of C verified end-to-end against a formal specification (~11 person-years for initial functional correctness per Klein et al. SOSP 2009, and approximately 25 person-years for the full suite of subsequent proofs including information-flow and binary verification) [@sel4-project]. The Object Manager subsystem, the Security Reference Monitor, and the parse procedures the Object Manager delegates to (file-system drivers via IopParseDevice; the registry via CmpParseKey; ALPC; the I/O manager itself) collectively comprise tens of thousands of lines of C, putting the TCB for "open a named object" at one to two orders of magnitude above the verification threshold any current proof system can handle. The Object Manager is not evaluable in the formal sense Anderson required.

8.4 Non-bypassable: the privilege short-circuit

A process holding SeDebugPrivilege (or any privilege that grants PROCESS_VM_* rights) can short-circuit per-directory ACLs. The privilege evaluation happens at SeAccessCheck time, after ObpLookupObjectName has resolved the name. The Object Manager will resolve any path the privileged caller asks for; the gate fires, but it lets the call through. The namespace cannot defend against the holder of SeDebugPrivilege. This is by design -- you want a debugger to be able to attach to anything -- but it is also the structural reason why "lock down the namespace" is not by itself a containment story.

8.5 What else the namespace cannot do

It cannot prevent in-process memory disclosure -- the Pass-the-Challenge limit covered in the Section 7 aside. It cannot defend against a malicious driver -- KMCS, HVCI, and WDAC gate driver load; the namespace itself trusts already-loaded drivers. It cannot eliminate time-of-check / time-of-use racing during a path walk; the walker walks components one at a time, and any reentrant call into the walker is a TOCTOU surface. The mitigation is per-call -- callers pass OBJ_DONT_REPARSE on object-attributes, FILE_FLAG_OPEN_REPARSE_POINT on file opens, or otherwise instruct the path-walker to refuse symbolic-link substitution -- not a structural property of the namespace.

8.6 The honest accounting

The Object Manager namespace is a coordination mechanism, not a containment mechanism. Containment is in the layers above: the session ID, the package SID, the integrity level, the silo ID, the VTL split. The namespace's job is to make those layers enforceable by partitioning the path space so the bad open cannot resolve to the privileged object's name. The layers above decide which partition the caller is in; the namespace's only job is "given a path and a caller, find the object." Anderson 1972 names the kernel mechanism (the reference-validation mechanism with NEAT properties); Saltzer-Schroeder 1975 names the design principles the mechanism must satisfy. The Object Manager is the Windows realisation; it inherits both the strengths and the limits.

The namespace is a coordination mechanism, not a containment mechanism. The containment is in the layers above.

Key idea: The Object Manager is the coordination layer; the containment is in the partition primitives stacked on top (session ID, package SID, integrity level, silo ID, VTL). The namespace's only job is "given a path and a caller, find the object." Every Windows security boundary is a parameter to that one job: a per-directory ACL, a token-keyed name rewrite, or a kernel callback registered against an OBJECT_TYPE.

The provable gaps are real. What is the active research direction in 2026 -- where do attackers and defenders actually meet inside the namespace today?

9. Open problems in 2026

Five open problems sit in active research as of 2026.

9.1 Hash-bucket collision pressure

The 37-bucket constant has not changed since 1993. On a 2026 Windows 11 25H2 machine with several hundred MSIX packages, each owning an \AppContainerNamedObjects\<package-sid>\ subtree, average chain lengths inside \Sessions\1\AppContainerNamedObjects exceed two and routinely run higher under load. The structural impact is small per-lookup (O(chain length) at each component), but it compounds across deep path walks and across the per-VM hot loops in ObpLookupObjectName. Microsoft has not committed to a larger table or a different structure; the constant remains.

9.2 Cross-AppContainer object-directory privacy

Per-AppContainer isolation is the AppContainer model's promise; residual cross-package reads erode it. Forshaw's Project Zero work between 2017 and 2020 documents specific classes; Windows 11 25H2 DACLs are tighter than Windows 10 RTM, but the impersonation-mediated cases survive. The HackSys / CVE-2023-35359 family covered in Section 4.5 is the current realisation of the cross-AppContainer-plus-impersonation surface, and the same broader resource-planting taxonomy Forshaw described in the 2017 Named Pipe Secure Prefixes post [@tiraniddo-named-pipe-secure-prefixes] is still rediscovered every year.

9.3 Silo-escape via routines that ignore silo attachment

Siloscape (June 7, 2021) showed that NtSetInformationSymbolicLink could retarget a silo-scoped symbolic link at a host-scoped path. Microsoft patched the specific function; the class -- kernel routines whose path resolution does not honour Process->Silo->RootDirectory -- remains open. Microsoft's long-standing position is that Server Silo is not a security boundary; Hyper-V Container is the security-boundary product. Container runtimes that depend on Server Silo for tenant isolation are knowingly running outside the supported boundary.

9.4 ObRegisterCallbacks erosion under HVCI

ObRegisterCallbacks requires a KMCS-signed driver, and on HVCI-enabled machines the binary must additionally be HVCI-compatible. Microsoft has progressively raised the compatibility bar -- preventing unsigned drivers, banning common runtime-patching idioms, and tightening the W^X policy. EDR vendors depend on the surface staying open; if HVCI's compatibility bar ever excludes the EDR kernel driver pattern, the in-kernel callback layer is at risk. The CrowdStrike Falcon Sensor outage of July 2024 made the brittleness of in-kernel EDR a public conversation. Microsoft's Defender for Endpoint and EDR-on-Linux eBPF projects point at alternative-mediation futures, but in-kernel ObRegisterCallbacks is still the primary credential-theft sensor.

Note: As attackers ship Hell's Gate / Halo's Gate / direct-syscall stubs to bypass userland EDR hooks, the kernel callback fires regardless. The arms race accordingly shifts to the access-mask-strip vs. impersonate-trusted-parent-PID layer inside the kernel callback itself, with both sides racing to define the right pre-operation policy for lsass.exe handle opens. Watch the Microsoft Security Response Center advisories and the EDR-vendor incident postmortems for the bleeding edge.

9.5 Public benchmark vacuum

No peer-reviewed benchmark compares per-call namespace-lookup cost across the Windows Object Manager, Linux namespaces, and Mach ports. Choice of namespace design at the OS level is a multi-decade commitment; the absence of an empirical comparison forces architecture decisions on theoretical-only grounds. The Linux Kernel Test Robot, the Phoronix Test Suite, and various academic systems-conference benchmarks measure adjacent properties (filesystem-call latency, system-call vector cost), but none publishes head-to-head numbers on the named-object-lookup hot path. This is an open invitation to systems researchers.

Five open problems is a research agenda, not a how-to. How do you actually look at this thing on your own machine?

10. Reading the namespace from a live system

Three tools cover the operational practice: Sysinternals WinObj, Forshaw's NtObjectManager PowerShell module, and WinDbg in kernel mode.

10.1 WinObj on a live system

Download winobj.exe from Sysinternals [@ms-winobj] and run it as administrator. The left pane is the directory tree; the right pane shows the children of the selected directory with their object types. Navigate to \Sessions\1\BaseNamedObjects and read off the named events and mutants every Win32 app in your interactive session has created. Navigate to \Sessions\1\AppContainerNamedObjects and pick an S-1-15-2-... directory; right-click, choose Properties, and read the security descriptor. You will see a single allow-ACE granting full access only to the package SID itself. That ACE is the entire AppContainer sandbox at the namespace layer.

Note: WinObj cannot traverse \ObjectTypes, \Security, or \Sessions\0\ without administrator rights. Without traversal, the enumerate fails silently and the tree looks empty. Always run elevated, and accept that the tool will show the kernel view, not a per-process view.

10.2 NtObjectManager PowerShell

NtObjectManager is Forshaw's PowerShell module that exposes the Object Manager namespace through cmdlets (PowerShell Gallery [@powershellgallery-ntobjectmanager]; GitHub [@p0-sandbox-attacksurface-analysis-tools]). Install with Install-Module NtObjectManager. Useful commands: Get-ChildItem NtObject:\ walks the root; Get-NtType lists the registered OBJECT_TYPE singletons; Get-NtObject \BaseNamedObjects enumerates the global BNO; Get-NtAlpcPort '\RPC Control' lists every LRPC endpoint on the machine. The module wraps the same NTDLL syscalls WinObj uses, but in a scripting surface that composes into automation.

10.3 WinDbg kernel session

In a kernel-mode WinDbg session attached to a target machine (or to a live local kernel via Microsoft's local-kernel debug mode), !object \ dumps the root directory and its children. dt nt!_OBJECT_HEADER <addr>-30 reads the header preceding any object's body (the offset 0x30 is the size of OBJECT_HEADER on x64; subtract that from the body pointer to land on the header -- the field layout is documented in Windows Internals 7th Edition* Chapter 8, Microsoft Press Store [@microsoftpressstore-wininternals7-part1]). `dx -r1 ((nt!_OBJECT_TYPE)nt!PsProcessType[0]).TypeInfo` walks the Process type's method table and lists all eight procedure pointers and the WaitObjectFlagOffset, including the parse procedure.

10.4 The EDR primitive: an ObRegisterCallbacks driver template

The minimal sketch of an in-kernel EDR sensor is four steps. Register an OB_CALLBACK_REGISTRATION for PsProcessType with OB_OPERATION_HANDLE_CREATE | OB_OPERATION_HANDLE_DUPLICATE [@ms-obregistercallbacks]. In the pre-operation callback, examine OperationInformation->Object, derive the target process's PID, and compare it against lsass.exe. If it matches, strip credential-relevant access bits from OperationInformation->Parameters->CreateHandleInformation.DesiredAccess (or duplicate-handle equivalent). The kernel grants the handle with the reduced rights, the attacker's PROCESS_VM_READ is gone before the call returns, and the post-operation callback logs the attempt. The parallel API PsSetCreateProcessNotifyRoutineEx [@ms-pssetcreateprocessnotifyroutineex] covers process creation, which is the other half of the EDR sensor surface.

sequenceDiagram participant A as Attacker process participant NT as nt!NtOpenProcess participant OM as Object Manager participant EDR as EDR Pre-Op Callback participant LSASS as lsass.exe (target) A->>NT: NtOpenProcess(lsass PID, PROCESS_VM_READ | PROCESS_QUERY_INFORMATION) NT->>OM: lookup PsProcessType, target by PID OM->>EDR: fire pre-op callback (handle create) EDR->>EDR: target == lsass.exe? EDR->>EDR: strip PROCESS_VM_READ from DesiredAccess EDR-->>OM: granted = PROCESS_QUERY_LIMITED_INFORMATION OM-->>NT: HANDLE with reduced access NT-->>A: open succeeded (but useless rights)

{` const PROCESS_VM_READ = 0x0010; const PROCESS_VM_WRITE = 0x0020; const PROCESS_VM_OPERATION = 0x0008; const PROCESS_QUERY_INFORMATION = 0x0400; const PROCESS_QUERY_LIMITED_INFORMATION = 0x1000; const PROCESS_CREATE_THREAD = 0x0002; const PROCESS_DUP_HANDLE = 0x0040;

function stripForLsass(desired) { const STRIPPED = PROCESS_VM_READ | PROCESS_VM_WRITE | PROCESS_VM_OPERATION | PROCESS_CREATE_THREAD | PROCESS_DUP_HANDLE | PROCESS_QUERY_INFORMATION; return desired & ~STRIPPED; }

const desired = PROCESS_VM_READ | PROCESS_QUERY_INFORMATION | PROCESS_DUP_HANDLE; console.log('attacker asked for:', '0x' + desired.toString(16)); const granted = stripForLsass(desired) | PROCESS_QUERY_LIMITED_INFORMATION; console.log('EDR pre-op granted:', '0x' + granted.toString(16)); `}

```c OB_OPERATION_REGISTRATION op = { .ObjectType = PsProcessType, .Operations = OB_OPERATION_HANDLE_CREATE | OB_OPERATION_HANDLE_DUPLICATE, .PreOperation = MyPreOp, .PostOperation = MyPostOp, }; OB_CALLBACK_REGISTRATION reg = { .Version = OB_FLT_REGISTRATION_VERSION, .OperationRegistrationCount = 1, .Altitude = RTL_CONSTANT_STRING(L"123456"), .OperationRegistration = &op, }; ObRegisterCallbacks(®, &g_handle); ``` The driver must be KMCS-signed (`IMAGE_DLLCHARACTERISTICS_FORCE_INTEGRITY`) per the wdm.h documentation; an unsigned image returns `STATUS_ACCESS_DENIED` from `ObRegisterCallbacks`. Two drivers cannot pick the same Altitude; collisions return `STATUS_FLT_INSTANCE_ALTITUDE_COLLISION`.

You can now read the namespace, register an EDR-style callback, and dump the type registry. What are the questions readers ask after they finish reading?

11. Frequently asked questions

No. The registry is a separate Windows Executive subsystem implemented in `nt!Cm*`, with its own hive on-disk format and its own in-memory hive structures. It hooks into the Object Manager namespace through one and only one mechanism: the `Key` `OBJECT_TYPE` registers a `ParseProcedure` (`CmpParseKey`) that takes over path walking when the namespace walker reaches `\REGISTRY`. The registry is therefore a *consumer* of the Object Manager, but not part of the Object Manager. Because `\BaseNamedObjects` is the *global* / `Global\`-prefixed-only view, distinct from the per-session BNO at `\Sessions\\BaseNamedObjects`. The Win32 `Local\` prefix routes through `kernel32!BaseGetNamedObjectDirectory` into the per-session BNO; `Global\` routes into the global one [@ms-termserv-kernel-object-namespaces]. Cross-session named-object coordination still needs the global view; per-session isolation lives in the per-session subtree. Because the lowbox token attached to the UWP app's process tells `ObpLookupObjectName` to rewrite the path to `\Sessions\\AppContainerNamedObjects\\Global\Foo` before path walking. Two different UWP apps have two different package SIDs and therefore land on two different directories. The Win32 names look the same; the kernel resolves them to different objects. `\??\C:` is the per-session DosDevices alias; if `C:` is not defined in the current session's `\??`, the walker falls through to `\GLOBAL??\C:`. `\GLOBAL??\C:` is the machine-wide DosDevices symbolic link to `\Device\HarddiskVolume*` -- the real on-disk volume object. The split matters because the per-session `\??` is where per-session drive-letter remappings (`net use X: \\server\share`, `subst Z: C:\foo`, `DefineDosDevice`) live, and the activation-context resolver class covered in Section 4.5 is the exploit family that lives at this boundary. Several top-level directories have `Directory`-`TRAVERSE` ACLs that restrict to SYSTEM and the local Administrators group. Without traversal, the directory enumeration silently fails. `\ObjectTypes`, `\Security`, and `\Sessions\0\` are the directories users most often notice as "missing" when running unelevated. By DACL plus loader-side validation. The directory grants `Directory`-`READ` to everyone but `Directory`-`WRITE` only to SYSTEM and TrustedInstaller. The `Section` objects inside are Authenticode-signed by Microsoft and validated at boot by `smss.exe`. The historical `DefineDosDevice` + `\??` symlink-plant bypass class survived until Windows 10 21H2 build 19044.1826 (July 2022), when an NTDLL patch closed it [@itm4n-the-end-of-ppldump]. `ObRegisterCallbacks` [@ms-obregistercallbacks] and `PsSetCreateProcessNotifyRoutineEx` [@ms-pssetcreateprocessnotifyroutineex] are both fully documented. The HVCI compatibility requirements, the KMCS attestation flow, and the exact policy interactions with Defender for Endpoint's tamper-protection layer are partly implementation-defined; EDR vendor engineering teams maintain private regression suites against successive Windows feature updates. When two or more processes that don't share a session or package must coordinate over a securable directory keyed by a SID-list they agree on at design time. The boundary descriptor is the *agreement primitive*: the kernel requires every SID in the boundary to be in the caller's token. The namespace's `OBJECT_DIRECTORY` lives in `\BNOLINKS`, keyed by the alias-prefix string plus a hash of the boundary descriptor's SID-list (CreatePrivateNamespaceW [@ms-createprivatenamespacew]; Object Namespaces overview [@ms-object-namespaces]; native NtCreatePrivateNamespace [@ntdoc-ntcreateprivatenamespace] and OBJECT_BOUNDARY_DESCRIPTOR [@ntdoc-object-boundary-descriptor] signatures). From inside an AppContainer process the lookup is rewritten into the per-package subtree, so private namespaces are not a substitute for the `windows.applicationModel.*` brokered APIs when cross-package coordination is the goal. A user-mode structure produced by `CreateBoundaryDescriptor` and populated with `AddSIDToBoundaryDescriptor` (plus the optional `CREATE_BOUNDARY_DESCRIPTOR_ADD_APPCONTAINER_SID` flag). Conceptually the descriptor is a SID-list that the caller and every other participant must share via their tokens. Kernel-side the structure is `OBJECT_BOUNDARY_DESCRIPTOR` (Version, Items, TotalSize, Flags). `NtCreatePrivateNamespace` materialises a directory in `\BNOLINKS` keyed by the `lpAliasPrefix` plus a hash of the boundary descriptor's SIDs.

12. Coming back to the WinObj screen

Open WinObj one more time. Navigate back to \Sessions\1\AppContainerNamedObjects and pick the Edge renderer's S-1-15-2-... directory. You can now name everything you are looking at. The directory is an _OBJECT_DIRECTORY instance with 37 hash buckets. You reach it through a token-keyed rewrite that the kernel applies inside ObpLookupObjectName before path walking begins. Its security descriptor grants GenericAll only to the package SID. Every EDR loaded on this machine has registered an ObRegisterCallbacks filter on PsProcessType, watching for handle creations against lsass.exe. If you are running on a Server SKU with Windows Server Containers, the directory might also be silo-scoped, with Process->Silo->RootDirectory indirecting your view of the rest of \.

The four pieces of the 1993 Cutler design have shipped without architectural change for thirty-three years. The six generations of partition primitives stacked on top are all simultaneously load-bearing on Windows 11 25H2. The namespace itself is a coordination mechanism, in Anderson 1972's sense of the reference-validation mechanism, with Saltzer-Schroeder 1975's complete-mediation principle as the design constraint it must satisfy. Containment lives in the partition layers above it: the session, the package, the integrity level, the silo, and the VTL split. Every other article in this corpus -- the Credential Guard piece, the AppContainer piece, the VBS Trustlets piece, the Hyper-V piece, the App Identity piece, the TPM piece -- quietly assumes this tree underneath them.

Key idea: Every Windows security boundary is a path rewrite, a per-directory ACL, a token-keyed name substitution, or a kernel callback against an OBJECT_TYPE. The Object Manager is the data structure underneath them all.

**Key terms.** Object Manager (`Ob`), `OBJECT_HEADER`, `OBJECT_TYPE`, `ParseProcedure`, `OBJECT_DIRECTORY`, Lowbox token, AppContainer, Server Silo, Trustlet / IUM, Boundary descriptor, Session 0 isolation, Mandatory Integrity Control, `ObRegisterCallbacks`, KMCS, HVCI, `\BaseNamedObjects`, `\Sessions\\AppContainerNamedObjects`, `\RPC Control`, `\KnownDlls`, `\BNOLINKS`, `\GLOBAL??`, `\??`.

Review questions.

Why does AppContainer isolation work even when the calling UWP app explicitly asks for Global\X?
What is the relationship between IopParseDevice, \Device\HarddiskVolume1, and IRP_MJ_CREATE?
Which of Anderson 1972's four NEAT properties does the Object Manager achieve cleanly, and which does it provably fail?
Why is ObRegisterCallbacks an enforcement gate only against handle creation and duplication, not against handle use?
Why does the canonical MS15-090 OM-symlink CVE point at CVE-2015-2428 [@nvd-cve-2015-2428] rather than CVE-2015-2528 or CVE-2015-1463?
What is the structural difference between \??\C: and \GLOBAL??\C:, and which one does the HackSys / CVE-2023-35359 worked example abuse?

Recommended reading. Russinovich, Ionescu, and Solomon, Windows Internals, Part 1 (7th edition, Microsoft Press, 2017), Chapter 8 [@microsoftpressstore-wininternals7-part1]. James Forshaw, Windows Security Internals (No Starch Press, 2024), Chapter 8 [@nostarch-windows-security-internals]. Alex Ionescu, Battle of SKM and IUM, Black Hat USA 2015 [@ionescu-bh2015-pdf]. The Google Project Zero blog's symlink mitigations [@p0-symlink-mitigations], arbitrary directory creation [@p0-issue1550], and who contains the containers [@p0-who-contains-containers] posts. James P. Anderson, Computer Security Technology Planning Study [@csrc-nist-ande72].