A group of malicious npm packages is using the shape and naming of JavaScript build tooling to reach developer machines, with JFrog identifying three packages that appear to lead into the same Windows-focused malware chain.
The packages are named aes-decode-runner-pro, postcss-minify-selector, and postcss-minify-selector-parser. Their download counts were listed at 145, 256, and 615, respectively, in the available package data. All three were published by an npm user named “abdrizak.”
The naming is the point. Two of the packages present themselves as AES or custom-codec utilities while depending on the legitimate postcss-selector-parser package. Another presents itself as a PostCSS selector minifier and depends on postcss-minify-selector-parser. That creates a plausible-looking dependency path around a real JavaScript ecosystem component with massive usage.
For developers and security teams, the practical concern is not just that a package name looks suspicious. It is that a small, parser-like package can sit inside a familiar build pipeline while doing something very different on a Windows host.
What the npm packages do
The three packages identified in the campaign are:
- aes-decode-runner-pro, listed with 145 downloads
- postcss-minify-selector, listed with 256 downloads
- postcss-minify-selector-parser, listed with 615 downloads
JFrog’s analysis describes the packages as leading to a common attack chain. The package postcss-minify-selector-parser appears to borrow credibility from postcss-selector-parser, a widely used npm library. The source package name is close enough to look routine during a quick dependency review, especially in projects that already use PostCSS tooling.
That kind of naming does not need to fool everyone. It only needs to blend into one developer workflow, one transitive dependency review, or one rushed install command.
How the Windows malware chain unfolds
The packages include a JavaScript dropper that writes a PowerShell script called settings.ps1 to disk and runs it. That PowerShell script is described as downloading the next stage from an external server using curl.exe.
The next payload is a ZIP archive. Inside it is a Visual Basic Script file named update.vbs, along with a Python runtime, a Python loader named loader.py, and several Python extension modules compiled with Nuitka.
JFrog describes the Visual Basic stage as setting up the Python environment and launching loader.py, although that specific implementation detail should be treated as analysis-based rather than independently confirmed. From there, the Python components appear to handle the malware’s core behavior.
The reported capabilities include host profiling, Chrome credential theft, Chrome extension data collection, shell command execution, and file upload and download through a command-and-control server identified as 95.216.92207:8080. Those capabilities are also based on JFrog’s malware analysis and should be treated as indicators for investigation rather than assumptions about every exposed machine.
The malware components are split across several native Python extension modules:
- config.pyd, which contains constants, command IDs, C2 information, and registry key names
- api.pyd, which handles HTTP communication with the command-and-control infrastructure
- audiodriver.pyd, which is described as managing the main RAT loop
- command.pyd, which handles host profiling, virtual machine checks, file transfer, and shell execution
- auto.pyd, which is associated with Chrome credential and extension theft, including an attempt to bypass app-bound encryption protections
- util.pyd, which provides tar and gzip archive helper functions
That modular layout matters because it makes the payload look less like a single obvious malicious binary and more like a staged toolchain assembled during install or execution.
What to check if these packages were installed
Teams that find these package names in a project should treat the affected developer machine as potentially exposed, especially if the install happened on Windows.
A practical response should include:
- Remove aes-decode-runner-pro, postcss-minify-selector, and postcss-minify-selector-parser from package manifests and lockfiles where they appear.
- Inspect developer machines for artifacts tied to the chain, including settings.ps1, update.vbs, loader.py, bundled Python runtimes, and suspicious .pyd modules.
- Review npm install logs, endpoint telemetry, PowerShell execution history, and wscript.exe activity around the time the package was installed.
- Rotate credentials that may have been accessible from affected machines, especially browser-stored secrets, npm tokens, GitHub credentials, SSH keys, Docker credentials, and cloud or CI tokens.
- Audit recent commits and dependency changes for lookalike package names, unexpected transitive dependencies, or packages introduced outside normal review.
The credential rotation step is deliberately broad. The reported malware behavior centers on developer workstations, and those systems often hold more than one kind of reusable secret.
The wider pattern hitting developer ecosystems
The npm findings sit alongside several other recent software supply chain campaigns targeting developers and TypeScript or JavaScript workflows.
One package, apintergrationpost, claimed to be a Node.js integration client for authorized red team exercises but was described by SafeDep as delivering a Linux RAT called MYRA. SafeDep said the package compiles a native C rootkit during installation, adds multiple persistence mechanisms, disguises itself as a systemd service, supports fileless execution, and provides interactive shell access with live screen streaming.
Another package, @withgoogle/stitch-sdk, impersonated Google’s Stitch AI design tool. It was described as targeting developer credentials from eight locations, including Claude Code, git configuration, ~/.git-credentials, SSH public keys, GitHub CLI, npm configuration, ~/.npmrc, and Docker configuration files.
A separate cluster of packages named procwire, routecraft, endpointmap, bytecraft, and staticlayer was tied to a Windows dropper flow. In that cluster, routecraft depended on procwire, while procwire depended on endpointmap and bytecraft. SafeDep described staticlayer as a server-side component that delivered files only when a client matched the expected dropper User-Agent, although that behavior should be treated as analysis-based rather than independently verified.
There was also a supply chain attack involving the gonex-AI/Understand-Anything knowledge graph tool. In that case, the malicious flow was described as using hardcoded command-and-control servers, a campaign marker, an XOR-decrypted bot client, and a second-stage command resolved through blockchain transaction data.
That activity overlaps with PolinRider, a North Korean supply chain operation that has been observed injecting obfuscated JavaScript into developer configuration files across nearly 2,000 compromised GitHub repositories. The injected code was tied to BeaverTail, a downloader and stealer that can lead to the InvisibleFerret backdoor.
Why lookalike build dependencies are hard to catch
The lesson for engineering teams is uncomfortable but simple: malicious packages do not need to look like malware at the package registry level. A package that sounds like a minifier, parser, SDK, or integration client can be enough to pass casual review, especially when it borrows naming patterns from legitimate tools.
That makes dependency governance a developer workflow problem, not only a malware-scanning problem. Package names, maintainers, install scripts, transitive dependencies, and newly introduced build-time tools all deserve scrutiny, particularly when they run code during installation.
For npm projects, the useful checks are familiar but often skipped under deadline pressure: pin dependencies, review lockfile diffs, restrict install scripts where possible, monitor new maintainers and new package names, and keep high-value developer credentials out of browsers and local plaintext configuration files when they are not needed.
The risk is not limited to production servers. Developer laptops and CI runners are attractive targets because they often sit close to code, credentials, package publishing rights, and deployment systems. A fake PostCSS-adjacent package is a small entry point, but the blast radius can be much larger if it reaches the wrong workstation.