The software supply chain has once again emerged as a critical front line for enterprise security, highlighted by a sophisticated, large-scale npm supply chain attack documented by Microsoft Threat Intelligence. Dubbed “Miasma: The Spreading Blight,” this campaign specifically targeted the @redhat-cloud-services npm scope, weaponizing 32 maliciously modified packages spanning across more than 90 distinct versions (including widely adopted libraries like frontend-components-utilities, frontend-components, rbac-client, and javascript-clients-shared). Unlike traditional rogue package injections that rely on basic typo-squatting or social engineering, the threat actors behind the Miasma campaign successfully infiltrated an upstream Continuous Integration and Continuous Delivery (CI/CD) pipeline—specifically the RedHatInsights/javascript-clients repository. By hijacking this trusted infrastructure, the attackers exploited legitimate GitHub Actions OpenID Connect (OIDC) publishing workflows. This allowed them to distribute trojanized packages that boasted valid, authentic cryptographic provenance signatures, fundamentally undermining the automated trust ecosystems that modern enterprises rely on to verify library integrity.
Deconstructing the 4.29 MB Dropper: Multi-Layer Cryptography and Bun Runtime Abuse
The execution mechanism of the Miasma payload is a masterclass in defense evasion, pivoting on a 4.29 MB heavily obfuscated dropper script masquerading inside a modified index.js while leaving source-map metadata entirely unchanged to obscure pipeline tampering. The infection begins silently via a weaponized preinstall hook defined in the package’s package.json, forcing automatic execution during standard npm install operations without requiring any manual user interaction or explicit application execution. The payload’s defense evasion relies on a heavily layered cryptographic progression designed to blind traditional static analysis engines. At Stage 1, the outer wrapper leverages a massive character-code array decoded at runtime using a variable Caesar cipher (ROT-XX) transformation, which is subsequently interpreted using dynamic eval() execution.
Once executed, Stage 2 leverages AES-128-GCM to decrypt two hidden blobs embedded within the dropper. The first blob dynamically fetches the Bun JavaScript runtime directly from official, legitimate Bun infrastructure, while the second carries the primary payload. By initiating a complex runtime process lineage (node → shell → bun → payload), the malware actively shifts its execution context away from traditional Node.js-focused endpoint detection and response (EDR) hooks. The final layers (Stages 3 and 4) leverage aggressive Obfuscator.io protections consisting of rotated string arrays, decoder functions, and hundreds of alias wrappers, reinforced by a custom cryptographic string cipher. This custom routine derives keys using PBKDF2-HMAC-SHA-256 with 200,000 iterations, followed by multiple SHA-256-seeded permutation and XOR stages, significantly complicating reverse engineering and static signature detection.
Advanced Post-Exploitation: Scrutinizing Linux Runner Memory Scraping and Privilege Escalation
Once firmly established across Windows, macOS, or Linux systems—with Linux CI/CD runners serving as the primary target—the decrypted primary payload acts as an exhaustive multi-platform credential harvester. The malware targets cloud service provider configurations, searching out Amazon Web Services (AWS) credentials via the Instance Metadata Service (IMDS) and Elastic Container Service (ECS) metadata endpoints, alongside scraping Azure and Google Cloud Platform (GCP) management portal OAuth2 tokens from local service environments. Additionally, the malware scans for HashiCorp Vault instances listening locally and harvests Kubernetes Service Account tokens.
To bypass the native secret masking built into automated build environments, Miasma incorporates an advanced process-memory scraping mechanism. By systematically iterating through the /proc filesystem on Linux runner systems, the malware isolates the Process ID (PID) belonging to the Runner.Worker process. It then executes memory dumps, scraping runtime memory segments directly for raw JSON strings containing sensitive keys (such as ACTIONS_RUNTIME_TOKEN and ACTIONS_ID_TOKEN_REQUEST_TOKEN) using targeted regular expressions (grep -aoE '"[^"]+":{"value":"[^"]*","isSecret":true}'), completely neutralizing standard CI/CD logging redactions. Furthermore, the payload performs targeted local privilege escalation by injecting a passwordless sudoers rule (runner ALL=(ALL) NOPASSWD:ALL) through a bind mount directed at /etc/sudoers.d/runner, validating sudo access before executing deeper system operations and modifying /etc/hosts to redirect DNS and neutralize security product monitoring.
Worm Propagation Mechanics and the Destructive Honeytoken Safeguard
The true danger of the Miasma campaign lies in its self-propagating worm capabilities and ruthless persistence strategies. For exfiltration and propagation, the malware avoids reliance on a singular, high-profile command-and-control (C2) domain that could be quickly blacklisted. Instead, it utilizes three diverse avenues across a rotating pool of 16 attacker-controlled GitHub accounts per session. Channel A dynamically creates public repositories on the victim’s own GitHub account with randomized names matching an adjective-creature-<0-99999> pattern to host exfiltrated JSON arrays containing stolen keys. Channel B injects malicious tracking scripts (.github/setup.js) directly into non-protected downstream code branches using the Git Data API, committing changes under the spoofed persona of [email protected] with the commit message chore: update dependencies [skip ci]. Channel C acts as a fallback path interacting with the Anthropic API (api.anthropic.com:443/v1/api), verifying stolen Claude keys while maintaining a swappable live exfiltration path.
Crucially, the attackers implemented a devastating failsafe mechanism: a decoy honeytoken explicitly named IfYouInvalidateThisTokenItWillNukeTheComputerOfTheOwner. If the malware detects that an analyst or automated security tool attempts to interact with or invalidate this specific token, it trips a destructive wiper routine. This fail-safe command triggers an immediate rm -rf ~/ and rm -rf ~/Documents, completely destroying the developer’s home directory, local codebase, and configurations to eliminate forensic evidence.
Our Opinion: The Fragility of Cryptographic Provenance and the Rise of Weaponized DevOps
The Miasma campaign represents a watershed moment in software supply chain security, exposing a glaring architectural vulnerability in modern DevOps trust frameworks. For years, the security industry has championed Supply-chain Levels for Software Artifacts (SLSA) and cryptographic provenance attestations via frameworks like Sigstore as the ultimate defense against code tampering. However, Miasma demonstrates a sobering reality: if threat actors can compromise the underlying identity layer—in this case, via trusted OIDC publishing workflows within a legitimate CI/CD pipeline—the resulting malware carries an impeccable, cryptographically valid seal of authenticity. This effectively transforms our most sophisticated security controls into a vehicle for misplaced trust.
Furthermore, the malware’s inclusion of a destructive wiper payload triggered by honeytoken interaction signals a dark shift toward active anti-analysis tactics designed to hold developer machines hostage. Organizations can no longer treat build environments as transient, isolated black boxes. To counter threats of this caliber, engineering teams must implement strict runtime monitoring within runners, tightly restrict OIDC token scopes, enforce mandatory multi-party approvals for all upstream package releases, and treat the execution of npm install hooks with the same level of zero-trust scrutiny as running an unverified binary directly on a production server.
