Detecting WDAC Bypass LOLBINs — A Baseline Image-Load Strategy#

This is the first in a series on detecting the WDAC / Application Control bypass techniques catalogued in the WDAC bypass reference. The offensive side is well-documented; the defensive side is usually underwritten. The goal of this series is to turn each family of bypasses into concrete telemetry, a Sigma rule, and a false-positive plan.

We start with the most general and most valuable control: a baseline image-load and process-creation strategy for the binaries that show up again and again across application-control bypass research. Get this right and you catch a large fraction of the catalogue with one rule shape, before you ever specialise.

1. The Detection Premise#

Almost every WDAC bypass in the catalogue works the same way at the process level: a Microsoft-signed binary whose legitimate job is to compile, debug, interpret, install, or transform content is invoked in a context it would not normally appear in, usually with an argument pointing at attacker-controlled content (a script, a project file, a stylesheet, a .wds file). The binary itself is trusted, so the policy allows it. The telemetry, however, is rich.

The detection premise is therefore not “did something bypass WDAC” (the kernel will not tell you that, because from its point of view nothing did). It is:

Did a known application-control-abuse primitive execute in a context that is abnormal for my environment?

That is a baseline-and-deviation problem, and it is solvable with standard EDR/Sysmon telemetry plus a small, well-tuned allow-list.

2. Telemetry You Need#

You need three event streams, all of them standard:

Process creation — Windows Security Event ID 4688 (with command-line auditing enabled) or Sysmon Event ID 1. This is where the binary, its path, its parent process, and its command line live.
Image load — Sysmon Event ID 7. Loading of DLLs by a process. Essential for the libraries side of the catalogue (Microsoft.Build.dll, system.management.automation.dll, webclnt.dll, and friends).
File creation — Sysmon Event ID 11, for the moment a script/policy/payload lands on disk before being fed to the trusted binary.

If you run a modern EDR, the equivalent of all three is almost always available through its own event schema; Sigma lets you target whichever abstraction layer you operate on.

3. The Baseline Strategy#

Three layers, in increasing specificity.

Layer 1 — Presence. Maintain a list of the binaries from the catalogue that have no legitimate reason to run on the host in question. On a typical workstation, cdb.exe, windbg.exe, WinDbgX.exe, dbgsrv.exe, msbuild.exe (outside of a developer’s machine), csi.exe, rcsi.exe, fsi.exe, runscripthelper.exe, visualuiaverifynative.exe, Microsoft.Workflow.Compiler.exe, and the WSL family are strong candidates. Their mere execution on a non-developer host is worth an alert.

Layer 2 — Lineage. The same binaries have a small set of legitimate parents. msbuild.exe is spawned by Visual Studio, dotnet, or CI agents — not by winword.exe, outlook.exe, a browser, or cmd.exe invoked from a temp directory. Debugger binaries are spawned by developers or build tooling — not by Office documents. A trusted binary whose parent is an office productivity app, a browser, a scripting engine, or a process running from a user-writable path is the single highest-signal relationship in this entire catalogue.

Layer 3 — Content. The command-line shape is distinctive. wmic.exe ... /format:<xsl>, mshta.exe <url-or-path>, msbuild.exe <project-from-downloads>, cdb.exe -cf <script>, WinDbgX.exe /c "$$>a<...wds", and InstallUtil.exe /logfile= /LogToConsole=false /U <assembly> all have fingerprints. Layer 3 catches the specific invocation; Layers 1 and 2 catch the general abnormality.

4. A Sigma Rule for the Baseline#

A baseline rule that fires on Layer 1 (presence on a non-developer host) combined with Layer 2 (suspicious parentage). Tune the image and parent lists to your estate.

1
title: WDAC Bypass LOLBIN Executed from Suspicious Parent
2
id: 8c4f1a2e-9b3d-4e7a-8f6c-1a2b3c4d5e6f
3
status: experimental
4
description: >
5
  Detects execution of binaries commonly abused to bypass Windows Defender
6
  Application Control (WDAC) / Application Control for Business, when spawned
7
  by a parent process that is abnormal for the host (office apps, browsers,
8
  script engines, or processes running from user-writable paths).
9
references:
10
  - https://github.com/bohops/UltimateWDACBypassList
11
  - /posts/wdac-bypass-techniques-reference-catalog/
12
author: Anubhav Gain
13
date: 2026/07/13
14
tags:
15
  - attack.defense_evasion
16
  - attack.t1218
17
  - attack.t1127
18
  - attack.t1059
19
logsource:
20
  product: windows
21
  category: process_creation
22
detection:
23
  selection_image:
24
    Image|endswith:
25
      - '\cdb.exe'
26
      - '\windbg.exe'
27
      - '\WinDbgX.exe'
28
      - '\dbgsrv.exe'
29
      - '\kd.exe'
30
      - '\ntsd.exe'
31
      - '\msbuild.exe'
32
      - '\dotnet.exe'
33
      - '\csi.exe'
34
      - '\rcsi.exe'
35
      - '\fsi.exe'
36
      - '\fsiAnyCpu.exe'
37
      - '\wfc.exe'
38
      - '\dnx.exe'
39
      - '\mshta.exe'
40
      - '\Microsoft.Workflow.Compiler.exe'
41
      - '\runscripthelper.exe'
42
      - '\VisualUiaVerifyNative.exe'
43
      - '\InstallUtil.exe'
44
      - '\AddInUtil.exe'
45
      - '\AddInProcess.exe'
46
      - '\AddInProcess32.exe'
47
      - '\aspnet_compiler.exe'
48
      - '\bginfo.exe'
49
      - '\InfDefaultInstall.exe'
50
      - '\powershellcustomhost.exe'
51
  suspicious_parent:
52
    ParentImage|endswith:
53
      - '\winword.exe'
54
      - '\excel.exe'
55
      - '\powerpnt.exe'
56
      - '\outlook.exe'
57
      - '\msaccess.exe'
58
      - '\excel.exe'
59
      - '\chrome.exe'
60
      - '\msedge.exe'
61
      - '\firefox.exe'
62
      - '\iexplore.exe'
63
      - '\wscript.exe'
64
      - '\cscript.exe'
65
      - '\pwsh.exe'
66
      - '\powershell.exe'
67
      - '\cmd.exe'
68
      - '\bash.exe'
69
      - '\wsl.exe'
70
  suspicious_path:
71
    Image|contains:
72
      - '\Users\Public\'
73
      - '\AppData\Local\Temp\'
74
      - '\AppData\Roaming\'
75
      - '\Downloads\'
76
      - '\Windows\Temp\'
77
  condition: selection_image and (suspicious_parent or suspicious_path)
78
fields:
79
  - Image
80
  - ParentImage
81
  - CommandLine
82
  - User
83
falsepositives:
84
  - Developer workstations running legitimate build/debug tooling
85
  - CI/build agents invoking msbuild or dotnet
86
  - Sysinternals bginfo in a managed login script (constrain by path/user)
87
level: high

This is intentionally a starting point. On a developer fleet it will need a parent/path allow-list; on a locked-down workstation fleet it will be quiet and high-signal.

5. Tuning and False Positives#

Tier the fleet. Tag developer machines and CI agents separately. The rule’s condition can exclude them, or they route to a lower-severity queue. Do not run the un-tuned rule globally and drown the SOC.
Allow-list legitimate parents by path. msbuild.exe from C:\Program Files\Microsoft Visual Studio\... or C:\Program Files\dotnet\... is normal; the same binary from a user profile is not.
Expected invocations. bginfo.exe in a corporate login script is legitimate — constrain that case to a specific path and a specific service account.
Command-line enrichment. For the highest fidelity, add a Layer 3 condition on the command line (e.g. /format: for wmic.exe, /c "$$>a<" for WinDbgX.exe). Layer 3 rules are covered in the technique-specific posts that follow.

6. Where This Catches, and Where It Doesn’t#

The baseline catches the invocation of the bypass primitive. It does not catch:

In-memory execution within an already-running trusted process — e.g. shellcode staged via .dvalloc/eb inside an already-launched debugger. That requires the behavioural detection in part 2 (thread-context manipulation density).
A genuinely novel signed primitive not on your image list. The catalogue is reactive; keep the list current against the UltimateWDACBypassList.
Fileless COM/XSL transforms that never spawn a new process image. Covered in part 5.

The baseline is the floor, not the ceiling. The rest of the series layers the behavioural and content-specific detections on top.

7. What’s Next in the Series#

Part 2 — Detecting the debugger-as-injector (cdb/windbg/dbgsrv/WinDbgX): thread-context manipulation density, script-file arguments.
Part 3 — Detecting compiler/REPL-host abuse (msbuild/dotnet/csi/rcsi/fsi).
Part 4 — Detecting WDAC-as-weapon (EDR blinding): malicious .cip writes and the “dark endpoint.”
Part 5 — Detecting COM/XSL/script-host abuse.

Newsletter