All the Guards–Part 10

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

All the Guards – Part 9 Control Flow Guard

In this article I’m going to summarise all the previously articles which included:

All the Guards – Part 9 Control Flow Guard

All the Guards – Part 8 DMA Guard

All the Guards – Part 7 Exploit Guard

All the Guards – Part 6 Application Guard

All the Guards – Part 5 Credential Guard

All the Guards – Part 4 System Guard

All the Guards – Part 3 Device Guard

All the Guards – Part 2 Virtualization Based Security

All the Guards – Part 1 Secure Boot

To successfully implement many of these you’ll need current hardware and an up to date version of Windows 10 Professional or Enterprise. The majority of protection is provided by virtualisation, which the device needs to support and have enough RAM (recommended minimum would be 8GB, but you can do it with less) to facilitate.

Configuration of these options can be handled individually but a better approach is to use a policy method such as via Microsoft Endpoint Manager across your fleet.

I have shared all the information I have found on these topics, hopefully in a manner that makes sense. Unfortunately, information about many of these technologies is not presented in a straight forward manner and in many cases, specifics are hard to find and confirm. Hopefully, however, there is enough information there to show you the benefits of implementing these technologies across your Windows 10 devices.

My advice, is that you look at implementing these technologies in the order that I have presented them to accommodate dependencies that exist. I have done exactly that in my production environment and now don’t even think about them.

So if you haven’t as yet implemented all the Guards that Microsoft has available, I’d encourage you to do so. The improvement in security it provides is worth the investment.

All the Guards–Part 9

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

All the Guards–Part 8

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

All the Guards–Part 7

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

All the Guards – Part 6 (Application Guard)

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

Exploit Guard

The four components of Windows Defender Exploit Guard are designed to lock down the device against a wide variety of attack vectors and block behaviours commonly used in malware attacks, while enabling enterprises to balance their security risk and productivity requirements.

These four components are:

The four components of Windows Defender Exploit Guard are:

  • Attack Surface Reduction (ASR): A set of controls that enterprises can enable to prevent malware from getting on the machine by blocking Office-, script-, and email-based threats
  • Network protection: Protects the endpoint against web-based threats by blocking any outbound process on the device to untrusted hosts/IP through Windows Defender SmartScreen
  • Controlled folder access: Protects sensitive data from ransomware by blocking untrusted processes from accessing your protected folders
  • Exploit protection: A set of exploit mitigations (replacing EMET) that can be easily configured to protect your system and applications

More details can be found here:

Windows Defender Exploit Guard: Reduce the attack surface against next-generation malware

Typically you use Microsoft Endpoint Manager to:

Create and deploy Exploit Guard policy

but there are other methods as I have detailed here for

Attack Surface Reduction (ASR)

Windows Defender Exploit Guard is one of the best ways that you can minimise the risk of malware infection on Windows 10 devices and as such, should be enabled across all such devices in your fleet.

The next article will look at:

DMA Guard

All the Guards–Part 6

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.

Hardware isolation diagram

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

Windows Features, turning on 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

All the Guards–Part 5

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 overview

Windows Defender Credential Guard Requirements

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


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

All the Guards–Part 4

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

Windows Defender System Guard

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.Virtual TPM and parts of Windows Defender Exploit Guard.

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.

Device Health Attestation

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:

Verifying Secure Launch is running in the Windows Security Center

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:

Secure System 
44,744 K 
Not allowed 
Not allowed 
Microsott VVlnaows bearcn Indexer 
NT Kernel & System

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 –

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.


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

Troubleshoot Windows 365 Business Cloud PC setup issues


This, unfortunately, was the error that keep greeting me whenever I tried to set up a Windows 365 Business Cloud PC:

Setup failed, please reset your cloud PC

I repeated the reset process over and over but still no luck. I then came across the following article from Microsoft:

Troubleshoot Windows 365 Business Cloud PC setup issues

which helped me greatly and I recommend you follow through that article and suggestions it makes. I therefore thought I’d share my process in troubleshooting this issue, because there are some things the article doesn’t specifically call out that I’ll mention to help you.

The first learning was that the Windows Business Cloud PC creating process creates a new account called


the user principal name for this appears like:



so, you need to ensure this exists in your active Directory.

The next learning from that article was:

Make sure there are no MFA conditional access policies for that first user. MFA must remain turned off during any setup attempts. After all Cloud PCs are successfully set up across your organization, you may turn on MFA for this user.

In essence, during the very first set up of your Windows Business Cloud PC environment you’ll need to do this using an account that doesn’t have MFA enabled. After that, accounts can have MFA enable, but it’s important that the very first account you use with Windows Business Cloud PC doesn’t have MFA enabled.

Remember, there are various ways to enforce MFA inside a tenant, directly, via Security Defaults and also using Conditional Access. Check that your initial user has all these options disabled. I’d suggest it is also a good idea to ensure the account CloudPCBPRT does not have any MFA enforcement either.

Now, the thing that I found the Microsoft article didn’t cover off was:

1. Checking that any Conditional Access policies are not blocking the join process. In my case, I have policies that prevent users adding devices via Conditional Access unless they are joining compliant devices. Ensure that these policies are not being applied to that initial user during set up. Again, double check that CloudPCBPRT is also excluded from such policies.

2. It turns out that even though I have an Australian Microsoft 365 subscription, the virtual machines where provisions for Windows Business Cloud PC from the Microsoft datacenters in Singapore. Thus, I needed to further adjust my Conditional Access policies to allow logins from this region as I generally restrict all logins to tenant to be from Australia only. As before, ensure CloudPCBPRT, can login to your tenant from the region where the VMs are provisioned.

Once I had made all those changes I could create the initial Windows Business Cloud PC and then go on and create another Windows Cloud PC for my ‘normal’ production account. And as you can see, I’m now one of the cool kids:


In summary then, your troubleshooting for Windows Business Cloud PC should start with the Microsoft article and if you are still having issues, check and adjust your Conditional Access policies to allow that first account to get set up. I’d also make sure that the account CloudPCBPRT is generally excluded from things like MFA and strict Conditional Access policies. Once I’d done all that I could do everything I needed.