Supply Chain Alert: Malicious PostCSS Packages Dropping Windows RATs
Just came across reports of a new supply chain attack targeting the npm ecosystem. Threat actors are weaponizing the trust we place in build tools, specifically mimicking PostCSS utilities to deliver a Windows Remote Access Trojan (RAT).
The three malicious packages identified so far are:
aes-decode-runner-propostcss-minify-selectorpostcss-minify-selector-parser
While the download counts aren't massive (sub-1000), the impact on a compromised dev machine can be severe, especially given the persistence mechanisms of a RAT. The payload seems to execute specifically on Windows environments, so Mac/Linux devs aren't entirely off the hook (they could be propagating malicious code), but they might not be the primary target of the malware itself.
If you are running a CI/CD pipeline or local dev environment, you should audit your dependencies immediately. Here is a quick Bash command to scan your current environment for these specific artifacts:
npm ls --depth=0 2>/dev/null | grep -E "aes-decode-runner-pro|postcss-minify-selector"
For those managing Windows-based build agents, you might want to run a quick check for unusual process executions from Node, as the RAT likely spawns a child process:
Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4688} | Where-Object {$_.Message -like "*node.exe*" -and $_.Message -like "*powershell.exe*"} | Select-Object TimeCreated, Message | Format-List
If you find the packages, remove them, nuke `node_modules`, and rotate any credentials stored on that box.
What are you guys using for automated blocking in your pipelines? Are you relying on npm audit, or have you moved to stricter third-party scanners to catch these supply chain hits before the lockfile is even generated?
Good catch on the IOCs. We've blocked these specific package hashes at the registry level, but that's reactive. If you're using a SIEM, you can hunt for this behavior by looking for node.exe spawning shells, which is abnormal for a build process in most contexts.
DeviceProcessEvents
| where InitiatingProcessFileName == "node.exe"
| where FileName in ("powershell.exe", "cmd.exe", "powershell_ise.exe")
This usually catches the RAT execution phase regardless of the specific package name used to deliver it.
This is exactly why I hate relying on the public registry directly for production builds. We proxy npm through Artifactory and set it to 'quarantine' mode for any new package that hasn't been explicitly whitelisted by the team. It adds friction to the dev process, but it stops these low-hanging-fruit attacks instantly. If you can't use a proxy, strict dependency pinning (removing the ^ in package.) is your bare minimum defense.
From the sysadmin side, the scariest part here is the RAT landing on developer workstations. Devs often have local admin rights and cached credentials for cloud services. If your EDR is only deployed on servers and not on employee laptops, you're basically inviting the attackers in. I'm pushing to get our CI runners moved to non-privileged containers just to mitigate the blast radius if something like this slips through.
Verified Access Required
To maintain the integrity of our intelligence feeds, only verified partners and security professionals can post replies.
Request Access