Ultimate WDAC Bypass List: a catalogue of documented application control gaps

What the repository is, in one sentence

The Ultimate WDAC Bypass List is described as a centralized resource for previously documented WDAC, Device Guard and UMCI bypass techniques, as well as for building, managing and testing WDAC policies. The word previously is the operative one, and it separates this project from a toolkit. Nothing here is a tool that performs a bypass. It is an index of research that other people have already published, with each entry recording the binary name, the researcher who documented it and a link to the write-up. The repository contains a single top level file, README.md, and nothing else: no code, no scripts, no configuration, no releases. The primary language is not recorded, the licence is not recorded either, and the last push was on 2026-09-26, so this is a document that is maintained rather than a program that is built.

The naming shift from WDAC to Application Control

The first note in the README is a terminology update that matters if you are reading older documents. WDAC, Windows Defender Application Control, has been rebranded by Microsoft as Application Control or Application Control for Business. That rename is not cosmetic in a list like this one, because the documentation that these entries link to is written against both names depending on its age, and because the Microsoft guidance the list points at is now filed under the newer name. A reader building a policy in 2026 will be working with the current naming while the underlying research spans more than a decade, and the list exists to bridge those two worlds rather than to explain the control itself.

The Microsoft block rules list, and the two rules to remove

The README points out that many of the LOLBINs in the catalogue are already included on the Microsoft Applications that can bypass WDAC list, formerly called the Microsoft Recommended Block Rules List. That is the single most useful sentence in the document for a defender, because it tells you that the list is not a shopping list of exploits but a superset of what the vendor already blocks. The reason to keep your own catalogue anyway is that the vendor list and the set of binaries your policy actually permits are different things, and the gap between them is where a misconfiguration lives. The README also carries a pro tip that is easy to miss: if you are applying the Block Rules policy, do not forget to remove the first two file rules, ID_ALLOW_A_1 and ID_ALLOW_A_2. Those two rules are permissive by design, and leaving them in place while believing you have blocked the catalogue would be a straightforward misconfiguration.

Where the idea came from, and the lineage it extends

The repository states that it was inspired by Oddvar Moe's Ultimate AppLocker Bypass List, which was itself the well known predecessor in this space. That lineage explains the shape of the document. A bypass list in this tradition is a running file of trusted binaries that have turned out to be usable for purposes their publisher did not intend, and the value of the format is in the attribution: each entry records who found the technique, when it was written up, and where the write-up lives, so that a defender can trace a claim back to primary research rather than to a summary. Many of the entries in this list are from the 2016 to 2020 period, from researchers who were working on Device Guard and application whitelisting bypasses as research topics, and several of the entries credit more than one person, with a write-up by one researcher and documentation by another.

What the entries look like, and who they credit

The format is a heading per binary followed by attribution and a link. The entries visible in the README include addinprocess.exe and addinprocess32.exe by James Forshaw, addinutil.exe documented by McKinleyMike and TheLatteri, aspnet_compiler.exe by cpl, bginfo.exe by Oddvar Moe, cdb.exe by Matt Graeber, csi.exe and dbghost.exe by Casey Smith, dbgsrv.exe credited to Casey Smith and Ross Wolf, dnx.exe and rcsi.exe by Matt Nelson, dotnet.exe by Jimmy Bayne, fsi.exe and fsiAnyCpu.exe by Nick Tyrer with a write-up by Jimmy Bayne, infdefaultinstall.exe by Kyle Hanslovan and Chris Bisnett, InstallUtil.exe by James Forshaw, IntuneWindowsAgent.exe by Kim Oppalfens, kill.exe by hyp3rlinx, microsoft.Workflow.Compiler.exe and runscripthelper.exe by Matt Graeber, msbuild.exe by Casey Smith, mshta.exe documented by conscioushacker, powershellcustomhost.exe by Lasse Trolle Borup, and texttransform.exe with a TextTransformer tool use case documented by Casey Smith and a shellcode injection template by Chris Sphen. A few entries also point at a companion repository, such as the TextTransformer project on secdev02, and one entry, IntuneWindowsAgent.exe, points at an issue in this repository itself. The author is bohops, who appears in the list as both a documenter and a write-up author.

The limits: a document, and a document that admits it is incomplete

Two limits are worth stating plainly. The first is that this is a link list, so its usefulness depends entirely on the quality and continued availability of the research it points at, and several of the links are web archive snapshots of blog posts that have moved or disappeared, which is a fragility that comes with linking to personal write-ups. The second is coverage. The README says plainly, as always, that this is a work in progress, and the list of entries visible in it is a fraction of the binaries that have been written about. There is also a scope boundary that the document states indirectly: these are previously documented techniques, so a technique that has not been published will not appear here, and the list is therefore a lagging indicator of the gap between what a policy blocks and what an attacker can use. A defensive programme that treats the list as complete will be surprised.

How to use the list without turning it into a shopping list

The way this resource is meant to be used follows from what it contains. It is a checklist for the person writing the policy, and the workflow the README implies is to take each entry, find the write-up, and understand the mechanism, then decide which of the trusted binaries in the environment genuinely need to remain allowed. The Microsoft list is the starting point, since the vendor already blocks many of these, and the value you add is in the delta between that list and your own estate: the binaries your line of business or your software distribution depends on, and which are therefore allowed in your policy, and which of those have a documented bypass. The opposite use, treating the catalogue as a menu, is what the resource is not for, and the fact that the project is credited to defenders and researchers, and the fact that the README's own practical advice is about rule hygiene rather than execution, both point the same way. The repository is also where the upstream source of truth for Microsoft's own catalogue is linked, which makes it a reasonable place to start even if you never read a single write-up.

Editorial conclusion

Adopt this list as a policy testing reference if you run Windows application control and want a starting catalogue of the trusted binaries that have been documented as ways past it, because every entry names the original research and its author rather than just the binary. Do not treat it as a complete coverage list, since the README describes it as a work in progress and the repository contains only a README with no scripts, tooling or releases. Before you use it, check each entry against the current Microsoft recommended block rules list, since the README itself notes that many of the LOLBINs are already covered there, and read the note about removing the first two allow rules before applying a block rules policy.

Frequently asked questions

Official sources

1. bohops/UltimateWDACBypassList on GitHub
2. Issues
3. README