Microsoft Defender for Endpoint Restrict app execution

In a recent blog I looked at how Microsoft Defender for Endpoint can allow an administrator to restrict a device from communicating with everything except the Defender for Endpoint admin console. You’ll find that post here:

Microsoft Defender for Endpoint device isolation

Isolating a device is a pretty drastic measure, however Defender for Endpoint does have another device restriction option that is probably less intrusive known as Restrict app execution.

What Restrict app execution does is that it present applications that are not signed by Microsoft from running.

To Restrict app execution on a device firstly navigate to:

https://security.microsoft.com

and select the Device inventory from the options on the left. This will display a list of all the devices that Defender for Endpoint knows about. Select the device you wish to isolate from the list. In the top right hand side should appear an option Restrict app execution as shown above.

Once you select this option you’ll need to provide a reason for this restriction and press the Confirm button. This action will be logged in the admin console for later reference.

You will see the action item display as shown above. You can also cancel if required here.

On the device, in a matter of moments, a message will now appear:

and if a non Microsoft application is run you’ll see:

putty.exe

Brave browser

This process is using Windows Defender Application Control (WDAC) that I have spoken about before:

Windows Defender Application Control (WDAC) basics

which you can apply yourself via a policy, but in this case, it is being applied on the fly, which is impressive!

To remove this device restriction, all you need to do is select

the Remove app restriction which can be again found in the top right of the device page.

You’ll again be prompted to enter a reason for removing the restriction and then you’ll need to select the Confirm button.

The Action center confirmation will then appear as shown above and in a very short period of time the restriction will be removed from the device.

These confirmation can be found in the Action center option on the left hand side menu under the Actions & submissions item as shown above.

This is handy option in Defender for Endpoint for isolating a possible security issue on a device while minimising the impact to the user. Of course, smart attackers will use Microsoft tools located on the device, such as PowerShell to compromise machines to avoid this restriction. However, typically, they will also need to run a non-Microsoft application somewhere along the line which this technique will block.

For more information about Microsoft Defender Restrict app execution see the Microsoft documentation here:

Take response on a device

and remember that Restrict app execution is another feature that can be used with Defender for Endpoint when responding to security threats on devices.

Implementing Windows Defender Application Control (WDAC)–Part 4

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

Implementing Windows Defender Application Control (WDAC)–Part 3

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:

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

Implementing Windows Defender Application Control (WDAC)–Part 2

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

Introduction

In this article I’m going to start looking at the XML you use to create policies.

WDAC policies are composed using XML format. 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

The first item I want to examine is the Rules block contained within the tags <Rule></Rule> and everything in between as shown above.

Information about the available rules is contained here:

Policy rule options

As a best practice, I would suggest the following rule options should be set:

0 Enabled:UMCI – Enabling this rule option validates user mode executables and scripts.

2 Required:WHQL – Enabling this rule requires that every executed driver is WHQL signed and removes legacy driver support. Kernel drivers built for Windows 10 should be WHQL certified.

3 Enabled:Audit Mode – Instructs WDAC to log information about applications, binaries, and scripts that would have been blocked if the policy was enforced. To enforce the policy rather than just have it log requires removing this option. That will come later in our process, so no now we’ll only be logging results of the policy/

4 Disabled:Flight Signing – WDAC policies will not trust flightroot-signed binaries. This option would be used by organizations that only want to run released binaries, not pre-release Windows builds. In short, we don’t to support Windows Insider builds with our policy.

6 Enabled:Unsigned System Integrity Policy – Allows the policy to remain unsigned. When this option is removed, the policy must be signed and the certificates that are trusted for future policy updates must be identified in the UpdatePolicySigners section.

8 Required:EV Signers – This rule requires that drivers must be WHQL (Windows Hardware Quality Labs) signed and have been submitted by a partner with an Extended Verification (EV) certificate. All Windows 10 and Windows 11 drivers will meet this requirement.

9 Enabled:Advanced Boot Options Menu – Setting this rule option allows the F8 menu to appear to physically present users. This is a handy recovery option but may be a security concern if physical access to the device is available for an attacker.

10 Enabled:Boot Audit on Failure – Used when the WDAC policy is in enforcement mode. When a driver fails during startup, the WDAC policy will be placed in audit mode so that Windows will load.

12 Required:Enforce Store Applications – WDAC policies will also apply to Universal Windows applications.

13 Enabled:Managed Installer – Automatically allow applications installed by a managed installer. For more information, see Authorize apps deployed with a WDAC managed installer

14 Enabled:Intelligent Security Graph Authorization – Automatically allow applications with “known good” reputation as defined by Microsoft’s Intelligent Security Graph (ISG).

15 Enabled:Invalidate EAs on Reboot – When the Intelligent Security Graph (above) is used, WDAC sets an extended file attribute that indicates that the file was authorized to run. This option will cause WDAC to periodically revalidate the reputation for files that were authorized by the ISG.

16 Enabled:Update Policy No Reboot – allow future WDAC policy updates to apply without requiring a system reboot.

Since we are going to be modifying the WDAC policy, best practice is to take a copy of the example start point XML file and modify that. Thus, take a copy of:

C:\Windows\schemas\CodeIntegrity\ExamplePolicies\denyallaudit.xml

and use this going forward.

There are two methods of adjusting this new policy. You can directly edit the XML file or you can make the modifications using PowerShell.

To add a policy rule option add the appropriate rule setting encapsulated by <Rule></Rule> and <Option></Option> tags within the <Rules></Rules> global tag like so:

</Rules>

<Rule>

<Option>Enabled:Audit Mode</Option>

<Rule>

</Rule>

and like what is shown above.

You can also make the same updates using PowerShell. The new, copied XML prior to modification appears like:

with five rules. To add the additional rules detailed above use the following:

Set-RuleOption -FilePath “.\newaudit.xml” -Option 0
Set-RuleOption -FilePath “.\newaudit.xml” -Option 2
Set-RuleOption -FilePath “.\newaudit.xml” -Option 3
Set-RuleOption -FilePath “.\newaudit.xml” -Option 4
Set-RuleOption -FilePath “.\newaudit.xml” -Option 6
Set-RuleOption -FilePath “.\newaudit.xml” -Option 8
Set-RuleOption -FilePath “.\newaudit.xml” -Option 10
Set-RuleOption -FilePath “.\newaudit.xml” -Option 12
Set-RuleOption -FilePath “.\newaudit.xml” -Option 13
Set-RuleOption -FilePath “.\newaudit.xml” -Option 14
Set-RuleOption -FilePath “.\newaudit.xml” -Option 15
Set-RuleOption -FilePath “.\newaudit.xml” -Option 16

where newaudit.xml is the policy file being built. The numbers for each option correspond to the:

Policy rule options

If you open the XML policy file you should now see all the rule options have been added as shown above (13 in all).

In summary then, we have taken an example policy provided by Microsoft and started to modify it to suit our needs. This modification can either be done by directly editing the XML file or using PowerShell commands. I’d suggest PowerShell is a better way because you can save all the commands together in a script and re-run it if you wish.

With this first modification of the policy complete we’ll next look at how to work with the EKU area in the XML file.

Part 3 – Understanding EKUs

Implementing Windows Defender Application Control (WDAC)–Part 1

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

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

Windows Defender Application Control (WDAC) is the more modern approach to application white listing on a windows 10 device when compared to AppLocker. It is however, just as easy to deploy using Intune as this video shows:

https://www.youtube.com/watch?v=M2cZrV-mRlo

You firstly need to create your WDAC policy as an XML file. Then you use the PowerShell command:

ConvertFrom-CIPolicy

to ‘compile’ it into a .bin file. You upload this .bin file into an Intune device configuration policy and apply that to all the desired machine.

Remember, unlike AppLocker, WDAC applies to the whole machine, not individual users of that machine.

Remember, WDAC is already part of Windows 10 so there is no additional cost and using Intune, it will work with both Windows 10 Enterprise and Professional to help you secure your environment.