Windows sandbox and AppContainer escape

Windows sandbox and AppContainer escape

TL;DR: AppContainer is Windows’s process isolation for sandboxed apps (Edge tab processes, UWP apps, Microsoft Office). An exploit lands inside the sandbox first; to do real damage you need to escape. Escape vectors: (1) bug in a broker process that talks to the sandboxed process, (2) abuse of an exposed COM endpoint, (3) bug in win32k that’s reachable from sandbox, (4) bug in a higher-privileged service via IPC, (5) hardware-side-channel info leaks. Companion to browser-exploitation-primer and hevd-stack-overflow-walkthrough.

What an AppContainer is

A Windows process token with a low-integrity SID, an AppContainer SID, and a set of capability SIDs (file access, network, camera, etc.). The token denies access by default; only resources matching its capabilities are accessible.

Concretely:

  • Filesystem: only writable in AppContainer’s per-app folder.
  • Network: only if internetClient capability.
  • Registry: only AppContainer-specific keys.
  • Win32k: severely restricted; many syscalls return error.
  • Kernel objects: cannot access global objects without explicit acl.

A successful exploit inside AppContainer pops a shell that can’t read user files, hit the internet, or escalate via standard means.

Escape strategy 1 — broker process abuse

Sandboxed apps need to do real things (open files via dialog, print, etc.). They call a broker — a higher-privileged process that does it on the sandbox’s behalf.

Brokers expose:

  • COM interfaces.
  • LPC / ALPC channels.
  • Named pipes.
  • File handles passed via duplicateHandle.

Bugs:

  • Broker accepts input from sandbox without sanitizing.
  • Broker performs an operation as a higher-privileged user, with attacker-controlled args.
  • Broker has a memory-safety bug → broker compromise → break out of sandbox via broker’s privileges.

Audit: identify the brokers your sandboxed app talks to. Walk their interfaces. Send malformed input.

Escape strategy 2 — exposed COM endpoint

Many COM servers run outside the sandbox. Some are explicitly callable from sandboxed apps via specific allowed CLSIDs.

Identify which COM CLSIDs are callable:

1

Get-ItemProperty HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Capabilities\AppCompat

(Approximate; actual API requires deeper investigation.)

For each callable COM server: audit its interface. Bugs in COM server = sandbox escape.

Real examples:

  • DCOM activation bugs.
  • IE COM addins reachable from Edge legacy sandbox.

Escape strategy 3 — win32k

Win32k.sys (the windowing subsystem) is the historical biggest sandbox-escape surface. Many bug classes:

  • USER object handling — race conditions during window creation/destruction.
  • Font parsing (less applicable now — fontdrvhost.exe isolation).
  • Palette / DC objects.

For Edge / Chrome sandboxes, win32k lockdown via the ProcessSystemCallDisablePolicy mitigation severely restricts which win32k syscalls are accessible from sandbox. Bugs in allowed syscalls remain candidates.

Escape strategy 4 — IPC to high-privileged service

Beyond brokers, the sandboxed app can:

  • Open ALPC ports owned by SYSTEM services.
  • Send LPC messages.
  • Trigger work in lsass, csrss, services.exe.

Bug in the receiving service → escape.

Andrey Konovalov / Project Zero historically published many ALPC-attack chains against csrss, lsass, etc.

Escape strategy 5 — kernel bug from sandbox

If a kernel bug exists in a syscall reachable from AppContainer (limited but not zero), exploiting it gives kernel-mode control → sandbox + integrity bypass.

Most kernel attack surface from AppContainer is closed; what remains is highly-researched (Pwn2Own territory).

Escape strategy 6 — info leak + privilege check race

A privileged service performs a permission check on a token; the sandboxed app duplicates the handle or swaps it during the race window. The service operates on the wrong token.

Pwn2Own 2020+ produced several such bugs in lsass / csrss.

Specific sandbox examples

Edge / Chromium

Edge runs each tab as a separate AppContainer process. Communication with the browser broker (the “browser process”) via Mojo IPC. Bugs in Mojo handlers → escape.

Chromium publishes a sandbox-escape bug bounty; Edge inherits.

Microsoft Office (Protected View)

Office documents opened from internet run in a limited sandbox (“Protected View”). The user clicks “Enable Editing” to leave it. Bugs that bypass — re-enable macros, escape AppContainer — fire on document open.

Common vectors: ODF / OOXML parser bugs in the sandbox process.

UWP apps

UWP apps each run in AppContainer with declared capabilities. Bugs in:

  • WindowsAppRuntime host.
  • runFullTrust capability misuse.

Windows Sandbox (the lightweight VM)

Windows Sandbox (since Win10 1903) is a Hyper-V-based VM. Escape requires Hyper-V escape — much harder.

Workflow for finding a sandbox escape

  1. Map the sandbox’s allowed APIs.
  2. For each, enumerate parameters; fuzz.
  3. For each broker / COM / LPC endpoint, document the interface.
  4. Audit each endpoint for memory safety + logic bugs.
  5. When a bug found, validate that triggering from sandbox + escaping leaves you outside.

Tools

  • API Monitor — observe syscalls / API calls from sandbox.
  • WinDbg — debug sandboxed process + broker.
  • Process Explorer — see tokens / integrity levels.
  • AccessChk — check what tokens can access.
  • OleViewDotNet (James Forshaw) — enumerate COM surface.

Defence

  • Strict AppContainer policy.
  • Capability minimisation per app.
  • Broker code with security review.
  • Win32k disabled for high-risk sandboxes.
  • Patch quickly.

OSEE relevance

OSEE covers Windows sandbox escape lightly; deeper coverage is research-tier (Pwn2Own browser categories). The fundamentals (broker interactions, ALPC bugs, win32k surface) overlap with OSEE-level Windows exploitation.

References