The cybersecurity landscape witnessed a significant development when the National Police Agency (NPA) and the National center of Incident readiness and Strategy for Cybersecurity (NISC) released a security advisory on January 8, 2025.
This advisory highlighted an Advanced Persistent Threat (APT) campaign conducted by a group known as “MirrorFace,” targeting organizations in Japan.
The threat actors cleverly exploited Windows Sandbox and Visual Studio Code as part of their attack methodology.
This article presents a comprehensive analysis of the Windows Sandbox exploitation technique, drawing from technical verification research, to provide insights into the attack methodology, forensic artifacts, and essential countermeasures that security professionals can implement to detect and prevent such attacks.
Understanding Windows Sandbox and Its Security Implications
Windows Sandbox is a built-in virtualization feature available in Windows 10 (Build 18342 and later) and Windows 11 that creates an isolated, temporary desktop environment.
This lightweight virtual machine allows users to run potentially unsafe applications without risking permanent changes to their host system.
By default, Windows Sandbox is disabled and requires explicit activation through either the graphical user interface or command-line interface.
Once enabled, it provides an environment that runs under a default user account named WDAGUtilityAccount, which notably belongs to the Administrators group.
This administrative privilege within the sandbox environment creates a significant security consideration that attackers have learned to exploit.
The sandbox utilizes Virtual Hard Disk (VHDX) technology and employs a differential backup mechanism. When launched, it creates VHDX-related folders under C:ProgramDataMicrosoftWindowsContainers, containing both parent and differential virtual disks.
C:ProgramDataMicrosoftWindowsContainers folderA key security limitation within the sandbox is that Windows Defender is disabled by default and cannot be enabled through either GUI or PowerShell commands.
This protective gap creates an opportune environment for malware execution without security product interference.
Another important aspect is the capability to configure Windows Sandbox through WSB files – XML-based configuration files that can define network access, folder sharing between host and sandbox, automatic command execution at startup, and resource allocation parameters.
The security implications of Windows Sandbox become particularly concerning when considering recent functional updates.
As of October 24, 2024, Microsoft released KB5044384, introducing significant changes to Windows Sandbox functionality, including the addition of wsb.exe command for command-line control, background execution capability, and GUI-configurable settings.
These enhancements, while improving legitimate use cases, simultaneously make detection of malicious sandbox activities more challenging.
The most concerning developments include the ability to run the sandbox in the background without user awareness, configuration without traceable WSB files, and persistence of data within the sandbox environment until explicitly terminated.
MirrorFace’s Sophisticated Attack Methodology
The threat actor MirrorFace, believed to be a subgroup within the broader APT10 umbrella, developed a sophisticated attack methodology leveraging Windows Sandbox as a stealth mechanism.
Their attack campaign utilized LilimRAT, a customized version of the open-source Lilith RAT.
This malware was specifically designed to operate within Windows Sandbox, as evidenced by its code that checks for the existence of the WDAGUtilityAccount user folder – terminating if this folder is not found.
This deliberate design choice demonstrates the attackers’ targeted approach to using Windows Sandbox as an operational environment.
The attack flow begins after the initial compromise of a target system, where the threat actors enable Windows Sandbox, which requires administrative privileges, followed by a system restart.
They strategically place three key components on the compromised host: a batch file, an archiver utility (such as 7-Zip), and an archive file containing the malware payload.
The attackers then create and execute a WSB configuration file that establishes folder sharing between host and sandbox, enables network connectivity, allocates memory resources, and most critically, automatically executes the batch file upon sandbox startup.
This batch file typically contains commands to extract the archive, create a scheduled task that executes the malware with SYSTEM privileges, and run the scheduled task.
What makes this technique particularly insidious is that when Windows Sandbox is executed via Task Scheduler under a different user account (such as SYSTEM), it runs in the background without displaying a window, effectively concealing its operation from users.
The malware executed within this isolated environment communicates with command and control (C2) servers via the Tor network, encrypting communications and obscuring the C2 infrastructure.
Since the malware operates within the sandbox according to the WSB configuration, it can access files on the host machine while evading monitoring tools that only observe host system activities.
Furthermore, the absence of Windows Defender within the sandbox environment allows attackers to operate without security product interference.
The recent Windows Sandbox feature updates have further enhanced the attackers’ capabilities.
The new wsb.exe command-line functionality allows for background execution without visible windows, configuration without traceable WSB files, and persistent data storage until explicit termination.
These developments significantly increase the attack surface and complicate detection efforts for security professionals.
Effective Monitoring, Investigation, and Mitigation Strategies
Defending against Windows Sandbox exploitation requires a multi-layered approach encompassing monitoring, forensic investigation, and preventive controls.
On the monitoring front, several processes associated with Windows Sandbox can be tracked to detect its activation: WindowsSandbox.exe, WindowsSandboxClient.exe, cmproxyd.exe, and in newer Windows 11 builds, WindowsSandboxServer.exe, WindowsSandboxRemoteSession.exe, and wsb.exe.
Since Windows Sandbox utilizes the host machine’s network adapter, standard network monitoring remains effective for detecting communication with C2 servers, though additional detection mechanisms for Tor network traffic may be necessary when this anonymity network is employed.
An important discovery for detection is that sandbox processes are executed within the memory space allocated to the host machine.
Specifically, strings and artifacts from processes running inside the sandbox can be found within the vmmemWindowsSandbox process (Windows 11) or vmmem process (Windows 10) on the host machine.
This provides a critical opportunity for security tools to scan these memory regions for indicators of compromise, even when the malicious activities are confined to the sandbox environment.
Memory scanning of these processes can potentially detect malware and attack tools that might otherwise remain hidden.
From a forensic investigation perspective, several artifacts can provide evidence of Windows Sandbox activity.
On the host machine, the Master File Table ($MFT) and Update Sequence Number Journal ($UsnJrnl) may record the creation of WSB files, mounted folders, and VHDX files.
Prefetch data might contain records of WSB and VDHX file loading, while the Windows Registry contains application associations related to Windows Sandbox.
Event logs can also provide valuable information about sandbox activation and usage.
More importantly, if VHDX files are recovered while maintaining the parent and differential virtual disk chain, they can be mounted for comprehensive analysis of sandbox activities.
Within the mounted sandbox environment, investigators can access valuable artifacts including $MFT, $UsnJrnl, Registry, browser history, and event logs, though some data sources like Prefetch and SRUM are not available.
For preventive control measures, organizations should consider keeping Windows Sandbox disabled by default and implementing strict user privilege management to prevent unauthorized activation.
Since enabling Windows Sandbox requires administrative rights, restricting administrative privileges can effectively block this attack vector.
Additionally, AppLocker policies can be deployed to prevent Windows Sandbox execution even when it is enabled or when users have permission to enable it.
When AppLocker blocks Windows Sandbox, these events are recorded in the event logs, providing an additional detection mechanism.
The exploitation of Windows Sandbox by the MirrorFace APT group represents a sophisticated evolution in attack techniques that leverage legitimate operating system features to evade detection.
By operating within an isolated environment that runs with administrative privileges but lacks security controls, attackers can execute malware, access host system files, and communicate with C2 infrastructure while minimizing their digital footprint.
Are you from SOC/DFIR Teams?: Analyse Malware Incidents & get live Access with ANY.RUN -> Start Now for Free.
