Supply Chain Trojanized Claude Binary npm Package

How the attack works

The attacker publishes a scoped npm package named like a Claude Code platform sub-package, for example @go-hare/claude-code-darwin-x64, mimicking the naming pattern legitimate tools use to ship native binaries per OS/architecture. A developer or an AI coding agent installs it via npm, npx, or bunx, or it appears in a package.json dependency block. At install or first run, the platform binary executes automatically with the privileges of the person or agent running the install. The rule watches for this package name pattern appearing in install commands, execution of the unpacked binary, tool responses mentioning the scope, or registry/tarball HTTP requests.

Netzilo detection

Why it matters

A successful install runs attacker code with developer-level privileges, which can lead to credential theft, source code exfiltration, or further compromise of the build environment. This rule only flags the suspicious package naming and install/execution activity — it does not confirm exploitation or block the install.

What you can do

• →Verify the publisher and scope of any Claude-related npm package before installing, especially ones with an OS/arch suffix in the name.
• →Check package provenance and download counts on the npm registry rather than trusting the name alone.
• →Pin dependencies and use a lockfile with integrity hashes to prevent silent substitution of platform sub-packages.
• →If a suspicious package is found installed, treat it as compromised: remove it, rotate any credentials the environment could access, and inspect for further unauthorized activity.

Known benign look-alikes

• A vendor legitimately shipping Claude tooling as npm platform sub-packages (the esbuild/swc optionalDependencies pattern). The rule reports rather than blocks precisely because this naming shape is not inherently malicious - triage by confirming the publishing scope and package provenance on the registry.
• Incident responders or dependency-scanning tooling running 'npm view/info/audit/why' or 'npm uninstall/remove' against the malicious package name during cleanup - suppressed by filter_investigation.
• Threat-intelligence write-ups, advisories, SBOM diffs or this rule's own documentation pasted into an agent conversation - suppressed by filter_threat_intel.
• A lockfile or 'npm ls' style tool_response that merely enumerates an already-quarantined dependency; the finding is accurate but the event is an audit artefact rather than a fresh installation.

References

• https://attack.mitre.org/techniques/T1195/002/

Related threats