
Según los hallazgos de OX Security, SafeDep, Socket y StepSecurity, se observaron cuatro paquetes npm comprometidos en el espacio de nombres @asyncapi distribuyendo un cargador de botnet de varias etapas.
Los paquetes afectados se enumeran a continuación:
@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)
«El paquete comprometido implementa una carga útil de primera etapa ofuscada y descarga una carga útil cifrada de segunda etapa identificada como Miasma de IPFS», dijo Socket.
Los paquetes contaminados se envían con implantes de JavaScript ocultos, y cada paquete contiene un archivo fuente inyectado que se decodifica en el mismo descargador de segunda etapa. A diferencia de iteraciones anteriores que aprovecharon los ganchos de instalación para desencadenar la ejecución de cargas útiles de JavaScript, el código malicioso en este caso se ejecuta cuando Node.js carga el módulo infectado, que luego inicia un nodo en segundo plano aislado que descarga y ejecuta el malware desde IPFS.
La carga útil de la siguiente etapa es un cargador de JavaScript cifrado llamado «sync.js» que se escribe en una ruta específica del sistema operativo y se ejecuta. La URL del programa de descarga es «ipfs(.)io/ipfs/QmQobZSp1wRPrpSEQ56qnyq7ecZh5Bg5k1fnjt4SUwwHb9». El cargador contiene dos componentes:
Carga útil final de JavaScript cifrada (decodificada en el marco de tareas de Miasma) Gran blob cifrado utilizado por el marco de la cadena de generación en tiempo de ejecución
El marco incluye 744 módulos y está construido como un marco de comando que admite seis canales de comunicación de comando y control (C2) independientes utilizando HTTP, Nostr Relay, IPFS, BitTorrent DHT, libp2p GossipSub P2P mesh y contratos inteligentes Ethereum.

Miasma tiene un mecanismo de persistencia único que facilita el robo de credenciales, el envenenamiento de herramientas de inteligencia artificial, el movimiento lateral de la LAN y la propagación similar a un gusano en los registros npm, PyPI y Cargo, además de configurar claves de inicio automático para los registros systemd, crontab, macOS launchd y Windows.
«Aunque este malware tiene algunas similitudes con las campañas Shai-Hulud y Miasma e incluye cadenas de Miasma varias veces en su código, este malware no es el mismo y no es atribuible a campañas Miasma/Shai-Hulud/TeamPCP observadas anteriormente», dijo Moshe Siman Tov Bustan de OX Security.
Además, incluye un interruptor de hombre muerto que monitorea los tokens robados y activa un borrado del directorio si el token se revoca, evitando sistemas identificados como entornos aislados o virtuales, que tienen el idioma actual configurado en ruso o que tienen instaladas las siguientes herramientas de seguridad: CrowdStrike, SentinelOne, Microsoft Defender, CarbonBlack, Cylance, Osquery, Tanium y Qualys.
«Su ruta operativa más obvia es C2 basado en REST, lo que significa implantar balizas en puntos finales HTTP, aceptar tareas cifradas y publicar resultados de comandos en la misma infraestructura. Alrededor de ese núcleo, la carga útil también es responsable del soporte para el transporte de carga, cifrado de comandos, firma de nodos, actualizaciones de carga útil, administración de archivos, ejecución de shell y escrituras persistentes».
Según StepSecurity, el atacante supuestamente obtuvo acceso push al repositorio y utilizó el proceso de lanzamiento legítimo de GitHub Actions del proyecto para publicar un paquete con un certificado de procedencia OIDC válido. El ataque a la cadena de suministro no implicó el robo de tokens npm.
«Ambos ataques fueron violaciones de los canales de CI/CD, no tokens npm robados ni mantenedores maliciosos», dijo el investigador de seguridad Rohan Prabhu. «Los atacantes impulsaron confirmaciones bajo ID de git de marcador de posición y forzaron el flujo de trabajo de lanzamiento real de cada repositorio a realizar la publicación a través de la integración de editor confiable GitHub OIDC de npm».
«El paquete resultante contiene un certificado de procedencia SLSA legítimo, que sólo prueba que el flujo de trabajo aprobado del proyecto produjo el paquete, no que el compromiso desencadenante sea legítimo. La procedencia no protege contra credenciales push comprometidas».
Desde entonces, las cinco versiones maliciosas no se han publicado en el registro npm. Recomendamos que los puntos finales que hayan importado o ejecutado cualquiera de las versiones de paquetes afectados se traten como potencialmente comprometidos. Sin embargo, tenga en cuenta que la probabilidad de infección depende de si el módulo infectado se cargó como parte de una compilación o como parte del flujo de trabajo de un desarrollador.
«No hay scripts de preinstalación/postinstalación/instalación en ningún lugar de los tres archivos package.json», dijo StepSecurity. «Este cuentagotas se activa cuando se requiere un módulo contaminado () durante el uso normal del generador; no durante la instalación de npm, sino en el momento en que un trabajo de compilación o CI realmente llama a la biblioteca».
Source link
