Malicious NPM package pretends to be Claude Code

Paul McCarty
10 mins
October 27, 2025

"Malicious-Claude-Code" malware pretends to be official Anthropic CLI

On October 27, 2025 AEST, The Safety research team's automated malicious package detection engine identified a new malicious NPM package called "@chatgptclaude_club/claude-code".

This package was published by a NPM user named "lustfully3904" using the email address a1973908310@gmail.com.

The package was originally published in August, and there have been a total of 19 versions of the package in total.

tl;dr

This package deploys a sophisticated payload that targets Claude Code installations, either locally on a developers computer, or in a CI pipeline. The intent is to steal Anthropic credentials, but more worriyngly the malware includes a bidirectional C2 server. Our initial analysis leads us to believe that this package is meant to proxy Claude commands and sensitive data back to the threat actor, while also allowing them to utilize someone else's Claude to run their own commands.

Lookalike package

The malicious package "@chatgptclaude_club/claude-code" is based on the legitimate "@anthropic-ai/claude-code". The Anthropic package is one of the most popular NPM packages and averages over five million downloads per week.

Here's the legitimate package:

And here's the malicious one:

Aside from the downloads there is almost no difference between the two. This is made possible by the fact that NPM still after all these years doesn't validate what users add to their package metadata. Because of this lack of validation, threat actors can use the real GitHub repositories in their malicious packages, which adds legitimacy.  Many NPM users think that the GitHub Repository data in the right upper part of the package page is validation by the platform, but unfortunately that's not the case.

Overwrites the local Claude implementation

If you look at the package.json file you can see that there's a bin property that maps the alias "claude" to the start.js file in the root of the package directory.

This is a clever way of forcing the user to run the malicious fake claude-code pacakge. On a Mac or a Linux server, the alias that is created by the bin property creates a symlink from /usr/local/bin/claude to the malicious start.js file in the node_modules directory. On a Mac or Linux machine, the /usr/local/bin directory will be in all users path, like this:

If you look in the /usr/local/bin directory you can see the symlink:

ubuntu@test:~$ ls -al /usr/local/bin/
total 8
drwxr-xr-x  2 root root 4096 Oct 26 06:44 .
drwxr-xr-x 11 root root 4096 Jul  9 12:09 ..
lrwxrwxrwx  1 root root   52 Oct 15 01:45 claude -> ../lib/node_modules/chatgptclaude_club/claude-code/start.js

That's some intense obfuscation!

The payloads are heavily obfuscated and use multiple obfuscation techniques. For example it uses hex-encoded strings like "x61 x70 x69" which decode to ASCII characters:

  • "f x73 " = "fs"
  • "p x61 x74 x68" = "path"
  • "a x70 x69 x2E x61 x6E x74 x68 x72 x6F x70 x69 x63" = "api.anthropic"

It also uses:

  • Unicode (`\uXXXX`) and Hex (`\xXX`) escapes
  • XOR string encryption with variable keys
  • Confusing Unicode identifiers (ꓳΟ, ଠଠ, 〇ₒ)
  • Control flow obfuscation with nested ternaries

What does the malware payload do?

There are two distinct stages to this payload.

Stage one - start.js

The first stage starts when a user executes the "claude" command on their system. They think they are calling the real claude cli, but they're not. They're calling the malicious NPM package via the symlink in /usr/local/bin.

This executes the start.js file, which immediately looks for Claude API keys or existing sessions in environment variables, or in the ~/.claude/ directory. It then enumerates some basic system information, and then creates a ~/.chatclub/ directory to store the stolen data.

Finally, it injects the intercepter.cjs into the real Claude CLI .

Stage two - intercepter.cjs

This JavaScript file acts as a proxy between the compromised host and the legitimate Anthropic API, api.anthropic.com/v1/messages.  This file hooks into the 'fs', 'http', and 'child_process' modules to intercept traffic to Anthropic to exfiltrate all user prompts, conversations, authentication data, and billing and usage data which it sends to a C2 server at claude-code[.]chatgptclaude[.]club.

Every 60 seconds, the malware sends a status update to the C2 server. This isn't just for monitoring—the C2 server can send commands back:

  • update_token - Refresh stolen credentials with new ones
  • redirect_model - Execute man-in-the-middle attacks by redirecting your API calls to different Claude models
  • stop - Terminate the malware and exit the process (useful for avoiding detection)

The malware uses environment variables to configure itself:

  • process.env[".claude"] - C2 server URL
  • process.env.SESSION_ID - Victim tracking identifier
  • process.env.DEVICE_ID - Device fingerprint
  • process.env.ACCESS_TOKEN - C2 authentication token

This means the malware can be configured without modifying code, making it harder to detect through static analysis.

Indicators of Compromise (IOCs)

Based on my research this threat campaign has several IOCs you can look for:

NPM Packages - all versions:

@chatgptclaude_club/claude-code

URL/Domains:

claude-code[.]chatgptclaude[.]club

Files:

~/.chatclub/

How can Safety help protect you from these attacks?

Traditional vulnerability scanning happens too late - after potentially malicious code is already in your system. Which means that ASPM and EDR solutions don't protect you from this type of threat.

But all is not lost, as the Safety Firewall protects develoeprs and CI pipelines proactively. Every package installation request is analyzed before reaching public repositories. Malicious, vulnerable, and policy-violating packages are automatically blocked before they can enter your systems, preventing rather than just detecting threats.Every package installation request is analyzed before reaching public repositories. Malicious, vulnerable, and policy-violating packages are automatically blocked before they can enter your systems, preventing rather than just detecting threats.Every package installation request is analyzed before reaching public repositories. Malicious, vulnerable, and policy-violating packages are automatically blocked before they can enter your systems, preventing rather than just detecting threats.

You can sign up for a free Safety account and try the Safety Firewall HERE. Feel free to reach out to me with any questions!

Let us know if this blog post helped you

I hope this blog post has helped you. Feel free to hit me up directly if you have any questions about this campaign.

Paul McCarty - Head of Research, Safety

You can find me on LinkedIn and BlueSky.

Related

Similar Posts

Secure your supply chain in 60 seconds.
No sales calls, no complex setup.
Just instant protection.

Get Started for Free
View Documentation
Arrow
CTA Graph