El repositorio venía con regalo: phishing con hooks de git

El viernes apareció en Lobsters un relato que debieras leer obligatorio si trabajas con código: a Frank Wiles lo intentaron hackear con un phishing tan bien armado que casi pasa como proyecto freelance normal. Una consulta de trabajo, una supuesta NDA, un enlace a Dropbox con el spec del proyecto en Markdown. Todo creíble. El detalle: el Dropbox incluía la carpeta .git completa.

Por qué un hook de git es el caballo de Troya perfecto

Los hooks de git son scripts que viven en .git/hooks/ y se ejecutan solos en momentos determinados: antes de un commit, después de un checkout, al hacer push. Lo primero que todos aprendemos es que no se versionan ni se suben al remoto, así que uno asume que son cosa propia y de confianza. Esa suposición es justo lo que explotaron.

El gancho: en el Dropbox venía un post-checkout real entre todos los archivos .example. Si la víctima hacía checkout hacia la supuesta «rama de la NDA», el script se disparaba: descargaba un binario desde una app legítima en Vercel (usada como C2), lo ejecutaba y se borraba. Limpio, silencioso y con la cara de que un checkout de git es la operación más banal del mundo. Además sabían a quién apuntar: Wiles tiene acceso a repos de muchos clientes de su consultora, o sea, el objetivo era llave maestra, no una laptop cualquiera.

Lo que más me llama la atención es la industria que implica esto. Ya no es el ZIP con un .exe garabateado; es un atacante que estudió el flujo de trabajo de un desarrollador, suplantó a una agencia real, montó infraestructura en un PaaS conocido y ensambló cada paso para que cayera dentro de una reunión con Calendly. Eso es paciencia de gente que sabe cómo trabajamos.

Lo que haría yo con esto

Primero: desconfía de cualquier repo que llegue por fuera de tu remoto normal. Un Dropbox, un zip, un USB, un «te lo paso aquí». Si la carpeta .git viene incluida y no es la tuya, revisa .git/hooks/ antes del primer checkout. Un ls -la de dos segundos, porque los archivos .example son cortina de humo perfecta: uno espera ver basura ahí.

Segundo: audita los hooks existentes en las máquinas donde vives. Si tienes scripts de despliegue que hacen git pull o cambian de rama en servidores, un post-checkout malicioso ahí es juego terminado. Yo mantengo un listado de los hooks legítimos en mi infraestructura; si aparece uno que no reconozco, alarma.

Tercero: git moderno ya bloquea hooks que llegan en clones y no se propagan por push, precisamente por ataques como este. Pero ningún parche te salva si el paquete llegó por Dropbox de mano en mano. La defensa no es técnica, es de flujo: el código entra a tu máquina solo por el camino que tú controlas.

Y una lección para quien vende seguridad o administre servidores de terceros: estos ataques van por el eslabón donde menos lo esperas, no por el CVE de moda. La NDA falsa es el nuevo PDF malicioso. Cachai qué es lo más incómodo: el ataque funcionó igual contra un experto, que solo lo detectó porque prestó atención al detalle de «la NDA está en una rama». Un guiño al azar separó esto de una cuenta comprometida.

Revisa tus hooks hoy. Toma dos minutos y puede ahorrarte semanas de forense.

Fuente: I got targeted, de Frank Wiles.

Fuente de inspiración: I got targeted