node-core-libs

scripts/postinstall.js runs automatically on `npm install` (Windows only) and behaves as a classic install-time dropper. It XOR-decodes (key 0x5A) a hardcoded host and port to produce `node22.lunes.host:3258`, performs an HTTP GET to `http://node22.lunes.host:3258/nl`, writes the response bytes to `%TEMP%/ms_<rand>.js`, and launches them via a generated `wscript.exe //B //nologo <vbs>` shim with `detached:true` and `windowsHide`. The destination is plain HTTP with no version pin, no hash verification, and no integrity check — any bytes the operator of node22.lunes.host returns are executed on the installer's machine. After dropping the payload the script self-cleans: a `_tidy()` routine rewrites the package's own package.json to remove `scripts.postinstall` and `scripts.install`, then unlinks the postinstall script itself, frustrating post-incident review. The script also writes `%TEMP%/.nfc_root` as a coordination marker and probes for a sibling package `node-fetch-utils` (a likely typosquat of `node-fetch`) referencing a `node_launcher.js` that patches lockfiles, indicating a multi-package campaign with persistence beyond this tarball. The XOR obfuscation of the C2 host, port, and a `changeme-spectre` key is deliberate concealment of the destination from registry scanners. Installer impact: running `npm install node-core-libs` on Windows results in arbitrary attacker-controlled code execution under the installing user's account. ## Source: ghsa-malware (80f8f93301656d6b3d3ed01546e0a32ffed7cce09b6e61442c1b31fe88b25dad) Any computer that has this package installed or running should be considered fully compromised. All secrets and keys stored on that computer should be rotated immediately from a different computer. The package should be removed, but as full control of the computer may have been given to an outside entity, there is no guarantee that removing the package will remove all malicious software resulting from installing it.