In Windows 10 update 1903 Microsoft introduced a new security feature for Windows Pro and Enterprise users. That feature is Windows Sandbox. Windows Sandbox uses Microsoft’s excellent Hyper-V technology to create a temporary virtual Windows 10. This Small virtual machine takes only a few second to load up and destroys everything when you close it. This short term VM is great for testing out programs before you install them on your main computer, but is it a good idea to use this VM to detonate malware?
TLDR upfront: No. It’s not recommended.
When I first heard about Windows Sandbox I was immediately curious about it’s potential for quick turn malware analysis or browsing questionable websites. I did some testing and decided that it’s probably not a good idea to use Windows Sandbox for malware analysis.
The first reason I don’t think it’s a great idea is because the temporary nature of Windows Sandbox mean that any long term analysis will be near impossible. In addition to this Windows Sandbox always starts as a basic Windows 10. This means no tools are installed and nothing is configured for analysis. Trying to conduct analysis would require you copy over and install all of your tools on the VM every time you opened it up.
While having to reinstall all your tools is inconvenient it’s not the real reason I recommend against using this sandbox for malware analysis.
The primary reason I don’t think Windows Sandbox is because of how it handles networking. Windows Sandbox uses the Hyper-V switch to NAT your ethernet adapter and provide internet access to the VM. This is pretty standard for hypervisors to NAT your computer for the VMs but normally the VM does not have a router to other devices on your network. The Windows Sandbox is able to reach any device across your network.
I was curious what I could reach through the VM so I first started out with a traceroute.
As you can see the Sandbox is on a different subnet but the VM is still able to route both to something in the same broadcast domain and is able to reach services on a different subnet.
Traceroute is not the best way to test connectivity since it uses ICMP. ICMP is frequently handled by different rules in networks, for example Firewalls may block all inbound yet still allow ICMP to get through.
Next up I decided to run a quick scan using NMAP from the Sandbox against my main subnet. The Windows Sandbox was able to find every computer I had connected
Something interesting I noticed when looking through my NMAP scan was there was that there was no port 445 (SMB) listed in the ports.
There also wasn’t port 443 which is clearly listed in the image above. This made me curious if what the Sandbox can actually reach. Malware laterally moving over SMB (T1021.002) is a major concern, particularly with ransomware. Some ransomware is capable of encrypting files on network shares attached to a computer. Other malware is able to brute force SMB credentials. Because of this I really wanted to understand if you could make an SMB connection out from the Windows Sandbox. I took one of my malware analysis VMs (which already has a shared drive for sharing objects between analysis VMs) and attempted to connect to it from my Windows Sandbox.
In my testing I was not able to make a connection to the shares on my malware analysis machine from the Windows Sandbox. I am able to make a connection to these shares from my SIFT Workstation.
I was able to make a successful SMB connection over to my NAS so SMB is not blocked in the Sandbox.
That’s encouraging. Next up I wanted to test if the Sandbox could connect over RDP. Remote Desktop is another lateral movement technique (T1021.001) sometimes used directly by attackers and sometimes brute forced by malware. I connect to my malware analysis VM through RDP so I know that it has RDP set up. When I tested it in the Windows Sandbox I actually got a message that the security package did not exist to initiate an RDP session from the sandbox.
The next question I had was if the Windows Sandbox could reach out over any port or if it was limited to common ports only. You might look at the NMAP scan and say “well obviously not, you can see the ports right there”, and you’d be almost correct. TCP SYN Scans use raw sockets when scanning so they are handled differently.
I attempted to browse to a webserver I have over port 2342. The Sandbox was able to successfully reach the web browser over a non standard HTTP port.
The Windows Sandbox is not as insecure as I was initially concerned about, but I still have concerns about the Sandbox being able to see my main network. In the future I would like to run some tests using Meterpreter to see if I can get a handler to beacon out and then if I can get a route to go through the sandbox into another machine.
At the end of the day, I still don’t think that Windows Sandbox is going to be a good way to analyze malware due to having to reinstall tools every time and it’s ability to reach the LAN.