Una campaña de ataque coordinada está dirigiendo activamente sus esfuerzos hacia desarrolladores de software mediante repositorios maliciosos disfrazados de proyectos legítimos de Next.js y materiales de evaluación técnica. Los atacantes utilizan señuelos con temática laboral, presentando desafíos de reclutamiento falsos que convencen a los desarrolladores de clonar y ejecutar código envenenado en sus propias máquinas. Una vez que un desarrollador ejecuta el proyecto, este se conecta silenciosamente a servidores controlados por los atacantes.

Una campaña de ataques coordinados está dirigiendo activamente sus esfuerzos hacia desarrolladores de software mediante repositorios maliciosos disfrazados de proyectos legítimos de Next.js y materiales de evaluación técnica.

Los atacantes utilizan señuelos con temática laboral, presentando desafíos falsos de reclutamiento que convencen a los desarrolladores de clonar y ejecutar código envenenado en sus propias máquinas.

Una vez que un desarrollador ejecuta el proyecto, este se conecta silenciosamente a una infraestructura de comando y control (C2) controlada por los atacantes, otorgando a los hackers acceso remoto al sistema del desarrollador junto con cualquier dato sensible almacenado en él.

La campaña fue detectada por primera vez a través de conexiones de red salientes sospechosas originadas en procesos de Node.js en máquinas de desarrolladores afectadas.

Estos procesos intentaban repetidamente conectarse a direcciones IP conocidas de C2, lo que llevó a una revisión más profunda de las cadenas de ejecución detrás de esas conexiones.

Al correlacionar la actividad de red con la telemetría de procesos, los analistas rastrearon la ejecución de Node.js hasta repositorios maliciosos, incluyendo uno alojado en Bitbucket presentado como una evaluación técnica con temática de reclutamiento y otro que utilizaba la convención de nombres “Cryptan-Platform-MVP1”.

Los expertos de Microsoft Defender y el Equipo de Investigación de Seguridad de Microsoft Defender identificaron un grupo más amplio de repositorios relacionados al analizar la estructura compartida del código, la lógica del cargador y los patrones de nombres.

Familias de repositorios como “Cryptan”, “JP-soccer”, “RoyalJapan” y “SettleMint” contenían variantes casi idénticas etiquetadas como v1, master, demo, platform y server.

Esta estructura consistente ayudó a los analistas a descubrir repositorios adicionales que no aparecían en la telemetría observada, pero que exhibían la misma lógica de ejecución e infraestructura de preparación.

La escala de esta campaña la hace particularmente peligrosa para equipos de desarrollo que operan en entornos corporativos.

Las máquinas de los desarrolladores suelen tener acceso a activos de alto valor, como código fuente, secretos de entorno, claves API en la nube, credenciales de bases de datos y pipelines de compilación.

Cuando se ejecuta código no confiable en un dispositivo corporativo, un solo compromiso puede extenderse rápidamente más allá de un endpoint y potencialmente exponer toda la infraestructura de una organización.

Esta campaña refleja un cambio calculado en cómo los atacantes abordan las amenazas a la cadena de suministro de software.

Al incrustar comportamiento malicioso dentro de lo que parece ser un proyecto normal, los hackers pueden lograr una ejecución de código confiable mientras se mezclan con los flujos de trabajo habituales de los desarrolladores, convirtiéndola en una amenaza significativa para equipos de desarrollo en todo el mundo.

Tres puntos de entrada, un mismo backdoor compartido

Los tres caminos de ejecución en esta campaña conducen al mismo resultado: la recuperación en tiempo de ejecución y la ejecución en memoria de JavaScript controlado por el atacante.

El primer camino abusa de la automatización de espacios de trabajo de Visual Studio Code. Cuando un desarrollador abre y confía en una carpeta de proyecto, el archivo .vscode/tasks.json está preconfigurado con runOn: "folderOpen,", lo que desencadena inmediatamente un script de Node.js que descarga un cargador JavaScript desde un endpoint de preparación alojado en Vercel.

Tras la ejecución, el script comienza a enviar señales a la infraestructura controlada por el atacante.

El segundo camino se activa cuando un desarrollador inicia el servidor de desarrollo usando npm run dev. Activos troyanizados, como un jquery.min.js modificado, decodifican una URL codificada en base64 y recuperan el mismo cargador JavaScript desde Vercel.

El tercer camino se activa al iniciar el servidor, donde rutas maliciosas del backend decodifican un endpoint oculto en base64 desde un archivo .env, transmiten todo el entorno del proceso —incluyendo claves API en la nube y tokens de acceso— al atacante, y ejecutan JavaScript proporcionado por el atacante mediante compilación dinámica.

Una vez que se activa cualquiera de estos caminos, una carga útil ligera de Etapa 1 perfila el host y comienza a sondear el servidor C2 a intervalos fijos.

Luego, la Etapa 2 toma el control, proporcionando tareas persistentes impulsadas por el operador, navegación de directorios, recolección de archivos sensibles y subidas escalonadas de datos robados a la infraestructura del atacante.

Los desarrolladores deberían habilitar el Modo de Confianza de Espacios de Trabajo y el Modo Restringido en Visual Studio Code para bloquear la ejecución automática de código en carpetas desconocidas.

Las organizaciones deberían aplicar reglas de reducción de la superficie de ataque para evitar la ejecución de scripts ofuscados, reforzar la autenticación y el acceso condicional para cuentas de desarrolladores, y evitar almacenar credenciales de producción en máquinas de desarrollo.

Los equipos de seguridad deberían monitorear conexiones salientes inusuales de Node.js utilizando consultas de búsqueda como DeviceNetworkEvents y DeviceProcessEvents, y realizar una evaluación de riesgos de identidad cada vez que se sospeche de un compromiso en un endpoint de desarrollador.