This article is a part of a series. The previous article can be found here:

All the Guards – Part 5 (Credential Guard)

In this article I’m going to focus on the next component, which is:

Application Guard

For Microsoft Edge, Application Guard helps to isolate enterprise-defined untrusted sites, protecting your company while your employees browse the Internet. As an enterprise administrator, you define what is among trusted web sites, cloud resources, and internal networks. Everything not on your list is considered untrusted. If an employee goes to an untrusted site through either Microsoft Edge or Internet Explorer, Microsoft Edge opens the site in an isolated Hyper-V-enabled container.

For Microsoft Office, Application Guard helps prevents untrusted Word, PowerPoint and Excel files from accessing trusted resources. Application Guard opens untrusted files in an isolated Hyper-V-enabled container. The isolated Hyper-V container is separate from the host operating system. This container isolation means that if the untrusted site or file turns out to be malicious, the host device is protected, and the attacker can’t get to your enterprise data. For example, this approach makes the isolated container anonymous, so an attacker can’t get to your employee’s enterprise credentials.

In essence, Application Guard provides an sandbox to use with your browser and Office. Untrusted web sites and documents are open in this sandbox to provide isolation from the rest of the system for security. You can implement Application Guard on both Windows 10 Pro and Enterprise out of the box as well as with Edge and other common browsers.

You can read about the specific:

System Requirements for Microsoft Defender Application Guard

but in essence you’ll need the

Virtualization Based Security (VBS)

configured prior.

There are various ways to enable Application Guard and you’ll find these here:

Prepare to install Microsoft Defender Application Guard

However, the easiest way is to enable Application Guard is by adding the Microsoft Defender Application Guard feature to Windows from the Control Panel as shown above.

If you are an administrator then you will also want to take a look at:

Application Guard for admins

Remember there is Application Guard for Edge and for Office:

Application Guard for Office

However, to use the Office version you’ll currently need Microsoft 365 E5.

Getting Application Guard to work as expected can be a tricky endeavour because it relies on things like Network Boundaries to define trusted and untrusted sites, which are determined by policy configurations. For all this, I suggest you take a look at my earlier article:

Getting Windows Defender Application Guard (WDAG) working

That article will also show you how to use the:

Windows Defender Application Guard Companion

which is really handy if you want to run Application Guard manually, which you’ll typically have to do unless you are using Windows 10 Enterprise.

Another handy resource is:

Frequently asked questions – Microsoft Defender Application Guard

To test your environment see:

Application Guard testing scenarios

Finally, here is a nice overall summary guide:

Windows 10 – All things about Application Guard

which importantly, provides the following troubleshooting tips:

• To reset (clean up) a container and clear persistent data inside the container:
• 1.  Open a command-line program and navigate to Windows/System32.
  2. Type wdagtool.exe cleanup. The container environment is reset, retaining only the employee-generated data.
  3. Type wdagtool.exe cleanup RESET_PERSISTENCE_LAYER. The container environment is reset, including discarding all employee-generated data.

Window Defender Application Guard is a great way to provide a sandbox for your browser as well as Office documents. The main limitation is that many of the automated features are only available if you are using Windows 10 Enterprise but that doesn’t stop you adopting Application Guard for your environment I would suggest, as any impact can easily be minimised for Windows 10 Pro environments.

Next up will be:

Exploit Guard

This article is a part of a series. The previous article can be found here:

All the Guards – Part 4 (System Guard)

In this article I’m going to focus on the next component:

Credential Guard

Microsoft Defender Credential Guard protects against credential theft attacks. It isolates secrets so that only privileged system software can access them.

Credential Guard is a specific feature that is not part of Device Guard that aims to isolate and harden key system and user secrets against compromise, helping to minimize the impact and breadth of a Pass the Hash style attack in the event that malicious code is already running via a local or network based vector.

Credential Guard isolates credentials using Virtualization Based Security (VBS).

Prior to Windows 10, the LSA stored secrets used by the operating system in its process memory. With Windows Defender Credential Guard enabled, the LSA process in the operating system talks to a new component called the isolated LSA process that stores and protects those secrets. Data stored by the isolated LSA process is protected using virtualization-based security and is not accessible to the rest of the operating system. LSA uses remote procedure calls to communicate with the isolated LSA process

For security reasons, the isolated LSA process doesn’t host any device drivers. Instead, it only hosts a small subset of operating system binaries that are needed for security and nothing else. All of these binaries are signed with a certificate that is trusted by virtualization-based security and these signatures are validated before launching the file in the protected environment.

Windows Defender Credential Guard Requirements

• Support for Virtualization-based security (required)
  

• Secure boot (required)
  

• Trusted Platform Module (TPM, preferred – provides binding to hardware) versions 1.2 and 2.0 are supported, either discrete or firmware
  

• UEFI lock (preferred – prevents attacker from disabling with a simple registry key change)

You can enable Credential Guard using various methods which are detailed here:

Manage Windows Defender Credential Guard

To verify that Credential Guard is running:

run the System Info app on you Windows 10 device

and look for the:

Virtualization-based security Service Configured

and

Virtualization-based security Service Running

to make sure you see Credential Guard in both as shown above.

If you look at your Task Manager you should see a task called lsalso.exe as shown above, which is the protected version of lsass.exe that Credential Guard sets up.

You should also review as some features and passwords could be impacted by protecting credentials per:

Considerations when using Windows Defender Credential Guard

There are also a few readiness tools for Credential Guard I found that may be handy:

Windows Defender Device Guard and Windows Defender Credential Guard hardware readiness tool

Device Guard and Credential Guard hardware readiness tool

Once you have Virtualization Based Security (VBS) and Secure boot enable on your system, you can take advantage of Windows Defender Credential Guard to isolate credentials and protect them.

In Part 6 we’ll take a look at:

Application Guard

This article is a part of a series. The previous article can be found here:

All the Guards – Part 3 (Device Guard)

In this article I’m going to focus on the next component:

System Guard

Windows Defender System Guard reorganizes the existing Windows 10 system integrity features under one roof and sets up the next set of investments in Windows security. It’s designed to make these security guarantees:

– Protect and maintain the integrity of the system as it starts up
– Protect and maintain the integrity of the system after it’s running
–  Validate that system integrity has truly been maintained through local and remote attestation

As Windows 10 boots, a series of integrity measurements are taken by Windows Defender System Guard using the device’s Trusted Platform Module 2.0 (TPM). This process and data are hardware isolated away from Windows to help ensure that the measurement data is not subject to the type of tampering that could happen if the platform was compromised. From here, the measurements can be used to determine the integrity of the device’s firmware, hardware configuration state, and Windows boot-related components, just to name a few. After the system boots, Windows Defender System Guard signs and seals these measurements using the TPM, and, upon request a management system, like Intune or System Center Configuration Manager, can acquire them for remote analysis. From here the management system can take a series of actions, such as denying the device access to resources, if Windows Defender System Guard indicates that the device lacks integrity.

At the end of the Windows boot process, System Guard will start the system’s antimalware solution which scans all third party drivers, at which point the system boot process is completed. In the end, Windows Defender System Guard helps ensure that the system securely boots with integrity and that it hasn’t been compromised before the remainder of your system defenses start.

At the end of the Windows boot process, System Guard will start the system’s antimalware solution which scans all third party drivers, at which point the system boot process is completed. In the end, Windows Defender System Guard helps ensure that the system securely boots with integrity and that it hasn’t been compromised before the remainder of your system defenses start.

Windows Defender System Guard: How a hardware-based root of trust helps protect Windows 10

To enable System Guard Secure launch, the platform must meet all the baseline requirements for Device Guard, Credential Guard, and Virtualization Based Security.

System requirements for System Guard

There are various ways that you can enable System Guard detailed here:

System Guard Secure Launch and SMM protection

You can also use Microsoft Endpoint Manager | Windows 10 Security Baseline | Device Guard:

To verify that System Guard is running, once again run msinfo32 at the command prompt:

You should see the text Secure Launch in the text for the options Virtualization-based Security Services Running and Virtualization-based Security Services Configured as shown above.

If you also look at the items running in Task Manager you should see one called Secure System as shown:

While I was investigating Secure Launch on my Surface PC’s I found that it wasn’t launching for some reason. Here is the reason why I received from the surface team about why this is on these devices:

We actually don’t support Secure Launch but we have the same/similar protection built into the Surface firmware regardless. It’s one of the main arguments of why most Surface devices don’t fall under the “Secure Core PC” definition

Secure Core PCs – https://www.microsoft.com/en-us/windowsforbusiness/windows10-secured-core-computers

Secure Launch is required because of the variety of OEM firmware versions that became to cumbersome to manage statically for Windows to verify that it hadn’t been tampered with. Secure Launch uses Dynamic Root of Trust Management which is a creative approach for the OS to “learn” what a clean firmware looks like and then make sure it doesn’t get maliciously changed.

The Surface firmware (since its first party) can still be measured statically and Windows can validate whether its been tampered with or not.

SMM (System Management Mode) is a set of highly privileged instructions that the CPU can use to the OS, firmware and key resources. OEM firmware uses SMM for a number of different process (updates, firmware changes, offline servicing using AMT, etc). SMM Protection does not add much value for Surface since we limit our SMM instruction set to just 2 or 3 key handlers which wouldn’t allow a hacker to exploit much.

1) DRTM

Dynamic Root of Trust Measurements (DRTM) is a security feature that must be supported by the SoC and TPM to ensure the boot chain is trusted at each stage. DRTM provides for checking of each stage of UEFI boot by fully checking the code with measurement in the TPM. The SoC supports DRTM by providing special instructions that prevent other cores from running except the core the boot is running on, to address UEFI DXE extensions that may have been installed.

ProX supports DRTM, but Pro7 and Laptop3 use a different mechanism to ensure the integrity of the trust chain. It isn’t just a measurement that is checked before the first UEFI phase; the first UEFI Phase is verified using a Microsoft signature that is fused into the Soc at the factory. Each phase of UEFI verifies the signature of the next phase through the OS boot loader. Only code authorized by Microsoft is able to execute in the boot chain.

​2) SMM Protection

System Management Mode (SMM) Protection is used to prevent malicious low level code from accessing resources out of their bounds. Pro7 and Laptop3 support all of the SMM Protections that ICL supports. Kernel mode drivers that access SMM use SMM interrupts (SMI). Reducing the available attack surface is import; defense in depth. Surface reduces the attack surface by reducing the number of SMI handlers on Surface devices, to two handlers; the realtime clock and UEFI variables.

The main thing I suggest you check for in regards to Secure Guard being enabled is the Secure System process in the Task Manager.

The concept of Secure System and Secure Launch seem to used inter changeably in places resulting in confusion along with the fact that Surface PC’s take a different approach to System Guard/Secure launch. Unfortunately, I have not been able to track down a consistent explanation of all of this so I hope you at least have a better idea of what System Guard is and does, plus maybe how to enable it if you wanted.

In Part 5 of this series I’ll take a look at:

Credential Guard