Repositorios Next.js maliciosos roban variables de entorno

Introducción: por qué esto importa

Las estaciones de trabajo de desarrollo y los entornos de compilación son objetivos de alto valor porque a menudo contienen código fuente, material de firma y secretos (tokens de API, credenciales de nube) en variables de entorno. Microsoft Defender Experts informa sobre una campaña que siembra repositorios Next.js maliciosos —con frecuencia presentados como evaluaciones “para llevar” relacionadas con empleo— diseñados para mezclarse con flujos normales de trabajo de desarrolladores y activar de forma confiable la ejecución de código.

Qué hay de nuevo / hallazgos clave

Microsoft observó múltiples repositorios relacionados con convenciones de nombres compartidas y lógica de cargador reutilizada. Aunque el señuelo inicial varía, el estado final es consistente: recuperación en tiempo de ejecución y ejecución en memoria de JavaScript controlado por el atacante, seguida de C2 por etapas.

1) Ejecución del workspace de VS Code al abrir la carpeta

Algunos repos incluyen .vscode/tasks.json configurado con runOn: "folderOpen". Si un desarrollador abre (y confía) el proyecto, una tarea se ejecuta automáticamente e inicia un script de Node que obtiene un cargador JavaScript (observado en etapas alojadas en Vercel) y lo ejecuta.

2) Ejecución en tiempo de compilación al ejecutar la app

Otras variantes se activan cuando un desarrollador inicia el proyecto (por ejemplo, npm run dev). Estos repos integran lógica maliciosa en recursos aparentemente normales (p. ej., un jquery.min.js troyanizado). El recurso decodifica una URL en base64, recupera el cargador (de nuevo, con frecuencia desde Vercel) y lo ejecuta en memoria.

3) Ejecución al inicio del backend con exfiltración de env + RCE dinámica

Una tercera vía se activa durante la inicialización del servidor/importación de módulos. Los repos pueden contener un valor .env como AUTH_API=<base64>. En el arranque, el código del backend decodifica el endpoint, envía process.env al atacante y luego ejecuta el JavaScript devuelto usando compilación dinámica (por ejemplo, new Function("require", response.data)(require)). Esto puede filtrar configuración sensible y habilita la entrega de payloads posteriores dirigida por el operador.

Registro de etapa 1 → command-and-control por etapas

En todas las vías, la ejecución converge en una etapa inicial de “registrador” que perfila el host y consulta un endpoint de registro, recibiendo un instanceId para correlacionar actividad posterior. La telemetría también observó callbacks persistentes a infraestructura controlada por el atacante (incluido tráfico HTTP en el puerto 300) después del staging inicial.

Impacto para administradores de TI y equipos de seguridad

• Mayor riesgo en endpoints de desarrolladores: Abrir un repo puede ser suficiente para ejecutar código si se confían las tareas del workspace.
• Exposición de credenciales: La vía de inicio del backend puede exfiltrar variables de entorno (claves de nube, credenciales de base de datos, tokens de CI).
• Detección más difícil: La ejecución en memoria y los cargadores por etapas pueden reducir artefactos evidentes en disco.

Acciones / próximos pasos

• Guía para desarrolladores: Trate las evaluaciones para llevar y los repos desconocidos como no confiables; evite hacer clic en “Trust” en VS Code hasta revisarlos.
• Inspección de repos: Señalice/inspeccione .vscode/tasks.json (especialmente runOn: "folderOpen"), scripts de Node inesperados bajo .vscode/, y librerías minificadas que no coincidan con hashes conocidos como válidos.
• Higiene de secretos: Reduzca la dependencia de secretos de larga duración en .env; use identidades administradas/tokens de corta duración cuando sea posible y rote cualquier credencial expuesta.
• Detección y controles: Monitoree procesos de Node.js en busca de conexiones salientes inusuales (p. ej., herramientas de desarrollo llamando a dominios de staging seguidos de C2 desconocido), y considere restricciones de egreso desde dispositivos de desarrolladores y agentes de build.
• Hunting: Busque en hosting de código y espejos internos “familias” de nombres y patrones de reutilización estructural descritos por Microsoft (repos casi duplicados, cargadores similares, endpoints de staging repetidos).