Skip to content
reverseshell

Usar un generador de reverse shell sin romper tu laboratorio

Flujo práctico para generar reverse shells en entornos autorizados, preparar el listener y diagnosticar fallos reales.

Publicado el 3 min de lectura

Un generador de reverse shell no es un exploit. Es una herramienta para ahorrar errores de sintaxis cuando trabajas en un laboratorio o una prueba autorizada. Lo difícil suele estar fuera del snippet: rutas, NAT, firewall local, listener, quoting, terminal inestable y controles de seguridad que matan procesos sin dejar un mensaje amable.

La mayoría de sesiones fallidas no fracasan por elegir Bash en vez de Python. Fracasan porque el operador puso la IP equivocada, escuchó en una interfaz que la máquina objetivo no puede alcanzar, o probó desde un contenedor que nunca publicó el puerto al host.

Empieza por la ruta de red

Antes de generar nada, confirma qué dirección puede alcanzar el sistema objetivo. En la máquina que escucha:

ip addr
ip route
ss -lntp

En macOS, ifconfig y netstat -rn siguen siendo útiles. En laboratorios cloud, revisa security groups, ACL, firewall del sistema y reglas NAT. Un callback a 127.0.0.1 desde una máquina remota no va a llegar. Tampoco llegará a una IP de VPN que solo existe dentro de tu portátil.

Para escuchar, empieza simple:

nc -lvnp 4444

Si tu versión de netcat no tiene las opciones esperadas, usa ncat. OpenBSD netcat, GNU netcat, BusyBox y Nmap Ncat no se comportan igual. Parece un detalle menor hasta que pierdes media hora mirando una ventana vacía.

Genera menos, comprueba más

La aplicación debe hacer visibles las decisiones: Bash, Python, PHP, PowerShell, TCP, quizá TLS si el escenario lo pide. Pero no puede conocer el entorno real. ¿Existe Python 3? ¿PowerShell está en modo restringido? ¿Hay /bin/bash, o el sistema solo trae sh dentro de una imagen mínima?

No pegues cinco variantes a ciegas. Prueba una hipótesis, mira el listener y captura tráfico si no ocurre nada:

tcpdump -ni any port 4444

Sin paquetes, probablemente el comando no se ejecutó o el tráfico fue bloqueado antes de salir. SYNs que llegan pero no establecen sesión apuntan al firewall local o al listener. Una conexión que se cierra al instante suele indicar quoting roto, binarios ausentes o un intérprete que arrancó y murió.

Una conexión no es una terminal decente

El primer shell casi nunca es cómodo. Puede no gestionar Ctrl-C, no tener PTY, romper sudo, fallar con herramientas interactivas o perder edición de línea. Las recetas de upgrade sirven para estabilizar una sesión que ya existe. No deberían mezclarse con la generación inicial.

También hay una línea ética y operativa clara. En un lab o pentest autorizado, un reverse shell es un canal de diagnóstico. No necesita persistencia, evasión, robo de credenciales ni movimiento lateral automático. Si una herramienta añade eso por defecto, ya no es un generador. Es otra cosa.

El flujo útil es estrecho: escoger familia de payload, rellenar host y puerto, lanzar el listener correcto y documentar lo que funcionó. Poco glamuroso. Muy eficaz.

Artículos relacionados

Una prueba reverse shell autorizada debe dejar notas claras, listeners apagados, artefactos conocidos y logs útiles.
Cómo depurar callbacks que no llegan por problemas de rutas, egreso, listeners, runtimes ausentes y comandos mal escapados.
La detección de reverse shells necesita contexto de procesos, red y workload. Las firmas aisladas generan ruido y pierden casos reales.