Auditing Windows Sandbox and Application Guard: The Isolation Features Attackers Can Turn Against You

Windows Sandbox and Microsoft Defender Application Guard (MDAG) are two of the most underrated isolation primitives shipped with Windows. Both lean on the same Hyper-V-based container technology to run untrusted code in a disposable, kernel-isolated environment. Used well, they are a legitimate detonation and browsing safety layer. Enabled carelessly, they become one more optional feature that expands your attack surface and hands attackers a hypervisor to play with. This is a short field guide to auditing them the way a senior security engineer actually does.

What these features really are

Windows Sandbox is a lightweight, throwaway desktop. You launch it, run something suspicious, and everything is destroyed on close. It depends on the Containers-DisposableClientVM optional feature plus hardware virtualization. Defender Application Guard spins Edge (and historically Office) into a Hyper-V container so that web content and documents never touch the host file system or credentials. Both require virtualization extensions in firmware and the Hyper-V hypervisor components.

The security promise is real: a process inside the container cannot trivially read your host's LSASS, browse your profile, or persist across reboots. But that promise has limits, and the controls that enforce it are exactly what drifts over time.

Why auditors care — the attacker's view

Three things make these features worth auditing on every endpoint, not just on "security researcher" machines:

• Enablement is attack surface. Turning on Windows Sandbox installs a full virtualization stack. Vulnerable-driver and hypervisor-level bugs (VM escapes) have real CVEs. If a machine does not need the feature, it should not be installed.
• Sandbox escape and host interop. Windows Sandbox supports .wsb configuration files that can enable mapped folders, clipboard redirection, networking, GPU passthrough, and arbitrary logon commands. A malicious or sloppy .wsb can map the host's C:\ read-write straight into the sandbox, defeating the entire isolation story.
• False confidence. Teams assume "it ran in the sandbox, so we're fine." If networking is on and a mapped folder is writable, exfiltration and host persistence are a config line away.

What to audit

1. Is the feature even supposed to be here?

Inventory which machines have the disposable VM and Application Guard features installed. On a standard knowledge-worker fleet, most endpoints do not need Windows Sandbox at all.

Get-WindowsOptionalFeature -Online -FeatureName "Containers-DisposableClientVM"
Get-WindowsOptionalFeature -Online -FeatureName "Windows-Defender-ApplicationGuard"

Any machine reporting State : Enabled that has no business running untrusted code is a finding. Remove the feature rather than leaving a dormant hypervisor installed.

2. Virtualization-based security posture

Both features ride on VBS/Hyper-V. Confirm that if virtualization is enabled, the protective layers around it (Memory Integrity / HVCI, Credential Guard) are also on — an isolated container is small comfort if the host kernel is soft.

Get-CimInstance -ClassName Win32_DeviceGuard `
  -Namespace root\Microsoft\Windows\DeviceGuard |
  Select-Object SecurityServicesConfigured, SecurityServicesRunning

3. Sandbox configuration defaults

The dangerous knobs live in .wsb files, not the registry. Treat any .wsb on disk as code and review it for:

• <MappedFolder> entries that expose host paths — especially with <ReadOnly>false</ReadOnly>.
• <Networking>Enable</Networking> on a sandbox meant purely for offline detonation.
• <LogonCommand> blocks that auto-run scripts at sandbox start.
• Clipboard and GPU passthrough left at default-on when not needed.

Rule of thumb: a detonation sandbox should have networking disabled, no writable host mappings, and no logon command. If it has all three, it is not a sandbox — it is a bridge.

4. Application Guard enforcement

For MDAG, verify it is actually enforced by policy rather than merely available, and that clipboard/print/download redirection between the container and host are locked down. Loosely configured redirection is the most common way isolated browsing leaks back to the host.

Where WinSentinel fits

Checking one laptop by hand is fine. Checking whether any of your machines quietly has Windows Sandbox installed, networking-enabled, or a host-mapping .wsb sitting in a user profile is where manual auditing collapses.

On a single machine, WinSentinel Free runs the full audit — all 64 modules, no limits — including optional-feature enablement, VBS/HVCI and Credential Guard posture, and the virtualization attack surface. You get the complete finding set and remediation guidance for that endpoint without paying for anything.

Across an organization, WinSentinel Pro adds the fleet layer: a central node that rolls these findings up across every managed machine, flags drift when a host suddenly has the disposable VM feature enabled, and lets you dispatch a remediation (remove the feature, enforce HVCI) from one place instead of RDP-ing into each box. The per-machine audit is identical and free; Pro is about orchestrating it across many endpoints and catching the one laptop that drifted.

Bottom line

Isolation features are only as strong as their configuration. Audit enablement first (remove what you don't need), then lock down the .wsb knobs and redirection paths, and make sure the host-level VBS protections are running underneath. Do it once by hand to understand it; then let an agent check it on every machine, every day, so a single enabled hypervisor never becomes your soft spot.