Microsoft ataque supply chain Mastra AI: Norcorea

En pocas palabras: Microsoft atribuyó con alta confianza el ataque a la cadena de suministro de Mastra AI al grupo norcoreano Sapphire Sleet (BlueNoroff). En junio de 2026, los atacantes secuestraron una cuenta de maintainer en npm y publicaron malware en más de 140 paquetes del scope @mastra.

Microsoft atribuyó el ataque a la cadena de suministro de Mastra AI al grupo norcoreano Sapphire Sleet (también conocido como BlueNoroff). Los atacantes secuestraron una cuenta de maintainer en npm y publicaron actualizaciones maliciosas en más de 140 paquetes del scope @mastra, según reveló la compañía esta semana de junio de 2026.

El ataque a la cadena de suministro de Mastra AI es un compromiso de la cadena de suministro de software: alguien tomó el control de la cuenta del desarrollador que publica los paquetes de Mastra en npm y, desde ahí, inyectó una dependencia maliciosa en decenas de librerías legítimas. Cuando un programador instalaba esos paquetes, su máquina ejecutaba malware sin que se diera cuenta. Microsoft evalúa “con alta confianza” que detrás está un actor estatal de Corea del Norte.

¿Quién es Sapphire Sleet y por qué lo vinculan con Corea del Norte?

Sapphire Sleet no es nombre nuevo. Es un actor estatal norcoreano, el mismo que la industria conoce desde hace años como BlueNoroff, y su especialidad histórica fue el sector financiero: bancos, exchanges de cripto, fintechs. La novedad es a quién apuntan ahora.

Ya no van solo por la plata directa. Van por los desarrolladores. ¿Por qué? Porque el que escribe código tiene en su máquina las llaves del reino: tokens de la nube, claves de API, accesos a repos privados y, con frecuencia, wallets de cripto. Comprometés a un dev y de paso te metés en la infraestructura de su empresa. Sobre eso hablamos en implementar controles de seguridad Microsoft.

Ojo con la palabra que usó Microsoft: la atribución es “con alta confianza”, no certeza absoluta. Según el comunicado de Microsoft Security, “esta actividad es atribuible a Sapphire Sleet, un actor estatal norcoreano que apunta principalmente al sector financiero”. Es el lenguaje estándar de las firmas de seguridad cuando la evidencia técnica es fuerte (infraestructura reutilizada, patrones de código, tácticas conocidas) pero no hay una confesión firmada. Tomalo como muy probable, no como dogma.

¿Cómo comprometieron la cuenta del maintainer de Mastra?

Acá viene lo bueno (y lo incómodo). Todo arrancó cuando los atacantes tomaron el control de la cuenta ehindero, que tenía permisos de publicación sobre todo el entorno de paquetes de Mastra. Con esa cuenta, empujaron actualizaciones maliciosas como si fueran releases normales.

El método exacto del secuestro no figura en lo que Microsoft hizo público hasta ahora. No voy a inventarte un detalle que no está. Lo que sí sabemos por casos previos de este mismo grupo: BlueNoroff es conocido por campañas de robo de criptomonedas, extensiones de navegador maliciosas y compromisos de la cadena de suministro de software. Sea cual sea la puerta, el resultado fue el mismo.

Y este es el punto que duele: una sola cuenta con permisos amplios abrió la puerta a más de 140 paquetes. Cualquiera que haya configurado permisos en una organización de npm sabe lo fácil que es dejar a un maintainer con acceso de publicación a todo el scope “para no andar tocando permisos cada vez”. Bueno, esto es lo que pasa cuando ese atajo sale mal.

¿Qué es easy-day-js y cómo funciona el typosquat?

Ponele que instalás un paquete de Mastra y, sin que lo pidas, te baja también una dependencia llamada easy-day-js. Suena inofensiva. Parece una de esas mil utilidades de fechas que andan dando vueltas. Ese es justo el truco. Esto se conecta con lo que analizamos en alternativas seguras para tu empresa.

easy-day-js es un typosquat de dayjs, una de las librerías de manejo de fechas más usadas del ecosistema JavaScript. El typosquatting es eso: registrar un nombre parecido a uno legítimo para que pase desapercibido en la lista de dependencias. Nadie revisa una por una las transitivas, y ahí se cuela.

¿Qué hace cuando entra? La secuencia, según el reporte de BleepingComputer, es así:

• Dispara un post-install hook. npm permite ejecutar scripts apenas terminás de instalar un paquete. El malware aprovecha eso para correr solo, sin que vos hagas nada.
• Ejecuta un dropper ofuscado. Un script ilegible a propósito, diseñado para esquivar antivirus y análisis automático.
• Desactiva la verificación de certificados TLS. Así puede hablar con sus servidores sin que los controles de seguridad de la red lo frenen.
• Se conecta a servidores controlados por los atacantes. Desde ahí baja el resto del payload y empieza a robar.

¿Cuántos paquetes npm cayeron y quién está en riesgo?

Más de 140 paquetes del scope @mastra. No es un número menor.

Y acá está la trampa que mucha gente no ve: no hace falta que uses Mastra de forma directa para estar en riesgo. Si una de tus dependencias depende a su vez de un paquete @mastra comprometido (lo que se llama dependencia transitiva), el malware llega igual a tu máquina. Vos instalaste la librería A, A depende de B, B traía la versión envenenada. Listo, estás adentro.

El riesgo concreto recae sobre cualquier desarrollador que haya hecho npm install de versiones comprometidas durante la ventana del ataque, en junio de 2026, antes de que se detectara y se limpiaran los paquetes. Si tu CI/CD instaló dependencias en ese período, el problema también puede estar en tus servidores de build, no solo en tu laptop.

¿Qué información roba el malware y cuál es el impacto real?

El payload va directo a lo que más duele. Esto es lo que busca:

• Credenciales locales: usuarios y contraseñas guardados en la máquina del dev.
• API keys: las claves que conectan tu app con servicios externos, pasarelas de pago, modelos de IA, lo que tengas.
• Tokens de autenticación: sesiones activas que permiten saltarse el login, incluso con 2FA ya pasado.
• Wallets de criptomonedas: la firma de la casa de BlueNoroff. Acá es donde se monetiza el ataque.

¿El impacto? Con esas credenciales, un atacante puede entrar a tus repos privados, escalar a tus cuentas en la nube, levantar infraestructura a tu nombre (y a tu costo) o vaciarte una billetera. El dropper viene ofuscado para que el antivirus no lo marque, así que confiar solo en “tengo un antivirus instalado” no alcanza. La detección tardía es parte del diseño. Te puede servir nuestra cobertura de cómo funcionan realmente estos modelos.

¿Cómo verificar si tu proyecto fue afectado por el ataque?

Antes de entrar en pánico, revisá. Estos son los pasos concretos:

• Abrí tu package-lock.json o yarn.lock. Buscá cualquier entrada del scope @mastra y fijate las versiones instaladas durante junio de 2026.
• Buscá easy-day-js. Si aparece en tus lock files y vos nunca lo agregaste a mano, mala señal. Esa es la dependencia maliciosa.
• Corré npm audit. No es infalible, pero te marca vulnerabilidades conocidas y paquetes señalados.
• Revisá conexiones de salida anómalas. Si tu máquina o tu runner de CI hizo conexiones raras justo después de un install, anotalo.
• Mirá el comportamiento de las máquinas dev. Procesos desconocidos, picos de red, certificados TLS desactivados donde no deberían.

Si encontrás aunque sea una sola coincidencia, asumí que la máquina está comprometida y pasá directo a la próxima sección. No te quedes en el “capaz que no pasó nada”.

¿Qué medidas implementar para proteger tu cadena de suministro?

Ahora mismo (si ya te tocó)

• Actualizá a versiones limpias. Pasá los paquetes @mastra a releases posteriores a la limpieza y eliminá easy-day-js.
• Rotá todas las credenciales. API keys, tokens, contraseñas, accesos a la nube. Todo. Si tu app corre en un VPS o hosting (sea donweb.com u otro proveedor), cambiá también las claves de esos paneles.
• Mové tus fondos de cripto si esa wallet estuvo en una máquina afectada.

Corto plazo (para no repetir)

• Meté npm audit en el CI/CD. Que cada build falle si aparece algo señalado, no que sea opcional.
• Usá lock files siempre y commiteálos. Sin lock file, cada install es una ruleta.
• Rotá tokens de API de forma periódica, no solo cuando hay incendio.

Largo plazo (la cultura)

• Evaluá gestores con verificación de firma, como pnpm o Yarn moderno, que dan más control sobre la integridad de los paquetes.
• Monitoreo de comportamiento de dependencias: herramientas que alertan cuando un paquete hace algo que antes no hacía (como abrir conexiones de red en un post-install).
• Auditá los permisos de los maintainers. Nadie debería tener publish sobre todo el scope “por comodidad”. Principio de mínimo privilegio, en serio.

Qué está confirmado y qué todavía no

Confirmado por Microsoft: el secuestro de la cuenta ehindero, la publicación de updates maliciosos en 140+ paquetes @mastra, la inyección de easy-day-js como typosquat de dayjs, el post-install hook que despliega un dropper, la desactivación de TLS y el robo de credenciales, API keys, tokens y wallets. La atribución a Sapphire Sleet figura como “alta confianza”.

Lo que todavía no está claro: el método exacto con el que comprometieron la cuenta del maintainer (no fue detallado públicamente), el número final de víctimas y la lista cerrada de versiones exactas afectadas. Sobre esos puntos, todo lo que circule por ahora hay que tomarlo con pinzas hasta que haya datos oficiales.

Errores comunes al responder a un ataque así

• Pensar que “no uso Mastra, no me afecta”. Falso. Las dependencias transitivas no te preguntan. Revisá igual tus lock files.
• Solo actualizar el paquete y seguir. Si el malware ya corrió, las credenciales ya salieron. Actualizar sin rotar claves es cerrar la puerta después de que el ladrón salió con la caja fuerte.
• Confiar ciegamente en el antivirus. El dropper viene ofuscado justo para esquivarlo. Verificá comportamiento de red, no solo firmas.
• Limpiar la laptop y olvidarse del CI/CD. Tus servidores de build instalan dependencias igual que vos. Si corrieron en la ventana del ataque, también están en la lista.

Preguntas Frecuentes

¿Qué pasó exactamente en el ataque a Mastra AI?

Atacantes secuestraron la cuenta del maintainer ehindero en npm y publicaron updates maliciosos en más de 140 paquetes del scope @mastra. Esas actualizaciones inyectaban easy-day-js, una dependencia que ejecutaba malware al instalarse. Microsoft lo reveló en junio de 2026. Para más detalles técnicos, mirá otras plataformas de IA disponibles.

¿Quién es Sapphire Sleet?

Sapphire Sleet, también conocido como BlueNoroff, es un grupo de hackers patrocinado por el Estado de Corea del Norte. Su objetivo histórico fue el sector financiero, y en los últimos tiempos amplió el blanco hacia desarrolladores para robar credenciales y criptomonedas.

¿Cómo sé si mi código fue comprometido?

Revisá tu package-lock.json o yarn.lock buscando paquetes @mastra instalados en junio de 2026 y cualquier presencia de easy-day-js. Corré npm audit y verificá si hubo conexiones de red anómalas después de un install.

¿Qué hago ahora si usé Mastra?

Actualizá a una versión limpia, eliminá easy-day-js y rotá todas tus credenciales: API keys, tokens, contraseñas y accesos a la nube. Si tenías una wallet de cripto en esa máquina, movés los fondos a una billetera nueva.

¿El typosquat easy-day-js sigue activo en npm?

Los paquetes maliciosos suelen retirarse una vez detectados, pero el riesgo persiste en proyectos que ya instalaron las versiones comprometidas y las tienen fijadas en sus lock files. Por eso conviene revisar y limpiar a mano, no asumir que la baja del paquete te protege retroactivamente.

Conclusión

Lo que cambió con este caso es la escala y el blanco. Un solo maintainer comprometido derivó en 140+ paquetes envenenados, y el objetivo ya no es el banco: sos vos, el que escribe el código. Sapphire Sleet entendió que la cadena de suministro de software es el camino corto a las credenciales que importan.

¿Qué hacer? Si tocaste Mastra en junio de 2026, asumí compromiso hasta probar lo contrario: revisá lock files, corré npm audit, rotá credenciales y limpiá también tu CI/CD. Y más allá de este ataque puntual, tratá las dependencias con la misma desconfianza que un mail raro: lock files, mínimo privilegio para los maintainers y verificación de integridad dejaron de ser opcionales. El próximo typosquat ya está dando vueltas, solo que todavía no tiene nombre.

Fuentes

• Microsoft Security Blog – atribución oficial del ataque a Sapphire Sleet
• BleepingComputer – Microsoft links Mastra AI supply chain attack to North Korean hackers