Alerta de seguridad: paquetes npm de @asyncapi comprometidos disparan el framework malicioso Miasma durante builds y flujos de CI

Investigadores de seguridad han identificado una campaña de compromiso de la cadena de suministro que afectó a varios paquetes npm del espacio de nombres @asyncapi, y que distribuían un cargador en varias etapas que desemboca en un framework malicioso avanzado conocido como "Miasma". Los paquetes afectados incluían versiones concretas de @asyncapi/generator-helpers, @asyncapi/generator-components, @asyncapi/generator y @asyncapi/specs; esos paquetes contenían un archivo inyectado que, al ser cargado por Node.js con require(), ejecutaba un primer payload ofuscado que descargaba desde IPFS un segundo estadio cifrado llamado "sync.js". El recurso de descarga observado fue publicado en la pasarela pública: ipfs.io/ipfs/QmQobZSp1wRPrpSEQ56qnyq7ecZh5Bg5k1fnjt4SUwwHb9.

La cadena de infección descrita no depende de hooks de instalación (preinstall/postinstall) sino de la carga en tiempo de ejecución: el código malicioso se activa cuando la librería infectada es require()d durante un build o en un flujo de trabajo de CI. Esa diferencia es crucial para la detección y la respuesta, porque un simple npm install que no llegue a cargar la librería puede no activar la ejecución, mientras que una compilación o un job de CI que importe el módulo sí lo hará.

El loader "sync.js" alberga dos componentes: uno es el payload JavaScript final cifrado que contiene el framework Miasma y otro es una gran estructura cifrada usada por el runtime para ejecutar cadenas de procesos. El framework reportado empaqueta cientos de módulos y soporta múltiples canales de mando y control, incluyendo HTTP REST, relés Nostr, IPFS, BitTorrent DHT, libp2p GossipSub y hasta un contrato inteligente en Ethereum. Entre sus capacidades se encuentran robo de credenciales, envenenamiento de herramientas de IA, movimiento lateral por LAN y propagación tipo gusano a registries como npm, PyPI y Cargo, además de mecanismos de persistencia en systemd, crontab, launchd y claves del registro de Windows.

Los análisis muestran además funcionalidades operacionales maduras: cifrado de comunicaciones y tareas, transporte de subida de archivos, firma de nodos y actualización remota de payloads. El malware incluye un mecanismo de "dead man’s switch" que vigila un token robado y puede activar un borrado de directorios si el token se revoca, y evita sistemas que parezcan sandboxes, máquinas virtuales, equipos configurados en ruso o aquellos con software de seguridad concreto instalado (p. ej. CrowdStrike, SentinelOne, Microsoft Defender y otros), lo que indica intención de permanecer operativo en entornos reales y evitar análisis.

Un punto operativo importante que diferencian a esta intrusión es el vector de publicación: según los equipos implicados en la investigación, el atacante obtuvo acceso para hacer push a los repositorios y usó los flujos legítimos de GitHub Actions del proyecto, publicando paquetes mediante la integración OIDC de GitHub para npm. Esto produjo paquetes con attestations de SLSA y OIDC válidas, lo que demuestra que las builds se realizaron por una workflow autorizada, pero no garantiza que los commits que la activaron fueran legítimos. En otras palabras, la presencia de pruebas de procedencia SLSA no sustituye el control estricto sobre quién puede push y qué commits se aceptan.

Las versiones maliciosas ya han sido retiradas del registro npm, pero el daño puede haberse materializado en cualquier endpoint que haya importado y ejecutado esos módulos en builds, entornos de desarrollo o jobs de CI. Se debe tratar como potencialmente comprometido cualquier sistema que cargó las versiones afectadas, y no asumir seguridad por ausencia de scripts de instalación en package.json.

Para equipos y responsables, las acciones inmediatas recomendadas son aislar y preservar artefactos si sospechan ejecución, auditar dependencias y builds, y buscar indicadores concretos: rastrear en los lockfiles y en el árbol de dependencias versiones afectadas de @asyncapi; buscar en repositorios y en la base de código llamadas a require() sobre esos paquetes; detectar procesos Node.js hijos que se ejecuten en segundo plano y ficheros llamados "sync.js" escritos en rutas específicas del sistema; verificar la presencia de unidades systemd, entradas de crontab, launchd y claves Run en el Registro de Windows creadas recientemente. También conviene bloquear a nivel de red el CID/IPFS conocido y la pasarela involucrada para impedir futuras descargas: además del enlace IPFS anterior, las organizaciones pueden aplicar controles de egress para gateways públicos.

A nivel de prevención de la cadena de suministro, es clave restringir quién puede modificar repositorios y qué workflows pueden publicar artefactos. Revisar protecciones de ramas, forzar revisiones humanas antes de merges que disparen releases, auditar los secrets y credenciales de push al repositorio, y limitar las identidades de GitHub Actions con permisos mínimos. Tener en cuenta que las attestations de OIDC/SLSA confirman que la build fue producida por la workflow confiada, pero no sustituyen controles de integridad del repositorio ni la protección de las credenciales de push. Documentación útil sobre el modelo OIDC en GitHub y sobre la iniciativa SLSA está disponible en los recursos oficiales: GitHub - OIDC para GitHub Actions y SLSA (Supply-chain Levels for Software Artifacts).

En la fase de respuesta y remediación conviene combinar medidas técnicas y de proceso: revocar y rotar credenciales expuestas, revisar y reemplazar paquetes comprometidos por versiones limpias o reconstruidas desde fuentes verificadas, reconstruir artefactos de releases en entornos controlados y comprobar hashes, y ejecutar análisis forense en endpoints sospechosos con EDR/antimalware para detectar exfiltraciones, persistencias y módulos cargados por Node.js. Para reducir el riesgo futuro, implantar escaneo continuo de dependencias, firma de releases y políticas que limiten la publicación automática sin revisión del código que dispara la workflow.

Este incidente subraya que la confianza en la cadena de suministro es condicionada: las garantías de workflow y de firma facilitan la trazabilidad, pero no sustituyen la necesidad de controles de acceso, revisión humana y monitorización de comportamiento. Si tu organización usó alguna de las versiones comprometidas, actúa como si hubiera habido compromiso: aisla, investiga y recupera desde fuentes limpias, y aprovecha la lección para endurecer controles en repositorios y CI/CD.