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

Restricting user file downloads in SharePoint Online

https://www.youtube.com/watch?v=9NIcw5jghyA

There are situations with SharePoint Online where businesses wish to restrict users from downloading files. Unfortunately, this can’t be done at a document library level but I can be done at a user level provided you have licenses for Conditional Access.

Conditional Access is a features of Azure AD P1 and is included in SKUs like Microsoft 365 Business Premium. The above video takes you through the steps of configuring an appropriate Conditional Access policy in your environments to prevent downloads. The policy can be targeted at specific users and expanded to include other Microsoft 365 cloud services if desired.

Allow contribute with no delete in SharePoint

By default, users in SharePoint can created, modify and delete file. This deletion capability also extends to files that they may not have created. This is the default nature of collaboration.

However, there are times when businesses may want an environment that allows collaboration but prevents user deletion of a file from say, a document library.

In this video:

https://www.youtube.com/watch?v=_qbWVGwdNV4

I’ll show you how to set that up. In essence, an administrator needs to create a new custom permission level in SharePoint that excludes the delete capability. They then need to assign that new permissions to the location and users where they wish to apply this. The great thing is that once it is set up, it can be used across the whole site collection.

Testing for CVE-2021-40444 vulnerability

There are current concerns around:

Microsoft MSHTML Remote Code Execution Vulnerability

which is yet to have a patch made available.

I found this excellent article:

CLICK ME IF YOU CAN, OFFICE SOCIAL ENGINEERING WITH EMBEDDED OBJECTS

which provide some PowerShell scripts to create Word documents that can be used to test for the vulnerability.

I have run these scripts to create the actual Word documents and uploaded them for you here:

Office365/example at master · directorcia/Office365 (github.com)

In both cases, when you open these documents, you should NOT be able to get CALC.EXE to execute on your system unlike what you see above and below.

I have also added these tests to my security testing script which you can download from my GitHub repo here:

Office365/sec-test.ps1 at master · directorcia/Office365 (github.com)

When I opened these documents in my production environment, the vulnerability was largely blocked thanks to Windows ASR which I have detailed previously:

Attack surface reduction for Windows 10

You can use the follow KQL query as I did above to view the result of this blocking if you are using something like Azure Sentinel like I am:

Another great security add on for Microsoft 365

KQL:

DeviceEvents
| where ActionType startswith ‘Asr’

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