Elegir un listener para reverse shell: netcat sirve hasta que deja de servir
Cómo escoger listener para pruebas reverse shell autorizadas, entre netcat, ncat y socat, sin complicar el laboratorio.
El listener es la mitad aburrida de un reverse shell. También es donde muchas pruebas fallan. La gente revisa tres veces la sintaxis del payload y luego ejecuta el primer nc que encuentra, como si todas las versiones de netcat fueran iguales.
No lo son.
Empieza por lo simple
Para un callback único en un laboratorio autorizado, netcat suele bastar:
nc -lvnp 4444
Es útil porque tiene pocas piezas móviles. Si la conexión llega, ruta, puerto y payload tienen sentido. Si no llega, puedes depurar sin preguntarte si un handler más complejo escondió el error.
El problema es la portabilidad. OpenBSD netcat, GNU netcat, BusyBox netcat y ncat de Nmap cambian flags, TLS, soporte de proxy y comportamiento de stdin. Cuando una guía dice "usa nc", muchas veces omite ese detalle incómodo.
Ncat cuando quieres menos sorpresas
ncat funciona mejor cuando necesitas comportamiento más consistente o TLS en un escenario de laboratorio que lo exige. No es sigilo. No es magia. Solo es más predecible.
ncat -lvnp 4444
Para pruebas con proxy o redes segmentadas, ncat también permite modelar condiciones más cercanas a producción. Aun así, no empieces por ahí. Primero demuestra que la ruta básica funciona. Luego añade complejidad de transporte.
Socat cuando importa el terminal
socat puede asignar PTY, ajustar modo raw y arreglar sesiones donde netcat entrega una shell torpe. Es potente y poco amable, como muchas herramientas Unix buenas.
El coste es el error humano. Los comandos socat se vuelven largos. Los comandos largos acaban en notas con comas perdidas, opciones viejas o IPs equivocadas. Úsalo cuando la calidad de sesión importe. No lo conviertas en tu primera prueba.
Listener no es C2
Un listener acepta una conexión. Un C2 gestiona agentes, tareas, cifrado, identidad, persistencia, logs y workflow de operadores. Son problemas distintos. Para validar ejecución de comandos en un lab controlado, un framework pesado puede añadir ambigüedad.
El flujo bueno es aburrido: generar, escuchar, observar, documentar y apagar.