Malicious NPM Package Claude Code Rust Native Binary
This rule watches for a specific npm package name — @srothgan/claude-code-rust-*, which pretends to provide 'Claude Code Rust' native binaries and a private Bun runtime bridge. It flags any command line where that package name shows up, whether installed, run, or invoked from a build script.
How the attack works
An attacker publishes a package under the scoped name @srothgan/claude-code-rust-* to npm, claiming it ships a Rust native binary and a Bun bridge for Claude Code. A victim installs it (via npm, pnpm, yarn, or bun), or a lifecycle script inside it runs, or someone directly executes the vendored binary. In every case, the package's name appears as a literal string on the command line that gets run. This rule catches that string appearing on any executed command — it does not inspect what the package actually does once running.
Netzilo detection
Netzilo reports this behaviour when it is observed.
- Signature ID
- 6f3c9a41-8d2b-4e57-b0a9-1c74e2f5ad38
- Severity
- Medium
Why it matters
This is a narrow tripwire for one named artifact, not a general malware detector. If it fires, it confirms this specific package touched a host — it does not confirm the package is malicious, nor does it show what happened after installation, since no install-time or file-write data is used.
What you can do
- →Treat any hit as a report to investigate, not a confirmed compromise — check what the package actually did on the host.
- →If the package is present, isolate the host and inspect the installed files and any binaries it dropped before deciding on remediation.
- →Remove the package via your normal dependency-audit process, and keep a record of when and where it appeared.
- →Add @srothgan/claude-code-rust-* to your internal package deny-list until its behaviour is independently verified.
Known benign look-alikes
- Incident responders or malware analysts deliberately fetching or unpacking the package in a sandbox to triage it (the IOC string is unavoidable in that workflow).
- Dependency/SBOM scanners, IOC sweeps and vulnerability tooling that pass the package name as an argv token — the common ones are suppressed by filter_inspection, but an in-house wrapper script will still match.
- Developers removing or auditing the package as part of remediation — suppressed by filter_remediation, but only when the verb and the package name are in the same shell segment.
- Shell history replay, CI log playback, or a documentation/runbook command that echoes the package specifier back onto a command line.
- A future, legitimately maintained package published under the same scope and name — the rule is a name-based IOC and cannot distinguish provenance.