"For defenders, the important lesson is to treat lookalike build dependencies as potential delivery mechanisms, not just harmless naming noise," JFrog warned after uncovering a multi-stage Windows remote access trojan hidden inside an npm package that posed as a core JavaScript build tool.
JFrog's discovery and the package postcss-minify-selector-parser
New analysis from JFrog identified a malicious npm package named postcss-minify-selector-parser that was crafted to resemble the legitimate postcss-selector-parser library. JFrog noted the genuine library has "more than 150 million weekly downloads," and the malicious package remained available on the npm registry at the time of their report.
JFrog traced the malicious cluster to a publisher using the name abdrizak and found two related packages in the same cluster: postcss-minify-selector and aes-decode-runner-pro. Decoded payloads from two of these packages led to the same Windows attack chain.
Supply-chain tactic: package-impersonation and lookalike naming
According to JFrog, the attacker intentionally chose a name close enough to the legitimate package to pass a quick dependency review. The malicious package used the same keywords — postcss, selector and parser — and even listed the genuine postcss-selector-parser among its own dependencies to appear plausible during cursory checks.
JFrog characterized the incident as a package-impersonation attack and emphasized that lookalike build dependencies can function as delivery mechanisms rather than merely naming noise.
From npm import to Windows RAT: the multi-stage execution chain
JFrog's analysis shows the malicious code executed immediately when the package was imported. The file that should have contained parser logic instead held a large encrypted blob and an AES-256-GCM decoder. Once decrypted, the payload acted as a dropper that wrote a PowerShell script to disk and executed it.
The PowerShell script downloaded an additional payload from a domain posing as a driver site, nvidiadriver[.]net. It retrieved a ZIP archive disguised as a Windows patch, unpacked the archive into the temporary folder, and revealed a bundled Python runtime plus multiple Nuitka-compiled modules. A VBScript bootstrapper launched those components and started the remote access trojan (RAT).
Once active, JFrog said the RAT contacted its command server over encrypted HTTP, established persistence using a registry run key, profiled the host and checked for virtual machine environments. Functionally, the malware could open a remote shell, transfer files to and from the machine, and steal data.
Google Chrome targeted; credential hygiene urged
JFrog reported the RAT was specifically built to target Google Chrome: it could steal saved logins and was designed to defeat the browser's newer app-bound encryption. In response to the discovery, JFrog urged anyone who installed the malicious packages to remove them, examine the temp-folder and registry for traces, and rotate any stored credentials.
What this means for technologists and security teams, affected enterprises, and end users
- Technologists and security teams: Treat lookalike packages as active threats rather than naming anomalies. The incident shows an import can trigger a native Windows attack chain that drops and executes PowerShell and native runtimes, so review dependency intake processes, scanning, and runtime monitoring for post-install activity.
- Affected enterprises and procurement leaders: A library that appears to reference a trusted dependency may still be malicious; dependency provenance and publisher verification should be part of procurement checkpoints. JFrog’s tracing to a publisher name (abdrizak) and sibling packages demonstrates the value of supply-chain mapping.
- End users and developers: If you imported any of the flagged packages, follow JFrog’s steps: remove the package, search temporary folders and registry run keys for artifacts, and rotate stored credentials that may have been accessed by the RAT.
This case is a succinct reminder that supply-chain attacks can begin at the simplest step in a build: importing a package that looks right at a glance. The specifics — an encrypted blob inside a supposedly benign parser file, an AES-256-GCM decoder, a PowerShell dropper, a ZIP disguised as a patch downloaded from nvidiadriver[.]net, and a Python-based RAT that targets Chrome logins — show how an npm dependency can turn into a multi-stage Windows intrusion.
For defenders, the practical next steps are clear in JFrog's guidance: treat lookalike build dependencies as potential delivery mechanisms, scan for the described artifacts, and rotate credentials that may have been exfiltrated. The incident leaves open a concrete question for maintainers and registries alike: how to make automated dependency review robust enough to flag affordances of malicious intent without overwhelming developers with false positives.
Original report: https://www.infosecurity-magazine.com/news/lookalike-npm-package-postcss/
