Demystifying Windows Defender Application Guard

Windows Defender Application Guard (Application Guard) was introduced with Windows 10 build 1709  and is designed to protect from current and future attacks against internet exposed applications such as Edge or Office applications. WDAG leverages Microsoft virtualization and hardware isolation technology, in fact Hyper-V containers to isolate applications from the operating system. Hyper-V containers seem to be an ideal solution for this as the have a more secure virtualization abstraction layer than classic container.

For more information on Hyper-V containers see here:

https://docs.microsoft.com/en-us/virtualization/windowscontainers/manage-containers/hyperv-container

Windows Defender Application Guard in Depth

Disclaimer: The following details have been discovered by myself and may not be 100% accurate, based on process tracking and reverse engineering my assumptions could be wrong. However, this is what I’ve found out so far.

WDAG is an optional component to install / activate on Windows 10 Enterprise and Professional. To enable the feature (which requires a reboot):

Enable-WindowsOptionalFeature -FeatureName Windows-Defender-ApplicationGuard -Online

After reboot you’ll notify that your available user memory has significantly decreased, which is because of a new hidden Hyper-V container instance beeing spun up behind the scenes. As soon as new application guard windows are started the memory footprint of the corresponding vmmem.exe process will increase significantly. I’ve observed up to 1.3GB working set with just a few web pages opened. Vmmem reflects the memory used inside a virtual machine or in this case here, the Hyper-V Container.

You won’t find this container instance using regular management tools such as docker client, because it is hidden from the management layer. However as any other windows container it is managed by the “Container Manager Service”. Protected applications (currently Edge exclusively) are started within this container while they are seamlessly presented on the host operating system using a tiny version of the RDP client. So very simplified, think of a remote app, launched in a container, presented to the host OS via RDP.

Depending on the mode (standalone or enterprise), Browser Broker get’s called manually or automatically based on the entered URL / address. Windows Defender Guard Manager talks to the Container Manager Service which initiates the launch of a new Edge Browser instance inside the pre-launched container. A special RDP Client (HvsiRdpClient) displays content and allows KVM interaction to the edge app running inside the Hyper-V Container.

Standalone vs. Enterprise Mode

There are two working modes for WDAG. The difference is quite simple. The enterprise mode automatically detects safe versus unsafe URLs, based on group policy settings and launches the url within a guarded Edge process inside the WDAG container. In contrary, with standalone mode, the user has to explicitly launch a new guarded window/tab. Enterprise mode requires Windows 10 Enterprise SKU.

How to configure Windows Defender Application Guard

Configuration of WDAG settings can be done via GPO (requires enterprise SKU) or via settings application.

Summary

Windows Defender Application Guard protects the operating system from malicious software as it runs the application inside a Hyper-V Container. Using this technology you can now safely speak of a real “sand boxed Browser”. Enterprise organisations can keep a high level of security and control, while still allowing users to access non-trusted websites through the isolated environment enriching the overall user experience. Although there is some interaction between the host OS and the app running inside the container, it’s very secure by default, as no file, process, registry or RPC access is allowed with the “mother” OS. Files can be printed out if configured by the admin, but not saved outside the container environment. Copy and paste (RDP Clip only) can also be enabled as well as keeping settings and cookies for the containerized browser. Very nice move, we’ll see what other types of applications will leverage this technology in the future.