How many Windows Defender application Control policies Can a computer system have defined for it?

This post is part of a series focused on Windows Defender Application Control (WDAC). The previous article can be found here:

EKUs

Unfortunately, from this point forward, I can find no ‘official’ definition of the syntax of the WDAC XML file anywhere. Thus, I have done my best to try and decipher the file. However, please keep in mind, this is simply the determination that I can make looking at the file.

What I’ll focus on in this post is the FileRules block. This block is defined in the XML with the following boundaries:

<FileRules>

</FileRules>

The documentation I found about FileRules specifically is here:

Windows Defender Application Control file rule levels

which says:

File rule levels allow administrators to specify the level at which they want to trust their applications. This level of trust could be as granular as the hash of each binary or as general as a CA certificate. You specify file rule levels when using WDAC PowerShell cmdlets to create and modify policies.

Between these headers can be the following definitions:

1. Generic Files

This would typically appear as:

<FileAttrib ID=”ID_FILEATTRIB_F_1_0_1″ FriendlyName=”Microsoft Teams” ProductName=”MICROSOFT TEAMS” />

2. Allow Files

This would typically appears as:

3. Deny files

<Deny ID=”ID_DENY_BASH” FriendlyName=”bash.exe” FileName=”bash.exe” MinimumFileVersion=”65535.65535.65535.65535″/>

Each of these definitions starts off with a ‘ID’ field either: FileAttrib ID, Allow ID or Deny ID. Next, comes a variable that will be used later to refer to the specifics of that file definition. Here those are: ID_FILEATTRIB_F_1_0_1, ID_ALLOW_A_1B_ONEDRIVE_1_1 and ID_DENY_BASH. From what I can determine, these IDs can be any text.

Next, is the FriendlyName field, which again can be any text but typically will be the file name, with or without the path. From what I can determine, this is simply a ‘tagging’ field. If the FileName or is not specified this Friendlyname field will be used as the actual file name.

The next field options are used to actually define the individual file on the system. This can be achieved in a number of different ways specified, including by path and file name, hash, file path, publisher and more as detailed here:

Windows Defender Application Control policy – file rule levels

The most common types of definitions I have found are:

– FileName field, which actually refers to the executable file i.e. bash.exe as shown above.

– FilePath field. which refers to the location of the executables i.e. C:\Program Files\*

– ProductName can be used to identify the file in question. I assume this refers to a product that is registered with the operating system.

– Hash which specifies a unique file hash

It appears that you can also use the field MinimumFileversion when specifying the Fieldname and Productname definitions

These file rule definitions will be utilised by later items in the XML configuration, so they must be present if they are going to referred to.

You can use the

New-CIPolicy

and

New-CIPolicyRule

for drivers

PowerShell command to generate these file rules.

The precedence order of these file rules is defined here:

File rule precedence order

but is basically, deny, then allow, then the rest.

That’s the best I can work out from the documentation and experimenting. I’m sure there is more information somewhere, and if you do find any, please let me know.

Part 5 – Specifying Signers

Join me for the free monthly CIAOPS Need to Know webinar. Along with all the Microsoft Cloud news we’ll be taking a look at using eDiscovery and Content search in your environment.

Shortly after registering you should receive an automated email from Microsoft Teams confirming your registration, including all the event details as well as a calendar invite! Yeah Teams webinars.

You can register for the regular monthly webinar here:

October Webinar Registrations

The details are:

CIAOPS Need to Know Webinar – October 2021
Friday 29th of October 2021
11.00am – 12.00am Sydney Time

All sessions are recorded and posted to the CIAOPS Academy.

The CIAOPS Need to Know Webinars are free to attend but if you want to receive the recording of the session you need to sign up as a CIAOPS patron which you can do here:

http://www.ciaopspatron.com

or purchase them individually at:

http://www.ciaopsacademy.com/

Also feel free at any stage to email me directly via with your webinar topic suggestions.

I’d also appreciate you sharing information about this webinar with anyone you feel may benefit from the session and I look forward to seeing you there.

This post is part of a series focused on Windows Defender Application Control (WDAC). The previous article can be found here:

Understanding Policy Rules

In this article I’ll continue looking at the XML used to create WDAC policies. Specifically, I’ll focus on the EKU block.

If you open up the XML policy file that we have been working through so far, you’ll effectively find just a placeholder for EKUs as shown above.

If you look at another, more complete, WDAC policy, you’ll see that the EKU block is populated as shown above. The block reads like:

</EKUs>

I am no expert, but in essence this is telling the WDAC policy about trusted Microsoft certificates for the environment.

To simplify let’s look at:

<EKUID=”ID_EKU_WINDOWS “Value=”010A2B0601040182370A0306 “FriendlyName=”Windows System Component Verification – 1.3.6.1.4.1.311.10.3.6″/>

From what I understand, this refers to capability with PKI style certificate. Trusted certificates are used to sign each file on a Windows 10 device to ensure it is original and untampered with.

The Object Identifier (ODI) number, 1.3.6.1.4.1.311.10.3.6, helps identify who the certificate is from. If you look at this article:

Object Identifiers (OID) in PKI

you’ll learn that a certificate that starts with 1.3.6.1.4.311 is from Microsoft and that the specific certificate 1.3.6.1.4.311.10.3.6 OID is for the Windows System Component Verification.

If we now dig into a typical Windows system file that we want to ensure is secure:

c:\windows\system32\kernel32.dll

and examine that files’ properties, Digital Certificates, Details, View Certificate as shown above, we see that this certificate can be used for:

– Ensuring the software came from the software publisher

– Protects the software from alteration after publication

Which is exactly what functionality we are after.

If we now look at the certificate Details, then select the field Enhanced Key Usage (EKU) as shown above we see:

Windows System Component Verification (1.3.6.1.4.1.311.10.3.6) which matches what we found in the EKU block in the WDAC policy in the lower box.

I will say that I am no expert on how certificates and how they exactly interact with file verification but all we need to know, in essence, is that the EKUs in the WDAC XML file tell the policy which certificates to trust when evaluating whether to trust a file. If the file in question is signed with a certificate that is in the EKU list, then that file will be trusted. This makes it easy to trust a large number of files from Microsoft, which is good as we need to trust Windows system files to boot.

<EKUID=”ID_EKU_WINDOWS “Value=”010A2B0601040182370A0306 “FriendlyName=”Windows System Component Verification – 1.3.6.1.4.1.311.10.3.6″/>

Returning to the EKU line in question from the WDAC policy file, we note that:

Value=”010A2B0601040182370A0306”

This is, as I again understand it, the internal Microsoft identification for the certificate in question. EKU instances have a “Value” attribute consisting of an encoded OID. The process for this Object Identifier (OID) encoding is detailed here:

Object Identifier

which, I must say, is very complex. Luckily, I found this PowerShell function:

https://gist.github.com/mattifestation/5bdcdbadfc4070f9191705853c5481da

which you can use to convert. Now for reasons I can’t yet determine, you need to change the leading 01 to an 06. Thus, to view all the Object IDs using the PowerShell function above you can use the following code:

Which provides the following result:

Note: 1.3.6.1.4.1.311.76.11.1 = AntiMalware EKU

You can select which EKUs you wish to include in the WDAC XML file, but in this case I will include them all.

The best way to add these to the policy, from what I have found so far, is simply to edit the XML and add it. After you do this the modified policy XML file will appear like shown above.

Most of WDAC relies on certificates and verification of signing. I will readily admit that I don’t have a full appreciate for how the world of certificates work, but I hope you, like me, are satisfied enough with what I have detailed here.

So, in summary, the EKU block in the WDAC policy, specifies known certificates from Microsoft that are used to sign Windows system files that we want to trust on the device. Thus, by trusting those certificates we can trust files signed by those certificates. Using the EKU block in the policy allow us to do this for many Microsoft system files quickly and easily and is why, as a best practice, we should include it in the policy.

The next block in the XML policy to focus on will be covered in the next article in the series:

Part 4 – Specifying File Rule

Windows Defender Application Control (WDAC) is a technology that is built into Windows 10 that allows control of what applications execute on the device.

WDAC also allows you to control which drivers are allowed to run and is thus, a very powerful security measure that many should consider implementing. A typical WDAC blocking message is shown above.

Microsoft also has an older application white listing technology known as AppLocker. Here is the recommendation from Microsoft when choosing between the two technologies:

“Generally, it is recommended that customers, who are able to implement application control using WDAC rather than AppLocker, do so. WDAC is undergoing continual improvements, and will be getting added support from Microsoft management platforms. Although AppLocker will continue to receive security fixes, it will not undergo new feature improvements.”

You can deploy AppLocker and WDAC together if your wish, and thus the best practice recommendation from Microsoft is:

“As a best practice, you should enforce WDAC at the most restrictive level possible for your organization, and then you can use AppLocker to further fine-tune the restrictions.”

This is also a good side by side feature comparison here:

Windows Defender Application Control and AppLocker feature availability

So, WDAC it is!

WDAC policies apply to the managed computer as a whole and affects all users of the device. WDAC rules can be defined based on:

– Attributes of the codesigning certificate(s) used to sign an app and its binaries

– Attributes of the app’s binaries that come from the signed metadata for the files, such as Original Filename and version, or the hash of the file

– The reputation of the app as determined by Microsoft’s

– Intelligent Security Graph

–
The identity of the process that initiated the installation of the app and its binaries (managed installer)

– The path from which the app or file is launched (beginning with Windows 10 version 1903)

– The process that launched the app or binary

WDAC policies are composed using XML. You can view a number of example policies on any Windows 10 device by navigating to:

C:\Windows\schemas\CodeIntegrity\ExamplePolicies\

and looking at the file I’ll be starting is process with:

denyallaudit.xml

and building from there.

Before we get too much further along I need to give you this warning. Application whitelisting is a lot of work to implement and maintain. The more variations (i.e. third party software) you have floating around the environment, the more challenging it is to implement. Also, remember that application whitelisting of ANY form is placing restrictions on user productivity. The things you do with tools like WDAC have the potential to severely restrict users ability to do their job. This can result in the ‘local villages’ pitching up to your door with burning effigies, sharp weapons, menacing looks and foul language if you are not careful. I’ll give you my best practices for reducing the pain and suffering but be prepared for this to be a journey rather than a set and forget update.

Before anything else, I would suggest that you should be conducting a software audit in your environment. You should know what applications are being run by users, however, I’ll guarantee that you won’t know them all. This should not preclude you from at least making an attempt to catalogue what you have. Doing so will save you a lot of pain in the long run.

Next, you’ll create start creating a default WDAC policy in audit mode to see what is actually happening and what issues may be faced. This policy will then be adjusted along the way to accommodate any required inclusions (typically third party software). Once that stage has been completed, the policy will then be flipped from audit to enforcement mode to actually start preventing unknown applications from running.

That’s the plan for these upcoming series of WDAC articles and I hope you’ll follow along and with the knowledge I share look to implement WDAC in your own environment.

Part 2 – Understanding a basic WDAC policy

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.

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 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