Shellcode reverse TCP: la checklist de laboratorio que uso de verdad
Un flujo reverse TCP práctico para pruebas autorizadas: listener, revisión de bytes y fallos reales antes de integrar el exploit.
payloads reverse TCP, listener, validación de LHOST/LPORT, bytes de sockaddr y fiabilidad del callback no son temas abstractos. Aparecen cuando un laboratorio autorizado deja la demo limpia y toca un binario real, con un parser real, una ruta de red real y un informe que alguien revisará dentro de dos meses.
El error común es ajustar codificadores cuando el problema real es una salida bloqueada o un listener ligado a la interfaz incorrecta. Es aburrido, y por eso sobrevive. Parece una hipótesis sin comprobar en el builder, un valor copiado de la VPN de ayer o una secuencia de bytes pegada a través de una herramienta que reescribe texto.
Por qué importa en un laboratorio real
El trabajo con shellcode es trabajo a nivel de byte. El exploit no sabe que la interfaz parecía correcta. Ejecuta los bytes que llegaron a memoria. Si el payload cruza una shell, un formulario web, un cuerpo JSON, el scrollback del terminal o un ticket, ya no tienes un solo problema. Tienes el payload más cada parser del camino.
Prefiero comprobaciones explícitas antes que confianza: tamaño esperado, bytes prohibidos, OS objetivo, arquitectura, familia de payload, formato de exportación y hash final. Cuando algo falla, las notas deben reducir la búsqueda, no abrir otra discusión.
Un flujo que aguanta el contacto con herramientas
Start from the smallest thing that proves the primitive. Then add constraints.
nc -lvnp 4444
Ese comando no es todo el flujo. Es un ancla. Alrededor, conserva un blob conocido, su SHA-256 y la configuración exacta del builder. Si cambias LHOST, LPORT, orden de encoders, lista de bad chars o formato de exportación, trata el resultado como un artefacto nuevo.
Fallos que merece la pena probar
El patrón de fallo que busco es un callback que nunca llega, una conexión que muere al instante o una shell que aparece una vez y cae por SIGPIPE. Pruébalo antes de integrar si puedes. Un payload que falla en un harness pequeño cuesta menos que uno que falla dentro de un intento ruidoso contra un entorno monitorizado. No ignores la longitud. Los fallos de tamaño se camuflan bien: el payload sigue pareciendo shellcode, solo que ya no cabe en la primitiva disponible.
Qué deberían ver los defensores
Desde defensa, el generador rara vez es la señal importante. Lo es el comportamiento. Busca egress inesperado, genealogías raras de procesos, transiciones a memoria ejecutable, buffers de tamaño payload y crashes repetidos cerca del mismo offset.
Notas de runbook
Guarda la configuración separada de los bytes crudos cuando la política lo exija, pero conserva detalle suficiente para regenerar exactamente. Un runbook útil incluye referencia de alcance, contexto del objetivo, restricciones, hash y una nota corta sobre por qué se eligió esa familia de payload. Sin magia. Solo menos sitios donde esconder errores.