The PostCSS Package That Wasn’t PostCSS
- Javier Conejo del Cerro
- 23 jun
- 3 min de lectura
Software supply chain attacks continue to evolve, and threat actors are increasingly abusing the trust developers place in package repositories. In this campaign, attackers published several malicious npm packages disguised as legitimate PostCSS development tools. Although the package names appeared to belong to common front-end build workflows, their true purpose was to deploy a sophisticated Windows remote access trojan capable of stealing credentials, executing commands, and maintaining persistent access to compromised systems. The incident highlights how a seemingly insignificant dependency can become the entry point for a full-scale compromise of developer environments and corporate infrastructure.
Phase 1: Impersonating Trusted Development Tools
The campaign began with the publication of npm packages that closely resembled legitimate PostCSS tooling. By choosing names associated with popular development libraries, the attackers increased the likelihood that developers would mistake them for authentic dependencies.
One of the most convincing examples was “postcss-minify-selector-parser,” which closely resembled the legitimate “postcss-selector-parser” package that receives more than 127 million weekly downloads. This naming strategy allowed the malicious packages to blend naturally into software projects and dependency trees.
Phase 2: PowerShell Downloader Execution
Once installed, the malicious package executed embedded JavaScript code that wrote a PowerShell script to disk.
The PowerShell component acted as the first-stage downloader, contacting an external server controlled by the attackers and retrieving additional payloads. Rather than delivering the malware directly through npm, the attackers used a multi-stage approach to reduce detection and maintain flexibility in future operations.
This stage transformed what appeared to be a simple package installation into the beginning of a much larger compromise.
Phase 3: Building the Malware Environment
The downloaded payload arrived as a ZIP archive containing multiple components, including Visual Basic scripts, a Python runtime, custom Python loaders, and several compiled Python extension modules.
The Visual Basic script prepared the environment and launched the Python loader, which orchestrated the remainder of the infection chain. This modular architecture allowed the attackers to separate functionality across multiple components, making analysis and detection more difficult.
Each stage served a specific purpose, from environment preparation to payload execution and command handling.
Phase 4: RAT Deployment and Credential Theft
Once active, the remote access trojan established communication with its command-and-control infrastructure and began gathering intelligence from the infected system.
The malware collected host information, performed virtual machine detection checks, stole Google Chrome credentials, harvested data from browser extensions, executed shell commands, and transferred files between the victim system and attacker-controlled servers.
Particularly concerning was the malware’s ability to bypass Chrome’s App-Bound Encryption protections, allowing it to access sensitive browser data that many users assume is adequately protected.
Phase 5: Expanding the Attack Surface
The discovery coincided with several additional campaigns targeting the npm and TypeScript ecosystem.
These included a Linux RAT disguised as a red-team utility, credential-stealing packages impersonating Google’s Stitch AI platform, and multiple dependency chains designed to deliver additional malware during installation. Researchers also identified overlaps with the North Korean-linked PolinRider operation, which has compromised nearly 2,000 GitHub repositories to distribute BeaverTail and InvisibleFerret malware families.
Together, these campaigns demonstrate a coordinated trend: threat actors are no longer targeting only end users but are increasingly focusing on developers, software supply chains, and CI/CD environments where access to credentials and infrastructure can provide significantly greater rewards.
Who Was Affected?
The primary victims are developers and organizations relying on npm packages as part of their software development process.
Developer workstations, build servers, CI/CD runners, and corporate environments that installed the malicious packages could expose sensitive credentials, browser data, cloud secrets, SSH keys, npm tokens, Docker configurations, and other valuable information.
Because modern development workflows often grant elevated access to infrastructure, a single compromised machine can become a gateway into broader enterprise environments.
Measures to Defend Against the Attack
Remove all identified malicious packages immediately.
Rotate passwords, API keys, tokens, and other credentials stored on affected systems.
Audit developer endpoints for persistence mechanisms and unusual outbound connections.
Verify package authenticity before installation.
Implement software supply chain security controls and dependency monitoring.
Restrict unnecessary privileges within development environments.
Monitor CI/CD pipelines for unexpected package installations.
Use package provenance validation whenever available.
Review browser-stored credentials and sensitive extension data.
Continuously monitor for indicators of compromise associated with the campaign.
Conclusion
This campaign demonstrates how attackers continue to weaponize developer trust by disguising malware as legitimate software dependencies. What appeared to be a harmless PostCSS-related package concealed a sophisticated multi-stage infection chain capable of deploying a fully featured remote access trojan.
As software ecosystems become increasingly interconnected, dependency repositories have become one of the most attractive targets for cybercriminals. Organizations must treat package management as a critical security function and recognize that even the smallest dependency can become a pathway to credential theft, remote access, and broader infrastructure compromise.
Comentarios