DEV Community

NetSecOpsIO
NetSecOpsIO

Posted on • Originally published at cyber.netsecops.io

npm Supply Chain Attacks: Miasma RAT & CI/CD Pipeline Exploits

#cybersecurity #supplychainattack #malware #threatactor

Originally published on CyberNetSec.

Executive Summary

The npm ecosystem's threat landscape has fundamentally shifted from isolated nuisance incidents to systematic, high-consequence supply chain attacks. Since the Shai-Hulud worm demonstrated the viability of self-propagating malware on the npm registry in September 2025, threat actors have accelerated their campaigns in both frequency and technical sophistication. A July 15, 2026 report from Unit 42 details this evolution, culminating in a recent attack against the AsyncAPI project. Attackers compromised its CI/CD pipeline by exploiting unprotected GitHub release branches, bypassing code reviews to publish packages trojanized with the Miasma Remote Access Trojan (RAT). This incident underscores a strategic focus by adversaries on compromising automated build and release processes to steal credentials and distribute malware through trusted developer channels.

Threat Overview

The era of simple typosquatting on npm has been supplanted by complex, multi-stage supply chain attacks. The Shai-Hulud worm in 2025 served as a proof-of-concept, and threat actors have since refined its methods.

  • April-May 2026 Campaigns: The threat actor TeamPCP launched multiple campaigns, including "Shai-Hulud: The Third Coming" and "Mini Shai-Hulud," introducing credential-free access techniques and achieving record-high malicious package publication rates.
  • June 2026 Red Hat Compromise: An attack compromised at least 32 packages under the @redhat-cloud-services npm namespace, deploying an early version of the Miasma payload.
  • July 2026 AsyncAPI Compromise: On July 14, 2026, attackers executed the "miasma-train-p1" campaign, compromising four core AsyncAPI GitHub repositories. Unlike previous attacks that may have relied on compromised user accounts, this incident exploited a process gap in the CI/CD pipeline itself. The attackers pushed malicious code directly to unprotected pre-production release branches, which then triggered automated workflows to build and publish trojanized packages to the public npm registry.

These events illustrate a clear trend: attackers are moving up the software supply chain, targeting the very automation that powers modern development to achieve widespread and trusted distribution of their malware.

Technical Analysis

The AsyncAPI compromise provides a detailed case study of modern npm supply chain attack TTPs.

Attack Chain

  1. Initial Access & Execution: Attackers gained access to push code directly to unprotected next and schema branches in AsyncAPI's GitHub repositories. A malicious commit (3eab3ec9304aa26081358330491d3cfeb55cc245) was pushed, bypassing mandatory peer review controls that were only enforced on the main branch. This maps to T1195.001 - Compromise Software Dependencies and Development Tools.
  2. CI/CD Pipeline Abuse: The malicious commit triggered trusted GitHub Actions workflows. The injected code executed within the CI runner's environment.
  3. Credential Access: The script harvested sensitive environment secrets, including NPM_TOKEN and GITHUB_TOKEN, from the CI runner. This is a form of T1552.006 - Unsecured Credentials: CI/CD Secrets.
  4. Malicious Package Publication: Using the stolen NPM_TOKEN, the attackers programmatically published five trojanized packages to the official @asyncapi scope on npm, leveraging the stolen credentials as per T1078 - Valid Accounts.

Payload Analysis: Miasma RAT

The payload is a multi-stage RAT designed for stealth and persistence.

The RAT creates a lockfile at ~/.config/.miasma/run/node.lock to prevent multiple instances and uses OS-specific paths like ~/Library/Application Support/nodejs/ or %APPDATA%\nodejs\ for its cache to blend in with legitimate Node.js activity.

Impact Assessment

The compromise of a trusted open-source project's release pipeline carries significant business and security impact for both the project maintainers and downstream consumers.

  • Erosion of Trust: Such attacks undermine trust in the open-source ecosystem and the specific project. Developers may become hesitant to use or contribute to AsyncAPI, fearing their own systems could be compromised.
  • Widespread Downstream Compromise: Any developer, build server, or production environment that pulls the trojanized package version becomes infected. The Miasma RAT can then steal credentials, exfiltrate source code, or serve as a pivot point into the victim's network.
  • Intellectual Property Theft: The RAT's primary function is credential harvesting, which can lead to the theft of proprietary code, API keys, and other sensitive data from developer workstations and CI/CD systems.
  • Remediation Costs: AsyncAPI and its users face significant costs for incident response, forensic analysis, credential rotation, and rebuilding trust. All downstream users must audit their systems to identify and eradicate the compromise.

IOCs — Directly from Articles

The following indicators were explicitly mentioned in the source report.

Type Value Description
IPFS CID Qmet4fhsAaWMBUxNDfREHwgiyDeSWy4YSYs9wiKUW5jGyf Stage-2 Miasma RAT payload.
IPFS CID QmQobZSp1wRPrpSEQ56qnyq7ecZh5Bg5k1fnjt4SUwwHb9 Stage-2 Miasma RAT payload.
File Path ~/.config/.miasma/run/node.lock Miasma RAT operational lockfile.
File Path ~/.node_cache/ Disguised persistence directory (Linux/macOS).
File Path ~/Library/Application Support/nodejs/ Disguised persistence directory (macOS).
File Path %APPDATA%\nodejs\ Disguised persistence directory (Windows).
Service Name miasma-monitor.service Persistence mechanism on Linux/macOS.
Registry Key miasma-monitor Persistence mechanism (Run key) on Windows.
String Shai-Hulud: The Third Coming String found in related TeamPCP campaigns.
Other 3eab3ec9304aa26081358330491d3cfeb55cc245 Malicious commit hash in AsyncAPI repository.
Other 148100 Attacker's GitHub user ID.

Cyber Observables — Hunting Hints

Security teams may want to hunt for the following patterns, which could indicate related activity:

Type Value Context / Where to Look Description
command_line_pattern node * --detached EDR, Process creation logs (Event ID 4688) The malware spawns a detached child process to run in the background.
network_traffic_pattern Outbound TCP/443 to *.ipfs.dweb.link or gateway.ipfs.io Firewall logs, Proxy logs, Netflow The payload fetches its second stage from public IPFS gateways.
file_path ~/.config/.miasma/ File system monitoring, EDR The malware creates this directory for its operational files.
service_name miasma-monitor.service systemctl command output, Linux audit logs The service used for persistence on Linux systems.
registry_key HKCU\Software\Microsoft\Windows\CurrentVersion\Run\miasma-monitor Windows Registry, EDR The Run key used for persistence on Windows systems.
log_source GitHub Audit Logs GitHub Enterprise/Organization audit logs Search for direct commits to protected or release-critical branches by unexpected users.
url_pattern */api/v0/cat?arg=Qm* Web proxy logs The API call pattern used to retrieve files from an IPFS node.

Detection & Response

Detecting and responding to this type of supply chain attack requires a multi-layered approach focusing on the development lifecycle and endpoint behavior.

Detection Strategies

  1. CI/CD Monitoring: Implement strict monitoring on Git repositories. Alert on any direct commits to release, pre-production, or main branches that bypass the standard pull request and peer review process. Use GitHub audit logs to track these events.
  2. Endpoint Detection (EDR): Deploy EDR solutions on developer workstations and build runners. Create rules to detect suspicious process chains, such as an npm or node process spawning a detached child process, making outbound network connections to unusual destinations like IPFS gateways, or writing new executable files.
  3. Network Analysis: Monitor for and alert on outbound connections from build servers and developer machines to known IPFS gateways or other decentralized file-sharing networks. This can be achieved through Network Traffic Analysis (D3-NTA).
  4. Dependency Scanning: While static analysis may be bypassed by obfuscation, tools that analyze package behavior at installation time (Dynamic Analysis (D3-DA)) can identify malicious actions like network callbacks or file system modifications.

Response Actions

  1. Isolate: Immediately isolate affected developer machines and build servers from the network to prevent lateral movement or further data exfiltration.
  2. Revoke Credentials: Revoke all NPM_TOKEN, GITHUB_TOKEN, and other secrets present in the compromised CI/CD environment and on affected developer machines.
  3. Remove Malicious Packages: Work with the npm security team to remove the trojanized package versions from the registry.
  4. Audit and Remediate: Conduct a full audit of all systems that may have installed the malicious package. Remove the persistence mechanisms (systemd service, Run key) and any related files.

Mitigation

Preventing CI/CD pipeline compromises requires both technical controls and process improvements.

  1. Harden Git Repositories: Enforce branch protection rules on ALL branches that feed into a release pipeline, not just main. Require signed commits and mandatory peer reviews for any code changes to these branches. This is a form of Application Configuration Hardening (D3-ACH).
  2. Principle of Least Privilege for Tokens: CI/CD access tokens (NPM_TOKEN, GITHUB_TOKEN) should be short-lived and scoped with the minimum permissions necessary. For npm, use granular access tokens that can only publish to specific packages.
  3. Dependency Integrity: Use lockfiles (package-lock.json, yarn.lock) and run npm ci instead of npm install in automated environments to ensure that only vetted dependency versions are installed. This helps prevent unexpected updates to malicious versions.
  4. Sandboxed Builds: Execute CI/CD jobs in ephemeral, isolated environments (sandboxes or containers) with no access to the broader corporate network. The environment should be destroyed after each run. This aligns with Application Isolation and Sandboxing.
  5. Vet Dependencies: Use tools to scan for known vulnerabilities in dependencies. For critical dependencies, consider vendoring or mirroring them in a private, trusted registry after a security review.

Top comments (0)