The cybersecurity community has been jolted into attention by the latest findings from Japan’s National Police Agency (NPA) and the National center of Incident readiness and Strategy for Cybersecurity (NISC), who have jointly sounded the alarm about a particularly sleek campaign from the MirrorFace threat group—a branch closely linked to the notorious APT10. Their January 2025 advisory not only underscores a highly targeted attack against Japanese organizations, but also reveals the creative abuse of Windows Sandbox and Visual Studio Code in conducting business-focused espionage.
Windows Sandbox has always been marketed as a friend to security-conscious users and IT administrators. By design, this virtualization feature, present in Windows 10 (from build 18342 onward) and Windows 11, provides a contained, temporary desktop environment where suspect files or applications can be executed without endangering the host system. It’s a remarkably minimalistic virtual machine—ephemeral by nature and reset with every fresh launch. But as is often the case in infosec, every security feature can double as an attack vector in the wrong hands.
Of particular importance to defenders and attackers alike is the default user within this environment: WDAGUtilityAccount. Despite being a system-created account for container and sandbox management, it’s endowed with administrative privileges inside the sandbox. This grants any process within the sandbox considerable leeway, and with Defender—Microsoft’s built-in antivirus—disabled by design within this enclave, attackers see a near-perfect testing ground for their craft.
Their approach unfolds through a multistage procedure:
Even network monitoring, often the last line of detection for behavioral anomalies, faces increased hurdles. The sandbox platform piggybacks on the host’s network adapter, meaning outbound connections—especially encrypted Tor traffic—can be particularly difficult to attribute exclusively to malicious activity within the sandbox.
Moreover, the campaign’s WSB configurations allow the sandboxed malware to reach back into shared folders, accessing or modifying files on the host. For organizations reliant on endpoint-based detection and logging tools—solutions that rarely peer inside the memory or storage of sandboxed processes—this presents a significant blind spot.
Several processes betray sandbox activity, and defenders are advised to monitor for:
Windows Sandbox’s processes, namely vmmem or vmmemWindowsSandbox (depending on Windows version), allocate and manage the memory space for the sandboxed environment. Security teams can scan these memory regions for signatures of known malware or telltale artefacts, even where the payload is confined inside the sandbox. Such memory scans represent a promising avenue for threat detection, complementing the more standard endpoint monitoring suite.
The registry also yields clues: application associations and virtualization platform usage leave their signatures here. If responders are able to recover the relevant VHDX chain (the base and its differentials), they can mount the sandbox as a virtual disk, opening another trove of evidence within—everything from browser history to in-sandbox event logs.
Understanding these sources helps organizations build playbooks around incident response, supporting quick triage and the possibility of reconstructing a full attack timeline.
AppLocker, Microsoft’s application whitelisting solution, can be configured to outright block execution of Windows Sandbox, whether by the main binaries or by attempts to spawn from scheduled tasks. Intriguingly, when AppLocker is tripped in this way, Windows records the event, giving security operations centers a valuable detection point. Continuous audit and alerting on such events should be built into any Windows-heavy security operations workflow.
Another underutilized strategy is to keep the sandbox feature disabled on desktops and laptops where there is no valid use case. Though it’s a helpful tool for administrators and testers, it is a rarity in the average corporate digital workspace. When threat intelligence such as this APT campaign surfaces, quick action to disable or restrict the feature can save serious remediation effort down the line.
The impact isn’t theoretical. For organizations whose detection is based solely on file-based indicators, static analysis, or non-memory-resident behaviour, campaigns like this are virtually invisible. The interplay between Windows Sandbox updates and attacker innovation, as demonstrated by the enhanced wsb.exe command-line control, proves that as defensive technology evolves, so does adversarial tradecraft.
This incident also reinforces the need for layered security strategies. Endpoint protection, network monitoring, application control, privilege restriction, and memory forensics all play a part. Organizational resilience will increasingly depend on integrating preventative controls with proactive detection, and on the capacity to ask and answer forensic questions in the wake of new attacks.
Organizations should not wait for another wave of exploitation before acting. Developing a comprehensive visibility strategy around privileged operations, sandbox usage, and virtual disk artifacts is paramount. Investing in memory scanning capability and ensuring that event logs are centralized, parsed, and actively monitored may be the difference between catching—or missing—the next engineered breach.
Vigilance, agility, and a readiness to rethink old assumptions will be the hallmarks of robust cybersecurity organizations as attack techniques grow ever more creative. MirrorFace’s sandbox exploitation campaign should prompt every defender, from sysadmin to CISO, to ask a simple question: “What legitimate feature could be hiding our next major threat?” The best-prepared teams will already be digging for answers.
Source: gbhackers.com MirrorFace APT Using Custom Malware To Exploited Windows Sandbox & Visual Studio Code
Windows Sandbox has always been marketed as a friend to security-conscious users and IT administrators. By design, this virtualization feature, present in Windows 10 (from build 18342 onward) and Windows 11, provides a contained, temporary desktop environment where suspect files or applications can be executed without endangering the host system. It’s a remarkably minimalistic virtual machine—ephemeral by nature and reset with every fresh launch. But as is often the case in infosec, every security feature can double as an attack vector in the wrong hands.Of particular importance to defenders and attackers alike is the default user within this environment: WDAGUtilityAccount. Despite being a system-created account for container and sandbox management, it’s endowed with administrative privileges inside the sandbox. This grants any process within the sandbox considerable leeway, and with Defender—Microsoft’s built-in antivirus—disabled by design within this enclave, attackers see a near-perfect testing ground for their craft.
The MirrorFace Playbook: Precision and Persistence
The sophistication of MirrorFace’s campaign is not merely technical; it’s strategic. After gaining initial access to a victim system, the threat actors enable Windows Sandbox—something that requires admin rights—before orchestrating a stealthy relay of attacks. The core of their method relies on a custom flavor of the open-source Lilith RAT, refashioned as LilimRAT, which deliberately checks for the existence of the WDAGUtilityAccount profile to ensure it’s running in the intended virtual environment. If the check fails, the malware simply terminates, a simple yet effective way to avoid exposure on unintended hosts.Their approach unfolds through a multistage procedure:
- Initial access leads to the creation of several artifacts on the victim machine: a batch script, an archiving utility (commonly 7-Zip), and an archive holding the malware payload.
- The adversaries then craft a Windows Sandbox configuration (WSB) file, which automates a range of critical tasks: network enablement, folder sharing between the host and sandbox, resource allocation, and most crucially, the silent execution of the aforementioned batch file.
- When executed, this sequence unpacks the malware, establishes persistence via scheduled tasks, and launches the RAT with SYSTEM-level privileges—all inside a supposedly sterile, isolated VM.
Living Off the Land: Evasion at Scale
MirrorFace’s ingenuity is both a technical marvel and a security nightmare. By leveraging legitimate Windows features—sandboxing, scheduled tasks, and network folder sharing—they maximize their dwell time while shrinking the window for detection. The lack of Windows Defender within the sandbox creates a welcoming environment for malware, and the addition of Tor-based communication to command-and-control (C2) infrastructure adds a layer of impenetrable anonymity.Even network monitoring, often the last line of detection for behavioral anomalies, faces increased hurdles. The sandbox platform piggybacks on the host’s network adapter, meaning outbound connections—especially encrypted Tor traffic—can be particularly difficult to attribute exclusively to malicious activity within the sandbox.
Moreover, the campaign’s WSB configurations allow the sandboxed malware to reach back into shared folders, accessing or modifying files on the host. For organizations reliant on endpoint-based detection and logging tools—solutions that rarely peer inside the memory or storage of sandboxed processes—this presents a significant blind spot.
Hunt, Detect, and Respond: Countermeasures in Focus
With the attack leveraging a sanctioned, built-in OS feature, traditional prevention and detection techniques require an upgrade. Effective defense starts with visibility—knowing when, why, and how Windows Sandbox is being invoked across an organization’s endpoints.Several processes betray sandbox activity, and defenders are advised to monitor for:
- WindowsSandbox.exe and WindowsSandboxClient.exe (core processes)
- cmproxyd.exe (for communication management)
- WindowsSandboxServer.exe, WindowsSandboxRemoteSession.exe, and wsb.exe (added for Windows 11 environments)
Windows Sandbox’s processes, namely vmmem or vmmemWindowsSandbox (depending on Windows version), allocate and manage the memory space for the sandboxed environment. Security teams can scan these memory regions for signatures of known malware or telltale artefacts, even where the payload is confined inside the sandbox. Such memory scans represent a promising avenue for threat detection, complementing the more standard endpoint monitoring suite.
Forensic Traces: Following the Breadcrumbs
In the aftermath of a suspected attack, digital investigators have a cluster of artefacts to scrutinize. On the host, the creation of WSB files, mounting of folders, and the generation of VHDX (virtual disk) files by the sandbox can all leave footprints in the Master File Table and USN Journal. Prefetch data, though easily overlooked, might record opening and modification times for both the Windows Sandbox binaries and associated virtual disks.The registry also yields clues: application associations and virtualization platform usage leave their signatures here. If responders are able to recover the relevant VHDX chain (the base and its differentials), they can mount the sandbox as a virtual disk, opening another trove of evidence within—everything from browser history to in-sandbox event logs.
Understanding these sources helps organizations build playbooks around incident response, supporting quick triage and the possibility of reconstructing a full attack timeline.
Policy and Prevention: Hardening Organizational Defenses
Curbing such sophisticated exploitation takes a blend of technical controls and solid governance. Since enabling Windows Sandbox requires administrative privileges, one of the most effective mitigations is to severely restrict and monitor those privileges within the corporate environment. Reducing the number of accounts that can invoke sandboxing (or, indeed, install or execute sensitive WSB configurations) narrows the available attack surface.AppLocker, Microsoft’s application whitelisting solution, can be configured to outright block execution of Windows Sandbox, whether by the main binaries or by attempts to spawn from scheduled tasks. Intriguingly, when AppLocker is tripped in this way, Windows records the event, giving security operations centers a valuable detection point. Continuous audit and alerting on such events should be built into any Windows-heavy security operations workflow.
Another underutilized strategy is to keep the sandbox feature disabled on desktops and laptops where there is no valid use case. Though it’s a helpful tool for administrators and testers, it is a rarity in the average corporate digital workspace. When threat intelligence such as this APT campaign surfaces, quick action to disable or restrict the feature can save serious remediation effort down the line.
Implications for Enterprise Security and the Broader Ecosystem
The exploitation of Windows Sandbox by MirrorFace sets a new bar for so-called “living off the land” attacks—the practice of abusing legitimate system features for malicious purposes. What’s clear from this campaign is that security boundaries are becoming ever blurrier. Features designed to protect users—like sandboxing and temporary virtual environments—can become the very mechanisms by which attackers evade scrutiny.The impact isn’t theoretical. For organizations whose detection is based solely on file-based indicators, static analysis, or non-memory-resident behaviour, campaigns like this are virtually invisible. The interplay between Windows Sandbox updates and attacker innovation, as demonstrated by the enhanced wsb.exe command-line control, proves that as defensive technology evolves, so does adversarial tradecraft.
This incident also reinforces the need for layered security strategies. Endpoint protection, network monitoring, application control, privilege restriction, and memory forensics all play a part. Organizational resilience will increasingly depend on integrating preventative controls with proactive detection, and on the capacity to ask and answer forensic questions in the wake of new attacks.
Looking Ahead: Lessons for Security Teams and Microsoft
There is an urgent need for Microsoft and other OS vendors to revisit the security posture of features like sandboxing. The architectural decision to ship Windows Sandbox with Defender disabled, for example, may have made sense from a performance or compatibility standpoint, but it creates a well-understood weak spot that advanced threat groups will inevitably exploit. Red teams, security researchers, and perhaps most critically, defenders “in the trenches” should collaborate to test and ultimately harden the configurations and default settings of these features.Organizations should not wait for another wave of exploitation before acting. Developing a comprehensive visibility strategy around privileged operations, sandbox usage, and virtual disk artifacts is paramount. Investing in memory scanning capability and ensuring that event logs are centralized, parsed, and actively monitored may be the difference between catching—or missing—the next engineered breach.
The Bottom Line: Security is a Moving Target
MirrorFace’s campaign is a vivid illustration of the constant arms race in cybersecurity. Today’s handy virtualization tool can be tomorrow’s most insidious attack mechanism. The abuse of Windows Sandbox underscores this duality, serving as both a technical marvel and a cautionary tale. Where security features converge with usability enhancements, both blue and red teams will accelerate their innovations. Staying ahead means testing not just for vulnerabilities, but also for abuse of what we believe to be safe by design.Vigilance, agility, and a readiness to rethink old assumptions will be the hallmarks of robust cybersecurity organizations as attack techniques grow ever more creative. MirrorFace’s sandbox exploitation campaign should prompt every defender, from sysadmin to CISO, to ask a simple question: “What legitimate feature could be hiding our next major threat?” The best-prepared teams will already be digging for answers.
Source: gbhackers.com MirrorFace APT Using Custom Malware To Exploited Windows Sandbox & Visual Studio Code
Last edited: