Cross-Platform RAT via `lib-mtop`: npm Supply Chain Analysis
Everyone's probably seen the breaking report regarding the 18 malicious npm packages surfacing today. The attackers are specifically targeting Chinese-speaking dev environments, utilizing a cross-platform RAT that is quite sophisticated. The primary culprit appears to be lib-mtop, an unscoped package designed to mimic Alibaba's private libraries.
Since this is a cross-platform threat, standard Windows-only EDR rules might miss the behavior on Linux or Mac build agents. The malware seems to execute immediately upon installation via preinstall scripts.
Immediate Remediation: You'll want to scan your environments for this specific package name immediately. Here is a Python script to recursively check for the malicious package name in your dependency tree:
import os
import
def scan_directory(root_dir):
malicious_package = "lib-mtop"
for subdir, dirs, files in os.walk(root_dir):
if 'package.' in files:
path = os.path.join(subdir, 'package.')
with open(path, 'r') as f:
data = .load(f)
deps = data.get('dependencies', {})
dev_deps = data.get('devDependencies', {})
if malicious_package in deps or malicious_package in dev_deps:
print(f"[!] Found {malicious_package} in {path}")
scan_directory('./node_modules')
**Discussion:**
We've seen dependency confusion before, but the targeting here is very specific. How are you enforcing namespace boundaries to prevent unscoped packages from overriding your internal private registries? Are you using `.npmrc` strict scopes or network-level blocks?
Great post. We caught this in our CI/CD pipeline because we block all unscoped packages by default in our enterprise .npmrc config. It's a bit painful to onboard new libs, but it totally stops dependency confusion attacks like this one.
ini
.npmrc
scope=@mycompany registry=https://registry.npmjs.org/
Block unscoped
lib-mtop=false
Has anyone analyzed the C2 infrastructure yet? I'm curious if it's hardcoded or domain fronting.
From a SOC perspective, the cross-platform nature is concerning. We're seeing the parent process as node spawning distinct shells.
If you're using Sentinel, try hunting for unusual child processes:
DeviceProcessEvents
| where InitiatingProcessFileName == "node.exe"
| where FileName in ("bash", "sh", "powershell", "cmd")
| project Timestamp, DeviceName, FileName, ProcessCommandLine, InitiatingProcessCommandLine
We found a few false positives with build scripts, but it's worth tuning.
Sasha's approach is solid for prevention, but for detection on existing agents, I recommend checking npm audit logs specifically for the preinstall phase. This RAT relies on scripts running immediately upon download. You can audit the manifest of installed packages to find suspicious binaries:
npm ls -- | grep -A 5 '"scripts"' | grep -v "^ --"
Additionally, for Linux agents, monitor for outbound connections to non-CDN IP addresses initiated by node, as this specific strain tries to phone home immediately post-install.
Verified Access Required
To maintain the integrity of our intelligence feeds, only verified partners and security professionals can post replies.
Request Access