Contagious Interview: así se cuela un backdoor a través de proyectos maliciosos en VS Code

Última actualización: enero 22, 2026
  • Amenaza vinculada a actores norcoreanos que usan VS Code como vector de infección
  • Repositorios en GitHub, GitLab o Bitbucket se disfrazan de pruebas técnicas para entregar backdoors
  • El ataque abusa de tasks.json y JavaScript ofuscado alojado en dominios legítimos como Vercel
  • Objetivo prioritario: desarrolladores de cripto, blockchain y fintech con acceso privilegiado a activos digitales

Ataque Contagious Interview a traves de VS Code

La campaña de ciberespionaje conocida como Contagious Interview ha dado un nuevo giro preocupante al aprovechar proyectos de Microsoft Visual Studio Code (VS Code) manipulados como gancho para colar un backdoor en los equipos de las víctimas. La estrategia se integra de forma casi natural en el flujo de trabajo habitual de desarrolladores, lo que la hace especialmente peligrosa en entornos técnicos europeos y españoles donde este editor es ampliamente usado.

Investigaciones recientes de laboratorios de análisis de malware han constatado que estos actores, vinculados a la República Popular Democrática de Corea (DPRK), están refinando de forma constante sus métodos. Lejos de ser una campaña puntual, se trata de una operación en evolución que explota tanto la confianza en las plataformas de código como la rutina de las pruebas técnicas en procesos de selección.

Cómo funciona el señuelo: falsas pruebas técnicas en GitHub, GitLab o Bitbucket

Según los análisis publicados por firmas especializadas como Jamf Threat Labs, el ataque arranca con una supuesta oferta de trabajo o prueba técnica dirigida a desarrolladores, muchas veces a través de plataformas profesionales o contactos directos. A la víctima se le pide clonar un repositorio alojado en GitHub, GitLab o Bitbucket y abrirlo con VS Code como parte de un ejercicio práctico.

El repositorio contiene una estructura aparentemente legítima de proyecto, pero incluye una configuración de tareas de VS Code cuidadosamente preparada. El fichero tasks.json se ajusta para que determinadas tareas se ejecuten automáticamente cada vez que se abre el proyecto o cualquiera de sus archivos, utilizando la opción «runOn»: «folderOpen». Esto significa que basta con abrir la carpeta en VS Code para activar el código malicioso sin que el usuario ejecute nada explícitamente.

Una vez abierto el proyecto, VS Code muestra su habitual aviso pidiendo al usuario que confíe en el autor del repositorio. Si la persona acepta, el editor procesa automáticamente la configuración definida en tasks.json. En ese momento se pueden lanzar comandos arbitrarios en el sistema, algo que los atacantes aprovechan para iniciar la cadena de infección sin levantar sospechas.

Este modelo encaja perfectamente con procesos de selección reales, en los que es frecuente recibir enlaces a repositorios de prueba y que recuerda casos de ataques de cadena de suministro en GitHub. Por eso, la campaña tiene especial impacto en perfiles técnicos europeos, particularmente en compañías de criptomonedas, blockchain y fintech, donde las pruebas de código remoto son habituales.

Abuso de VS Code tasks y Vercel para ejecutar JavaScript malicioso

El núcleo de la técnica pasa por explotar el sistema de tareas de Visual Studio Code. La configuración de tasks.json está preparada para ejecutar comandos de fondo que descargan y lanzan payloads JavaScript alojados en infraestructuras legítimas como Vercel. Esta elección complica notablemente la detección por parte de soluciones de seguridad tradicionales.

En sistemas macOS, por ejemplo, se observa la ejecución de un comando de shell en segundo plano que combina nohup bash -c con curl -s. El objetivo es recuperar un archivo JavaScript remoto y canalizarlo directamente hacia el runtime de Node.js, sin dejar rastro visible en pantalla y permitiendo que la ejecución continúe incluso si se cierra VS Code.

Ese primer JavaScript alojado en dominios de Vercel contiene la lógica principal del backdoor, que establece un bucle de ejecución persistente. Entre sus funciones se incluye la recopilación de información básica del host, la comunicación periódica con un servidor de mando y control y la capacidad de ejecutar código remoto, lo que en la práctica otorga control total sobre el sistema comprometido.

Además, se ha observado que el código JavaScript descargado puede ir variando a lo largo del tiempo. En un caso estudiado, se ejecutaron nuevas instrucciones aproximadamente ocho minutos después de la infección inicial. Este segundo módulo se encarga de balizar al servidor cada pocos segundos, ejecutar JavaScript adicional y borrar evidencias cuando el operador así lo ordena, reforzando la dificultad de análisis forense.

Dictionaries falsos y droppers en varias fases como plan de respaldo

Las evoluciones más recientes de Contagious Interview muestran un nivel añadido de sofisticación mediante el uso de droppers multinivel ocultos en los ficheros de configuración de tareas. Para evitar que el ataque fracase si falla la descarga desde Vercel, algunos componentes se disfrazan de diccionarios de corrección ortográfica aparentemente inocuos.

Dentro de estos supuestos diccionarios se oculta código JavaScript ofuscado que se activa en cuanto la víctima abre el proyecto en el entorno de desarrollo. Una vez en marcha, establece comunicación con un servidor remoto, por ejemplo en dominios del tipo ip-regions-check.vercel.app, desde donde recibe y ejecuta instrucciones JavaScript adicionales que forman nuevas etapas del ataque.

La última fase suele consistir en otro bloque de JavaScript fuertemente ofuscado que implementa funciones avanzadas de control remoto. Este diseño en capas, con varios niveles de descarga y ejecución, reduce la huella inicial en el repositorio y permite a los atacantes actualizar componentes sobre la marcha sin necesidad de modificar el proyecto original que ve el desarrollador.

En algunos análisis se ha sugerido que ciertos fragmentos de este código podrían haber sido generados con asistencia de herramientas de IA, debido a la presencia de comentarios en línea y estilos de redacción poco habituales en malware escrito a mano. Esto encaja con una tendencia más amplia: el uso de inteligencia artificial para acelerar el desarrollo y la mutación de familias de malware.

BeaverTail, InvisibleFerret y otros componentes del arsenal

La campaña no se limita a un único backdoor. Entre las cargas útiles identificadas se encuentran módulos con nombres en clave como BeaverTail y InvisibleFerret, que corresponden a distintas capas tecnológicas del ataque y se complementan entre sí en la fase de explotación.

BeaverTail suele asociarse con la parte basada en Node.js, capaz de ejecutar comandos, mantener una conexión persistente con los servidores de los atacantes y orquestar el resto de la infección. Esta pieza actúa como controlador central, permitiendo, por ejemplo, desplegar nuevas funciones según las necesidades de la operación o del entorno comprometido.

InvisibleFerret, por su parte, se relaciona con una capa adicional en Python, que se instala en paralelo a través de scripts «stager». Este entorno secundario habilita capacidades de recolección de datos más amplias, minería de criptomonedas mediante herramientas como XMRig, registro de pulsaciones de teclas y la posible instalación de software de acceso remoto como AnyDesk.

Los analistas han documentado, además, otros backdoors integrados en campañas similares, como el caso de Tsunami o TsunamiKit, un backdoor de gran alcance que también puede instalar un minero de criptomonedas XMRig. Aunque no siempre forma parte de la misma cadena de Contagious Interview, ilustra la tendencia de combinar acceso remoto, robo de información y monetización mediante minería ilícita.

Este enfoque modular, con capas en JavaScript y Python que se refuerzan mutuamente, subraya la intención de los atacantes de asegurar persistencia, redundancia y múltiples vías de explotación del sistema víctima, tanto para fines de espionaje como para beneficio económico.

Ingeniería social: del contacto en LinkedIn al repositorio malicioso

Otra pieza clave de esta campaña es la ingeniería social. En más de un incidente se ha observado cómo los atacantes se hacen pasar por responsables técnicos o directivos de proyectos tecnológicos, contactando a desarrolladores a través de plataformas profesionales como LinkedIn.

Un caso documentado describe cómo un supuesto director de tecnología de un proyecto llamado «Meta2140» contactó a una víctima, compartiendo un enlace a un documento en Notion con los detalles de una prueba técnica. En ese mismo documento se incluía la URL a un repositorio de Bitbucket que, en realidad, albergaba el código malicioso y la configuración de tareas manipulada.

El diseño de la prueba resulta convincente: el repositorio tiene apariencia legítima, el contenido del documento parece una evaluación técnica auténtica y todo el flujo de comunicación imita procesos habituales de selección internacional, especialmente en el ecosistema de startups tecnológicas y cripto muy presente en Europa.

En paralelo, los atacantes han desplegado mecanismos de reserva para mantener la infección incluso si una de las vías falla. Por ejemplo, se ha observado la instalación de dependencias npm maliciosas como el paquete «grayavatar» o la ejecución de JavaScript diseñado para descargar un controlador Node.js sofisticado, capaz de acciones como registrar pulsaciones de teclado, tomar capturas de pantalla o monitorizar el directorio de inicio en busca de archivos sensibles.

Este controlador, organizado en varios módulos, puede también sustituir direcciones de monedero copiadas al portapapeles, robar credenciales almacenadas en navegadores y mantener un canal de comunicación permanente con servidores remotos. El conjunto convierte la máquina de la víctima en un activo completamente controlable por los operadores de la campaña.

Objetivos prioritarios: desarrolladores con acceso a cripto y activos sensibles

Los grupos de amenazas relacionados con DPRK llevan años centrando sus esfuerzos en el ecosistema de criptomonedas, blockchain y servicios financieros digitales. La razón es clara: los desarrolladores de estas áreas suelen gestionar monederos, infraestructura crítica y código sensible que, si se compromete, puede abrir la puerta al robo directo de activos.

Al tomar control del equipo de un ingeniero, los atacantes pueden acceder a repositorios privados, claves API, configuraciones de servidores, billeteras de prueba que a menudo se conectan a entornos de producción y otros recursos de alto valor. La combinación de espionaje técnico y potencial beneficio económico encaja con los objetivos tradicionales del aparato de ciberoperaciones de Corea del Norte.

Estas campañas, además, se adaptan bien al tejido empresarial europeo y español, donde es habitual que los desarrolladores trabajen en remoto, colaboren con empresas internacionales y participen en procesos de selección fuera de su país. Esta globalización del talento facilita que una oferta aparentemente atractiva, en inglés y con un flujo de prueba técnica habitual, no levante sospechas.

Para las organizaciones del sector fintech, exchanges de criptomonedas y compañías blockchain, este tipo de ataques representa un riesgo sistémico. Un solo equipo comprometido puede bastar para abrir una brecha significativa en la red interna o en los sistemas que gestionan fondos de clientes, especialmente si no existen controles estrictos de segregación de privilegios y acceso.

El uso de herramientas de desarrollo comunes como VS Code, Node.js o gestores de dependencias como npm refuerza la eficacia de la campaña, ya que los atacantes no necesitan introducir herramientas extrañas: se apoyan en el propio ecosistema que los desarrolladores utilizan a diario, reduciendo el número de señales anómalas que podrían delatar la intrusión.

Recomendaciones para desarrolladores y empresas en España y Europa

Ante este escenario, los expertos recomiendan fortalecer las prácticas de seguridad, especialmente en equipos de desarrollo. Una de las medidas clave es desconfiar por defecto de repositorios de terceros recibidos en procesos de selección, colaboraciones espontáneas o mensajes directos en redes profesionales, incluso cuando aparentemente proceden de empresas conocidas.

Es fundamental revisar el contenido del repositorio antes de abrirlo en VS Code, prestando atención a ficheros como .vscode/tasks.json y otras configuraciones que puedan ejecutar comandos automáticos. Siempre que sea posible, conviene analizar estos archivos manualmente o pasarlos por herramientas de revisión antes de conceder confianza al proyecto en el IDE.

Asimismo, se aconseja instalar solo paquetes npm verificados y con buena reputación, revisando el origen de dependencias poco conocidas y evitando incluir módulos sugeridos de forma informal o sin documentación clara. En entornos empresariales, la adopción de repositorios internos de dependencias y políticas de allowlist puede reducir de forma significativa el riesgo.

Para las compañías con presencia en España y en el resto de Europa, resulta recomendable formar específicamente a sus desarrolladores sobre este tipo de campañas, simulando escenarios de pruebas técnicas maliciosas y reforzando procedimientos internos de verificación antes de ejecutar código externo. Integrar la seguridad en el ciclo de desarrollo y en los procesos de recursos humanos se ha vuelto casi obligatorio.

Finalmente, soluciones de seguridad centradas en endpoints y monitorización de comportamiento pueden ayudar a detectar patrones como la ejecución inusual de curl, Node.js o Python en segundo plano vinculada a proyectos recién clonados. Aunque los atacantes intentan camuflar sus acciones en flujos legítimos, un análisis continuo del comportamiento del sistema sigue siendo una de las defensas más efectivas.

La campaña Contagious Interview ilustra hasta qué punto los actores vinculados a Corea del Norte han conseguido integrar sus tácticas en flujos de trabajo legítimos, abusando de herramientas tan comunes como VS Code, Vercel o npm, y apuntando directamente a desarrolladores con acceso privilegiado a activos digitales. En un contexto donde las fronteras entre procesos de selección, colaboración remota y trabajo diario se diluyen, elevar el nivel de sospecha ante repositorios y pruebas técnicas no solicitadas se ha convertido en una pieza esencial de la higiene de seguridad tanto para profesionales individuales como para empresas tecnológicas en España y en el resto de Europa.

AWS CodeBuild Misconfiguration Exposed GitHub Repos to Potential Supply Chain Attacks
Artículo relacionado:
Fallos en AWS CodeBuild abrieron la puerta a ataques de cadena de suministro en GitHub