npm Supply Chain RAT: PostCSS Impersonation & Dependency Confusion

Originally published on satyamrastogi.com

Three malicious npm packages masquerading as PostCSS tools delivered Windows RAT payloads. Analysis of supply chain attack mechanics, payload delivery chains, and detection gaps in dependency management.

---

Malicious npm Packages Pose as PostCSS Tools to Deliver Windows RAT

Executive Summary

This is a textbook supply chain attack leveraging npm's trust model. Three packages published in June 2026 - aes-decode-runner-pro, postcss-minify-selector, and postcss-minify-selector-parser - delivered Windows RAT payloads to developers. The attack demonstrates why automated dependency management without behavioral validation is a critical vulnerability.

What makes this particularly effective: PostCSS is a legitimate, widely-used build tool. Developers hunting for PostCSS plugins via search or copy-pasting dependency names from tutorials become easy prey. The attacker didn't need zero-days, social engineering sophistication, or exploit kits. Just npm account registration and package uploads.

This follows the exact pattern we've seen in credential theft campaigns prioritizing convenience over complexity. Low barrier to entry, high payoff.

Attack Vector Analysis

MITRE ATT&CK Framework Mapping

This attack chains multiple techniques:

1. T1195.001: Compromise Third-Party Software Supply Chain - Malicious package publication on npm registry
2. T1566.002: Phishing - Spearphishing Link - Package discovery and recommendation (implicit trust)
3. T1059.003: Command and Scripting Interpreter - Windows Command Shell - RAT payload execution
4. T1105: Ingress Tool Transfer - Initial RAT download mechanism
5. T1571: Non-Standard Port - C2 communication channels (typical)

Kill Chain Breakdown

Stage 1: Reconnaissance & Naming

• Attacker identifies PostCSS as high-value target (builds present in thousands of projects)
• Creates names that blend legitimacy with search results: postcss-minify-selector exploits incomplete package searches
• The aes-decode-runner-pro variant suggests obfuscation awareness (generic naming, "pro" implies legitimacy)

Stage 2: Publication & Discovery

• Published via single npm account (operational security failure on attacker's end, but irrelevant if account is compromised)
• Download counts (145-615) indicate organic discovery - developers finding these through search, tutorials mentioning PostCSS plugins without explicit package names, or typosquatting variants

Stage 3: Installation & Payload Delivery

• npm install triggers package installation scripts (preinstall/postinstall hooks)
• Payload likely embedded in install scripts or dependencies
• Windows RAT delivered with elevated privileges if npm install run as admin (common in CI/CD)

Stage 4: C2 & Persistence

• RAT establishes reverse shell to attacker infrastructure
• Persistence mechanisms (Task Scheduler, registry RunKeys, WMI event subscriptions)
• Developer machine becomes internal network foothold

Technical Deep Dive

Attack Surface: npm Package.json Execution Model

The vulnerability isn't a bug in npm - it's the intentional design. Npm allows arbitrary code execution during installation:

{
 "name": "postcss-minify-selector",
 "version": "1.0.0",
 "scripts": {
 "preinstall": "node ./setup.js",
 "postinstall": "node ./inject.js"
 },
 "dependencies": {
 "malicious-payload": "file:./payloads/rat.exe"
 }
}

When developer runs npm install postcss-minify-selector, package.json scripts execute automatically. No confirmation, no sandboxing. This is T1195.001 in its purest form.

Payload Mechanisms (Likely TTPs)

Based on Windows RAT delivery patterns:

1. Direct Executable Drop

   • Payload downloaded via curl/PowerShell during postinstall
   • Stored in temp directory with random name
   • Executed with parent process privileges (npm running context)

2. Registry Injection
   

 # Typical persistence
 reg add "HKCU\Software\Microsoft\Windows\CurrentVersion\Run" /v "PostCSS Helper" /t REG_SZ /d "C:\Users\[user]\AppData\Local\Temp\[rat].exe"

1. Scheduled Task

 schtasks /create /tn "PostCSS Update" /tr "C:\Users\[user]\AppData\Local\Temp\[rat].exe" /sc minute /mo 5

1. DLL Hijacking into Legitimate Process
   • RAT loads into Visual Studio Code, Node.js, or other dev tools
   • Easier to avoid detection than standalone executable

Why This Works Against Blue Teams

• Trust Delegation: Developers trust npm ecosystem. Package managers = legitimate.
• Execution Context: npm often run with developer privileges or in CI/CD pipelines with admin context
• Signature Evasion: RAT payload can be obfuscated, downloaded post-installation, or wrapped in legitimate-looking code
• Log Noise: Thousands of packages install daily. Detecting malicious postinstall scripts requires behavioral analysis, not just hashing

Detection Strategies

Network-Based Detection

1. C2 Beaconing Pattern Analysis

   • Monitor for unsigned executables in AppData/Temp spawned from npm/Node.js processes
   • Track DNS queries from development machines to suspicious infrastructure during package installation
   • Use CISA threat feeds to cross-reference C2 IP ranges

2. Egress Filtering

   • Restrict outbound connections from development machines to known C2 ranges
   • Block non-standard ports from npm-spawned processes
   • Implement DNS sinkholing for malware-associated domains

Host-Based Detection

1. Process Monitoring

 Alert on: npm.exe or node.exe -> child process = powershell.exe or cmd.exe
 Alert on: npm.exe -> child process = curl.exe or wget.exe with egress to non-org IP
 Alert on: npm.exe -> registry modification (Run, RunOnce, Services)
 Alert on: npm.exe -> scheduled task creation

1. File Integrity Monitoring

   • Monitor node_modules directories for unexpected .exe, .dll, .ps1 files
   • Track modifications to system directories during npm install operations
   • Flag downloaded executables in temp directories

2. Package Manifest Analysis
   

 # Red flag indicators in package.json
 - preinstall/postinstall scripts with > 100 lines
 - scripts executing arbitrary code vs. build tasks
 - dependencies on unknown/unpopular packages
 - use of exec(), child_process, or dangerous system calls in scripts

Supply Chain Validation

1. Dependency Auditing

 npm audit
 npm ls --depth=3 # Review entire tree

But this is insufficient. Real-world detection requires:

1. Behavioral Package Analysis

   • Scan package.json scripts before installation
   • Require explicit approval for postinstall scripts
   • Log and alert on any network access during npm install

2. Hash-Based Validation

   • Maintain checksums of approved package versions
   • Reject installations if hashes don't match (requires npm lockfile discipline)

Mitigation & Hardening

Immediate Actions (Detection & Response)

1. Audit Installed Packages

 npm ls | grep -E "(postcss-minify-selector|aes-decode-runner-pro)"
 # Check git logs for when these were added

1. Incident Response

   • Isolate affected development machines
   • Capture RAT executable for analysis (NVD CVE cross-reference if available)
   • Monitor for lateral movement from compromised dev accounts
   • Credential reset for any developer with compromised machine

2. Timeline Reconstruction

   • Determine when malicious packages were installed
   • Check if RAT C2 was established (firewall logs, DNS queries)
   • Identify code commits made from compromised machines (potential code injection)

Strategic Hardening

1. Dependency Management Policy

   • Maintain internal npm registry proxy (e.g., Nexus, Artifactory)
   • Pre-screen all packages before allowing installation
   • Require lockfiles and checksums for reproducible builds
   • Implement deny-by-default for new packages

2. Execution Restrictions

   • Run npm install in sandboxed CI/CD environments only
   • Never run npm install as root/admin on developer machines
   • Use npm install --ignore-scripts for dependency audits (then verify manually)

3. Network Segmentation

   • Restrict outbound connections from development networks
   • Implement network policies blocking C2 communication patterns
   • Monitor VPN access from development machines for anomalies

4. Process Isolation

   • Container-based development environments with network restrictions
   • Virtual machines per project with snapshots before package installation
   • Browser-based IDE environments with no direct system access

This mirrors the vendor supply chain RCE pattern we documented in Texas TPWD - the attack vector is dependency management trust.

Detection Evasion Countermeasures

• Obfuscation of Detection Logic: Attackers will embed RAT payloads in legitimate-looking node modules (crypto libraries, compression utilities)
• Delayed Execution: RAT may not beacon C2 until days after installation, evading detection windows
• Process Hollowing: RAT injects into legitimate processes (VS Code, Git), avoiding command-line execution

Blue teams must treat every npm install as a potential execution point.

Key Takeaways

• npm's postinstall script execution model is a supply chain vulnerability by design, not bug. Attackers exploit convenience.
• This attack required no sophistication: package registration, payload hosting, basic obfuscation. Yet it bypassed most organizational defenses due to developer trust in package managers.
• Detection gaps exist because security teams don't monitor npm install operations with the same rigor as other execution contexts.
• The 145-615 download counts indicate developers found these organically. Naming conventions (PostCSS imitation) are more effective than sophisticated exploit kits.
• Persistence mechanisms (Task Scheduler, registry) ensure RAT survives reboots and provides attacker with long-term access for lateral movement, credential harvesting, or code injection.

Defensive Priorities

1. Immediate: Audit installed packages; isolate affected machines; reset credentials.
2. Short-term: Implement dependency scanning and network restrictions around npm operations.
3. Long-term: Move to internal package registry; containerized, isolated dev environments; behavioral analysis of installation operations.

The attacker didn't need to compromise npm's infrastructure or discover zero-days. They leveraged the trust model that makes npm so convenient. Defend accordingly.

Related Articles

• ShinyHunters Playbook: Credential Theft Over Zero-Days - Low-sophistication supply chain attacks that work
• Texas TPWD License Breach: Vendor Supply Chain RCE & Identity Theft at Scale - Another vendor supply chain RCE pattern
• SocGholish Botnet Takedown: WordPress Supply Chain Persistence TTPs - CMS-based supply chain persistence mechanisms