Abusing Windows Sandbox for Stealthy Persistence and Evasion

TLDR: Attackers are now using the built-in Windows Sandbox to execute malicious payloads while remaining invisible to EDR and EPP solutions. By registering the sandbox as a scheduled task with SYSTEM privileges and mapping host folders, they can run code in an isolated environment that security tools often ignore. This technique, observed in the wild by the Earth Kasha threat actor, allows for persistent, stealthy execution that bypasses standard endpoint monitoring.

Security researchers and red teamers often focus on the latest memory injection techniques or complex kernel exploits, but sometimes the most effective way to hide is to use the operating system against itself. The recent research presented at Black Hat 2025 on the abuse of Windows Sandbox is a perfect example of this. It is not about finding a zero-day in the hypervisor; it is about weaponizing a legitimate, trusted feature to create a blind spot in your security stack.

The Mechanics of the Sandbox Bypass

Windows Sandbox is designed to be a disposable, isolated desktop environment. It uses hypervisor-based virtualization to ensure that whatever happens inside the box stays inside the box. However, the configuration file format, the WSB file, provides enough flexibility for an attacker to turn this security feature into a persistence mechanism.

The attack flow starts with the delivery of a malicious payload, often via spear-phishing. Once the initial dropper is on the host, it does not immediately execute the final payload. Instead, it registers a scheduled task that triggers the Windows Sandbox. By setting the task to run with SYSTEM privileges, the attacker ensures the sandbox environment is initialized without requiring user interaction or displaying a visible UI.

The critical part of this technique is the configuration of the mapped folders. In the WSB file, an attacker can define shared directories between the host and the guest. By setting the ReadOnly attribute to false, the attacker grants the sandbox environment write access to sensitive host directories. This allows the sandbox to pull down additional tools, drop secondary payloads, or exfiltrate data back to the host filesystem, all while the primary malicious activity occurs within the isolated, and often unmonitored, sandbox process.

Technical Implementation and Evasion

When you look at the process tree, the evasion becomes clear. The sandbox runs as a distinct process, typically vmms.exe or vmms-sandbox.exe depending on the Windows version. Because most EDR solutions are tuned to monitor the primary user session and common application paths, they often treat the sandbox process as a black box.

The following XML snippet demonstrates how an attacker might configure a malicious sandbox task:

<Configuration>
    <Networking>Enable</Networking>
    <MappedFolders>
        <MappedFolder>
            <HostFolder>C:\Users\Public\AppData</HostFolder>
            <ReadOnly>false</ReadOnly>
        </MappedFolder>
    </MappedFolders>
    <LogonCommand>
        <Command>C:\Users\Public\AppData\msiexec.cmd</Command>
    </LogonCommand>
</Configuration>

By using wsb.exe with the -config argument, an attacker can trigger this configuration file silently. The msiexec.cmd script acts as the orchestrator, using native tools like certutil to decode payloads and winrar to extract them. Since these tools are signed and trusted, their execution within the sandbox rarely triggers behavioral alerts.

Real-World Implications for Pentesters

During a red team engagement, this technique is a goldmine for maintaining persistence. If you have already gained initial access, you can drop your configuration and the necessary scripts into a user-writable directory. Because the sandbox is a native Windows feature, you do not need to bring your own virtualization software, which significantly reduces your footprint and avoids triggering alerts related to unauthorized software installation.

The impact is significant. You are essentially running a secondary, isolated operating system on the target machine. You can perform reconnaissance, run credential dumping tools like Mimikatz, or stage your lateral movement tools without the EDR on the host ever seeing the actual execution of these binaries. The only thing the host sees is the sandbox process itself, which is often excluded from deep inspection to maintain system performance.

Detection and Defensive Strategy

Defending against this requires shifting your focus from the host process to the sandbox configuration and the lifecycle of the sandbox itself. You should monitor for the creation of scheduled tasks that invoke wsb.exe with custom configuration files. Any instance of wsb.exe running with a -config argument pointing to a file in a user-writable directory should be treated as highly suspicious.

Furthermore, you can use Sigma rules to hunt for these patterns in your logs. Focus on process creation events where the parent process is taskeng.exe or svchost.exe and the command line includes wsb.exe. If your EDR supports memory scanning, you should also look for the presence of known malicious tools within the memory space of the sandbox worker process. While the sandbox is isolated, the memory space of the worker process is still accessible to the host, providing a window into what is happening inside the box.

Do not assume that because a feature is built-in and "secure" that it cannot be used against you. The next time you are performing a threat hunt, check the scheduled tasks on your endpoints for any references to Windows Sandbox. You might be surprised by what you find running in the background.