Generación de shellcode en cliente: threat model sin marketing
Qué queda local en un builder de navegador, qué sigue filtrándose y cómo operar pruebas autorizadas con menos residuos.
generación local en navegador, límites de WASM, riesgo del portapapeles, perfiles separados y evidencia de auditoría 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 pensar que client-side significa cero fugas cuando todavía existen extensiones, agentes endpoint y capturas. 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.
shasum -a 256 payload.bin
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 bytes de payload en logs compartidos, hashes incoherentes en retest o una buena arquitectura arruinada por malos hábitos. 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.