Run ADscan From a Windows Workstation via QEMU

The most common assumed-breach engagement gives you a Windows 10 or 11 workstation and nothing else. No Linux box, no admin rights, and an EDR watching every process you spawn. The classic answer is to pivot: tunnel your traffic back to a Linux machine and run your toolkit from there. That still works, but on hardened networks it is getting slower and more fragile every year as clients lock down outbound proxying and flag the tunnels.

ADscan runs on Linux. It does not support native Windows or WSL. So the question I get from red teamers and MSSPs is always the same: how do I run it when the only foothold is a Windows endpoint? The answer is a self-contained Linux VM inside QEMU, running in user mode. The offensive tooling never executes as Windows code on the host, and the whole thing runs without local admin.

Authorized use only. Everything below is standard tradecraft for pentests and red team engagements you are contracted to perform. The QEMU-on-Windows pattern is publicly documented (the technique was popularized by Owais / thesecguy in Running Under the Hood: Bypassing Next Gen EDRs) and it is now used by ransomware crews too, which is exactly why blue teams should read the detection section at the end. This is not a secret 0-day; it is a compatibility technique with a known signature.

TL;DR for operators in a hurry:

• The problem: the foothold is a Windows workstation with an EDR and no local admin. ADscan is Linux-only.
• The setup: a portable QEMU folder + a small Linux guest image, copied to the workstation. Run qemu-system-x86_64 in user mode.
• Why it is EDR-quiet: to the EDR, one process (qemu-system-x86_64.exe) is running CPU-emulation machine code. The Impacket, BloodHound, and ADscan activity happens inside the guest and never surfaces as Windows process/API telemetry.
• Why no admin: QEMU's user-mode (SLIRP) network stack needs no TAP driver and no privileges. Software emulation (TCG) runs even when the host blocks KVM/Hyper-V.
• The catch: ADscan needs Docker and ~12 GB of disk inside the guest. Without hardware acceleration this is slow. Plan the image, do not improvise it on the box.
• The output: ADscan writes a workspace of standard JSON. Copy it back through a forwarded port and parse it with your own tools or C2.

Why pivot from a Windows workstation at all?

Because the modern assumed-breach scope forces it. Most of the audits my clients ask for start from the same premise: a workstation has been compromised, and we work from that system, typically a Windows 10 or 11 laptop. The old habit is to turn that box into a pivot: create routes, tunnels, and route traffic through it so you can drive Linux tools from the comfort of your own machine.

That has always worked. But over time the companies I work with are hardening their egress. Outbound proxying gets inspected, SOCKS tunnels get flagged, and pivoting this way becomes slower and less stable. So instead of tunneling out, you bring the toolkit in: drop a component on the workstation that does the reconnaissance, enumeration, and exploitation locally, and ships the results to something you control. That is a classic C2 shape, except here the "agent" is a general-purpose Linux VM and the results come back as JSON you parse yourself, not a proprietary protocol locked to one client.

How does a QEMU guest stay under the EDR?

An EDR builds its picture of a host from Windows process, thread, and API telemetry: what binaries launch, what handles they open, what syscalls they make. It assumes the code running on the machine is Windows code doing Windows things.

QEMU breaks that assumption. qemu-system-x86_64.exe is one Windows process running machine code that implements a CPU emulator. Inside that emulator runs a completely different operating system. When you run secretsdump.py or ADscan inside the Linux guest, the EDR does not see a secretsdump process, an LSASS handle, or a suspicious Kerberos API call. It sees one process crunching CPU-emulation instructions and moving memory around. The offensive behavior is real, but it is happening one abstraction layer below where the EDR is looking.

This is the same blind spot that ransomware crews started abusing in late 2025. Campaigns linked to Payouts King used a scheduled task running a hidden Alpine Linux VM to stage credential theft and AD reconnaissance out of the EDR's view. The mechanism is identical; only the authorization and the intent differ. For a pentester on an authorized engagement, it is a legitimate way to run a Linux-only toolkit from a Windows-only foothold.

It is not invisible. A guest with user-mode networking is quiet, but the presence of QEMU itself is detectable, and that is the honest trade-off. More on that in the detection section.

Why does this not need local admin?

Two independent reasons, and both matter on a locked-down endpoint.

First, networking. QEMU's default network backend is user-mode networking, historically called SLIRP. Per the QEMU documentation, with -netdev user "QEMU uses a completely user mode network stack (you don't need root privilege to use the virtual network)." There is no TAP adapter to install, no bridge to configure, no driver-signing prompt. The guest gets an emulated NIC, QEMU NATs its traffic out through the host's own network stack, and the guest reaches everything the host user can reach. On an internal engagement that means the guest can talk to the Domain Controller, SMB shares, and the ADCS CA exactly as the workstation can, because it is going out as the workstation.

Second, acceleration. Fast virtualization normally needs KVM (Linux) or a hypervisor platform (Hyper-V/WHPX on Windows), which is privileged and often disabled on a corporate build. QEMU does not require it. Its default TCG backend emulates the CPU purely in software, so qemu-system-x86_64 boots a Linux guest even when the host blocks every acceleration path. You pay for it in speed, and on a heavy workload like ADscan that cost is real. But "slow and running" beats "fast and blocked" when the box is locked down.

What does the QEMU setup actually look like?

The whole thing is a portable folder plus a guest disk image. Nothing gets installed on the host in the traditional sense; you copy files and run a binary. Build and test the image before the engagement, on your own gear, then bring it in.

A minimal invocation with user-mode networking and a forwarded SSH port looks like this:

qemu-system-x86_64 \
  -m 4096 \
  -drive file=guest.qcow2,format=qcow2 \
  -netdev user,id=n0,hostfwd=tcp::2222-:22 \
  -device e1000,netdev=n0 \
  -display none -serial stdio

Line by line: -m 4096 gives the guest 4 GB of RAM. -drive attaches the Linux disk image. The -netdev user line is the no-admin network stack, and hostfwd=tcp::2222-:22 forwards host port 2222 to the guest's SSH on 22, so you can ssh -p 2222 [email protected] from the workstation into your Linux box. -device e1000 gives the guest a well-supported emulated NIC. The hostfwd syntax is hostfwd=[tcp|udp]:[hostaddr]:hostport-[guestaddr]:guestport, straight from the QEMU docs, and you add one per port you want to reach.

Two addresses matter under SLIRP. The guest sits on 10.0.2.0/24 and the host is always reachable from inside the guest at 10.0.2.2. That gateway is how you move files the other direction: run a listener on the Windows host and the guest hits it at 10.0.2.2, or run one in the guest and forward a host port in with hostfwd. Either way you never need a real network interface on the host.

Can you actually run ADscan inside the guest?

Yes, with one hard requirement to plan around: ADscan runs inside Docker and needs roughly 12 GB of free disk for its runtime image (the installer wants 15 GB free before it will pull). That is a real constraint on two fronts. The guest disk image has to be sized for it, and Docker has to be installed and running inside the Linux guest before ADscan will work. None of that touches the Windows host, but it means the guest is not a 512 MB Alpine toy. Budget the disk and the RAM up front.

The workflow inside the guest is the normal ADscan one:

pipx install adscan
adscan install
adscan start

adscan install pulls the Docker runtime (this is the 12 GB step; do it while building the image, not on the client's box). From there adscan start runs the standard enumeration and attack-path workflow against the target AD over LDAP, SMB, and Kerberos, using the guest's SLIRP-NAT'd connectivity. Because the guest routes through the host, the Domain Controller sees connections from the workstation's IP, which is exactly what you want on an assumed-breach test.

The honest performance note: under TCG software emulation, a Docker-based Active Directory scan is not fast. If the client's build happens to allow WHPX (Windows Hypervisor Platform) unprivileged, QEMU can use it and the difference is night and day. If it does not, size your expectations and your scope window accordingly. This is a compatibility and stealth technique, not a speed one.

How do you get the results back out?

ADscan writes its findings to a workspace as plain files, and its reporting is structured. You do not need to screen-scrape a TUI. Pull the workspace directory out of the guest over the SSH port you forwarded (scp -P 2222), or serve it from the guest and grab it via 10.0.2.2, and you have the raw material on the host.

This is the part MSSPs specifically ask about: a component that runs the recon/enum/exploitation on the endpoint and returns results in a standard format you parse yourself, rather than a proprietary C2 protocol that locks you into one client. ADscan's output is exactly that. The JSON workspace drops straight into your own pipeline, your own report generator, or your own tooling. The Linux VM is the "agent"; the JSON is the wire format; your tools are the client.

How do blue teams detect this?

This technique is EDR-quiet, not EDR-invisible, and the detection story is the reason defenders should care. What hides the offensive activity does not hide QEMU itself. Detections that work, drawn from the incident-response write-ups on real abuse (TrustedSec's covert-tunnels analysis is a good starting point):

The practical control is application allowlisting: on a standard corporate workstation there is no legitimate reason for an unsigned or unexpected qemu-system-x86_64.exe to run, so block execution of virtualization binaries outside a known allowlist and alert on disk-image files appearing on user endpoints. That single policy closes the technique for both the red team and the ransomware crew.

FAQ

Does ADscan run on Windows now? No. ADscan is Linux-only and does not support native Windows or WSL. This technique runs ADscan on Linux inside a VM on a Windows host; it does not make ADscan a Windows tool.

Do I need administrator rights on the workstation? No. QEMU's user-mode networking needs no privileges and no driver, and TCG software emulation runs without KVM/Hyper-V. You do need enough disk and RAM for the guest, and Docker installed inside the guest.

Will this bypass every EDR? It moves the offensive activity below where host-based EDR looks, so process and API telemetry from your tools does not surface. It does not hide QEMU's own presence. A defender allowlisting binaries or hunting for disk images will catch it.

Is this legal to use? Only on systems you are authorized to test. It is standard pentest and red team tradecraft under a contract or rules of engagement. The same technique is abused by ransomware crews, which is why it is authorization that separates the two, not the tooling.

Why not just tunnel back to a Linux box? You often still can, and it is simpler when egress is open. This is the answer for hardened networks where outbound proxying is inspected and tunnels get flagged, and for scopes that require you to operate from the endpoint itself.

Related reading: running ADscan and the full assumed-breach workflow, the ADscan vs BloodHound comparison for how the enumeration compares, and initial access to Active Directory without credentials for what to do once the guest can reach the DC.