Alertan sobre malware en paquetes npm de AsyncAPI que forman botnets
Publicado el
Descubrimiento de malware en paquetes npm de AsyncAPI
Investigaciones realizadas por OX Security, SafeDep, Socket y StepSecurity han revelado que cuatro paquetes npm en el espacio de nombres de @asyncapi han sido comprometidos para distribuir un loader de botnet de múltiples etapas. Los paquetes afectados son los siguientes:
- @asyncapi/generator-helpers@1.1.1 - @asyncapi/generator-components@0.7.1 - @asyncapi/generator@3.3.1 - @asyncapi/specs (v6.11.2, v6.11.2-alpha.1)
Según Socket, los paquetes comprometidos despliegan un payload de primera etapa ofuscado que descarga un segundo payload cifrado, identificado como Miasma, desde IPFS. Cada uno de estos paquetes incluye un implant de JavaScript oculto, que contiene un archivo fuente inyectado que se decodifica en un downloader de segunda etapa común a todos los paquetes.
A diferencia de iteraciones anteriores que utilizaban hooks de instalación para activar la ejecución de un payload en JavaScript, el código malicioso en este caso se ejecuta cuando el módulo infectado es cargado por Node.js. Tras esto, se inicia un nodo en segundo plano que descarga y ejecuta el malware desde IPFS. El payload de la siguiente etapa es un loader de JavaScript cifrado llamado sync.js, que se escribe en rutas específicas del sistema operativo y se ejecuta.
La URL del downloader es: `ipfs[.]io/ipfs/QmQobZSp1wRPrpSEQ56qnyq7ecZh5Bg5k1fnjt4SUwwHb9`.
Estructura del malware Miasma
El loader contiene dos componentes clave: 1. El payload de JavaScript final cifrado, que se decodifica en el marco de tareas de Miasma. 2. Un gran blob cifrado utilizado por el marco de spawn-chain del runtime.
Este marco agrupa 744 módulos y está diseñado como un marco de comandos que soporta seis canales de comunicación comando y control (C2) independientes, que incluyen HTTP, Nostr relay, IPFS, BitTorrent DHT, libp2p GossipSub P2P mesh y un smart contract de Ethereum.
Además de facilitar el robo de credenciales, la contaminación de herramientas de IA, el movimiento lateral en LAN y la propagación tipo gusano en los registros de npm, PyPI y Cargo, Miasma cuenta con un mecanismo de persistencia que establece claves de autoinicio en systemd, crontab, launchd de macOS y en el Registro de Windows.
Características adicionales y vectores de ataque
Aunque el malware tiene similitudes con las campañas de Shai-Hulud y Miasma, no se le atribuye a estas, según Moshe Siman Tov Bustan de OX Security. El malware incluye un dead man's switch que monitoriza un token robado y activa un borrado de directorios si el token es revocado, además de evitar sistemas identificados como sandboxes o entornos virtuales, así como aquellos que tienen configurada la lengua actual en ruso o que tienen herramientas de seguridad como CrowdStrike, SentinelOne, Microsoft Defender, CarbonBlack, Cylance, Osquery, Tanium y Qualys instaladas.
La ruta operacional más clara para el malware es el C2 basado en REST: el implant envía señales a un endpoint HTTP, acepta tareas cifradas y envía de vuelta los resultados de los comandos a la misma infraestructura. Además, el payload soporta transporte de subida, cifrado de comandos, firma de nodos, actualizaciones de payload, gestión de archivos, ejecución de shell y escritura de persistencia.
Acceso a repositorios y consecuencias
Se ha informado que el atacante obtuvo acceso de push a los repositorios y utilizó el propio pipeline de lanzamiento legítimo de GitHub Actions del proyecto para publicar paquetes con atestaciones de proveniencia OIDC válidas. Este ataque a la cadena de suministro no implicó el robo de un token de npm.
Ambos ataques son compromisos de pipelines de CI/CD, no tokens robados ni mantenedores maliciosos, según el investigador de seguridad Rohan Prabhu. Los paquetes resultantes llevan atestaciones de proveniencia legítimas, lo que demuestra únicamente que el flujo de trabajo autorizado del proyecto los produjo, no que los commits que los activaron eran legítimos.
Todos los cinco versiones maliciosas han sido eliminadas del registro de npm. Se recomienda tratar cualquier endpoint que haya importado o ejecutado una de las versiones afectadas como potencialmente comprometido. Sin embargo, la exposición depende de si el módulo infectado fue cargado como parte de un build o flujo de trabajo de desarrollo. Según StepSecurity, "no hay scripts de preinstalación/postinstalación en ninguno de los archivos package.json de los tres paquetes". Este dropper se activa cuando el módulo envenenado es require() durante el uso normal del generador: el momento en que un trabajo de build o CI realmente llama a la biblioteca, no en el tiempo de instalación de npm.