Troyanizan cinco paquetes npm de AsyncAPI con el RAT Miasma

Cinta transportadora de paquetes de software donde una rama lateral sin control de seguridad inyecta un componente malicioso rojo brillante dentro de un paquete
0 0 votos
Valora la Publicación

El 14 de julio de 2026 se publicaron en npm cinco versiones troyanizadas de cuatro paquetes del scope @asyncapi, incluidas @asyncapi/generator@3.3.1 y @asyncapi/specs@6.11.2, este último con unos 2,7 millones de descargas semanales.

Las versiones maliciosas descargan desde IPFS el RAT «Miasma», un troyano de acceso remoto que apunta a credenciales de CI/CD, identidades cloud y herramientas de IA de los desarrolladores. Estuvieron disponibles entre 3 y 4 horas antes de ser despublicadas del registro.

Qué pasó

Según la reconstrucción de StepSecurity, a las 06:58 UTC un atacante empujó un commit malicioso a la rama next del repo asyncapi/generator, firmado con la identidad placeholder «Your Name <you@example.com>».

A las 07:10 UTC ya estaban publicadas @asyncapi/generator@3.3.1, @asyncapi/generator-helpers@1.1.1 y @asyncapi/generator-components@0.7.1. Menos de una hora después el atacante comprometió un segundo repo (asyncapi/spec-json-schemas) y publicó @asyncapi/specs@6.11.2-alpha.1 (08:06) y @asyncapi/specs@6.11.2 (08:30).

Entre las 11:12 y las 11:18 UTC las cinco versiones fueron despublicadas de npm. Las descargas semanales combinadas de los paquetes afectados superan los 2,9 millones.

El vector: ramas desprotegidas y el propio pipeline de release

Lo novedoso es cómo entraron. Los repos de AsyncAPI tenían protecciones estrictas y revisión obligatoria en main, pero las ramas de release pre-producción (como next y schema) estaban desprotegidas, según el análisis de Unit 42.

El atacante empujó commits directos a esas ramas, sin pasar por ninguna revisión humana. Esos commits dispararon los workflows legítimos de GitHub Actions del proyecto, que publicaron los paquetes vía trusted publishing con OIDC: el resultado son paquetes maliciosos con attestations de provenance SLSA válidas, porque efectivamente los produjo el workflow autorizado del proyecto.

Además, el código malicioso corrió dentro del propio runner de CI y cosechó los secretos NPM_TOKEN y GITHUB_TOKEN del entorno. Es decir: no hizo falta robarle el token npm a ningún mantenedor para publicar.

Miasma: activación al importar y C2 descentralizado

A diferencia de los ataques clásicos con hooks de instalación, el dropper (unos 7,7 KB ofuscados, escondidos en archivos legítimos detrás de 1.000 espacios en blanco) se ejecuta cuando el código hace require() del módulo, no al instalar. Instalar con --ignore-scripts no protege.

El dropper lanza un proceso Node oculto que descarga desde IPFS un archivo sync.js y lo persiste en rutas específicas por sistema operativo (~/.local/share/NodeJS/ en Linux, ~/Library/Application Support/NodeJS/ en macOS, %LOCALAPPDATA%\NodeJS\ en Windows).

El C2 de Miasma es inusualmente resiliente, con múltiples canales de respaldo:

  • HTTP contra la IP primaria 85.137.53[.]71:8080.
  • Contratos inteligentes de Ethereum como registro descentralizado de comando y control.
  • Relays de Nostr y la DHT de BitTorrent como canales de fallback peer-to-peer.

El malware busca llaves SSH, tokens de npm y GitHub, credenciales de AWS, Azure y GCP, tokens de service accounts de Kubernetes y secretos de CI/CD. StepSecurity identificó además un módulo orientado a envenenar herramientas de IA de los devs (Claude Code, GitHub Copilot, Cursor).

Qué hacer

  • Verificar lockfiles: las versiones seguras son generator@3.3.0, generator-helpers@1.1.0, generator-components@1.0.0 y specs@6.11.1. Regenerar el lockfile y limpiar cachés de npm.
  • Buscar el artefacto sync.js en las rutas de persistencia y matar procesos Node huérfanos.
  • Si hubo exposición, rotar todo: tokens de npm y GitHub, llaves SSH, credenciales cloud y API keys de herramientas de IA.
  • Bloquear la IP de C2 y auditar tráfico saliente de los builds hacia IPFS, relays Nostr y nodos DHT.
  • Proteger TODAS las ramas capaces de disparar un release, no solo main, y considerar la función min-release-age del npm CLI 11.10.0+.

La saga npm no afloja

Este incidente se suma a una seguidilla que ya cubrimos en el MUG: el gusano Shai-Hulud, el compromiso de los paquetes de Injective y el infostealer de jscrambler hace apenas unos días.

La novedad acá es incómoda: los paquetes maliciosos salieron del pipeline oficial, con provenance firmada y sin tocar el token de ningún mantenedor. ¿Las ramas pre-producción de sus repos tienen las mismas protecciones que main? Te leemos en los comentarios.

Fuentes

Escrito por

Pablo Ariel Di Loreto

Profesor. Informático. Fanático del helado de dulce de leche. Director de Ingeniería en MODO, y Secretario del Microsoft Users Group Asociación Civil. Además, soy owner de iniciativas como ConoSurTech y Aprender IT.

Ver todas las entradas de Pablo Ariel Di Loreto →
Suscribirse
Notificarme de
guest

0 Comentarios
Viejos
Nuevos Más votados
Scroll al inicio
0
Nos encantaría conocer tu opinión: ¡comenta!x