Eight malicious npm packages tied to the MALFEX campaign carried three separate Windows malware delivery paths. One fetched an Overlord remote access trojan loader. Another installed the movinlike information stealer when an application loaded a package. A third hid a downloader behind an ASCII art function, but its latest payload was unavailable for analysis.
The split matters because each path crosses a different execution boundary. A package installation can trigger an install script, while an ordinary module import can run code later. As a result, a clean installation log would not rule out the stealer path.
Eight Packages, Three Execution Paths
The campaign linked 12 npm packages to what appears to be one operator. Eight contained malicious code; four served as cover. However, the eight malicious packages did not all deliver the same payload, and the three paths did not share infrastructure.
Three packages, tlxbnhd, tldriver, and mxdriver, formed the Overlord path. Another three, native-runner, img-to-native, and cdn-img-fetch, formed the stealer chain. Finally, function-color pulled in function-flag, which concealed a separate downloader.
This packaging changes where an exposed developer or build system might encounter the code. The Overlord packages can act during installation when dependency scripts are permitted. By contrast, the stealer chain waits for an application to load the module. Meanwhile, function-color adds a dependency hop before the function-flag script runs.
Install Hooks Carry the Overlord Loader
The three Overlord packages placed obfuscated JavaScript in preinstall and postinstall scripts. Those scripts retrieved a file served with a PNG content type. Yet the file was a Windows IExpress archive containing a signed AutoIt interpreter and an encrypted script.
The script decoded Overlord RAT. Its code also indicated process hollowing into the signed Windows binary TapiUnattend.exe, although testing did not observe that step at runtime. The loader established persistence through a scheduled task configured to repeat every five minutes.
Overlord’s decoded code could derive command servers from encrypted Solana transaction memos. Still, the analyzed build had no configured address or server list, and testing observed no command traffic. The capability should therefore not be mistaken for an observed active connection in this sample.
A Module Load Starts the Stealer Chain
By contrast, the stealer packages used no install hook. Instead, native-runner depended on img-to-native, which loaded cdn-img-fetch. Loading that final module started a download of an apparent image. Encrypted executable data sat after the PNG end marker.
The chain decrypted a Go downloader, which fetched the movinlike Node.js stealer. Its targets included Discord authentication tokens, browser cookies and saved logins, Telegram Desktop session data, and cryptocurrency wallets. The malware sent collected data through a Discord webhook.
This path would evade a review limited to npm lifecycle scripts. It also makes package name and dependency inspection relevant beyond the installation phase. Execution begins when application code imports the package, even if the initial install produced no suspicious script output.
The ASCII Art Function Masks Another Downloader
function-flag used a postinstall script to call its own ASCII art function. A specific font value triggered hidden code that attempted to download and run a Windows executable. Its wrapper, function-color, brought the package into an installation as a dependency.
The latest function-flag payload could not be recovered because its host did not respond during the analysis. Consequently, its final malware family remains unconfirmed. The available evidence does not connect this path to movinlike.
An empty catch block swallowed download errors. Therefore, an installation could complete normally even when the remote payload was unavailable. A successful package install was not evidence that the package was harmless.
Downloads and Advisories Leave Different Blind Spots
As of October 1, 2026, npm statistics showed 40,767 cumulative downloads across the eight malicious packages. function-flag accounted for 37,419 of them. These figures measure registry activity, not infected devices, unique users, or successful execution on Windows.
Advisory coverage was also uneven at the time of the research. Six of the eight packages had malware advisories. However, function-flag and function-color had none, while the cdn-img-fetch advisory listed only versions 1.0.0 and 1.0.1. The analysis also identified 1.0.2 and 1.0.3 as malicious.
At the time, function-flag, function-color, and cdn-img-fetch installable around September 29 to October 1. That finding describes the registry state then; it does not establish their current availability. Likewise, a missing advisory did not mean the package lacked malicious behavior.
Execution Shifts From Installation to Application Runtime
npm 12.2.0 blocks dependency install scripts by default unless a project approves them. That gate can prevent the Overlord and function-flag hooks from running in that configuration. However, it does not govern the reported require() behavior in the stealer chain.
MALFEX spans two distinct moments in a software workflow. Installation can launch a downloader under configurations that allow lifecycle scripts. Later, application runtime can start a separate chain through a package import. A script review covers the first moment; it cannot explain the image fetch that begins when cdn-img-fetch loads.
Conclusion: Install-Time Protection Was Only Half the Boundary
MALFEX demonstrates why securing dependency installation does not automatically secure the software that runs afterward. Eight malicious npm packages used three distinct delivery paths to introduce remote access tooling, credential-stealing malware, and additional downloaders into Windows environments. Some relied on installation scripts, while others delayed execution until an application loaded the dependency.
The distinction is critical. npm’s newer install-script restrictions address a genuine supply-chain risk by preventing unapproved lifecycle scripts from running automatically. However, the movinlike delivery chain required no installation hook. Its malicious behavior began when Node.js imported the package, triggering a download disguised as an image and eventually delivering an information stealer.
The campaign also exploited weaknesses in dependency visibility. Malicious functionality appeared behind ordinary package names, additional dependencies, and seemingly harmless utility functions. Incomplete malware advisories created another gap: some malicious versions were not covered by published warnings. A package could therefore install without suspicious output or appear absent from advisory-based detection while still carrying executable malicious code.
The lesson extends beyond npm. Trust established during installation cannot become permanent authorization for everything a dependency executes later.
Why This Threat Matters
- Malware can execute at different stages. MALFEX used installation hooks and ordinary module imports, requiring security controls beyond a single installation checkpoint.
- Dependencies can conceal the actual payload. Wrapper packages introduced malicious components indirectly, making inspection of the complete dependency chain essential.
- Legitimate file formats can disguise executable content. Attackers presented Windows executables as images and concealed encrypted payload data inside apparent PNG files.
- Runtime activity determines the actual exposure. The
movinlikechain targeted browser credentials, Discord tokens, Telegram sessions, and cryptocurrency wallets after execution. - Advisory coverage cannot establish package safety. Missing warnings and incomplete affected-version lists left malicious packages outside some vulnerability feeds.
- Download counts do not prove compromise. The reported 40,767 downloads demonstrate distribution, not successful execution on an equivalent number of devices.
Where Defensive Control Must Operate
Xcitium Advanced EDR, powered by Xcitium’s patented Zero-Dwell platform, provides critical endpoint visibility across malicious installation scripts, suspicious downloads, unauthorized process execution, persistence mechanisms, and information-stealing activity.
Execution Governance strengthens protection by restricting what unknown or untrusted executables can modify or access when they run. However, malicious JavaScript executing inside an already trusted Node.js process requires additional dependency governance and runtime monitoring.
Secure the Dependency Beyond Installation
Organizations should maintain npm’s install-script restrictions, inspect direct and transitive dependencies, and verify package contents rather than relying exclusively on registry advisories or successful installation logs.
Security teams must also investigate unexpected child processes, external executable downloads, scheduled tasks, and network connections originating from development tools and Node.js applications. Where MALFEX packages were installed, affected Windows systems should be examined for persistence, credential theft, and unauthorized remote access.
The essential security boundary extends throughout the software lifecycle. A dependency approved for installation must not automatically receive unrestricted authority to execute additional code, access sensitive information, or introduce persistent malware when the application begins running.
