Microsoft Defender for Endpoint Plug-in for Windows Subsystem for Linux

WSL2 is a blind spot in most Windows-centric threat detection strategies as attackers increasingly exploit it by deploying payload persistence, and moving laterally from there. Your endpoint detection and response (EDR) solution may be alerting about suspicious PowerShell activity on the Windows host itself while an attacker orchestrates their entire operation inside a quiet Linux virtual machine running on the same platform.

The Microsoft Defender for Endpoint plug-in for WSL2 addresses this gap. It’s not a silver bullet but it changes the detection capabilities for an analyst by inserting Defender’s sensor inside the WSL2 Hyper-V boundary, allowing you to see what’s actually happening in Linux distributions running on those Windows machines.

This post dives deep into what the plugin is, and what it explicitly does not do. We have also added some hunting strategies you should consider if you have deployed WSL2 in your environment.

The WSL2 Visibility Problem

WSL1 vs WSL2 Differences

WSL2 is not a translation layer like its predecessor, WSL1. It runs a lightweight Hyper-V virtual machine with its own Linux kernel, isolated file system, and networking stack. From a Windows perspective, the only visible artifact is the wsl.exe process launching a distribution. What happens inside that VM is largely invisible to Windows and an EDR.

For threat hunters, detection engineers and blue teamers, this architecture creates a security challenge: 

• Windows Defender Real-Time Protection scans the VHDX file containing the WSL filesystem, but it does so at the file-system boundary, not the execution layer.
• Standard Windows telemetry logs the parent wsl.exe process and any Windows-to-Linux process calls (e.g., wsl.exe -e bash -c "super_sneaky_hacker_oneliner"), but interactive sessions inside the distro leave minimal traces.
• EDR agents on the Windows-side cannot see inside the VM without specialized tools and access.

What does this mean? 

An attacker with code execution on a machine can deploy post-exploitation tools, run reconnaissance, exfiltrate data, or stage lateral movement campaigns entirely within WSL2, while your telemetry streams show little more than a quiet wsl.exe process executing periodic background tasks. 

Why Attackers Favour WSL2 

Security researchers and red teamers have documented this extensively. WSL2 abuse can look like the following: 

• LOLbins (awk, curl, grep, nc, wget) blend in as normal developer activity and we often talk about threat actors hiding their attack in the noise a machine normally creates.
• Tools like BloodHound run inside WSL2 and exfiltrate domain data without Windows-side audit logs capturing the output files.
• Cron jobs, systemd services, or shell initialisation scripts persist across reboots within the WSL distro without Windows-side registry or scheduled task entries.

The WSL2 environment is especially attractive on developer workstations because it’s legitimate. Security analysts expect developers to use WSL just like the Finance department are expected to run calc.exe. Monitoring and restricting it heavily will only yield complaints from the developers since it will collide with their productivity.

Introducing the Microsoft Defender for Endpoint Plugin for WSL2

What Is It? 

The Microsoft Defender for Endpoint Plug-in for WSL2 is a DLL-based sensor that runs inside the WSL2 virtual machine, collects telemetry from the Linux kernel, and reports it back to the parent Defender for Endpoint service on the Windows host. It’s actually as simple as that.

Unlike native Linux Defender which must be installed separately on each Linux machine, the WSL2 plugin is a single installation on the Windows host that automatically handles all active WSL2 distributions without requiring any agent installation inside the distro itself. The plugin hooks into the WSL2 infrastructure at the kernel-level giving it visibility into process execution, file operations, and network activity just like Defender for Endpoint on a Windows host. The keyword here is visibility and we will get to that in a bit.

Key Components 

After installation, you will find these files in the %ProgramFiles%\Microsoft Defender for Endpoint plug-in for WSL\ folder: 

Component	Location	Purpose
DefenderforEndpointPlug-in.dll	\\plug-in	Core sensor library loaded by WSL infrastructure
healthcheck.exe	\\tools	Diagnostic tool to validate plugin health, versions, and connectivity

The installer is an MSI package (version DefenderPlugin-x64-1.25.825.2.msi as of writing this on March 12) downloaded from the MDE onboarding section in the Microsoft Security portal. 

Prerequisites 

Before deploying the plugin, ensure the following: 

1. Administrative rights on the Windows host
2. WSL2 is installed and updated. Minimum version is 2.0.7.0
3. Windows 11 or Windows 10 build 19044 and later is supported
4. The Windows host must already be reporting to Defender for Endpoint
5. Distros must be running on WSL2
6. The plugin does not support custom Linux kernels or custom kernel command lines. Standard distro kernels only.

Installation

The installation is simple and well-documented on Microsoft’s Learn pages, but for your convenience we will take you through it step-by-step.

Step 1: Prepare WSL2 

Open PowerShell as Administrator and run: 

wsl –install 
wsl –update 
wsl –list –verbose 

The last command should show all distros with Version 2 listed. If any show Version 1, convert them: 

wsl --set-version Ubuntu-22.04 2 

Ensure at least one distro is running by launching it: 

wsl 
# You should see a Linux prompt; type 'exit' to return to PowerShell 

Step 2: Download the Plugin MSI 

1. Sign into the Microsoft Security portal: https://security.microsoft.com
2. Navigate to Settings > Endpoints > Onboarding 
3. Select Windows Subsystem for Linux 2 (plug-in) from the list 
4. Click Download x64 installation package to get the MSI file 
5. Save it to a local folder, e.g. the Desktop is a marvellous place to use for this type of thing 

Step 3: Install the Plugin 

Open PowerShell as Administrator, again: 

cd C:\Temp\ 
msiexec /i defenderplugin-x64-1.25.825.2.msi /quiet /norestart 

Or use the graphical installer by double-clicking the MSI file that you so neatly saved to your Desktop. The installation is automatic so no annoying configuration prompts or popups will appear. 

Step 4: Validate Installation 

After installation, wait a few minutes for the plugin to initialize. Then run the health check: 

cd "%ProgramFiles%\Microsoft Defender for Endpoint plug-in for WSL\tools" 
.\healthcheck.exe 

The output should show something similar: 

Microsoft Defender for Endpoint plug-in for WSL 
 
[2026-03-11 13:37:00 UTC] 
Plug-in Version         : 1.25.825.2 
WSL Version             : 2.6.1 
Defender App Version    : 101.25022.0001 
Release Ring            : Production 
VM Start Time (UTC)     : 2026-03-11 13:37:00 UTC 
LKG Telemetry (UTC)     : 2026-03-11 13:37:00 UTC (Active) 
WSL Distro Running      : true 
 
Active User SID         : <REDACTED> 
Windows GUID            : <REDACTED> 
Windows Org ID          : <REDACTED> 
Windows Device ID       : <REDACTED> 
Licenced                : Valid 
 
WSL GUID                : <REDACTED> 
WSL Device ID           : <REDACTED> 
Health Status           : Healthy 
Health Issues           : [] 
Licensed                : Valid 
 
MDE Connectivity Test   : success 

If you have connected through a proxy, that information will also be shown in the Healthcheck output. 

If any field is missing or “Waiting for Telemetry” is shown, then wait another few minutes and retry. You should get something similar to the above output. 

Optional Proxy Configuration 

If your organization uses a proxy for outbound connectivity, the plugin automatically inherits the proxy settings from the Windows host’s MDE configuration: 

• If a Defender for Endpoint static proxy is set (registry key TelemetryProxyServer), it’s used automatically. 
• If a WinHTTP proxy is configured via netsh, it’s used automatically. 
• If Windows Network & Internet proxy settings are configured, they’re used as a fallback. 

No additional WSL-specific proxy configuration is needed unless you’re using an HTTP-only proxy (HTTPS proxies are supported by MDE but not by the WSL plugin; use HTTP in that case). 

Telemetry and Visibility 

Data Collection 

Once the plugin is active, the MDE portal begins ingesting Linux-based telemetry from your WSL2 instances. Key data includes: 

Data Type	Example	Hunting Value
Process Events	bash, curl, wget, nc, python, apt-get	High—baseline for command-line hunting
File Events	File creation, modification, deletion in /tmp, /home, /opt	Medium—only aggregated, not content-based
Network Events	TCP/UDP connections to specific IPs/ports	High—ideal for detecting C2 callbacks
User/Login Events	SSH sessions, sudo invocations	Medium—if distro logs to syslog, captured

Each WSL2 instance appears in the MDE portal as a separate device with: 

• OSPlatform: “Linux” 
• DeviceId: Unique identifier for that WSL instance 
• HostDeviceId: Device ID of the Windows host machine (which allows correlation) 
• Device Tag: “WSL2” (can be customized via registry key HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows Advanced Threat Protection\DeviceTagging) 

What the Plugin Does NOT Capture 

Understanding limitations is crucial for setting realistic expectations: 

1. If an attacker logs into a WSL distro via interactive bash shell and runs commands directly at the prompt, those commands are not logged. The shell process itself is visible, but its child processes spawned interactively are (most of the times) not. 
2. The plugin logs file creation/deletion events but not file content. An attacker can write a malware binary or exfiltrate data to /tmp and the plugin will see the event, but not the payload. 
3. While network connections are logged (source, destination, port), encrypted C2 traffic (HTTPS, DNS-over-TLS, etc.) shows only the connection, not the command or response payloads. 
4. The plugin operates at the Linux kernel-level, but if an attacker achieves kernel compromise (e.g., via a 0-day), the plugin’s own integrity may be compromised. 
5. If a WSL distro runs for less than ~30 minutes, it may not appear in the Security portal. This is a known limitation for short-lived container scenarios. 
6. Unlike the Windows host, the WSL2 device in MDE cannot be remotely isolated, patched, or have malicious processes terminated from the portal. Response actions are limited to monitoring, investigation and alerting only. 

How to Identify WSL Instances in the Portal 

In the Defender portal, filter your Devices list by tag WSL2: 

1. Go to Assets > Devices 
2. Click Filters 
3. Select Device tags and add WSL2 
4. Click Apply 

All active WSL2 instances appear as separate device entries. The Device Name matches the Windows host’s name, but each distro has a unique DeviceId and a populated HostDeviceId field. 

Threat Hunting with WSL2 Telemetry 

So, how can we best use the telemetry produced by the WSL2 plugin? Microsoft have a couple of good starting points on their Learn page that we can build on, and you can use the following threat hunting examples as inspiration to build your own detection around based on how your environment looks and behaviors. 

Detect Network Reconnaissance Tools 

Interactive WSL shells leave no process logs, but non-interactive invocations (via wsl -e or scheduled tasks) are captured. 

let wsl_endpoints = DeviceInfo 
| where OSPlatform == "Linux" and isnotempty(HostDeviceId) 
| distinct DeviceId; 
DeviceProcessEvents 
| where DeviceId in (wsl_endpoints) 
| where FileName in~ ("curl", "masscan", "nc", "netstat", "nmap", "ss", "wget", "zmap") 
| sort by Timestamp desc

Attackers can download and run reconnaissance tools via non-interactive shell invocations, which are logged. The query above is a simple way to find these process creation events. 

Detect Credential Dumping Utilities 

Even though tools like BloodHound, Mimikatz are rarely seen nowadays they still can be downloaded and run via WSL. BloodHound, Mimikatz and other custom credential harvesters show up as process creations:

let wsl_endpoints = DeviceInfo 
| where OSPlatform == "Linux" and isnotempty(HostDeviceId) 
| distinct DeviceId; 
let credential_tools = dynamic([ 
    // Keep the list sorted alphabetically 
    "bloodhound", 
    "crackmapexec", 
    "hashcat", 
    "hydra", 
    "john", 
    "mimikatz" 
  ]); 
DeviceProcessEvents 
| where DeviceId in (wsl_endpoints) 
| where FileName in~ (credential_tools) 

Detect Persistence

Cron jobs and systemd services are created as files inside the distro. While file content isn’t captured, file creations in system directories are and could be a detection opportunity. Let’s try the following:

let wsl_endpoints = DeviceInfo 
| where OSPlatform == "Linux" and isnotempty(HostDeviceId) 
| distinct DeviceId; 
DeviceFileEvents 
| where DeviceId in (wsl_endpoints) 
| where ActionType == "FileCreated" 
| where FolderPath in~ ("/etc/cron.d/", "/etc/cron.hourly/", "/etc/systemd/system/", "/home/*/") 
| order by Timestamp desc 

Detect Package Manager Abuse 

Attackers may install tools via apt, pip, or npm to execute malware or tooling: 

let wsl_endpoints = DeviceInfo 
| where OSPlatform == "Linux" and isnotempty(HostDeviceId) 
| distinct DeviceId; 
DeviceProcessEvents 
| where DeviceId in (wsl_endpoints) 
| where FileName in~ ("apt-get", "apt", "pip", "npm", "curl", "wget") 
| where ProcessCommandLine has_any ("install", "download", "get") 
| order by Timestamp desc 

Caution: Filtering the DeviceProcessEvents field for curl or wget can, depending on how your environment is set up, yield a lot of false positive alerts and trigger alert fatigue for your analysts. Be cautious!

Registry Settings and Some Troubleshooting 

Setting a Custom Device Tag 

By default, all WSL2 instances are tagged “WSL2”. To add a custom organizational tag (e.g., “Developer-WSL2” or “SecOps-WSL2”), set the Windows registry key: 

Registry Path: HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows Advanced Threat Protection\DeviceTagging 
Key Name: GROUP (REG_SZ) 
Value: (Your custom tag, e.g., “Developer-WSL2”) 

After you restart WSL (wsl --shutdown then simply wsl), the device will be tagged “Engineering_WSL2” in the portal. This is useful for scoping queries or filtering device lists. 

Proxy Hierarchy 

If the healthcheck.exe tool reports “Connectivity Test: invalid,” the plugin is unable to reach the Defender for Endpoint backend services. Check proxy configuration in this order: 

1. Defender Static Proxy: Registry key HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows Advanced Threat Protection > TelemetryProxyServer (if set by your organization) 
2. WinHTTP Proxy: Configured via netsh winhttp show proxy 
3. Windows Network Settings: Settings > Network & Internet > Proxy 

If your organization uses an HTTP-only proxy (HTTP, not HTTPS), this is supported; HTTPS proxies may fail. 

Troubleshooting If Connectivity Test Fails 

Run the extended proxy diagnostic 

cd "%ProgramFiles%\Microsoft Defender for Endpoint plug-in for WSL\tools" 
.\healthcheck.exe --extendedProxy

This command provides detailed output of which proxy configuration the plugin is trying to use. Cross-reference with your organization’s network settings. 

Troubleshooting If Plugin Installation Fails 

If the MSI installation fails with an error like: 

A fatal error was returned by plugin 'DefenderforEndpointPlug-in'. Error code: Wsl/Service/CreateInstance/CreateVm/Plugin/ERROR_FILE_NOT_FOUND 

This indicates a corrupted installation. Repair it by going through the following steps: 

1. Go to Control Panel > Programs > Programs and Features 
2. Find Microsoft Defender for Endpoint plug-in for WSL 
3. Click Repair 
4. Wait for it to complete and then test it with `healthcheck.exe` again

The Bigger Picture 

The plugin closes a visibility gap, but it is not a complete Linux EDR solution. So you need to understand these trade-offs that come with the plugin. We have talked about them already, but here is a short recap:

• If an attacker shells into WSL interactively and runs a multi-stage attack, the telemetry capture is sparse. You have the shell process, but not the subsequent commands. 
• The plugin does not capture file content. If data is exfiltrated or malware is staged to disk, you’ll see the file creation event but not the payload itself. 
• If an attacker escalates from a user to root inside WSL, the plugin will see the escalation attempt, but the subsequent root-level activity may be difficult to trace. 

For mature incident response, WSL2 compromises should be escalated to Linux forensics specialists. The plugin provides signals, not complete evidence nor response capabilities. 

Conclusion 

WSL2 is a blind spot in the modern Windows security posture. The Microsoft Defender for Endpoint plug-in for WSL2 is a meaningful tool that addresses it. It brings endpoint visibility into an isolated subsystem where we’ve seen attackers operate undisturbed before. 

The real security value, however, lies in understanding its limitations. The plugin is not a replacement for Linux-side forensics or behavioral defense mechanisms. It is a way to shift WSL2 from a blind spot to a monitored, queryable and alertable infrastructure component for your SOC and detection engineers.