--- title: Microsoft recommended block rules (Windows 10) description: View a list of recommended block rules, based on knowledge shared between Microsoft and the wider security community. keywords: security, malware ms.assetid: 8d6e0474-c475-411b-b095-1c61adb2bdbb ms.prod: w10 ms.mktglfcycl: deploy ms.sitesec: library ms.pagetype: security ms.localizationpriority: medium audience: ITPro ms.collection: M365-security-compliance author: jsuther1974 ms.reviewer: isbrahm ms.author: dansimp manager: dansimp ms.date: 04/09/2019 --- # Microsoft recommended block rules **Applies to:** - Windows 10 - Windows Server 2016 and above 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 allow 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 allow 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. Ensure that you also uncomment them in the signing scenarios section. ```xml 10.0.0.0 {A244370E-44C9-4C06-B551-F6016E563076} {2E07F7E4-194C-4D20-B7C9-6F44A6C5A234} 0 ```
> [!Note] > To create a policy that works on both Windows 10, version 1803 and version 1809, you can create two different policies, or merge them into one broader policy. ## More information - [Merge Windows Defender Application Control policies](merge-windows-defender-application-control-policies.md)