CyberJunkie explains: Data exfiltration via Windows Sandbox

In this blog post, CyberJunkie explores a newly discovered attacker tactic he has uncovered as a senior defensive content engineer at Hack The Box.

This new technique, which attackers could leverage, utilizes a Windows feature called Windows Sandbox, which allows users to create a disposable, isolated Windows container/VM within their host operating system. This enables them to perform various activities in a secure environment. 

However, attackers can exploit this feature to collect, stage, and exfiltrate sensitive data to servers they control, bypassing traditional Windows defenses and leaving minimal forensic evidence of their activities.

In this discussion, we will examine the aftermath of such an attack. Although there is typically no direct evidence left behind, certain indirect indicators can suggest that an attack may have occurred. 

It’s also worth mentioning that if the network has network traffic solutions like packet capture, IDS, IPS, those will have network related evidence. For example if a certain website is visited from inside the sandbox, packlet capture will have that data but the host system will not. We will first explore the mechanics of how this attack happens, and then we will discuss the forensic and defense aspects in the second section.

The attack 

Let’s get into the requirements for this attack. First, the attacker must have Administrator privileges and remote access to the target’s machine. Since this attack is part of defense evasion and data exfiltration in the cyber kill chain, we can assume that the attacker already has remote access to the environment.

In this example, we assume the attacker has RDP access to a Windows 10 system, and their goal is to exfiltrate data while bypassing defenses and leaving no traces.

The first step is to enable the Windows Sandbox feature, which is, by default, disabled on all supported Windows machines. This can be achieved either via the command line or the graphical user interface (GUI). Once this feature is enabled, the host machine needs to be restarted.

Attackers can use the following PowerShell command to enable Windows Sandbox:

“Enable-WindowsOptionalFeature -Online -FeatureName "Containers-DisposableClientVM" -All”

To enable Windows Sandbox through the GUI, open the Control Panel, select "Turn Windows features on or off," and enable the "Windows Sandbox" feature. After the machine reboots, the attacker can now execute Windows sandbox.

This will spawn an isolated instance of Windows with Defender disabled by default. Now, any activity performed under this container(like downloading tools) will leave no evidence on the host OS, essentially bypassing defenses and leaving no forensics trail.

In this example, we will stage and then exfiltrate data in Windows Sandbox. To lay the groundwork for this process, we need to download 7-Zip and FileZilla in the sandbox to prepare for this process.

After these are downloaded, we will install these applications.

Now that these tools are installed in the sandbox, we can start collecting, archiving, and exfiltrating data. First, we need to identify and stage all the data we are interested in. 

Since we’ll be exfiltrating data from Windows Sandbox, we need to transfer the relevant files from the host to the sandbox. Here are the files we plan to exfiltrate:

The easiest way to move these files to the sandbox is just to copy these documents and paste in Windows Sandbox instance.

Now that we have these files on Windows Sandbox, we can easily stage and create an archive containing them, as we already downloaded 7zip. We created a directory called “Exfiltration” and staged these files under that folder.

Now we will create a zip of this folder to prepare for exfiltration.

Now we will run Filezilla and connect to an ftp server to exfiltrate our Archive.

Windows Sandbox is a temporary environment, so when it’s closed or destroyed, all the data within it is lost. Why? This feature ensures that attackers do not leave any forensic evidence behind, as all their malicious activities take place within the Windows Sandbox, which does not retain any data. 

Once we have completed our exfiltration, simply close the Windows Sandbox window.

Now that we’ve simulated attacker behavior to bypass defenses and used Windows Sandbox to exfiltrate data without leaving forensic traces, we’ll now look at the forensic impact of this activity and what evidence can still be recovered

Attackers can download and run their preferred tools freely in Windows Sandbox without worrying about leaving any traces behind. But since Windows Sandbox is a restricted environment, not all tools will be useful to attackers. 

For instance, downloading and running Mimikatz in Windows Sandbox won't yield any benefits, as there is only one temporary user account in a Windows Sandbox session, and Mimikatz cannot dump credentials from the host system while operating in the Sandbox.

On the other hand, tools related to data exfiltration, such as archive utilities, can be valuable, as attackers can achieve their objectives using these tools within the Windows Sandbox. Another potential use case for Windows Sandbox, besides data exfiltration, is that attackers may use it to download and stage their tools. They can then shift these tools to the host system as needed.

For example, downloading a tool using Certutil or WGET could trigger antivirus or EDR alerts, even if the tool can bypass defenses. In such cases, attackers can download the Windows Sandbox tools and copy and paste them into the host system.

Forensics and defense

In this section, we will explore artifacts and logs that may indicate the use of this technique. As previously mentioned, activities conducted within a Windows Sandbox session do not leave any forensic evidence behind. Therefore, the mere usage of Windows Sandbox serves as indirect evidence that an attacker may have utilized this Windows feature.

We will examine all possible evidence following the attack flow discussed in the first section. We began by enabling Windows Sandbox, as it is disabled by default. Whenever the Windows Sandbox feature is enabled, Event IDs 7, 9, and 13 are recorded in the "Setup" event logs.

When we enabled the Windows feature (either via command line or GUI), Event ID 7 in the Setup Event logs was recorded. After enabling it, we were prompted to reboot the system to properly enable this feature, and this interaction is recorded in Event ID 13.

After successfully rebooting the system, Event ID 9 gets recorded, which proves that Windows Sandbox was enabled and turned on the system.

The next few artifacts we will discuss are related to the initiation and execution of a Windows Sandbox session. After enabling Windows Sandbox, we launched the Sandbox application to start our session. This activity triggers multiple artifacts that demonstrate the utilization of Windows Sandbox on the system. 

The first type of artifact is found in the Windows Event logs, specifically in the Hyper-V-Compute/Operational Event log. We are particularly interested in Event ID 2014, which records the creation of the virtual machine container image used in the sandbox session. This event also provides the GUID value of the virtual machine.

After the Virtual machine has been created by the Windows host and the container has started successfully (meaning all the components have been loaded and the sandbox is ready to be used), the Windows sandbox session truly starts for the user.

 This activity is recorded in the AppModel-Runtime Channel. Event ID 39 records the start of this activity, and Event ID 41 records the end of it.

It's important to note that this event ID is not exclusive to Windows Sandbox; it is also used for other container workloads within Windows. To specifically identify events related to Windows Sandbox activity, we should look for events with the keyword "CmProxyD."

Similarly, when the Windows Sandbox session is destroyed, Event ID 41 is recorded.

These Windows Event Logs prove that Windows Sandbox was enabled and started on the system. 

Next up is prefetch. We acquired artifacts from the host system and used PECmd.exe to parse prefetch files. 

Let's start by searching the tools we downloaded on the sandbox for exfiltration purposes. We downloaded 7zip and FileZilla and also executed and used them.

Performing a search in our Prefetch yields no results.

Time to do the same for Filezilla as well.

There are still no results for this as well. This proves that no forensics evidence is left behind on the host system related to the activity that took place inside the sandbox session. Even though no knowledge of the attacker’s tool activity can be found, we can still find further evidence of execution that Windows Sandbox was executed on the host system.

We can see the timestamp of execution for this is in line with the timeline we established from event log sources, which indicated enabling and starting of Windows Sandbox.

From the perspective of a forensic investigator, there is typically no knowledge of activities related to FileZilla or 7-Zip because such actions are often hidden; the attacker used Windows Sandbox. This technique is unique and dangerous because it creates a blind spot by completely bypassing traditional forensic artifacts.

This blog covers an unconventional  approach to analysis, using non-traditional artifacts to indirectly support claims for which we do not have direct evidence.

At this stage in the attack flow, the next step involved moving data from the host system to the Windows Sandbox session. If the attacker used the Windows Explorer GUI to copy and paste files into the sandbox, this activity could potentially be recorded in Shellbags and Jump Lists.

We will start by taking a look at shellbags using ShellBagsExplorer for the User account “CyberJunkie” since that was the account utilized in the attack.

According to the timestamps, this path was visited on 2025-06-10 at 12:57:47, which is a few minutes after the Sandbox activity began.

Jumping to Jumplists results, we again have confirmation of the timeline when the Documents folder was accessed.

After analyzing both Shellbags and Jumplists, we have found potential evidence suggesting that files located at “C:\Users\CyberJunkie\Documents\Important Documents” were of interest to the attacker. However, we still lack direct evidence indicating that the files were exfiltrated or that any tools were used.

The next artifact is critical for defining this attack technique and guiding a potential investigator in the right direction. Windows maintains a database at “C:\Users\AccountName\AppData\Local\ConnectedDevicesPlatform\L.AccountName\ActivitiesCache.db” that records copy-paste operations on the system.

We can examine this database to find evidence that files were moved or copied from the host to Windows Sandbox.

To open and analyze this database, we can use the Db Browser for SQLite. In the Db Browser, go to the Activity table.

Next, add a filter in the AppId column for the keyword “sandbox” and in ActivityType Column add a filter for “16”:

Activity Type 16 stands for “Copy operation,” and these entries proved that Files were copied to SandboxClient.exe, the App for the Sandbox session. We also have a column called StartTime and EndTime, which stores the epoch timestamp of the related activity.

If we convert these timestamps to UTC

Converting these timestamps to UTC, we’ll see that they perfectly match the timeline of events and closely align with the timestamp found in shellbags. This artifact dictates to us that some files were definitely copied and pasted into Sandbox, and the timeline of these activities also falls within our established timeline.

Before wrapping up, let's take a look at MFT and SRUM as well to see if we can find any evidence of 7zip or Filezilla on the host system or any evidence of data exfiltration. We will parse MFT using the Mftecmd tool.

Analysis of MFT Again proves that no traditional evidence works against this clever attacker potential technique.

SRUM is a classic Data exfiltration analysis artifact used by forensic investigators to determine whether any unexpected program uploaded or downloaded data. The SRUM database can be parsed with SRUMeCmd; from the results, we can analyze the Network Usages CSV, which contains the timestamp of the executables run on the system alongside the tool's network usage. 

Performing a search for Filezilla also yields no results because it was never exposed to the host system and left zero evidence.

Traditional artifacts vs Windows Sandbox Technique

If the same data exfiltration we simulated in the attack section had been conducted directly on the host system (as is typically done), we would have had several indicators and pieces of evidence to conclusively determine the root cause and the flow of the attack.

For example, when an attacker downloaded 7-Zip and FileZilla in a Windows Sandbox, that evidence never touched the host system and was lost when the session was closed. If the same tools were downloaded on the host system, we would have evidence of these tools in the registry, as well as filesystem artifacts (such as MFT and USN Journal) and execution artifacts (including UserAssist, prefetch files, LNK files, and jump lists). 

Because of this attack technique, none of that evidence would be available to prove that these tools were ever present on the host system. This is the core of this attack technique, which allows potential attackers to bypass defenses and evade forensic analysis, leaving no traces on the host system. 

However, we were still able to develop an investigative flow and mindset to uncover such attacks potentially. By the nature of the technique, fully detecting these kinds of attacks is simply impossible. The main goal of this blog is to raise awareness about this attack since Windows Sandbox is a feature of the Windows operating system that can be enabled and exploited by adversaries. 

To summarise this attack technique: 

1. It bypasses traditional defenses like EDR or Antivirus.

2. It leaves no traces in traditional artifacts like SRUM,Registry, Prefetch which would indicate certain attacker tools were downloaded and used.

3. It is potentially a LOLBIN, as this is a built-in feature on Windows 10 + Os versions.

Detection summary:

1. Event ID 7, 9 and 13 from “Setup” Event Log.

2. Event ID 2014 from “Hyper-V-Compute/Operational” Event Log.

3. Event ID 39 AND 41 from “AppModel-Runtime” Event Log.=

4. Evidence of execution for Windows Sandbox executables like WindowsSandbox.exe or WindowsSandboxClient.exe

5. Folder/Network Paths from shellbags around the timeline of events from event logs.

6. ActivitiesCache.db Activity type 16 for WindowsSandbox process around the timeline from shellbags and event logs.

Mitigations

Windows Sandbox is and should remain disabled by default on enterprise systems to reduce the attack surface and prevent potential security risks associated with virtualization-based isolation bypass techniques. 

Organizations should implement AppLocker policies to explicitly deny the execution of Windows Sandbox components (such as WindowsSandbox.exe) and related virtualization utilities, ensuring that only authorized personnel can access these features through controlled exceptions. This prevents unauthorized users from leveraging sandbox environments to exfiltrate data or bypass security controls.

Detection rules related to Windows Sandbox process executions should be created. In addition to this, network solutions should be used like firewall, IDS/IPS, netflow etc which will provide visibility into network activity in case of Sandbox abuse for Data Exfiltration.