El desarrollador Roman Imankulov evitó un ataque de ingeniería social tras recibir una oferta de trabajo falsa por LinkedIn. El código que debía revisar contenía una puerta trasera diseñada para ejecutarse automáticamente mediante npm install. Gracias a su intuición y al uso de un agente de IA para analizar el repositorio en un entorno aislado, logró detectar la vulnerabilidad antes de comprometer su equipo.

El desarrollador de Python Roman Imankulov estuvo a punto de morder el anzuelo. El hecho de que no lo hiciera puede atribuirse a la intuición humana y a la revisión de código mediante IA.

Una persona que decía ser reclutadora de una pequeña startup de criptomonedas se puso en contacto con él a través de LinkedIn, buscando ayuda con lo que describió como un código de prueba de concepto que no funcionaba. La empresa, explicó, necesitaba un ingeniero principal.

Según describió Imankulov el intercambio en una publicación de blog [https://roman.pt/posts/linkedin-backdoor/], la reclutadora le pidió que investigara un problema con un módulo de Node obsoleto. Algo en la solicitud parecía extraño.

"Había oído, como probablemente todos nosotros, sobre este tipo de ataques", explicó Imankulov en una entrevista telefónica. "Y pensé: '¿y si yo pudiera ser el objetivo?'. Se basó simplemente en la experiencia previa que tenía".

Así que tomó la medida inusual de levantar un VPS en Hetzner donde clonó el repositorio. Luego utilizó su agente de programación Pi (que ejecuta Codex) para realizar un análisis de solo lectura del código.

"Ejecuté un agente para probar cómo funcionaba, y estaba casi seguro de que me respondería 'todo está claro, el código es feo pero en general es seguro de ejecutar y simplemente proceda con su revisión'", explicó. "Para mi sorpresa, casi inmediatamente el agente devolvió una respuesta como: 'No ejecute este código, simplemente aléjese porque hay una trampa'".

El modelo de IA había marcado uno de los archivos, app/test/index.js.

El archivo contenía una puerta trasera (backdoor). Se presentaba en forma de una URL de servidor, fragmentada para parecer la configuración de una suite de pruebas, y una solicitud de red que ejecutaría cualquier cosa que el servidor enviara en respuesta.

Imankulov acreditó a su agente de IA la detección de detalles que él había pasado por alto.

"Abrí este código yo mismo, lo recorrí superficialmente y me pareció simplemente un archivo descuidado escrito por un desarrollador descuidado", dijo. "Así que bajé la página, [pensando] 'Sí, sí, es horrible, pero si me pueden pagar para arreglar este código, no me importa'. Pero el agente, en el mismo archivo, encontró la vulnerabilidad exacta que yo pasé por alto".

El simple hecho de instalar el repositorio usando npm habría sido suficiente para activar la puerta trasera. El archivo package.json del repositorio contenía un gancho (hook) de post-instalación "prepare" [https://docs.npmjs.com/cli/v8/using-npm/scripts#life-cycle-scripts] diseñado para ejecutar el script tras el proceso de instalación.

El repositorio malicioso referenciado ya no es accesible —presumiblemente GitHub lo eliminó en respuesta a la denuncia de Imankulov— pero todavía se puede encontrar un clon [https://github.com/bitcoin2026a/coin-promoting/blob/main/app/test/index.js].

"Lo que hace que este ataque sea insidioso es cómo secuestra los flujos de trabajo estándar de los desarrolladores", explicó Devashri Datta, arquitecta independiente de seguridad y código abierto, en un correo electrónico. "El adversario no confió en que el objetivo ejecutara un binario sospechoso; confió en que el objetivo ejecutara un comando rutinario: npm install.

"Al enterrar la lógica de ejecución dentro del gancho de ciclo de vida 'prepare' en package.json, la carga maliciosa se activa automáticamente durante la resolución de dependencias. Esta no es una técnica novedosa, pero sigue siendo muy efectiva precisamente porque los desarrolladores ejecutan npm install en piloto automático. La fragmentación de cadenas utilizada para ensamblar la URL maliciosa, uniendo un dominio a partir de pequeñas constantes, fue una ofuscación deliberada diseñada para vencer las herramientas de análisis estático que buscan indicadores de compromiso codificados".

Imankulov dijo que los commits en el repositorio malicioso parecían ser el trabajo de un desarrollador con una presencia web y trayectoria establecidas. Pero cuando contactó al supuesto autor, el desarrollador dijo que habían suplantado su identidad en GitHub más de una vez y que él no escribió ese código.

El perfil de LinkedIn de la reclutadora hacía referencia a un periodista de arte real, aunque Imankulov cree que el perfil asociado era falso. Sus interacciones en línea con la reclutadora sugerían un nivel de conocimiento técnico que no era evidente en su historial laboral.

LinkedIn suele hablar de los decenas de millones de cuentas falsas que detecta y elimina antes de que interactúen con alguien. Pero cientos de miles de cuentas siguen creándose e interactuando con personas antes de ser detectadas. Y esa cifra sigue creciendo. En el periodo de enero a junio de 2025 [https://about.linkedin.com/transparency/community-report#fake-accounts-2025-jan-jun], LinkedIn restringió 386,000 cuentas tras reportes de usuarios. Esa cifra fue de 266,000 en el periodo anterior de seis meses, y de apenas 86,000 entre enero y junio de 2021.

Este tipo de ataques de ingeniería social en la cadena de suministro de software se han vuelto habituales. A principios de este mes, se observó cómo estafadores vinculados a Corea del Norte han estado ejecutando diversas campañas para comprometer cuentas de desarrolladores mediante entrevistas y ofertas de trabajo falsas.

Otros desarrolladores han informado [https://youtu.be/VA7PsdI0zs8] haber estado a punto de caer en estas estafas (y también haber sido salvados por su agente de IA [https://www.reddit.com/r/openclaw/comments/1rlet0h/someone_tried_to_social_engineer_me_via_linkedin/]) y han publicado análisis de código [https://gist.github.com/vnovick/86dc0af8ffcb39260b7d9d01278a6263] [https://gist.github.com/adibhanna/6c66552b94577951bc4cce877fcf7729].

Datta afirmó que la respuesta de Imankulov resalta un cambio en la forma en que los desarrolladores conscientes de la seguridad abordan la higiene de la revisión de código.

"Históricamente, la guía era aislar el código no confiable en un sandbox o revisarlo manualmente", dijo. "Aquí, Roman desplegó un agente de IA local en un entorno restringido de solo lectura para analizar la base de código antes de ejecutar cualquier cosa. Este es un contrapunto útil a la narrativa dominante sobre la IA como vector de amenaza ofensiva. Utilizado defensivamente en el punto final del desarrollador, un agente de IA no es susceptible a la fatiga o la presión social; simplemente detecta comportamientos anómalos, como una suite de pruebas iniciando una conexión de red saliente para recuperar código no verificado, en segundos".

npm 12 podría cambiar el juego

Si sirve de consuelo, el vector de ataque relevante debería abordarse el próximo mes.

GitHub, que mantiene npm, se prepara para lanzar npm 12, que cambia el comportamiento [https://github.blog/changelog/2026-06-09-upcoming-breaking-changes-for-npm-v12/] del comando npm install. La configuración allowScripts estará desactivada por defecto. "npm install ya no ejecutará scripts de preinstall, install o postinstall de las dependencias a menos que se permitan explícitamente en su proyecto", explica GitHub.

"Los scripts de ciclo de vida en el momento de la instalación son la superficie de ejecución de código más grande en el ecosistema npm", explicó el gerente de producto de GitHub, Leo Balter, en una publicación de discusión comunitaria [https://github.com/orgs/community/discussions/198547] la semana pasada. "Cada npm install ejecuta scripts de cada dependencia transitiva, por lo que un único paquete comprometido en cualquier lugar de su árbol puede ejecutar código arbitrario en la máquina de un desarrollador o en un ejecutor de CI. Hacer que la ejecución de scripts sea opcional cierra esa vía".

Imankulov dijo que no tiene una opinión fuerte al respecto. "Desde mi perspectiva, solo por razones de seguridad personal, me cambié a pnpm [https://pnpm.io] solo para asegurarme de que no ejecuto esos scripts por defecto", afirmó.

Datta señaló que el incidente subraya por qué la seguridad de la cadena de suministro de software empresarial debe extenderse más allá del perímetro de la red corporativa.

"Los atacantes ahora se están desplazando hacia la izquierda, llegando hasta los puntos finales individuales de ingeniería antes de que una sola línea de código entre en la cadena de suministro corporativa", dijo. "Cuando la estación de trabajo local de un desarrollador se ve comprometida durante lo que parece ser una entrevista de trabajo rutinaria, esa máquina frecuentemente posee claves SSH activas, tokens de proveedores de nube y acceso en vivo a repositorios internos".

Una defensa adecuada, sostiene Datta, requiere la aplicación de barreras técnicas como contenedores de desarrolladores aislados o estaciones de trabajo en la nube seguras para evaluar código de terceros o no confiable.

"Los marcos emergentes están comenzando a extender el contexto de explotabilidad hasta la propia capa de la estación de trabajo, reconociendo que la señal estilo VEX necesita viajar más a la izquierda que el inventario SBOM empresarial si se quiere interceptar las amenazas en el punto de introducción", concluyó.

Fuente:
TheRegister