Compromised AsyncAPI npm Packages Deliver Multi-Stage Botnet Malware

Four compromised npm packages in the @asyncapi namespace have been observed distributing a multi-stage botnet loader, according to findings from OX Security, SafeDep, Socket, and StepSecurity.

The affected packages are listed below –

• @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)

“The compromised packages deploy an obfuscated first-stage payload that downloads an encrypted second-stage payload, identified as Miasma, from IPFS,” Socket said.

The poisoned packages ship a hidden JavaScript implant, with each of them containing an injected source file that decodes to the same second-stage downloader. Unlike previous iterations that leveraged install hooks to trigger the execution of a JavaScript payload, the malicious code in this case is run when the infected module is loaded by Node.js, after which it launches a detached background node that downloads and executes the malware from IPFS.

The next-stage payload is an encrypted JavaScript loader named “sync.js,” which is written to operating system-specific paths and executed. The downloader URL is “ipfs[.]io/ipfs/QmQobZSp1wRPrpSEQ56qnyq7ecZh5Bg5k1fnjt4SUwwHb9.” The loader contains two components –

Besides facilitating credential theft, AI tool poisoning, LAN lateral movement, and worm-like propagation on npm, PyPI, and Cargo registries, Miasma features a persistence mechanism of its own, setting up a systemd, crontab, macOS launchd, and Windows Registry autostart keys.

“Although the malware has some similarities to the Shai-Hulud and Miasma campaigns, and it contains the Miasma string multiple times inside its code, this malware isn’t the same as them, nor is it attributed to the Miasma/Shai-Hulud/TeamPCP campaigns that we’ve seen in the past,” OX Security’s Moshe Siman Tov Bustan said.

Furthermore, it incorporates a dead man’s switch that monitors a stolen token and triggers a directory wipe if the token is revoked, while avoiding systems identified as sandboxes or virtual environments, as well as those that have their current language set to Russian or have security tools from CrowdStrike, SentinelOne, Microsoft Defender, CarbonBlack, Cylance, Osquery, Tanium, and Qualys installed.

“Its clearest operational path is REST-based C2: the implant beacons to an HTTP endpoint, accepts encrypted tasking, and posts command results back to the same infrastructure. Around that core, the payload also carries support for upload transport, command ciphering, node signing, payload updates, file management, shell execution, and persistence writing.”

According to StepSecurity, the attacker is said to have gained push access to the repositories and used the project’s own legitimate GitHub Actions release pipeline to publish packages with valid OIDC provenance attestations. The supply chain attack did not involve the theft of an npm token.

“Both attacks are CI/CD pipeline compromises, not stolen npm tokens or malicious maintainers,” security researcher Rohan Prabhu said. “The attacker pushed commits under a placeholder git identity and let each repository’s real release workflow do the publishing via npm’s GitHub OIDC trusted-publisher integration.”

“The resulting packages carry legitimate SLSA provenance attestations, proving only that the project’s authorized workflow produced them, not that the triggering commits were legitimate. Provenance does not protect against a compromised push credential.”

All five malicious versions have since been unpublished from the npm registry. It’s advised to treat any endpoint that imported or executed one of the affected package versions as potentially compromised. However, it bears noting that exposure depends on whether the infected module was loaded as part of a build or a developer workflow.

“There is no preinstall/postinstall/install script anywhere in any of the three package.json files,” StepSecurity said. “This dropper fires when the poisoned module is require()d during normal use of the generator: the moment a build or CI job actually calls into the library, not at npm install time.”