Ejecutar ADscan desde un Windows con QEMU

La auditoría de assumed breach más habitual te da una estación Windows 10 u 11 y nada más. Sin máquina Linux, sin permisos de administrador, y con un EDR mirando cada proceso que lanzas. La respuesta clásica es pivotar: tunelizas tu tráfico de vuelta a una máquina Linux y corres el toolkit desde allí. Eso sigue funcionando, pero en redes con hardening se vuelve más lento y más frágil cada año, a medida que los clientes endurecen el proxy de salida y detectan los túneles.

ADscan corre en Linux. No soporta Windows nativo ni WSL. Así que la pregunta que me llega de red teamers y MSSPs es siempre la misma: ¿cómo lo ejecuto cuando el único punto de apoyo es un endpoint Windows? La respuesta es una VM Linux autocontenida dentro de QEMU, en modo usuario. El tooling ofensivo nunca se ejecuta como código Windows en el host, y todo funciona sin admin local.

Uso autorizado únicamente. Todo lo de abajo es tradecraft estándar de pentests y engagements de red team que estás contratado para hacer. El patrón QEMU-sobre-Windows está documentado públicamente (la técnica la popularizó Owais / thesecguy en Running Under the Hood: Bypassing Next Gen EDRs) y hoy también lo usan grupos de ransomware, razón de más para que los equipos de defensa lean la sección de detección al final. Esto no es un 0-day secreto; es una técnica de compatibilidad con una firma conocida.

TL;DR para operadores con prisa:

• El problema: el punto de apoyo es una estación Windows con EDR y sin admin local. ADscan es solo Linux.
• El montaje: una carpeta QEMU portable + una imagen Linux pequeña, copiadas a la estación. Ejecutas qemu-system-x86_64 en modo usuario.
• Por qué es discreto frente al EDR: el EDR ve un proceso (qemu-system-x86_64.exe) ejecutando código de emulación de CPU. La actividad de Impacket, BloodHound y ADscan ocurre dentro del guest y nunca aflora como telemetría de proceso/API de Windows.
• Por qué sin admin: la pila de red en modo usuario (SLIRP) de QEMU no necesita driver TAP ni privilegios. La emulación por software (TCG) funciona incluso si el host bloquea KVM/Hyper-V.
• La pega: ADscan necesita Docker y ~12 GB de disco dentro del guest. Sin aceleración por hardware, va lento. Planifica la imagen, no la improvises en la máquina.
• La salida: ADscan escribe un workspace de JSON estándar. Lo recuperas por un puerto reenviado y lo parseas con tus propias herramientas o tu C2.

¿Por qué pivotar desde una estación Windows?

Porque el alcance moderno de assumed breach lo obliga. La mayoría de las auditorías que me piden los clientes parten de la misma premisa: una estación de trabajo ha sido comprometida y trabajamos desde ese sistema, típicamente un portátil Windows 10 u 11. La costumbre de siempre es convertir esa máquina en un pivote: crear rutas, túneles y enrutar tráfico a través de ella para poder usar herramientas Linux desde la comodidad de tu propia máquina.

Eso ha funcionado desde siempre. Pero con el tiempo las empresas con las que colaboro endurecen su salida. El proxy de salida se inspecciona, los túneles SOCKS se marcan, y pivotar así se vuelve más lento e inestable. Así que en vez de tunelizar hacia fuera, metes el toolkit hacia dentro: dejas un componente en la estación que hace el reconocimiento, la enumeración y la explotación en local, y manda los resultados a algo que tú controlas. Es la forma clásica de un C2, salvo que aquí el "agente" es una VM Linux de propósito general y los resultados vuelven como JSON que parseas tú, no un protocolo propietario atado a un solo cliente.

¿Cómo se mantiene un guest QEMU por debajo del EDR?

Un EDR construye su imagen de un host a partir de la telemetría de procesos, hilos y API de Windows: qué binarios se lanzan, qué handles abren, qué syscalls hacen. Asume que el código que corre en la máquina es código Windows haciendo cosas de Windows.

QEMU rompe esa suposición. qemu-system-x86_64.exe es un proceso Windows que ejecuta código máquina que implementa un emulador de CPU. Dentro de ese emulador corre un sistema operativo completamente distinto. Cuando ejecutas secretsdump.py o ADscan dentro del guest Linux, el EDR no ve un proceso secretsdump, ni un handle a LSASS, ni una llamada sospechosa a la API de Kerberos. Ve un proceso masticando instrucciones de emulación de CPU y moviendo memoria. El comportamiento ofensivo es real, pero ocurre una capa de abstracción por debajo de donde el EDR está mirando.

Es el mismo punto ciego que los grupos de ransomware empezaron a abusar a finales de 2025. Campañas ligadas a Payouts King usaron una tarea programada que corría una VM Alpine Linux oculta para preparar robo de credenciales y reconocimiento de AD fuera de la vista del EDR. El mecanismo es idéntico; solo cambian la autorización y la intención. Para un pentester en un engagement autorizado, es una forma legítima de correr un toolkit solo-Linux desde un punto de apoyo solo-Windows.

No es invisible. Un guest con red en modo usuario es discreto, pero la presencia de QEMU en sí es detectable, y ese es el trade-off honesto. Más sobre esto en la sección de detección.

¿Por qué no hace falta admin local?

Por dos razones independientes, y las dos importan en un endpoint con hardening.

Primero, la red. El backend de red por defecto de QEMU es el modo usuario, históricamente llamado SLIRP. Según la documentación de QEMU, con -netdev user "QEMU usa una pila de red completamente en modo usuario (no necesitas privilegios de root para usar la red virtual)". No hay adaptador TAP que instalar, ni bridge que configurar, ni aviso de firma de driver. El guest recibe una NIC emulada, QEMU hace NAT de su tráfico a través de la propia pila de red del host, y el guest alcanza todo lo que alcanza el usuario del host. En una auditoría interna eso significa que el guest puede hablar con el controlador de dominio, los shares SMB y la CA de ADCS igual que la estación, porque es la estación la que sale.

Segundo, la aceleración. La virtualización rápida normalmente necesita KVM (Linux) o una plataforma de hipervisor (Hyper-V/WHPX en Windows), que es privilegiada y a menudo está deshabilitada en un build corporativo. QEMU no la requiere. Su backend TCG por defecto emula la CPU puramente por software, así que qemu-system-x86_64 arranca un guest Linux incluso si el host bloquea todas las rutas de aceleración. Lo pagas en velocidad, y en una carga pesada como ADscan ese coste es real. Pero "lento y funcionando" gana a "rápido y bloqueado" cuando la máquina tiene hardening.

¿Qué pinta tiene el montaje de QEMU?

Todo es una carpeta portable más una imagen de disco del guest. Nada se instala en el host en el sentido tradicional; copias ficheros y ejecutas un binario. Construye y prueba la imagen antes del engagement, en tu propio equipo, y luego la metes.

Una invocación mínima con red en modo usuario y un puerto SSH reenviado se ve así:

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

Línea a línea: -m 4096 da 4 GB de RAM al guest. -drive conecta la imagen de disco Linux. La línea -netdev user es la pila de red sin admin, y hostfwd=tcp::2222-:22 reenvía el puerto 2222 del host al SSH del guest en el 22, para que puedas hacer ssh -p 2222 [email protected] desde la estación hacia tu Linux. -device e1000 da al guest una NIC emulada bien soportada. La sintaxis de hostfwd es hostfwd=[tcp|udp]:[hostaddr]:hostport-[guestaddr]:guestport, directa de la doc de QEMU, y añades una por cada puerto que quieras alcanzar.

Dos direcciones importan bajo SLIRP. El guest está en 10.0.2.0/24 y el host es siempre accesible desde dentro del guest en 10.0.2.2. Ese gateway es cómo mueves ficheros en la otra dirección: levantas un listener en el host Windows y el guest lo alcanza en 10.0.2.2, o levantas uno en el guest y reenvías un puerto del host hacia dentro con hostfwd. En ningún caso necesitas una interfaz de red real en el host.

¿Se puede correr ADscan de verdad dentro del guest?

Sí, con un requisito duro que hay que planificar: ADscan corre dentro de Docker y necesita unos 12 GB de disco libre para su imagen de runtime (el instalador quiere 15 GB libres antes de descargarla). Eso es una restricción real por dos lados. La imagen de disco del guest hay que dimensionarla para ello, y Docker tiene que estar instalado y corriendo dentro del guest Linux antes de que ADscan funcione. Nada de esto toca el host Windows, pero significa que el guest no es un Alpine de 512 MB de juguete. Presupuesta el disco y la RAM de antemano.

El flujo dentro del guest es el normal de ADscan:

pipx install adscan
adscan install
adscan start

adscan install descarga el runtime de Docker (este es el paso de 12 GB; hazlo mientras construyes la imagen, no en la máquina del cliente). A partir de ahí adscan start corre el flujo estándar de enumeración y attack paths contra el AD objetivo por LDAP, SMB y Kerberos, usando la conectividad del guest con NAT de SLIRP. Como el guest enruta a través del host, el controlador de dominio ve conexiones desde la IP de la estación, que es justo lo que quieres en un test de assumed breach.

La nota honesta de rendimiento: bajo emulación por software TCG, un escaneo de Active Directory basado en Docker no es rápido. Si el build del cliente permite WHPX (Windows Hypervisor Platform) sin privilegios, QEMU puede usarlo y la diferencia es abismal. Si no lo permite, ajusta tus expectativas y tu ventana de alcance. Esta es una técnica de compatibilidad y sigilo, no de velocidad.

¿Cómo recuperas los resultados?

ADscan escribe sus hallazgos en un workspace como ficheros planos, y su reporting es estructurado. No hace falta rascar la salida de una TUI. Saca el directorio del workspace del guest por el puerto SSH que reenviaste (scp -P 2222), o sírvelo desde el guest y cógelo vía 10.0.2.2, y ya tienes el material en bruto en el host.

Esta es la parte que los MSSPs preguntan específicamente: un componente que corre el recon/enum/explotación en el endpoint y devuelve los resultados en un formato estándar que parseas tú, en lugar de un protocolo C2 propietario que te ata a un cliente. La salida de ADscan es exactamente eso. El workspace JSON entra directo en tu propio pipeline, tu generador de informes o tus herramientas. La VM Linux es el "agente"; el JSON es el formato de intercambio; tus herramientas son el cliente.

¿Cómo lo detecta un equipo de defensa?

Esta técnica es discreta frente al EDR, no invisible, y la parte de detección es la razón por la que los defensores deberían fijarse. Lo que oculta la actividad ofensiva no oculta QEMU en sí. Detecciones que funcionan, sacadas de los análisis de respuesta a incidentes sobre el abuso real (el análisis de túneles encubiertos de TrustedSec es un buen punto de partida):

El control práctico es el allowlisting de aplicaciones: en una estación corporativa estándar no hay razón legítima para que un qemu-system-x86_64.exe no firmado o inesperado se ejecute, así que bloquea la ejecución de binarios de virtualización fuera de un allowlist conocido y alerta cuando aparezcan imágenes de disco en endpoints de usuario. Esa única política cierra la técnica tanto para el red team como para el grupo de ransomware.

Preguntas frecuentes

¿Ahora ADscan corre en Windows? No. ADscan es solo Linux y no soporta Windows nativo ni WSL. Esta técnica corre ADscan sobre Linux dentro de una VM en un host Windows; no convierte a ADscan en una herramienta Windows.

¿Necesito permisos de administrador en la estación? No. La red en modo usuario de QEMU no necesita privilegios ni driver, y la emulación por software TCG funciona sin KVM/Hyper-V. Sí necesitas disco y RAM suficientes para el guest, y Docker instalado dentro del guest.

¿Esto evade cualquier EDR? Mueve la actividad ofensiva por debajo de donde mira el EDR basado en host, así que la telemetría de proceso y API de tus herramientas no aflora. No oculta la presencia de QEMU. Un defensor que haga allowlisting de binarios o cace imágenes de disco lo detecta.

¿Es legal usarlo? Solo en sistemas que estás autorizado a auditar. Es tradecraft estándar de pentest y red team bajo un contrato o unas reglas de enfrentamiento. La misma técnica la abusan grupos de ransomware, y por eso lo que separa a los dos es la autorización, no la herramienta.

¿Por qué no tunelizar de vuelta a una máquina Linux? A menudo todavía puedes, y es más simple cuando la salida está abierta. Esta es la respuesta para redes con hardening donde el proxy de salida se inspecciona y los túneles se marcan, y para alcances que exigen operar desde el propio endpoint.

Lecturas relacionadas: ejecutar ADscan y el flujo completo de assumed breach, la comparativa ADscan vs BloodHound para ver cómo se compara la enumeración, y acceso inicial a Active Directory sin credenciales para qué hacer cuando el guest ya alcanza el DC.