Windows Sandbox environment for cybersecurity enthusiasts

Releases

RedSand is a pre-made .wsb that spins up a Windows Sandbox tailored for security work — just double-click the file. It maps a read-only Utils/ folder (scripts, toolkits) and a read-write Files/ folder (your working files) into the VM, then runs a setup script on logon.

Modify the .wsb and .ps1 files freely to match your workflow. Contributions of all kinds — new scripts, .wsb tweaks, documentation — are welcome.

1. Enable the Windows Sandbox feature (one-time, requires Windows 10/11 Pro / Enterprise / Education):

   # Run as Administrator
   .\Utils\Scripts\AdditionalScripts\OnHost\enableSandboxFeature.ps1

   Reboot if prompted.
2. Double-click profiles\RedSand.wsb in File Explorer.
3. The sandbox boots, setup.ps1 runs automatically, and you land on a desktop ready to work.

The default RedSand.wsb enables a hardened baseline suitable for analysis work:

On logon, setup.ps1 also:

• Sets ExecutionPolicy to Unrestricted (sandbox-local, throwaway)
• Enables developer mode (AllowDevelopmentWithoutDevLicense)
• Switches to dark theme
• Applies the RedSand wallpaper

Loosen the wsb defaults if your workload needs the host clipboard or more RAM.

RedSand/
├── profiles/
│   └── RedSand.wsb             # Sandbox config — double-click to launch
├── Files/                      # Read-write; drop samples / payloads here
├── Utils/
│   ├── Toolkits/               # Tools downloaded by OnHost scripts land here
│   └── Scripts/
│       ├── DefaultScripts/     # Run automatically on logon
│       │   └── setup.ps1
│       └── AdditionalScripts/
│           ├── OnHost/         # Run these on your host before launching
│           └── InSandbox/      # Run these inside the sandbox (manual or via wsb)

Utils/ is mapped read-only; Files/ read-write. Anything you download on the host into Utils/Toolkits/ (via the OnHost scripts) becomes available inside the sandbox at C:\users\WDAGUtilityAccount\Desktop\Utils\Toolkits\.

To auto-run any in-sandbox script on logon, uncomment the matching line in RedSand.wsb:

<Command>powershell.exe -ExecutionPolicy Bypass -File C:\users\WDAGUtilityAccount\Desktop\Utils\Scripts\AdditionalScripts\InSandbox\installREToolkit.ps1</Command>

The .wsb schema is documented by Microsoft: Windows Sandbox configuration.

Common tweaks:

• More RAM — bump <MemoryInMB>
• Re-enable clipboard — set <ClipboardRedirection>Enable</ClipboardRedirection> (handy for paste-in samples, but breaks the isolation guarantee)
• GPU passthrough — already Default; change to Disable if you want strict CPU-only execution
• Extra logon commands — add more <Command> entries in <LogonCommand>

For one-off in-sandbox setup, edit customScript.ps1 and uncomment its <Command> line in the wsb — keeps your customizations out of the always-run setup.ps1.

A few things worth knowing before you drop sensitive material into the sandbox:

• Files/ persists on the host. The sandbox VM is destroyed on shutdown, but anything written to C:\users\WDAGUtilityAccount\Desktop\Files\ from inside is the same bytes as ./Files/ on your host. Treat that folder as host filesystem, not sandbox memory — don't put credentials there, and be careful about what malware artifacts you drop into it.
• Don't analyze live evasive malware here. Windows Sandbox is a convenience VM, not a research-grade analysis environment. Samples that fingerprint sandboxes, attempt escape via shared kernel surface, or rely on Hyper-V tricks may behave unexpectedly. Use REMnux / FLARE-VM on dedicated hardware for that.
• Defaults are a baseline, not a guarantee. RedSand ships with ProtectedClient, clipboard disabled, and a fixed memory cap, but networking is on by default. Tighten the .wsb further if your threat model requires it.
• Bootstrap scripts run remote code. installChocoAndScoop.ps1 and installREToolkit.ps1 execute code fetched from upstream over HTTPS — this is the documented install pattern for those projects, but it does mean a compromised upstream becomes a compromised sandbox. The sandbox's disposability is your main mitigation.
• WSL doesn't work inside Windows Sandbox. WSL2 needs nested virtualization, and the .wsb schema doesn't expose a knob to enable it. If you need Linux tooling inside the sandbox, look at Cygwin / MSYS2, or run scripted tools via portable Python / Node installed through scoop / choco.

See SECURITY.md for reporting vulnerabilities.

See CONTRIBUTING.md. New .ps1 scripts, .wsb tweaks, and doc improvements all welcome. CI runs PSScriptAnalyzer, parses every script, and validates the .wsb XML — please make sure it goes green.

Heavily influenced by and reusing concepts from:

• Sandbox by @firefart
• Customize Windows Sandbox by Thomas Maurer
• countless people on forums

• REtoolkit by @mentebinaria
• Get-ZimmermanTools by @EricZimmerman
• SysinternalsSuite by Microsoft
• Windows Sandbox logo by Microsoft

ISC