---
title: Microsoft recommended block rules (Windows 10)
description: To help you plan and begin the initial test stages of a deployment of Microsoft Windows Defender Application Comntrol, this article outlines how to gather information, create a plan, and begin to create and test initial code integrity policies.
keywords: virtualization, security, malware
ms.prod: w10
ms.mktglfcycl: deploy
ms.localizationpriority: medium
author: jsuther1974
ms.date: 04/09/2019
---
# Microsoft recommended block rules
**Applies to**
- Windows 10
- Windows Server 2016
Members of the security community\* continuously collaborate with Microsoft to help protect customers. With the help of their valuable reports, Microsoft has identified a list of valid applications that an attacker could also potentially use to bypass Windows Defender Application Control.
Unless your use scenarios explicitly require them, Microsoft recommends that you block the following applications. These applications or files can be used by an attacker to circumvent application whitelisting policies, including Windows Defender Application Control:
- addinprocess.exe
- addinprocess32.exe
- addinutil.exe
- bash.exe
- bginfo.exe[1]
- cdb.exe
- csi.exe
- dbghost.exe
- dbgsvc.exe
- dnx.exe
- fsi.exe
- fsiAnyCpu.exe
- kd.exe
- ntkd.exe
- lxssmanager.dll
- msbuild.exe[2]
- mshta.exe
- ntsd.exe
- rcsi.exe
- system.management.automation.dll
- windbg.exe
- wmic.exe
[1]A vulnerability in bginfo.exe has been fixed in the latest version 4.22. If you use BGInfo, for security, make sure to download and run the latest version here [BGInfo 4.22](https://docs.microsoft.com/sysinternals/downloads/bginfo). Note that BGInfo versions earlier than 4.22 are still vulnerable and should be blocked.
[2]If you are using your reference system in a development context and use msbuild.exe to build managed applications, we recommend that you whitelist msbuild.exe in your code integrity policies. However, if your reference system is an end user device that is not being used in a development context, we recommend that you block msbuild.exe.
*Microsoft recognizes the efforts of those in the security community who help us protect customers through responsible vulnerability disclosure, and extends thanks to the following people:
|Name|Twitter|
|---|---|
|Casey Smith |@subTee|
|Matt Graeber | @mattifestation|
|Matt Nelson | @enigma0x3|
|Oddvar Moe |@Oddvarmoe|
|Alex Ionescu | @aionescu|
|Lee Christensen|@tifkin_|
|Vladas Bulavas | Kaspersky Lab |
|Lasse Trolle Borup | Langkjaer Cyber Defence |
|Jimmy Bayne | @bohops |
|Philip Tsukerman | @PhilipTsukerman |
>[!Note]
>This application list will be updated with the latest vendor information as application vulnerabilities are resolved and new issues are discovered.
Certain software applications may allow additional code to run by design.
These types of applications should be blocked by your Windows Defender Application Control policy.
In addition, when an application version is upgraded to fix a security vulnerability or potential Windows Defender Application Control bypass, you should add deny rules to your WDAC policies for that application’s previous, less secure versions.
Microsoft recommends that you install the latest security updates.
The June 2017 Windows updates resolve several issues in PowerShell modules that allowed an attacker to bypass Windows Defender Application Control.
These modules cannot be blocked by name or version, and therefore must be blocked by their corresponding hashes.
For October 2017, we are announcing an update to system.management.automation.dll in which we are revoking older versions by hash values, instead of version rules.
Microsoft recommends that you block the following Microsoft-signed applications and PowerShell files by merging the following policy into your existing policy to add these deny rules using the Merge-CIPolicy cmdlet. Beginning with the March 2019 quality update, each version of Windows requires blocking a specific version of the following files:
- msxml3.dll
- msxml6.dll
- jscript9.dll
Pick the correct version of each .dll for the Windows release you plan to support, and remove the other versions.
```xml
10.0.0.0{A244370E-44C9-4C06-B551-F6016E563076}{2E07F7E4-194C-4D20-B7C9-6F44A6C5A234}
-->
-->
-->
-->
-->
0
```