npm Malware Hides C2 Traffic Inside Hugging Face
Compromised npm packages drop a RAT that exfiltrates to Hugging Face, hiding C2 traffic where AI teams least expect it
Most supply chain malware gives itself away with a weird outbound connection. A package phones home to some sketchy IP, your network tooling lights up, and a defender goes digging. That signal is the whole reason network monitoring works.
A recently reported campaign removes that signal almost entirely, and it does it by abusing the one platform AI teams trust most.
What happened
Microsoft Threat Intelligence flagged two compromised npm packages, utils-terminal@3.2.1 and logger-active@3.2.1. On install, they drop a remote access trojan that logs keystrokes, captures screenshots, and hunts specifically for crypto wallet data. Standard infostealer behavior so far.
The interesting part is where the stolen data goes. Instead of running their own command-and-control servers, the attackers use Hugging Face repositories for C2 and exfiltration. The implant pulls instructions from and pushes stolen archives to huggingface.co, the same domain your team hits all day when pulling models and datasets.
The packages trace back to npm user hexalpha10 (author toskypi). There is a fallback C2 at 195.201.194.107:8010 and c2-toskypi.onrender.com, plus persistence through registry Run keys, systemd services, and scheduled tasks named MicrosoftSystem64.
Why this is worse for AI builders
Here is the uncomfortable bit for anyone shipping AI products.
A traditional web shop has no reason to talk to huggingface.co. If that connection shows up in their logs, it is anomalous by definition, and a halfway decent SOC catches it. The malicious traffic stands out because it does not belong.
In an AI-heavy environment, it belongs completely. Your build pipeline pulls models from Hugging Face. Your developers fetch datasets. Your inference services hit the API constantly. A RAT exfiltrating to huggingface.co/api looks identical to a Tuesday afternoon. The defensive signal that protects everyone else is exactly the signal you have trained yourself to ignore.
This is the pattern we keep seeing in vibe-coded and agent-heavy stacks. The convenience that makes the stack fast to build is the same surface an attacker hides behind. Trusted infrastructure is not safe infrastructure. It is just infrastructure your monitoring has learned to wave through.
What to actually do
You cannot block Hugging Face if you build AI products. So the detection has to get more specific than the domain.
Flag huggingface.co/api connections coming from places that have no business making them. Your CI runner pulling a model is expected. A postinstall script on a developer laptop opening a session to Hugging Face is not. Scope the trust by origin, not just by destination.
Beyond that, the usual supply chain hygiene applies and matters more than ever. Pin your dependencies and review lockfile changes. Disable install scripts where you can (npm install --ignore-scripts) and audit the ones you cannot. Watch for the persistence artifacts: unexpected systemd services, scheduled tasks, or registry Run keys, especially anything wearing a Microsoft-sounding name like MicrosoftSystem64. Check installed versions against the named indicators above and rip them out if you find a match.
The takeaway
Attackers have figured out that the fastest way past your filters is to ride infrastructure you already trust. For AI teams, Hugging Face is now part of that trusted set, which means it is now part of your attack surface too.
The fix is not paranoia about every model download. It is being precise about which systems are allowed to make which calls, and treating "we use this all the time" as a reason to watch more closely, not less.
This is the kind of blind spot we look for when we audit AI-heavy and vibe-coded applications. If you are not sure what your stack is quietly trusting, that is usually where to start.