La campaña que transforma pruebas técnicas en puertas traseras y ejecuta código en memoria en entornos de desarrollo

Los desarrolladores se han convertido en un blanco estratégico para actores maliciosos que buscan no solo robar credenciales, sino plantar accesos persistentes en máquinas con información sensible. Un informe reciente de Microsoft describe una campaña coordinada que aprovecha proyectos o pruebas técnicas falsas —principalmente fingiendo ser proyectos Next.js o ejercicios de entrevista— para inducir a los desarrolladores a ejecutar código que luego carga y ejecuta scripts controlados por los atacantes. El objetivo final es muy claro: conseguir ejecución remota de código en memoria y, desde ahí, expandir control sin dejar rastros en disco. Puedes leer el análisis de Microsoft aquí: Microsoft Defender Security Research.

La amenaza se vale de la confianza que los equipos de desarrollo depositan en las herramientas y flujos cotidianos. Tres caminos de ejecución, distintos en su activador pero convergentes en su resultado, fueron descritos por los investigadores. En el primero, un archivo de configuración de Visual Studio Code aprovecha la automatización del workspace para invocar tareas al abrir la carpeta del proyecto; la configuración usa un trigger que ejecuta comandos remotos al confiar el proyecto, lo que permite descargar un cargador alojado en plataformas públicas y ejecutarlo en caliente.

El segundo vector es el que ocurre durante el desarrollo: basta con lanzar el servidor con el clásico comando de desarrollo —por ejemplo, npm run dev— para activar código oculto en bibliotecas JavaScript modificadas que aparentan ser dependencias inofensivas, como un fichero minificado de jQuery. Ese código malicioso descarga un loader desde un dominio de staging (con frecuencia Vercel) que, posteriormente, ejecuta instrucciones directamente en el proceso de Node.js.

El tercer método se dispara al iniciar el backend de la aplicación: módulos o rutas aparentemente legítimos pueden contener lógica que, al arrancar, envía el entorno del proceso (variables de entorno, por ejemplo) a un servidor externo y ejecuta la respuesta JavaScript en memoria. En todos los casos la misma carga útil JavaScript realiza un perfilado de la máquina y contacta periódicamente un endpoint de registro para obtener un identificador único (“instanceId”) que sirve para correlacionar y gestionar la sesión.

La importancia técnica de ejecutar código en memoria es que reduce la huella forense en disco y facilita la entrega de una segunda etapa que actúe como controlador: un “stage 2” capaz de ejecutar tareas a demanda, descubrir activos en el entorno y exfiltrar información. Microsoft subraya que el controlador incorpora telemetría de errores, lógica de reintento y capacidad para gestionar procesos hijos —es decir, se comporta como una herramienta de acceso remoto bien diseñada—. Más detalles en el informe original de Microsoft: informe técnico.

No es solo Vercel: los atacantes también han empezado a usar servidores de etapa alternativos para alojar etapas posteriores. Abstract Security ha documentado un cambio en las tácticas hacia el uso de gists de GitHub y acortadores de URL para esconder la verdadera procedencia de los payloads. Además identificaron un paquete npm malicioso llamado “eslint-validator” que recupera un payload ofuscado desde Google Drive: ese payload coincide con una familia de malware JavaScript conocida como BeaverTail.

En Windows se observaron cadenas de infección aún más elaboradas: una tarea de VS Code puede lanzar un script por lotes que descarga Node.js si no está presente, utiliza utilidades nativas como certutil para decodificar bloques de código embebidos y, con el runtime de Node, despliega un malware en Python protegido con PyArmor. Otros análisis apuntan a técnicas creativas de resiliencia: inyectar código dentro de contratos NFT en blockchains como Polygon para que el payload se recupere desde ahí, dificultando su retirada y aumentando su disponibilidad.

Investigadores independientes como Red Asgard han seguido esta actividad y la vinculan con tácticas usadas en campañas anteriores conocidas por su sofisticación. Mientras que Microsoft evita atribuir la campaña a un actor concreto, los patrones coinciden con una familia de operaciones que en el pasado han estado relacionadas con grupos norcoreanos bajo la etiqueta “Contagious Interview” en algunos informes públicos.

Plataformas de colaboración y repositorios públicos no han sido inmunes: GitLab informó la eliminación de más de un centenar de cuentas responsables de distribuir proyectos maliciosos conectados a esta campaña. Su equipo de inteligencia también encontró evidencias internas que apuntan a una estructura organizada detrás de estas operaciones, con registros financieros y control de rendimiento de equipos, lo que sugiere una actividad sostenida y orientada a beneficio económico. Más contexto en el análisis de GitLab: GitLab Threat Intelligence.

Para quienes trabajan en desarrollo, esto debería sonar la alarma: los repositorios de “prueba técnica” o plantillas de entrevista son vectores ideales porque encajan con tareas diarias. Ejecutar un servidor local, abrir un workspace o confiar en un proyecto por defecto puede ser suficiente para desencadenar una cadena de ejecución maliciosa. Herramientas y servicios legítimos que hospedan contenidos externos (Vercel, Render, Railway, JSON Keeper, npoint.io, entre otros) han sido reutilizados por los atacantes para almacenar y servir payloads.

Las recomendaciones prácticas no son radicales, pero sí requieren disciplina: limitar privilegios de cuentas de desarrollo, segregar entornos de build y CI/CD del equipo de desarrollo, aplicar autenticación fuerte y acceso condicional, y filtrar o auditar las tareas y automatizaciones incluidas en los proyectos antes de ejecutarlas. También conviene escanear dependencias, evitar ejecutar scripts de terceros sin revisión y no confiar automáticamente en prompts de confianza de VS Code ni en tareas con runOn configurado para abrir carpetas.

Además, empresas y responsables de seguridad deberían instrumentar detección para procesos Node.js que descargan y evalúan JavaScript en memoria, monitorizar conexiones salientes hacia servicios de hosting públicos y usar listas blancas donde sea posible. Proveedores de repositorios y plataformas ya están tomando medidas: la eliminación de cuentas y la coordinación entre equipos de seguridad es parte de la respuesta. Para entender la dimensión humana del problema y cómo el “empleo” es explotado como cebo, el informe de Okta ofrece una perspectiva interesante sobre cómo algunos candidatos falsos pasan controles y son usados en estos esquemas: Análisis de Okta.

El mensaje para la comunidad técnica es sencillo y urgente: no bajen la guardia. La combinación de ingeniería social con la automatización de flujos de desarrollo convierte un proyecto Git aparentemente inocuo en una puerta trasera efectiva. Revisar tasks.json, auditar dependencias y tratar con sospecha cualquier proyecto que solicite ejecutar comandos automáticos al abrirse son medidas que pueden detener estas cadenas antes de que ejecuten su primer payload en memoria.

Esta campaña es un recordatorio de que la seguridad del desarrollo debe incluir controles específicos para los flujos y herramientas del día a día. No se trata únicamente de proteger servidores en producción: proteger el “cliente” —el equipo del desarrollador— es igual de crítico cuando ese cliente contiene llaves, tokens y acceso a infraestructura que puede pivotarse en segundos. Mantener buenas prácticas de higiene de credenciales, segmentación y revisión de código es hoy una defensa imprescindible.