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

All the Guards – Part 8 DMA Guard

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

Control Flow Guard

Control Flow Guard (CFG) is a highly-optimized platform security feature that was created to combat memory corruption vulnerabilities. By placing tight restrictions on where an application can execute code from, it makes it much harder for exploits to execute arbitrary code through vulnerabilities such as buffer overflows.

An administrator or user cannot configure Control Flow Guard. It is something that a developer must do inside their code. It is however something they can take advantage of in Windows 10:

Control Flow Guard

Of course, browsers are a key entry point for attacks, so Microsoft Edge, IE, and other Windows features take full advantage of CFG.

That bring us to the end of all the ‘Guards’ that I can find out there from Microsoft. I’ll provide a summary of all of this information in the final part of the series::

Summary of all the Guards

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

All the Guards – Part 7 Exploit Guard

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

DMA Guard

In Windows 10 version 1803, Microsoft introduced a new feature called Kernel DMA Protection to protect PCs against drive-by Direct Memory Access (DMA) attacks using PCI hot plug devices connected to externally accessible PCIe ports (e.g., Thunderbolt™ 3 ports and CFexpress). In Windows 10 version 1903, Microsoft expanded the Kernel DMA Protection support to cover internal PCIe ports (e.g., M.2 slots)

Drive-by DMA attacks can lead to disclosure of sensitive information residing on a PC, or even injection of malware that allows attackers to bypass the lock screen or control PCs remotely.

This feature does not protect against DMA attacks via 1394/FireWire, PCMCIA, CardBus, ExpressCard, and so on.

Kernel DMA Protection requires UEFI firmware support, however, it does not require Virtualization Based Security (VBS). Systems running Windows 10 version 1803 or above that do support Kernel DMA protection do have this security feature enabled automatically without the need for any configuration.

To verify DMA Guard is running on your system, look at the Windows System information. Locate the setting for Kernel DMA Protection as shown above.

In host cases, with a modern Windows 10 device DMA guard should be automatically enabled. You can use policies to further control over the enumeration of external DMA capable devices incompatible with DMA Remapping/device memory isolation and sandboxing. However, this won;t be covered here.

Next up:

Control Flow Guard

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

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

All the Guards – Part 2 (Virtualization Based Security)

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

Device Guard

Device Guard is a group of key features, designed to harden a computer system against malware. Its focus is preventing malicious code from running by ensuring only known good code can run.

It’s worth noting here that these are enterprise features, and as such are included only in the Windows Enterprise client.

Device Guard consists of three primary components:
     – Configurable Code Integrity (CCI) – Ensures that only trusted code runs from the boot loader onwards. Requires code integrity policies
     – VSM Protected Code Integrity – Moves Kernel Mode Code Integrity (KMCI) and Hypervisor Code Integrity (HVCI) components into VSM, hardening them from attack.
     – Platform and UEFI Secure Boot – Ensuring the boot binaries and UEFI firmware are signed and have not been tampered with

When these features are enabled together, the system is protected by Device Guard, providing class leading malware resistance in Windows 10.

But:

Why we no longer use the Device Guard brand

When we originally promoted Device Guard, we did so with a specific security promise in mind. Although there were no direct dependencies between WDAC and HVCI, we intentionally focused our discussion around the lockdown state achieved when using them together. However, since HVCI relies on Windows virtualization-based security, it has hardware, firmware, and kernel driver compatibility requirements that some older systems can’t meet. This misled many people to assume that if systems couldn’t use HVCI, they couldn’t use WDAC either.

WDAC has no specific hardware or software requirements other than running Windows 10, which means customers were denied the benefits of this powerful application control capability due to Device Guard confusion.

But there is this article:

Windows 10 Device Guard and Credential Guard Demystified

that still talks about Device Guard??

also this:

Overview of Device Guard in Windows Server 2016

From what I can determine the major component to focus here is not Device Guard but:

Code integrity

So from:

Device Guard signing

Device Guard signing is a Device Guard feature that gives admins a single place to sign catalog files and code integrity policies. After admins have created catalog files for unsigned apps and signed the catalog files, they can add the signers to a code integrity policy.

Device Guard is a feature set that consists of both hardware and software system integrity hardening features. These features use new virtualization-based security options and the trust-nothing mobile device operating system model. A key feature in this model is called configurable code integrity, which allows your organization to choose exactly which software or trusted software publishers are allowed to run code on your client machines. Also, Device Guard offers organizations a way to sign existing line-of-business (LOB) applications so that they can trust their own code, without the requirement that the application be repackaged. Also, this same method of signing allows organizations to trust individual third-party applications.

From what I can understand of all this is that part of Device Guard kind of still exists but to implement you would need to implement:

Sign code integrity policy with Device Guard signing

The other part that was Device Guard is now Windows Defender Application Control (WDAC):

Deploying Windows Defender Application Control (WDAC) policies

The confusion about Device Guard is compounded by the way it is referred to in Endpoint Manager, for example here in the Windows 10 security baseline policy:

Here, it seems that Device Guard refers to things like Virtualization Based Security and items yet to be covered in this series, System Guard and Credential Guard.

Device Guard is good example of where all of this gets very confusing. It kind of exists but it doesn’t exist. It also seems to be referenced differently in different places. From what I can determine, unless you want to go down the path of signing your applications so they can all be verified at boot then don’t worry about Device Guard. Where you will need to consider some of the Device Guard feature is if you choose to implement Windows Defender Application Control which I have covered off previously here:

Windows Defender Application Control (WDAC) basics

and here

Basics of deploying Windows Defender Application Control (WDAC) using Intune

WDAC is more focused on software rather than hardware, while Device Guard, in its original form, was more about hardware. Again, very confusing. Unfortunately, the confusion with all these Guards doesn’t end here, so let’s move onto the next component:

Next – System Guard