Actores norcoreanos usan tareas automáticas de VS Code para propagar el malware StoatWaffle

Resumen

Investigadores han identificado una nueva técnica empleada por el grupo vinculado a Corea del Norte conocido como Contagious Interview (también rastreado como WaterPlum) para distribuir una familia de malware denominada StoatWaffle. En lugar de recurrir exclusivamente a binarios o a extensiones maliciosas, los atacantes incorporan comandos en proyectos legítimos de Microsoft Visual Studio Code mediante el archivo de configuración tasks.json, aprovechando la ejecución automática de tareas al abrir un espacio de trabajo. Según los reportes, esta táctica fue adoptada por el actor desde diciembre de 2025.

Contexto y por qué importa

El abuso de herramientas y flujos de trabajo de desarrollo ha sido una constante en la evolución de las campañas sofisticadas. Convertir un proyecto abierto en un vector de ejecución automatizada reduce la fricción para el atacante: basta con que la víctima abra el proyecto en su entorno habitual para que se ejecute una instrucción maliciosa. Esta técnica amplía la superficie de ataque al incorporar configuraciones de entorno —que suelen considerarse inofensivas— como mecanismos de entrega.

Por qué importa:

• Los desarrolladores confían en repositorios y proyectos compartidos; una tarea maliciosa en tasks.json puede pasar desapercibida durante la revisión de código si no se inspeccionan archivos de configuración.
• El vector cruza la línea entre cadena de suministro de software y errores de configuración: no se necesita compilar ni adjuntar ejecutables obvios.
• Grupos con motivación estatal y recursos, como actores norcoreanos, están instruidos para explotar cualquier vectores creativos que faciliten el acceso y la persistencia.

Análisis técnico: cómo se abusa de tasks.json

Visual Studio Code utiliza archivos de configuración, entre ellos tasks.json, para definir tareas que ejecutan comandos del sistema, scripts y secuencias de construcción. Estas tareas pueden configurarse para ejecutarse automáticamente cuando se abre el espacio de trabajo o en respuesta a eventos específicos del editor.

El uso de tasks.json permite ejecutar comandos en el equipo del desarrollador con el contexto y permisos de su sesión de usuario.

En el caso atribuido a Contagious Interview / WaterPlum, los atacantes integran en proyectos de VS Code tareas diseñadas para descargar o ejecutar componentes de StoatWaffle. Desde la perspectiva operacional, esto reduce la interacción requerida por la víctima: no es necesario que ésta ejecute manualmente un binario o habilite macros; basta con abrir el proyecto en su editor.

Implicaciones técnicas relevantes para defensores:

• Las tareas pueden encadenar comandos que usan herramientas legítimas (por ejemplo, PowerShell, curl, npm) para recuperar cargas útiles remotas, lo que complica la detección por firmas.
• Los archivos de proyecto y configuración suelen formar parte de repositorios y paquetes compartidos, por lo que la distribución puede ser amplia y rápida.
• Al ejecutarse con los permisos del usuario, StoatWaffle puede realizar reconocimiento, persistencia y movimientos laterales en función del contexto de red y credenciales disponibles.

Comparables y precedentes

El uso de entornos y herramientas de desarrollo como vectores de ataque no es nuevo, aunque el abuso específico de tasks.json es una evolución reciente y técnica. Casos relevantes y tendencias históricas incluyen:

• Abuso de extensiones maliciosas de editores: en años recientes se han detectado extensiones de Visual Studio Code y otros IDEs que exfiltraban secretos o ejecutaban código malicioso.
• Compromisos en cadenas de suministro de desarrollo: incidentes como Codecov y otros compromisos de CI/CD demostraron cómo scripts y configuraciones pueden ser modificados para persistencia y exfiltración.
• Manipulación de ecosistemas de paquetes (npm, PyPI): paquetes maliciosos o paquetes legítimos comprometidos han servido para distribuir cargas útiles a través de dependencias.

Estas situaciones comparten una lección común: componentes aparentemente accesorios (extensiones, tareas, scripts de build) son objetivos valiosos para atacantes que buscan una vector silencioso y de amplio alcance.

Riesgos, implicaciones y recomendaciones prácticas

Riesgos principales:

• Compromiso de entornos de desarrollo con acceso a repositorios, credenciales y sistemas internos.
• Propagación rápida mediante repositorios compartidos y clonación de proyectos.
• Elusión de controles tradicionales basados en firmas y clasificación de binarios al usar herramientas legítimas para descargar o ejecutar cargas útiles.

Recomendaciones prácticas para equipos de seguridad y desarrolladores:

• Habilitar y aplicar políticas de Workspace Trust en VS Code: exigir que los espacios de trabajo no confiables requieran confirmación explícita antes de ejecutar cualquier tarea o extensión.
• Revisar y auditar archivos de configuración en repositorios (tasks.json, launch.json, .vscode/*) como parte del proceso de revisión de código y pipelines de integración continua.
• Deshabilitar la ejecución automática de tareas en entornos de desarrollo corporativos o establecer una política de “no ejecutar tareas de terceros” sin revisión.
• Controlar y limitar el uso de extensiones de VS Code mediante políticas empresariales y catálogos aprobados; monitorizar instalaciones de extensiones con herramientas de gestión de endpoints.
• Aplicar controles de ejecución y bloqueo en endpoints: listas de permitidos, restricciones sobre scripts (PowerShell Constrained Language Mode, restricciones de ejecución), y aplicación de EDR para detectar comportamiento anómalo (descargas inusuales, creación de procesos hijos, modificaciones persistentes).
• Escaneo automatizado de repositorios: incorporar análisis estático y heurístico de archivos de proyecto para detectar definiciones de tareas que ejecuten comandos remotos o sospechosos.
• Formación y concienciación: instruir a desarrolladores sobre el riesgo de abrir proyectos de fuentes no verificadas y sobre la necesidad de revisar archivos de configuración antes de permitir su ejecución.
• Segregar entornos: usar máquinas virtuales o contenedores efímeros para examinar proyectos desconocidos en lugar de abrirlos en el entorno de desarrollo principal.

Para equipos de respuesta a incidentes y analistas: priorizar la búsqueda de indicadores relacionados con ejecuciones iniciadas por VS Code, procesos de descarga típicos (curl/wget/powershell) en momentos de apertura de proyectos, y artefactos asociados a StoatWaffle conocidos por los proveedores de inteligencia.

Comentario experto

Desde la perspectiva de un equipo de seguridad, este cambio de vector —aprovechar la configuración del IDE en lugar de un módulo binario evidente— es relevante porque explota la confianza implícita entre desarrollador y proyecto. Los controles que hasta ahora se centraban en binarios y dependencias externas deben ampliarse para incluir archivos de configuración y metadatos del entorno. La defensa efectiva exige una combinación de políticas de herramienta, controles de endpoint y hábitos operacionales más cautelosos por parte de los equipos de desarrollo.

Conclusión

La campaña atribuida a Contagious Interview / WaterPlum que emplea tasks.json para desplegar StoatWaffle ilustra una evolución táctica: convertir configuraciones de desarrollo en vectores de entrega. Esto amplía la superficie de ataque y exige que las defensas integren inspección y control de archivos de proyecto, políticas de confianza del workspace y medidas de contención en endpoints. Las organizaciones deben tratar las configuraciones del IDE con la misma sospecha y controles que aplican a dependencias y ejecutables.

Source: thehackernews.com