Latest / The Digital Warfare Podcast / EP. 175: MALFEX npm Campaign Delivers RATs and Credential Stealers Through Developer Packages
Transcript
- Digital Warfare: You're listening to the Digital Warfare podcast. Today, we're looking at a software supply chain campaign that demonstrates why developers themselves are becoming valuable entry points into enterprise environments. The campaign is called Malfex. It targets the NPM ecosystem. And researchers have linked the operation to eight malicious packages that have accumulated more than 40,000 downloads. The payloads include remote access malware. Credential stealers and downloaders. And some of the malicious packages remained available for installation long after the campaign began. Here's what happened. NPM is one of the largest package ecosystems used by JavaScript and node.js developers. Instead of writing every function from scratch, developers install reusable packages into their projects. That model makes software development faster, but it also creates a powerful trust relationship. When a developer runs NPM install, Code inside a package can execute automatically through lifecycle scripts. Malfex abuses exactly that behavior. Researchers identified 12 packages connected to the same operator. Eight contained malicious functionality. Four appeared to serve as benign cover packages. The campaign has been active since at least August 2023, but the malicious packages do not all behave the same way. There are several independent infection paths. One group of packages uses obfuscated pre-install and post-install scripts. Those scripts execute automatically during package installation. They retrieve a Windows executable from remote infrastructure, save it locally, and launch it. In one attack chain, the downloaded file leads to overlord RAT. A RAT, or remote access trojan, gives an attacker persistent control over the infected machine. That can include command execution. Surveillance, additional malware deployment, and access to local data. The delivery chain also uses techniques designed to make the payload appear less suspicious. Researchers observed Windows executables served with misleading content types and packaged using legitimate components, including assigned AutoIT executable. But Malfex does not stop at remote access. Another chain distributes a node.js information stealer known as MoveInlike. Its targets include stored browser information from Chrome, Edge, Brave, Opera, Vivaldi, and Yandex. It can collect cookies and saved login information. It also targets Telegram desktop session data, and cryptocurrency users face additional risk. The malware searches for extensions and wallets associated with platforms such as MetaMask, Phantom, and Coinbase wallet. Collected information can then be archived, divided into smaller chunks, and sent to attacker-controlled infrastructure. There is also a third delivery path involving the package function flag. That package has been malicious since July 2025 and accounts for the majority of Malfex downloads. Its malicious versions reference changing payload names such as node.exe, svchoast.exe, nocry.exe, and malfex.exe. That rotation is important. Blocking one file name or one hosting location does not necessarily eliminate the campaign. And there is another significant defensive problem. Traditional package security checks may not catch every malicious dependency. Some packages associated with Malfex had security advisories, others did not. That means an organization relying exclusively on advisory databases could believe a dependency is safe simply because no warning exists. So what should defenders do? First, Search dependency inventories and lock files. Look for all eight identified malicious Malfex packages, not just the packages that currently have advisories. Second, if one of these packages was installed on a Windows system, treat that host as potentially compromised. Do not assume uninstalling the NPM package removes the payload it delivered. Third, isolate affected systems, investigate persistence, review running processes, examine scheduled tasks. Inspect outbound network connections, and look for unexpected executables written during NPM installation. Fourth, review developer security controls. Package installation should not automatically be treated as trusted activity simply because the dependency comes from a public registry. And remember one important number: more than 40,000 downloads does not mean 40,000 confirmed infections. Package download statistics measure reach. They do not prove that every package executed successfully on a vulnerable Windows host, but the exposure is still significant. The larger lesson is that software supply chain security begins before production. An attacker does not always need to breach your web server. They can compromise the developer building the software. A malicious dependency can execute inside an environment that already contains source code, tokens, credentials, and access to internal systems. So review your dependencies, monitor what executes during package installation, and treat developer workstations as part of your critical security perimeter, because when attackers compromise the tools used to build software, they may gain access long before that software ever reaches production. This has been your Digital Warfare Daily Brief. Stay secure. We'll see you tomorrow.