Signed, Trusted, Abused: Making Sense of WDAC's Recommended Block Rules

Microsoft's Recommended Block Rules and the LOLBin Problem in WDAC

Windows Defender Application Control (WDAC) is one of the stronger application control technologies available on Windows. When properly configured, it significantly narrows the attack surface available to an adversary who has landed on a system. But "properly configured" is doing a lot of work in that sentence — and understanding why requires looking at a trust assumption that sits at the very core of how WDAC works by default.

The root of the problem: implicit trust in Microsoft-signed code

Out of the box, a WDAC policy that targets Microsoft's own recommended baseline will trust all Windows OS binaries. If you extend that to a broader Microsoft-signed posture, you are trusting anything carrying a valid Microsoft Authenticode signature. On the surface this sounds reasonable — Microsoft ships the operating system, so trusting OS components feels like a prerequisite for the system to function.

The problem is the sheer number of binaries that fall under that umbrella. Windows ships with hundreds of signed executables and scripts designed for legitimate administration and development tasks. Because WDAC sees a valid Microsoft signature, it considers these files allowed. An attacker who already has code execution — but wants to stay within your allowed set — can simply pick one of these trusted binaries and use its native functionality to run arbitrary payloads, download content, or proxy execution of things that would otherwise be blocked.

These are Living Off the Land Binaries, or LOLBins. They are not malware. They are real, signed, Microsoft-shipped tools. WDAC trusting them is a direct side effect of the policy trusting their signature.

What the recommended block rules actually do

Microsoft publishes a recommended block list specifically to address this side effect. The block rules' goal is to deny binaries that are known to have functionality to allow bypassing an allow listing implementation which might be allowed in a common implement. Allowed, because they are trusted by the Default Templates that come with the OS, or because they are trusted by a policy that allows anything signed by Microsoft.

A few prominent examples from the list:

• mshta.exe — the Microsoft HTML Application host, historically one of the most abused binaries for executing arbitrary VBScript or JScript payloads outside of a browser context.

  
  

• wmic.exe — the WMI command-line interface, routinely used for lateral movement, reconnaissance, and remote execution. Microsoft has been deprecating it for years partly for this reason, but it still ships on many systems.

  
  

• windbg.exe — the Windows debugger. Legitimate in a development context, but its ability to attach to processes and inject code makes it a useful post-exploitation tool when it happens to be present on a system.

  
  

• runscripthelper.exe — a less well-known entry on the list, used to execute scripts in certain update and deployment contexts. Its trusted status and relatively low profile make it attractive for abuse.

  
  

• wsl.exe — the Windows Subsystem for Linux launcher. WSL can spin up a Linux environment that operates partially outside the Windows security model, making it a meaningful bypass vector when permitted to run freely.

  
  

• IntuneWindowsAgent.exe — The Intune Management Extensions binary that had a flaw in older versions allowing it to be used as a bypass when it was set as a Managed Installer.

The intent behind blocking these is to add a deny layer on top of the broad allow that Microsoft-signing creates, carving out the highest-risk tools by name.

How the deny rules actually match — and what it takes to bypass them

A common misconception is that these deny rules match on the filename on disk. They do not. The rules match on the OriginalFileName value embedded in the binary's PE version information resource. This means renaming mshta.exe to helper.exe does nothing — WDAC reads the OriginalFileName field from the file's version metadata and the deny rule still matches regardless of what the file is called on disk.

To actually escape the deny rule, an attacker needs to modify that PE metadata. However, this should not be overstated as a meaningful technical barrier. Free tools like Resource Hacker can change a binary's version information, including OriginalFileName, in a few clicks with no programming knowledge required.

The rule provides a small amount of friction against the least-prepared attackers, but it is not a serious obstacle for anyone who has spent a few minutes researching how WDAC block rules work.

The weakness is real — it is just more accurately described as "requires a trivial extra step" rather than "trivially bypassed by renaming."

Why this is acceptable — if you have an allow list

The critical point that gets lost in conversations about LOLBin bypasses is this:

circumventing a deny rule does not automatically make a binary executable.

The deny rule is not the last line of defense; the allow rules are!

A properly constructed WDAC policy pairs the block list with an explicit allow list. That allow list defines exactly what is permitted to run — specific publishers, specific file paths, specific hashes, or some combination. A binary with a patched OriginalFileName may escape the deny rule, but it still has to satisfy an allow rule to execute.

If your allow list does not include the path or hash of that modified binary — and it should not — the file does not run. The 'WDAC allow' evaluation happens independently of the deny evaluation. A binary needs to pass the allow check regardless of whether a deny rule was in play.

This is the intended architecture. The block list complements the allow list, and modifying the originalfilename in the binary will invalidate the codesigning signature that provided the initial trust from the default policies.

The allow list is the control that actually matters. The block list supplements it, but it is not a substitute for it.

What this means for your policy design

Do not rely on the block list alone. 

If your policy is based solely on blocks, an attacker familiar with the list can modify PE metadata with a free tool and walk past the deny rules. The block list without a tight allow list only stops uneducated attackers.

The recommended block list is still worth including. 

Combined with a proper allowlist it stops the use of binaries that have been demonstrated to be able to bypass a default allowlist. Microsoft maintaining the list and keeping it up to date means you do not have to be on top of every new research that can be used to bypass your allowlisting implementation. That reassurance is incredibly valuable.

The recommended block rules are a well-intentioned and useful addition to a WDAC deployment. The OriginalFileName matching approach is more considered than a simple filename check, but it remains a low bar to clear for a motivated attacker. That is acceptable precisely because the block list is designed to work alongside an allow list — not replace one.

Bypassing the deny layer does not grant execution; it just means the allow list becomes the only thing standing between the attacker and their goal. And if your allow list is built correctly, that is exactly where you want the decision to be made.