How to Configure Windows Sandbox Protected Process Light (PPL) Simulation via XML in Windows 11

In Windows enterprise defense architecture, Protected Process Light (PPL) provides operating system-level protection for critical security processes—such as Local Security Authority Subsystem Service (LSASS), Windows Defender (MsMpEng.exe), and anti-cheat drivers. PPL prevents unprivileged administrators and malicious tools from injecting threads, reading memory, or terminating protected services via standard Win32 APIs (OpenProcess). When testing custom security telemetry, evaluating endpoint detection and response (EDR) agents, or simulating credential theft defense, developers can simulate hardened PPL environments inside Windows Sandbox in Windows 11.

Understanding Protected Process Light (PPL) Directives and Signer Levels

PPL enforces cryptographic signature verification on loaded binaries and controls access rights via defined signer levels:

• PsProtectedSignerWinTcb: Highest protection tier reserved for core operating system trusted computing base binaries.
• PsProtectedSignerAntimalware: Tier dedicated to verified antivirus and EDR sensor binaries (ELAM).
• RunAsPPL: The Windows configuration setting that elevates lsass.exe to run inside a protected process container, preventing unauthorized credential dumping (such as Mimikatz sekurlsa::logonpasswords).

Authoring the PPL Hardening Script

Create a dedicated host folder (e.g. C:\SandboxPPLTest) and save a PowerShell provisioning script named InitPPL.ps1:

# InitPPL.ps1 - Configure RunAsPPL and process protection boundaries inside Windows Sandbox
Write-Host "Configuring Protected Process Light (RunAsPPL) simulation..." -ForegroundColor Cyan

# Enable RunAsPPL for Local Security Authority (LSASS)
$lsaPath = "HKLM:SYSTEMCurrentControlSetControlLsa"
Set-ItemProperty -Path $lsaPath -Name "RunAsPPL" -Value 1 -Type DWord
Write-Host "LSASS RunAsPPL set to Enabled (Value: 1)." -ForegroundColor Green

# Enable Process Creation Auditing with Command Line Logging
$auditPath = "HKLM:SOFTWAREMicrosoftWindowsCurrentVersionPoliciesSystemAudit"
if (-not (Test-Path $auditPath)) { New-Item -Path $auditPath -Force | Out-Null }
Set-ItemProperty -Path $auditPath -Name "ProcessCreationIncludeCmdLine_Enabled" -Value 1 -Type DWord
Write-Host "Detailed command-line process auditing enabled." -ForegroundColor Green

Write-Host "PPL test environment initialisation complete." -ForegroundColor Green

Constructing the WSB Configuration File

Create an XML configuration file named PplSandbox.wsb on your desktop:

<Configuration>
  <VGpu>Enable</VGpu>
  <Networking>Default</Networking>
  <MemoryInMB>6144</MemoryInMB>
  <MappedFolders>
    <MappedFolder>
      <HostFolder>C:SandboxPPLTest</HostFolder>
      <SandboxFolder>C:PPLTest</SandboxFolder>
      <ReadOnly>true</ReadOnly>
    </MappedFolder>
  </MappedFolders>
  <LogonCommand>
    <Command>powershell.exe -NoExit -ExecutionPolicy Bypass -File C:PPLTestInitPPL.ps1</Command>
  </LogonCommand>
</Configuration>

Verifying Protection Boundaries Inside the Sandbox

To verify that PPL protections are operating effectively:

1. Double-click PplSandbox.wsb to boot the sandbox session.
2. The PowerShell window executes and applies the RunAsPPL registry configuration.
3. Open an elevated PowerShell prompt inside the sandbox and attempt to inspect LSASS process handles using Get-Process lsass.
4. Attempt to attach a user-mode debugger (such as Visual Studio or standard diagnostic memory tools) to lsass.exe.
5. Verify that Windows rejects handle access with an Access is denied (Error 5) error code, proving that the operating system kernel is actively enforcing protected process memory boundaries.