Detecting Novel WDAC Bypass Exploitation (Browser & Electron)#

Table of Contents#

1. Why This Family Is Different
2. The Two Exploitation Paths
3. Detection Signal 1 — Exploit-Like Process Behaviour
4. Detection Signal 2 — Child-Process Lineage from Browsers
5. Detection Signal 3 — Electron/Node Payload Telemetry
6. A Sigma Rule for the Family
7. Harden-the-Carrier Mitigations
8. Series Conclusion
9. References

1. Why This Family Is Different#

The first nine posts covered trusted binaries whose legitimate function is to run code, and we detected the abuse of that function. This family covers trusted binaries whose legitimate function is not to run attacker code — a browser rendering untrusted web content, or an Electron application rendering a UI — being made to run attacker code through exploitation or payload embedding. WDAC permits the carrier; the carrier carries the attack.

That shifts the detection problem. You cannot alert on “browser executed” or “Electron app executed” — those are the fleet’s normal operations. You have to detect the exploitation signature and the payload-behaviour signature, not the binary.

2. The Two Exploitation Paths#

• Browser exploit → WDAC bypass. A memory-corruption or logic exploit in a trusted browser achieves native code execution. Because the browser is trusted by WDAC, the executed payload inherits the browser’s trust and the policy permitted it. Palmiotti’s “Operationalizing browser exploits to bypass WDAC” is the reference.
• Signed Electron/Node.js shell. An Electron application (e.g. a C2 agent such as Loki) is itself a signed, trusted binary whose renderer/main process can load and execute attacker JavaScript. WDAC sees the signed Electron shell; the payload is data. Bobby Cooke’s “Bypassing WDAC with Loki C2” documents the pattern. The broader class is Bring Your Own Vulnerable Application (BYOVA) — bring a signed-but-exploitable or signed-but-scriptable binary and operate from it.

3. Detection Signal 1 — Exploit-Like Process Behaviour#

A browser that has just been exploited to achieve native execution tends to behave like an exploited process, regardless of the specific bug:

• Child-process creation from a renderer/content process — modern browsers sandbox renderers; a renderer spawning a child (cmd.exe, powershell.exe, an unsigned executable) is a strong exploit signal. This is the highest-signal relationship in this family.
• Unexpected outbound network connections from the browser process to non-CDN, non-first-party infrastructure, especially immediately after rendering untrusted content.
• Anomalous memory allocations in the renderer (large RWX regions) — visible to EDR behavioural sensors even when the specific bug is unknown.

4. Detection Signal 2 — Child-Process Lineage from Browsers#

Concretely, alert on:

chrome.exe | msedge.exe | firefox.exe (and content-process children) → cmd.exe | powershell.exe | pwsh.exe | wscript.exe | cscript.exe | an unsigned executable

Legitimate browsers do spawn helpers (the browser’s own update/process-isolation children), so allow-list the browser’s own signed children by path. A browser process spawning a shell is the signature of a drive-by or exploit-then-run.

5. Detection Signal 3 — Electron/Node Payload Telemetry#

Electron applications bundle Chromium + Node.js. The Node.js runtime has full system access by default, which is what makes a signed Electron shell such an effective carrier. Detection:

• Outbound beaconing from an Electron application that is not its documented network behaviour — the C2-channel signature.
• A signed Electron app loading scripts/content from user-writable paths (%APPDATA%, %LOCALAPPDATA%), which is how an attacker stages the payload alongside the trusted shell.
• Child-process creation by the Electron main process (cmd, powershell, unsigned executables) — the same lineage rule as the browser case, retargeted at electron.exe / app-specific Electron hosts.
• Inventory of installed Electron applications. A new, unsigned, or unrecognised Electron app appearing on a host is worth a look; many BYOVA shells present as Electron.

6. A Sigma Rule for the Family#

A rule covering browser/Electron shell-child lineage and Electron apps loading content from user-writable paths.

1
title: WDAC Bypass — Novel Exploitation via Browser or Electron Shell
2
id: 0e9c4b7d-2f3a-4e8c-b6d5-1a8f7e2d3c4b
3
status: experimental
4
description: >
5
  Detects novel WDAC/Application Control bypass via browser exploitation or
6
  signed Electron/Node shells — a browser or Electron main process spawning
7
  a shell, or an Electron application loading content from user-writable
8
  paths consistent with a BYOVA/payload-host pattern.
9
references:
10
  - https://www.ibm.com/think/x-force/operationalizing-browser-exploits-to-bypass-wdac
11
  - https://www.ibm.com/think/x-force/bypassing-windows-defender-application-control-loki-c2
12
  - /posts/wdac-bypass-techniques-reference-catalog/
13
author: Anubhav Gain
14
date: 2026/07/13
15
tags:
16
  - attack.defense_evasion
17
  - attack.t1068
18
  - attack.t1059
19
  - attack.t1218
20
logsource:
21
  product: windows
22
  category: process_creation
23
detection:
24
  browser_shell_child:
25
    ParentImage|endswith:
26
      - '\chrome.exe'
27
      - '\msedge.exe'
28
      - '\firefox.exe'
29
      - '\brave.exe'
30
    Image|endswith:
31
      - '\cmd.exe'
32
      - '\powershell.exe'
33
      - '\pwsh.exe'
34
      - '\wscript.exe'
35
      - '\cscript.exe'
36
  electron_shell_child:
37
    ParentImage|endswith:
38
      - '\electron.exe'
39
    Image|endswith:
40
      - '\cmd.exe'
41
      - '\powershell.exe'
42
      - '\pwsh.exe'
43
  electron_user_content:
44
    Image|endswith: '\electron.exe'
45
    CommandLine|contains:
46
      - '\AppData\Local\'
47
      - '\AppData\Roaming\'
48
      - '\Users\Public\'
49
      - '\Temp\'
50
      - '\Downloads\'
51
condition: browser_shell_child or electron_shell_child or electron_user_content
52
fields:
53
  - Image
54
  - ParentImage
55
  - CommandLine
56
  - User
57
falsepositives:
58
  - Legitimate browser-launched helpers (constrain by signed child path)
59
  - Approved Electron applications with documented shell-out behaviour
60
level: high

7. Harden-the-Carrier Mitigations#

Detection is half the posture; the other half is making the carrier harder to exploit:

• Keep browsers patched and enforce sandboxing. WDAC cannot save you from a patched-by-attacker exploit chain against an unpatched browser.
• Restrict Electron app deployment. Allow-list installed Electron applications; treat unrecognised Electron apps as untrusted by default.
• Application control on Electron/Node itself. Where possible, deny unsigned Electron shells from running; trust only known, catalogued Electron applications.
• Network egress controls. A signed C2 shell still has to talk to its controller; DNS/egress monitoring catches the beacon even when the process looks legitimate.
• EDR exploit protection. Enable exploit-protection features (CFG, DEP, ASLR, child-process blocking for browsers) — child-process blocking for browser renderers, in particular, would break most of the Signal-2 lineage attacks at the carrier.

8. Series Conclusion#

Ten posts cover the WDAC bypass catalogue’s detection surface:

1. Baseline image-load / lineage
2. Debugger-as-injector
3. Compiler/REPL host abuse
4. WDAC-as-weapon — EDR blinding
5. COM/XSL/script-host abuse
6. UMCI / PowerShell CLM escapes
7. WSL-family abuse
8. Signed-utility / deserialisation abuse
9. Catalog-hygiene / signing-trust abuse
10. Novel exploitation — browser/Electron (this post)

The throughline: WDAC bypass detection is a posture, not a rule. Image-load baselines, behavioural signals, content fingerprints, child-process lineage, file-integrity monitoring, and out-of-band telemetry (network, identity, heartbeat absence) compose into a coverage that is resilient to the next signed primitive an attacker reaches for. Layer them, tier them to your fleet, and remember that a control whose trust model a sufficiently privileged attacker can invert is a control you monitor, not one you forget.

9. References#

• Operationalizing browser exploits to bypass WDAC — Valentina Palmiotti, IBM X-Force
• Bypassing WDAC with Loki C2 — Bobby Cooke (0xBoku), IBM X-Force
• WDAC Bypass Techniques — The Complete Reference Catalog
• Exploit Protection reference — Microsoft Learn
• MITRE ATT&CK T1068 — Exploitation for Privilege Escalation
• MITRE ATT&CK T1059 — Command and Scripting Interpreter
• MITRE ATT&CK T1183 — Image File Execution Options Injection (system-proxy family)