Detecting WSL-Family Abuse (bash / lxrun / wsl / wslconfig / wslhost)#

Table of Contents#

1. Why WSL Crosses the Boundary
2. The Abuse Shapes
3. Detection Signal 1 — WSL on a Non-WSL Fleet
4. Detection Signal 2 — Invocations from Suspicious Parents
5. Detection Signal 3 — Distribution Installation and Mounting
6. A Sigma Rule for the Family
7. Tuning Notes
8. References

1. Why WSL Crosses the Boundary#

A WDAC policy compiled against Windows code-integrity trust does not generally evaluate the Linux ELF binaries a user runs inside WSL. The Linux subsystem is itself a trusted Microsoft component (lxssmanager.dll, the pico processes); the payloads an attacker executes inside it are data from the Windows policy’s point of view. So an attacker with the ability to invoke wsl.exe can run arbitrary Linux tooling — downloaders, reverse shells, crypto miners — even on a host where Windows-side unsigned executables are blocked.

The defensive lesson from part 1’s premise holds: if a trusted component’s job is to run code, an attacker will use it to run code.

2. The Abuse Shapes#

• Direct execution — wsl.exe <command> or bash.exe -c <command> to run Linux tooling that fetches a payload or establishes a channel.
• Distribution bring-up — wsl.exe --install / lxrun.exe /install to stand up a fresh Linux environment on a host where it was not present, then operate from inside it.
• Filesystem crossing — WSL’s automatic mount of the Windows filesystem (/mnt/c/...) lets Linux tooling read, modify, and stage Windows-side files, including the code-integrity policy paths covered in part 4.
• Persistence — a Linux-side cron/systemd unit inside WSL can re-establish a channel after a Windows-side cleanup, surviving a Windows-only investigation.

3. Detection Signal 1 — WSL on a Non-WSL Fleet#

On most locked-down workstations and servers, WSL is either disabled or never used. The cleanest single detection: any WSL-family binary executing on a host that is not in the WSL-enabled fleet tier. This is a fleet-baselining rule — tag WSL-authorized hosts (developer machines, specific build servers) and alert on WSL execution everywhere else.

4. Detection Signal 2 — Invocations from Suspicious Parents#

Where WSL is legitimately installed, the lineage gives the signal. wsl.exe/bash.exe as a child of an office app, a browser, or a script engine is abnormal; the same binaries as a child of a CI agent or an interactive developer session are normal. This reuses the parentage pattern from part 1 and part 3.

Command-line content also helps: wsl.exe invoked with a long base64-looking argument, a curl/wget/python/nc payload, or piping to bash -c is the shape of a one-liner tradecraft.

5. Detection Signal 3 — Distribution Installation and Mounting#

Two high-signal administrative actions:

• wsl --install / lxrun /install — standing up a new distribution. On a stable fleet this is rare and worth a high-severity alert, especially outside a change window.
• Mount manipulation — wsl --mount of a disk, or operations against /mnt/c/Windows/System32/CodeIntegrity/. The latter directly threatens the WDAC policy surface from part 4.

6. A Sigma Rule for the Family#

1
title: WDAC Bypass — WSL Family Abuse
2
id: 6b3c1d8e-4f2a-4c7e-9b1a-5d6e7f8a9b0c
3
status: experimental
4
description: >
5
  Detects Windows Subsystem for Linux binaries (bash/lxrun/wsl/wslconfig/
6
  wslhost) used to cross a Windows application-control boundary — invoked
7
  from suspicious parents, carrying execution payloads, or installing /
8
  mounting distributions outside change management.
9
references:
10
  - https://github.com/ionescu007/lxss
11
  - https://github.com/bohops/UltimateWDACBypassList
12
  - /posts/wdac-bypass-techniques-reference-catalog/
13
author: Anubhav Gain
14
date: 2026/07/13
15
tags:
16
  - attack.defense_evasion
17
  - attack.t1218
18
  - attack.t1027
19
logsource:
20
  product: windows
21
  category: process_creation
22
detection:
23
  wsl_image:
24
    Image|endswith:
25
      - '\bash.exe'
26
      - '\lxrun.exe'
27
      - '\wsl.exe'
28
      - '\wslconfig.exe'
29
      - '\wslhost.exe'
30
  suspicious_parent:
31
    ParentImage|endswith:
32
      - '\winword.exe'
33
      - '\excel.exe'
34
      - '\powerpnt.exe'
35
      - '\outlook.exe'
36
      - '\chrome.exe'
37
      - '\msedge.exe'
38
      - '\firefox.exe'
39
      - '\mshta.exe'
40
  payload_arg:
41
    Image|endswith:
42
      - '\wsl.exe'
43
      - '\bash.exe'
44
    CommandLine|contains:
45
      - 'curl'
46
      - 'wget'
47
      - 'python'
48
      - 'nc '
49
      - 'bash -c'
50
      - '/dev/tcp/'
51
      - 'base64'
52
  distro_ops:
53
    Image|endswith:
54
      - '\wsl.exe'
55
      - '\lxrun.exe'
56
    CommandLine|contains:
57
      - '--install'
58
      - '/install'
59
      - '--mount'
60
      - '--import'
61
      - '/mnt/c/Windows/System32/CodeIntegrity'
62
  condition: wsl_image and (suspicious_parent or payload_arg or distro_ops)
63
fields:
64
  - Image
65
  - ParentImage
66
  - CommandLine
67
  - User
68
falsepositives:
69
  - Developer / build hosts that legitimately use WSL (tier separately)
70
  - Approved WSL distribution installation during onboarding
71
level: high

7. Tuning Notes#

• Tier the fleet. WSL-authorized hosts (developer machines, specific build servers) go in their own tier; the rule runs at full severity everywhere else.
• Baseline the distribution list. Alert on a new distribution appearing (wsl --list) outside the approved set.
• Watch the /mnt/c crossing. Linux-side access to System32\CodeIntegrity from within WSL is the WDAC-policy attack path; correlate WSL launches with file-access telemetry on the policy paths.
• Pair with Sysmon EID 7. Loading of lxssmanager.dll by a process that is not the legitimate WSM service is anomalous.

8. References#

• Fun with the Windows Subsystem for Linux (lxss) — Alex Ionescu
• WDAC Bypass Techniques — The Complete Reference Catalog
• Windows Subsystem for Linux Documentation — Microsoft Learn
• MITRE ATT&CK T1218 — System Binary Proxy Execution
• MITRE ATT&CK T1027 — Obfuscated Files or Information