Applications that can bypass App Control and how to block them By jsuther1974 Archived: 2026-04-05 22:36:27 UTC 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 App Control. Unless your use scenarios explicitly require them, Microsoft recommends that you block the following applications. An attacker can use these applications or files to circumvent application allow policies, including App Control: addinprocess.exe addinprocess32.exe addinutil.exe aspnet_compiler.exe bash.exe bginfo.exe1 cdb.exe cscript.exe csi.exe dbghost.exe dbgsvc.exe dbgsrv.exe dnx.exe dotnet.exe fsi.exe fsiAnyCpu.exe infdefaultinstall.exe kd.exe kill.exe lxssmanager.dll lxrun.exe Microsoft.Build.dll Microsoft.Workflow.Compiler.exe msbuild.exe2 msbuild.dll mshta.exe ntkd.exe ntsd.exe https://docs.microsoft.com/windows/security/threat-protection/windows-defender-application-control/microsoft-recommended-block-rules Page 1 of 34 powershellcustomhost.exe rcsi.exe runscripthelper.exe texttransform.exe visualuiaverifynative.exe system.management.automation.dll webclnt.dll/davsvc.dll3 wfc.exe windbg.exe wmic.exe wscript.exe wsl.exe wslconfig.exe wslhost.exe 1 A vulnerability in bginfo.exe was fixed in version 4.22. If you use BGInfo, for security, make sure to download and run the latest version of BGInfo. BGInfo versions earlier than 4.22 are still vulnerable and should be blocked. 2 If you're 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. Otherwise, we recommend that you block msbuild.exe. 3 If you block WebDAV DLLs, we recommend that you also disable the WebClient service using a group policy or MDM policies. * Microsoft recognizes the efforts of people in the security community who help us protect customers through responsible vulnerability disclosure, and extends thanks to the following people: Name Twitter Alex Ionescu @aionescu Brock Mammen Casey Smith @subTee James Forshaw @tiraniddo Jimmy Bayne @bohops Kim Oppalfens @thewmiguy Lasse Trolle Borup Langkjaer Cyber Defence Lee Christensen @tifkin_ https://docs.microsoft.com/windows/security/threat-protection/windows-defender-application-control/microsoft-recommended-block-rules Page 2 of 34 Name Twitter Matt Graeber @mattifestation Matt Nelson @enigma0x3 Oddvar Moe @Oddvarmoe Philip Tsukerman @PhilipTsukerman Vladas Bulavas Kaspersky Lab Will Dormann @wdormann William Easton @Strawgate 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 other code to run by design. Unless these applications are business critical, you should block them in your App Control policy. In addition, when an application version is upgraded to fix a security vulnerability or potential App Control bypass, add deny rules to your App Control policies for that application's previous, less secure versions. Microsoft recommends that you install the latest security updates. For example, updates help resolve several issues in PowerShell modules that allowed an attacker to bypass App Control. These modules can be blocked by their corresponding hashes. As of October 2017, system.management.automation.dll is updated to revoke earlier versions by hash values, instead of version rules. If you wish to use this blocklist policy on Windows Server 2016, locate the deny rules for the following files, and change the comment block to only include the rules for that OS version. Applying the RS5+ rules to Windows Server 2016 may cause apps to malfunction: msxml3.dll msxml6.dll jscript9.dll The blocklist policy that follows includes "Allow all" rules for both kernel and user mode that make it safe to deploy as a standalone App Control policy. On Windows versions 1903 and above, Microsoft recommends converting this policy to multiple policy formats using the Set-CiPolicyIdInfo cmdlet with the -ResetPolicyId switch. Then, you can deploy it as a Base policy side-by-side with any other policies in your environment. To instead add these rules to an existing Base policy, you can merge the policy that follows using the Merge-CIPolicy cmdlet. If merging into an existing policy that includes an explicit allowlist, you should first remove the two "Allow all" rules and their corresponding FileRuleRefs from the blocklist policy. https://docs.microsoft.com/windows/security/threat-protection/windows-defender-application-control/microsoft-recommended-block-rules Page 3 of 34 App Control policy XML: 10.1.0.2{A244370E-44C9-4C06-B551-F6016E563076}{2E07F7E4-194C-4D20-B7C9-6F44A6C5A234}Enabled:Unsigned System Integrity Policy Enabled:Audit Mode Enabled:Advanced Boot Options Menu Enabled:UMCI Enabled:Dynamic Code Security Microsoft Windows Recommended User Mode BlockList 10.1.0.2 Merge App Control policies Source: https://docs.microsoft.com/windows/security/threat-protection/windows-defender-application-control/microsoft-recommended-block-r ules https://docs.microsoft.com/windows/security/threat-protection/windows-defender-application-control/microsoft-recommended-block-rules Page 34 of 34 https://docs.microsoft.com/windows/security/threat-protection/windows-defender-application-control/microsoft-recommended-block-rules Page 8 of 34 https://docs.microsoft.com/windows/security/threat-protection/windows-defender-application-control/microsoft-recommended-block-rules Page 10 of 34