El gusano SANDWORM MODE que roba credenciales y se expande por entornos de desarrollo

Un nuevo capítulo en la larga historia de ataques a la cadena de suministro de desarrolladores ha salido a la luz y deja claro que los vectores de compromiso siguen evolucionando con rapidez. Investigadores en seguridad han identificado una campaña activa que utiliza paquetes maliciosos publicados en npm como vehículos para robar credenciales, claves de criptomonedas y, sobre todo, para propagarse como un gusano por entornos de desarrollo. La firma que lo ha reportado ha bautizado la operación como SANDWORM_MODE y ha documentado una compleja mezcla de técnicas orientadas a maximizar el alcance y el daño.

La investigación técnica publicada por Socket describe cómo los atacantes han agrupado al menos diecinueve paquetes npm, publicados desde dos alias de editor, en una campaña de typosquatting y distribución intencionada. Entre los nombres detectados se encuentran paquetes con marcas sospechosas como claud-code, cloude, crypto-locale, crypto-reader-info, detect-cache, node-native-bridge, opencraw, secp256, y otros que emulan utilidades legítimas para engañar a desarrolladores y automatizaciones. Además se han identificado cuatro paquetes “dormidos” que, por ahora, no contienen carga maliciosa, lo que sugiere reservas operativas por parte del operador.

Lo que distingue a SANDWORM_MODE es la combinación de componentes: un primer estadio que actúa de “recolector” inicial y otro estadio secundario que, tras un período de latencia, activa capacidades avanzadas. Los módulos encontrados permiten capturar tokens de acceso de GitHub y npm, secretos de entornos de CI/CD, variables de entorno, ficheros de configuración de npm y, en algunos casos, claves privadas y credenciales asociadas a monederos. El diseño es deliberado: la primera etapa abre la puerta y la segunda explota el acceso para realizar una recolección masiva y propagación.

La campaña no se limita a la típica ejecución en instalaciones locales. Los paquetes incluyen un GitHub Action manipulado que extrae secretos de pipelines y los envía fuera del entorno afectado mediante HTTPS, con un mecanismo de respaldo que usa DNS para garantizar la exfiltración incluso si los canales convencionales fallan. También hay código que actúa como un interruptor destructivo: si el malware pierde acceso a sus repositorios de control, puede intentar borrar contenidos del directorio personal del usuario; ese mecanismo de borrado viene desactivado por defecto en las muestras analizadas, pero su mera existencia es alarmante.

Otro punto crítico es la orientación explícita hacia asistentes de programación y herramientas basadas en modelos de lenguaje. Los investigadores describen un módulo denominado “McpInject” que monta un servidor falso compatible con el Model Context Protocol (MCP) y lo registra como si fuera un proveedor de herramientas legítimo. Ese servidor ofrece “herramientas” que ocultan inyecciones de prompt diseñadas para leer ficheros sensibles —como claves SSH, credenciales en .aws o ficheros .npmrc y .env— y prepararlos para su exfiltración. Según el informe, las implementaciones objetivo incluyen asistentes y editores populares como Claude Code, Claude Desktop, Cursor, Microsoft Visual Studio Code y otras Integraciones modernas, lo que convierte a las cadenas de herramientas de IA en un nuevo frente de ataque. Más información sobre los conceptos de herramientas en MCP puede consultarse en la documentación oficial: Model Context Protocol — herramientas.

Además, se ha detectado la intención de que el malware emplee técnicas para evadir análisis estático y dinámico: los operadores han incorporado una unidad polimórfica capaz de invocar localmente un modelo (en los análisis figuró la referencia al proyecto DeepSeek Coder) con el objetivo de renombrar variables, reescribir flujo de control, insertar código basura y codificar cadenas. Aunque esa funcionalidad aparece desactivada en las muestras actuales, su presencia indica que los autores planean sofisticar las versiones futuras para hacerse menos detectables.

La arquitectura de la campaña también contempla un retraso programado: el segundo estadio no se activa inmediatamente, sino después de, como mínimo, 48 horas y con una aleatorización adicional por equipo que puede sumar hasta otras 48 horas. Ese comportamiento reduce la probabilidad de que la explotación sea detectada en los análisis de instalación inmediatos y facilita la infiltración sostenida antes de que se ejecute la fase más agresiva.

Paralelamente a este descubrimiento, otras firmas de seguridad han reportado paquetes npm maliciosos con finalidades similares. Veracode describió otro engaño con una carga oculta dentro de una imagen PNG que termina ejecutando un RAT, en tanto que JFrog detalló un paquete que se hace pasar por una utilidad legítima de ESLint y que desencadena una cadena de infecciones multimodal, desplegando agentes para Windows, macOS y Linux y aprovechando frameworks de C2 conocidos. Estos hallazgos muestran un patrón: las librerías y extensiones falsas buscan mecanismos de persistencia y extracción de datos que vayan mucho más allá de una simple instalación maliciosa. Los análisis de Veracode pueden leerse aquí: Veracode — Malicious npm package.

También hay vectores centrados en editores: Checkmarx ha identificado una extensión de Visual Studio Code que suplanta una extensión oficial para Solidity y que instala silenciosamente cargas útiles como ScreenConnect y puertas traseras en distintas plataformas. Este tipo de engaños contra comunidades de nicho (en este caso, desarrolladores de contratos inteligentes) subraya cómo los atacantes eligen objetivos donde el impacto y la confianza implícita en herramientas específicas pueden facilitar la infección. Puede consultarse su reporte en: Checkmarx — informe sobre extensión maliciosa.

¿Qué pueden hacer los equipos y desarrolladores ahora mismo? En primer lugar, es imprescindible asumir que cualquier paquete sospechoso detectado en proyectos debe ser eliminado y que las credenciales que pudieron exponerse (tokens de npm, secretos de GitHub Actions, claves de CI/CD) deben ser rotadas inmediatamente. También es recomendable auditar repositorios en busca de cambios inesperados en archivos como package.json, ficheros de bloqueo y flujos de trabajo en .github/workflows, y revocar tokens que tengan permisos amplios. Más allá de la respuesta inmediata, conviene endurecer el control de confianza en la cadena de suministro: exigir revisiones de dependencias, preferir paquetes con mantenedores reconocidos y con historial, utilizar firmas de paquetes o verificaciones reproducibles cuando sea posible, y aplicar el principio de menor privilegio en tokens y secretos.

Los equipos de seguridad deberían además monitorizar actividad anómala en cuentas de GitHub y en registros de CI, introducir análisis de dependencia automatizados y usar sandboxing para instalaciones desconocidas. Habilitar autenticación multifactor en cuentas de publicación y en las plataformas de hosting reduce la facilidad con que un actor puede secuestrar identidades para publicar nuevas ediciones maliciosas. Finalmente, para los responsables de plataformas y repositorios, la cooperación con servicios de seguridad y la rápida retirada de paquetes confirmados como maliciosos son medidas críticas para limitar la difusión.

La constatación de campañas como SANDWORM_MODE reafirma una lección ya conocida pero insuficientemente aplicada: las cadenas de herramientas modernas, incluidas las que incorporan asistentes y modelos de IA, amplían la superficie de ataque y requieren una combinación de higiene, vigilancia técnica y cultura de seguridad entre desarrolladores. Las investigaciones de Socket, JFrog, Veracode y Checkmarx ofrecen más detalles técnicos y muestras de indicadores para quienes quieran profundizar; consultarlas ayuda a contextualizar y a tomar decisiones informadas en el corto plazo.