Windows Sandbox GPU Access Expands the Attack Surface You Approved
Windows Sandbox GPU Access Expands the Attack Surface You Approved
When Microsoft added GPU virtualization support to Windows Sandbox, the feature was positioned as a productivity enhancement — let developers test GPU-accelerated applications without spinning up a full VM. Most enterprise admins who approved it treated it the same way. That framing is wrong, and the approval decision deserves a second look.
What GPU Virtualization in Sandbox Actually Enables
Windows Sandbox with GPU virtualization enabled uses Microsoft's WDDM GPU Paravirtualization (GPU-PV) driver model. The host GPU driver exposes a virtualized GPU interface to the Sandbox container. This is not a software renderer — it is a direct path to the physical GPU's compute and memory resources, mediated by the paravirtualization layer.
The Sandbox configuration file (.wsb) controls whether GPU virtualization is active:
<Configuration>
<VGpu>Enable</VGpu>
<Networking>Disable</Networking>
</Configuration>When <VGpu>Enable</VGpu> is set, the Sandbox process gains access to GPU compute shaders, video decode acceleration, and — critically — GPU memory (VRAM) that is shared with the host GPU context. The paravirtualization layer is designed to isolate guest memory allocations, but the isolation boundary is the driver stack, not hardware-enforced memory encryption.
This matters because the threat model for GPU-PV is materially different from CPU virtualization. CPU hypervisor isolation has decades of hardening, formal verification work, and a well-understood CVE taxonomy. GPU-PV isolation is newer, less formally verified, and has a shorter track record against adversarial workloads. Academic research — including work from groups studying GPU side-channel attacks on shared cloud infrastructure — has demonstrated that co-located GPU workloads can infer information about each other's memory access patterns under specific conditions.
The Sandbox's core security promise is disposability: nothing persists after the session ends. GPU-PV does not extend that promise to VRAM state. Host GPU memory residue from a Sandbox session is not guaranteed to be zeroed before the next workload claims those pages.
The distinction between "isolated" and "auditable" is where most enterprise governance frameworks break down. Your Intune policies can control whether Sandbox is enabled. They cannot currently inspect what runs inside it, what GPU memory was accessed, or whether a workload attempted to probe host memory through the paravirtualization boundary.
---
The Intune Policy Boundary and Where It Stops
Intune's current control surface for Windows Sandbox is limited to a single configuration catalog setting: Windows Sandbox enabled/disabled, surfaced through the Windows Security Baseline and the Settings Catalog under Computer Configuration > Windows Components > Windows Sandbox.
You can enforce this via a Settings Catalog profile:
$graphUri = "https://graph.microsoft.com/beta/deviceManagement/managedDevices"
$filter = "`$filter=operatingSystem eq 'Windows'"
$selectFields = "deviceName,id,operatingSystem,osVersion,complianceState"
$devices = Invoke-MgGraphRequest -Uri "$graphUri?$filter&`$select=$selectFields" -Method GET
foreach ($device in $devices.value) {
$configState = Invoke-MgGraphRequest `
-Uri "https://graph.microsoft.com/beta/deviceManagement/managedDevices/$($device.id)/deviceConfigurationStates" `
-Method GET
Write-Output "$($device.deviceName) | Compliance: $($device.complianceState)"
}What this query does not return: whether the Sandbox feature is actively running, whether a .wsb configuration file with <VGpu>Enable</VGpu> was invoked, or whether any GPU-accelerated workload executed inside the container during the session.
Intune's telemetry boundary ends at the host OS configuration layer. The Sandbox runtime is a Windows Container process (WindowsSandbox.exe) that is visible in the host process list, but its internal execution state — including GPU command queues, shader compilation, and VRAM allocation — is not surfaced to any Intune-connected diagnostic pipeline.
This is not a criticism of Intune's design. It is a structural reality that admins need to internalize before approving GPU-PV features in regulated environments. The monitoring gap is real and currently has no first-party closure.
---
Compliance Controls That GPU Sandbox Touches
If your organization operates under any of the following frameworks, GPU Sandbox enablement requires explicit risk acceptance documentation — not just a feature approval ticket.
SOC 2 Type II (CC6.6, CC6.7): These controls require that logical access to systems and data is restricted and monitored. A GPU execution environment that is not auditable by your SIEM or Intune telemetry pipeline creates a gap in the logical access monitoring chain. Your auditor will ask how you detect unauthorized data access within Sandbox sessions. The honest answer, currently, is that you cannot.
FedRAMP Moderate (AU-2, AU-12, SI-3): Audit event generation and malicious code protection controls require that all execution environments capable of processing federal data generate auditable logs. Windows Sandbox's transient nature — no persistent storage, no persistent logs by default — is architecturally incompatible with AU-12 requirements unless you implement a mapped folder with log forwarding before the session terminates.
HIPAA Security Rule (§164.312(b)): The Audit Controls standard requires mechanisms to record and examine activity in systems containing ePHI. If a user can open a Sandbox session on a workstation that has access to ePHI network shares — even if the Sandbox itself does not mount those shares — the GPU side-channel risk creates a plausible path for data inference that your risk assessment should document.
The governance failure mode here is not that admins approved GPU Sandbox. It is that the approval was made at the feature level without a corresponding update to the risk register, the compliance control mapping, or the monitoring architecture.
---
Detecting Sandbox GPU Usage with Defender and KQL
Microsoft Defender for Endpoint does extend some telemetry into Sandbox sessions — specifically process creation events. You can use this to detect GPU-enabled Sandbox invocations and flag them for review.
The following KQL query targets Defender's DeviceProcessEvents table to identify Sandbox sessions and correlate them with .wsb configuration files that may specify GPU access:
// Detect Windows Sandbox launches and flag potential GPU-enabled sessions
// Run in Microsoft Defender XDR Advanced Hunting
DeviceProcessEvents
| where FileName =~ "WindowsSandbox.exe"
| where Timestamp > ago(30d)
| project
Timestamp,
DeviceName,
AccountName,
ProcessCommandLine,
InitiatingProcessFileName,
InitiatingProcessCommandLine
| join kind=leftouter (
DeviceFileEvents
| where FileName endswith ".wsb"
| where Timestamp > ago(30d)
| project
DeviceName,
WsbFileName = FileName,
WsbFilePath = FolderPath,
WsbTimestamp = Timestamp
) on DeviceName
| where WsbTimestamp between (Timestamp - 5m .. Timestamp + 5m)
| project
Timestamp,
DeviceName,
AccountName,
ProcessCommandLine,
WsbFileName,
WsbFilePath
| order by Timestamp descThis query surfaces Sandbox launches correlated with .wsb file activity in the same five-minute window. It does not confirm GPU enablement — you cannot read the .wsb file contents from DeviceFileEvents — but it gives you a starting point for investigation and a list of devices where manual .wsb file review is warranted.
For a more targeted detection, add a file content search via Defender's Live Response or a proactive hunting script:
$wsbFiles = Get-ChildItem -Path "C:\Users" -Recurse -Filter "*.wsb" -ErrorAction SilentlyContinue
foreach ($file in $wsbFiles) {
$content = Get-Content $file.FullName -Raw -ErrorAction SilentlyContinue
if ($content -match '<VGpu>\s*Enable\s*</VGpu>') {
[PSCustomObject]@{
DeviceName = $env:COMPUTERNAME
FilePath = $file.FullName
VGpuEnabled = $true
LastModified = $file.LastWriteTime
}
}
}Deploy this as an Intune Proactive Remediation detection script. Set it to run on a schedule against your developer workstation group. Any device returning results should trigger a review of whether GPU Sandbox is an approved use case for that user's data classification level.
---
Governance Recommendations for Regulated Environments
These are not aspirational controls. They are the minimum steps required to bring GPU Sandbox enablement into alignment with a defensible compliance posture.
Disable GPU-PV at the policy layer for regulated device groups. Create a separate Intune Settings Catalog profile targeting devices in scope for SOC 2, FedRAMP, or HIPAA. Set Windows Sandbox to disabled for those groups. If Sandbox is required for developer workflows, create a separate, non-regulated device group with explicit risk acceptance documentation.
Require .wsb file review as part of your software request process. Any .wsb configuration file that specifies <VGpu>Enable</VGpu> should require security team sign-off before deployment. Treat it the same as a firewall rule change — it expands the attack surface of a shared hardware resource.
Implement log forwarding from Sandbox sessions where Sandbox is approved. Map a host folder into the Sandbox using the <MappedFolders> directive and configure the Sandbox to write session logs to that folder before termination. Forward those logs to your SIEM. This does not close the GPU monitoring gap, but it addresses the AU-12 audit trail requirement for process-level activity.
Document the GPU monitoring gap in your risk register explicitly. Your compliance auditor will ask about it. Having a documented, accepted risk with compensating controls is a defensible position. Having no documentation of the gap is not.
Track GPU driver CVEs for your hardware fleet. Subscribe to the security advisories for NVIDIA, AMD, and Intel GPU drivers deployed in your environment. GPU driver vulnerabilities that affect the WDDM user-mode interface are directly relevant to the Sandbox GPU-PV attack surface.
---
Final Thoughts
The approval decision for Windows Sandbox GPU access was probably made quickly, framed as a developer productivity feature, and processed through a change management workflow that was not designed to evaluate hardware-level isolation boundaries or GPU memory residue behavior.
That is not an indictment of the admin who approved it. It is an indictment of how GPU-PV features are marketed and documented — as productivity enhancements rather than as expansions of a shared hardware attack surface that sits outside your current monitoring boundary.
The practical path forward is not to ban Sandbox. It is to treat GPU enablement as a distinct security decision from Sandbox enablement, apply it only to device groups where the risk is documented and accepted, and build the detection capability — imperfect as it currently is — to know when and where it is running.
The monitoring gap between what Intune can enforce and what GPU-PV actually exposes is real. Naming it explicitly in your risk register is the first step toward controlling it.
---
