Microsoft unveils Windows Sandbox: Run any app in a disposable virtual machine

( Original text by PETER BRIGHT )

A few months ago, Microsoft let slip a forthcoming Windows 10 feature that was, at the time, called InPrivate Desktop: a lightweight virtual machine for running untrusted applications in an isolated environment. That feature has now been officially announced with a new name, Windows Sandbox.

Windows 10 already uses virtual machines to increase isolation between certain components and protect the operating system. These VMs have been used in a few different ways. Since its initial release, for example, suitably configured systems have used a small virtual machine running alongside the main operating system to host portions of LSASS. LSASS is a critical Windows subsystem that, among other things, knows various secrets, such as password hashes, encryption keys, and Kerberos tickets. Here, the VM is used to protect LSASS from hacking tools such that even if the base operating system is compromised, these critical secrets might be kept safe.Ars Technica

In the other direction, Microsoft added the ability to run Edge tabs within a virtual machine to reduce the risk of compromise when visiting a hostile website. The goal here is the opposite of the LSASS virtual machine—it’s designed to stop anything nasty from breaking out of the virtual machine and contaminating the main operating system, rather than preventing an already contaminated main operating system from breaking into the virtual machine.

Windows Sandbox is similar to the Edge virtual machine but designed for arbitrary applications. Running software in a virtual machine and then integrating that software into the main operating system is not new—VMware has done this on Windows for two decades now—but Windows Sandbox is using a number of techniques to reduce the overhead of the virtual machine while also maximizing the performance of software running within the VM, without compromising the isolation it offers.

The sandbox depends on operating system files residing in the host.
Enlarge / The sandbox depends on operating system files residing in the host.Microsoft

Traditional virtual machines have their own operating system installation stored on a virtual disk image, and that operating system must be updated and maintained separately from the host operating system. The disk image used by Windows Sandbox, by contrast, shares the majority of its files with the host operating system; it contains a small amount of mutable data, the rest being immutable references to host OS files. This means that it’s always running the same version of Windows as the host and that, as the host is updated and patched, the sandbox OS is likewise updated and patched.

Sharing is used for memory, too; operating system executables and libraries loaded within the VM use the same physical memory as those same executables and libraries loaded into the host OS.

That sharing of the host's operating system files even occurs when the files are loaded into memory.
Enlarge / That sharing of the host’s operating system files even occurs when the files are loaded into memory.Microsoft

Standard virtual machines running a complete operating system include their own process scheduler that carves up processor time between all the running threads and processes. For regular VMs, this scheduler is opaque; the host just knows that the guest OS is running, and it has no insight into the processors and threads within that guest. The sandbox virtual machine is different; its processes and threads are directly exposed to the host OS’ scheduler, and they are scheduled just like any other threads on the machine. This means that if the sandbox has a low priority thread, it can be displaced by a higher priority thread from the host. The result is that the host is generally more responsive, and the sandbox behaves like a regular application, not a black-box virtual machine.

On top of this, video cards with WDDM 2.5 drivers can offer hardware-accelerated graphics to software running within the sandbox. With older drivers, the sandbox will run with the kind of software-emulated graphics that are typical of virtual machines.

Taken together, Windows Sandbox combines elements of virtual machines and containers. The security boundary between the sandbox and the host operating system is a hardware-enforced boundary, as is the case with virtual machines, and the sandbox has virtualized hardware much like a VM. At the same time, other aspects—such as sharing executables both on-disk and in-memory with the host as well as running an identical operating system version as the host—use technology from Windows Containers.

At least for now, the Sandbox appears to be entirely ephemeral. It gets destroyed and reset whenever it’s closed, so no changes can persist between runs. The Edge virtual machines worked similarly in their first incarnation; in subsequent releases, Microsoft added support for transferring files from the virtual machine to the host so that they could be stored persistently. We’d expect a similar kind of evolution for the Sandbox.

Windows Sandbox will be available in Insider builds of Windows 10 Pro and Enterprise starting with build 18305. At the time of writing, that build hasn’t shipped to insiders, but we expect it to be coming soon.


An anti-sandbox/anti-reversing trick using the GetClipboardOwner API

( Original text by Hexacorn )

This is a little nifty trick for detecting virtualization environments. At least, some of them.

Anytime you restore the snapshot of your virtual machine your guest OS environment will usually run some initialization tasks first. If we talk about VMWare these tasks will be ran by the vmtoolsd.exe process (of course, assuming you have the VMware Tools installed).

Some of the tasks this process performs include clipboard initialization, often placing whatever is in the clipboard on the host inside the clipboard belonging to the guest OS. And this activity is a bad ‘opsec’ of the guest software.

By checking what process recently modified the clipboard we have a good chance of determining that the program is running inside the virtual machine. All you have to do is to call GetClipboardOwner API to determine the window that is the owner of the clipboard at the time of calling, and from there, the process name via e.g. GetWindowThreadProcessId. Yup, it’s that simple. While it may not work all the time, it is just yet another way of testing the environment.

If you want to check how and if it works on your VM snapshots you can use this little program: ClipboardOwnerDebug.exe

This is what I see on my win7 vm snapshot after I revert to its last state and run the ClipboardOwnerDebug.exe program:

Notably, I didn’t drag&drop/copy paste the ClipboardOwnerDebug.exe file to VM, I actually copied it via a network share to ensure my clipboard doesn’t change during this test; and, even if I did just CTRL+C (copy) the file on the host and CTRL+V (paste) it on the guest the result would be very similar anyway. The vmtoolsd.exe process just gets involved all the time.

The malware doesn’t need to rely on the first call to the GetClipboardOwner API. It could stall for a bit observing changes to the clipboard owner windows and testing if at any point there is a reference to a well-known virtualization process. Anytime the context of copying to clipboard changes between the host and the guest OS (very often when you do manual reversing), the clipboard window ownership will change, even if just temporarily.

The below is an example of the clipboard ownership changing during a simple VM session where things are copied to clipboard a few time, both on the host and on the guest and the context of the the clipboard changes. The context switch means that when the guest gets the mouse/keyboard focus, the changes to host clipboard are immediately reflected by the appearance of the vmtoolsd.exe process on the list:

Microsoft Sandboxes Windows Defender

As the infosec community talked about potential cyber attacks leveraging vulnerabilities in antivirus products, Microsoft took notes and started to work on a solution. The company announced that its Windows Defender can run in a sandbox.

Antivirus software runs with the highest privileges on the operating system, a level of access coveted by any threat actor, so any exploitable vulnerabilities in these products add to the possibilities of taking over the system.

By making Windows Defender run in a sandbox, Microsoft makes sure that the security holes its product may have stay contained within the isolated environment; unless the attacker finds a way to escape the sandbox, which is among the toughest things to do, the system remains safe.

Remote code execution flaws

Windows Defender has seen its share of vulnerability reports. Last year, Google’s experts Natalie Silvanovich and Tavis Ormandy announced a remote code execution (RCE) bug severe enough to make Microsoft release an out-of-band update to fix the problem.

In April this year, Microsoft patched another RCE in Windows Defender, which could be abused via a specially crafted RAR file. When the antivirus got to scanning it, as part of its protection routine, the would trigger, giving the attacker control over the system in the context of the local user.

Microsoft is not aware of any attacks in-the-wild actively targeting or exploiting its antivirus solution but acknowledges the potential risk hence its effort to sandbox Windows Defender.

Turn on sandboxing for Windows Defender

The new capability has been gradually rolling out for Windows Insider users for test runs, but it can also be enabled on Windows 10 starting version 1703.

Regular users can also run Windows Defender in a sandbox if they have the operating system version mentioned above. They can do this by enabling  the following system-wide setting from the Command Prompt with admin privileges:


Restarting the computer is necessary for the setting to take effect. Reverting the setting is possible by changing the value for forcing sandboxing to 0 (zero) and rebooting the system.

Sandboxing Windows Defender

Forcing an antivirus product to work from an insulated context is no easy thing to do due to the app’s need to check a large number of inputs in real time, so access to these resources is an absolute requirement. An impact on performance is a likely effect of this.

«It was a complex undertaking: we had to carefully study the implications of such an enhancement on performance and functionality. More importantly, we had to identify high-risk areas and make sure that sandboxing did not adversely affect the level of security we have been providing,» the official announcement reads.

Despite the complexity of the task, Microsoft was not the first to sandbox Windows Defender. Last year, experts from security outfit Trail of Bits, who also specialize in virtualization, created a framework that could run Windows applications in their own containers. Windows Defender was one of the projects that Trail of Bits was able to containerize successfully and open-sourced it.

AVs are as susceptible to flaws as other software

Despite their role on the operating system, security products are susceptible to flaws just like other complex software. Windows Defender is definitely not the only one vulnerable.

In 2008, security researcher Feng Xue talked at BlackHat Europe about techniques for finding and exploiting vulnerabilities in antivirus software, referencing bugs as old as 2004.

Xue pointed out that the flaws in this type of software stem from the fact that it has to deal with hundreds of files types that need to be checked with components called content parsers. A bug in one parser could represent a potential path on the protected system.

Six years later, another researcher, Joxean Koret, took the matter further and showed just how vulnerable are the defenders of the computer systems, and let the world know that exploiting them «is not different to exploiting other client-side applications.»

His analysis at the time on 14 antivirus solutions on the market revealed dozens of vulnerabilities that could be exploited remotely and locally, including denial of service, privilege escalation, and arbitrary code execution. His list included big names like Bitdefender and Kaspersky.

Antivirus developers do not leave their customers high and dry and audit their products constantly. The result is patching any of the bugs discovered during the code review and improving the quality assurance process for finer combing for potential flaws.