PhantomRaven npm Infostealer: Detecting LLM-Generated Malware in Your JavaScript Supply Chain

A financially motivated threat actor has been linked to the development and distribution of PhantomRaven, a JavaScript-based information stealer pushed through the npm package registry. What makes this campaign notable — and frankly, a preview of where the threat landscape is heading — is the assessment, made with high confidence, that the malware was authored using a large language model. Researchers based that conclusion on telltale artifacts: verbose, tutorial-style comments, placeholder code left in production payloads, and statistical token-analysis patterns consistent with LLM output. The actor has reportedly presented themselves as a bug bounty hunter, a persona that costs nothing to claim and buys credibility in developer communities.

Why should defenders care beyond the novelty? Because this is the industrialization of supply-chain malware. An actor who previously needed solid JavaScript chops and operational discipline can now generate a functional infostealer, iterate on it against your detections, and ship new variants through the world's largest package registry in hours. If your organization builds JavaScript — and in 2026, almost every organization does — your developers' workstations, your CI/CD runners, and your build secrets are the target. This post breaks down how PhantomRaven-style npm stealers operate, what LLM-authored code changes about detection, and exactly how to hunt and harden against this class of threat.

Technical Analysis

The Delivery Mechanism: npm as an Attack Vector

PhantomRaven follows the now-standard playbook for npm-distributed malware:

Package publication: The actor publishes malicious or trojanized packages to npm — typically using typosquatting of popular library names, dependency-confusion naming against internal package namespaces, or freshly invented but plausible-sounding utility packages.
Lifecycle hook execution: The malicious code executes via npm lifecycle scripts — preinstall, install, or postinstall — defined in package.json. These run automatically when a developer or CI system executes npm install, with no further user interaction. This is the critical execution point and your highest-value detection surface.
Staged payload retrieval: The install script typically spawns a child process (node -e, curl, wget, or platform shells) to pull a second-stage payload from attacker infrastructure, often using paste sites, Discord webhooks, or throwaway VPS endpoints as dead drops.
Credential harvesting: As an infostealer, PhantomRaven's payload class targets the developer environment: browser credential stores and session cookies, SSH private keys (~/.ssh/), cloud provider credentials (~/.aws/credentials, ~/.azure/, ~/.config/gcloud/), .npmrc files containing registry auth tokens, .env files, Kubernetes configs, and crypto wallet data.
Exfiltration: Stolen data is packaged and exfiltrated over HTTPS to attacker-controlled endpoints or legitimate services abused as C2 channels.

The blast radius here is amplified by where the code runs. A developer workstation compromise yields browser sessions and SSH keys. A CI/CD runner compromise yields deployment credentials, signing keys, registry tokens, and direct paths into production. npm malware that executes during build is, functionally, a pipeline compromise.

The LLM Dimension: What Actually Changes for Defenders

The LLM authorship assessment is not just an interesting footnote — it has operational implications:

Lowered barrier to entry: Expect more actors and more variants. The cost of producing a working infostealer has collapsed. Volume will go up even as individual sophistication stays mediocre.
Predictable code tells: LLM-generated malware tends toward verbose explanatory comments, generic function names (stealCredentials, collectSystemInfo), over-structured error handling, and leftover placeholder logic. Static analysis and YARA-style content matching against these stylistic markers is more viable against LLM-authored code than against hand-tuned malware.
Faster iteration against detections: The same tooling that writes the malware can rewrite it. Signature-only detection against PhantomRaven specifically will have a short shelf life. Behavior-based detection — install-hook execution, unexpected child processes from package managers, credential-store access by Node processes — is durable regardless of how many times the payload is regenerated.
The 'bug bounty hunter' persona: Social engineering via credibility claims will scale the same way. Treat unsolicited security tooling, PoC repos, and 'helpful' packages from unknown publishers with the same suspicion as any unvetted dependency.

Exploitation Status

PhantomRaven is distributed in the wild via the npm registry as an active, financially motivated campaign. No CVE identifier is associated with this activity — it abuses legitimate npm functionality (lifecycle scripts, transitive dependencies) rather than a software vulnerability. There is no patch to apply; the defensive burden falls on detection, dependency hygiene, and pipeline hardening.

Detection & Response

The highest-fidelity signals for PhantomRaven-class npm malware are: (1) package managers or Node spawning shells, downloaders, or script interpreters; (2) Node processes reading credential material; and (3) Node making network connections to non-registry destinations. The detections below target those behaviors, not the specific payload hashes, so they survive payload regeneration.

Sigma Rules

YAML

---
title: Package Manager or Node Spawning Shell or Downloader
id: 3f9a1c42-7b2e-4d58-a91c-6e4b8d2f5a10
status: experimental
description: Detects npm/node/yarn/pnpm spawning shells, script interpreters, or download utilities, consistent with malicious npm lifecycle hook execution as seen in PhantomRaven-class infostealers.
references:
  - https://thehackernews.com/2026/09/claimed-bug-bounty-hunter-likely-used.html
  - https://attack.mitre.org/techniques/T1195/002/
  - https://attack.mitre.org/techniques/T1059/
author: Security Arsenal
date: 2026/09/15
tags:
  - attack.execution
  - attack.t1059
  - attack.t1195.002
logsource:
  category: process_creation
  product: windows
detection:
  selection_parent:
    ParentImage|endswith:
      - '\node.exe'
      - '\npm.cmd'
      - '\npm.exe'
      - '\yarn.cmd'
      - '\pnpm.cmd'
  selection_child:
    Image|endswith:
      - '\powershell.exe'
      - '\pwsh.exe'
      - '\cmd.exe'
      - '\curl.exe'
      - '\certutil.exe'
      - '\bitsadmin.exe'
      - '\wscript.exe'
      - '\cscript.exe'
      - '\mshta.exe'
  condition: selection_parent and selection_child
falsepositives:
  - Build tooling that legitimately shells out during install (node-gyp, native module builds)
  - Tune by allowlisting known-good package build paths in your environment
level: high
---
title: Node Inline Script Execution with Obfuscation Indicators
id: 8c2d5e71-4a6f-4b39-9c12-1d7a3e8f6b24
status: experimental
description: Detects Node.js invoked with inline evaluation flags combined with base64, eval, or remote-fetch patterns, a common PhantomRaven staging technique for second-stage retrieval.
references:
  - https://thehackernews.com/2026/09/claimed-bug-bounty-hunter-likely-used.html
  - https://attack.mitre.org/techniques/T1059/007/
  - https://attack.mitre.org/techniques/T1027/
author: Security Arsenal
date: 2026/09/15
tags:
  - attack.execution
  - attack.t1059.007
  - attack.defense_evasion
  - attack.t1027
logsource:
  category: process_creation
  product: windows
detection:
  selection_img:
    Image|endswith: '\node.exe'
  selection_inline:
    CommandLine|contains:
      - ' -e '
      - ' --eval'
      - '-p '
  selection_suspicious:
    CommandLine|contains:
      - 'eval('
      - 'Buffer.from'
      - 'atob('
      - 'base64'
      - 'https.get'
      - 'fetch('
      - 'child_process'
  condition: selection_img and selection_inline and selection_suspicious
falsepositives:
  - Developer ad-hoc scripting; rare in CI/build contexts where this rule matters most
level: high
---
title: Node Process Accessing Credential or Secret Files (Linux)
id: 5b1e8a93-2c4d-4f17-8a36-9e2c6b4d7f18
status: experimental
description: Detects Node.js processes on Linux build/dev hosts reading SSH keys, cloud credentials, npm tokens, or environment files — the core harvesting behavior of npm-distributed infostealers like PhantomRaven.
references:
  - https://thehackernews.com/2026/09/claimed-bug-bounty-hunter-likely-used.html
  - https://attack.mitre.org/techniques/T1552/001/
  - https://attack.mitre.org/techniques/T1078/004/
author: Security Arsenal
date: 2026/09/15
tags:
  - attack.credential_access
  - attack.t1552.001
  - attack.t1552.004
logsource:
  category: file_event
  product: linux
detection:
  selection_target:
    TargetFilename|contains:
      - '/.ssh/'
      - '/.aws/credentials'
      - '/.azure/'
      - '/.config/gcloud/'
      - '/.npmrc'
      - '/.netrc'
      - '/.kube/config'
  selection_env:
    TargetFilename|endswith: '.env'
  selection_proc:
    Image|contains: 'node'
  condition: (selection_target or selection_env) and selection_proc
falsepositives:
  - Legitimate deployment tooling reading credentials (scoped deployment agents)
  - Recommend scoping to developer workstations and build runners, and baselining known deploy tools
level: medium

KQL — Microsoft Sentinel / Defender for Endpoint

This query hunts the execution chain: package managers or Node spawning shells/downloaders, plus Node processes establishing outbound connections to destinations that are not the npm registry — the exfiltration and staging side of the behavior. Run it across developer workstations and build agents, and consider alerting on hits within CI/CD machine groups specifically.

KQL — Microsoft Sentinel / Defender

// Hunt: npm/Node spawning suspicious child processes AND non-registry network connections
let SuspiciousChildren = dynamic(["powershell.exe","pwsh.exe","cmd.exe","curl.exe","wget.exe","bash","sh","certutil.exe","bitsadmin.exe","mshta.exe","wscript.exe","cscript.exe","python.exe"]);
let PackageManagers = dynamic(["node.exe","node","npm.cmd","npm","yarn","yarn.cmd","pnpm","pnpm.cmd","bun"];
let ProcHits =
DeviceProcessEvents
| where TimeGenerated > ago(7d)
| where InitiatingProcessFileName in~ (PackageManagers)
| where FileName in~ (SuspiciousChildren)
| project ProcTime=TimeGenerated, DeviceName, AccountName,
    ParentProc=InitiatingProcessFileName, ChildProc=FileName,
    ChildCmd=ProcessCommandLine, ParentCmd=InitiatingProcessCommandLine,
    ReportId, DeviceId;
let NetHits =
DeviceNetworkEvents
| where TimeGenerated > ago(7d)
| where InitiatingProcessFileName in~ (PackageManagers)
| where RemoteUrl !has_any ("registry.npmjs.org","registry.yarnpkg.com","npmjs.com") or isempty(RemoteUrl)
| where RemoteIP !startswith "10." and RemoteIP !startswith "192.168." and RemoteIP !startswith "172.16."
| project NetTime=TimeGenerated, DeviceName, AccountName,
    NetProc=InitiatingProcessFileName, RemoteUrl, RemoteIP, RemotePort,
    ReportId, DeviceId;
ProcHits
| join kind=inner NetHits on DeviceName, AccountName
| where abs(datetime_diff('minute', NetTime, ProcTime)) <= 30
| project DeviceName, AccountName, ProcTime, ParentProc, ChildProc, ChildCmd, NetTime, RemoteUrl, RemoteIP, RemotePort
| order by DeviceName, ProcTime asc

Note the deliberate join: a Node child process alone may be a noisy build artifact; a Node child process followed within 30 minutes by a Node network connection to a non-registry external host is a genuinely high-fidelity signal. Tune the registry allowlist to include your internal artifact repositories (Artifactory, Nexus, GitHub Packages) so legitimate proxied installs don't fire.

Velociraptor VQL — Endpoint Hunt

Use this artifact across developer endpoints and build runners to surface live Node processes with inline-execution or downloader-style command lines, and to enumerate recently modified package.json files that declare install lifecycle hooks — the persistence-free execution vector PhantomRaven relies on.

VQL — Velociraptor

-- PhantomRaven hunt: suspicious Node processes + install-hook packages
LET suspicious_procs = SELECT Pid, Ppid, Name, Exe, CommandLine, Username, CreateTime
FROM pslist()
WHERE Name =~ '(?i)node'
  AND CommandLine =~ '(?i)(-e |--eval|eval\\(|Buffer\\.from|atob\\(|base64|child_process|https\\.get|fetch\\(|curl |wget |iwr |Invoke-WebRequest|powershell)'

LET hook_packages = SELECT FullPath, Mtime, Size,
    read_file(filename=FullPath, length=100000) AS PackageJson
FROM glob(globs=['C:/Users/*/node_modules/**/package.json',
                 '/home/*/*/node_modules/**/package.json',
                 '/opt/**/node_modules/**/package.json'],
          accessor='file')
WHERE PackageJson =~ '(?i)"(preinstall|install|postinstall)"\\s*:'
  AND Mtime > now() - 604800

SELECT * FROM suspicious_procs
UNION ALL
SELECT NULL, NULL, FullPath AS Name, NULL, PackageJson AS CommandLine, NULL, Mtime AS CreateTime
FROM hook_packages

Scope the globs to your actual project checkout paths for performance; the seven-day modification window catches recently introduced dependencies, which is where fresh malicious packages appear.

Remediation / Audit Script

The following Bash script audits a Linux developer workstation or build runner for the exposure points PhantomRaven exploits: install lifecycle hooks in dependencies, inline-execution patterns in node_modules, plaintext credential artifacts, and globally installed packages with install scripts.

Bash / Shell

#!/bin/bash
# PhantomRaven npm supply-chain audit — run on dev workstations and CI runners
set -u
echo "=== npm Supply-Chain Audit: $(hostname) $(date -u) ==="

PROJECT_DIR="${1:-$PWD}"
echo "[*] Auditing project: $PROJECT_DIR"

# 1. Find dependencies declaring install lifecycle hooks (execution vector)
echo "--- [1] Packages with preinstall/install/postinstall hooks ---"
if [ -d "$PROJECT_DIR/node_modules" ]; then
  grep -rlE '"(preinstall|install|postinstall)"[[:space:]]*:' \
    "$PROJECT_DIR/node_modules" --include=package.json 2>/dev/null | head -50
else
  echo "No node_modules found."
fi

# 2. Scan for obfuscation / remote-fetch patterns inside node_modules
echo "--- [2] Suspicious code patterns in node_modules ---"
grep -rlE 'eval\(|Buffer\.from\([^)]*base64|atob\(|child_process|https\.get\(|fetch\(' \
  "$PROJECT_DIR/node_modules" --include='*.js' 2>/dev/null | grep -vE '\.min\.js' | head -50

# 3. Recently added/changed packages (last 7 days) — fresh supply-chain risk
echo "--- [3] Packages modified in last 7 days ---"
find "$PROJECT_DIR/node_modules" -name package.json -mtime -7 2>/dev/null | head -50

# 4. Credential artifacts at risk from infostealers
echo "--- [4] Credential artifacts present ---"
for f in "$HOME/.npmrc" "$HOME/.netrc" "$HOME/.aws/credentials" \
         "$HOME/.kube/config" "$PROJECT_DIR/.env"; do
  [ -f "$f" ] && echo "PRESENT: $f (perms: $(stat -c '%a' "$f"))"
done
find "$HOME/.ssh" -name 'id_*' ! -name '*.pub' 2>/dev/null | while read -r k; do
  echo "SSH PRIVATE KEY: $k (perms: $(stat -c '%a' "$k"))"
done

# 5. npm audit + lockfile integrity
echo "--- [5] npm audit (known-vuln check) ---"
cd "$PROJECT_DIR" && npm audit --audit-level=high 2>/dev/null | tail -20

echo "=== Audit complete. Review hits, quarantine suspicious packages, rotate exposed tokens. ==="

Treat any finding from checks 1 and 2 on a package you didn't deliberately vet as a containment trigger: isolate the host, assume any credentials in check 4 are compromised, and rotate npm tokens, cloud keys, and SSH keys — in that order of exposure.

Remediation & Hardening Guidance

There is no vendor patch for PhantomRaven — it abuses npm working as designed. Remediation is architectural:

Neutralize lifecycle hooks by default. Add ignore-scripts=true to a project-level .npmrc (or run npm ci --ignore-scripts in CI). This single change kills the execution vector for the overwhelming majority of npm-distributed malware. Explicitly re-enable scripts only for the small set of packages with native builds that genuinely require them (e.g., via npm rebuild <pkg> after review).
Pin and verify dependencies. Commit lockfiles (package-lock.json) and enforce npm ci (not npm install) in CI so the lockfile is authoritative. Enable npm package provenance verification (npm audit signatures) where packages support it.
Proxy the registry. Route all installs through an internal proxy/repository (JFrog Artifactory, Sonatype Nexus, or equivalent) with allowlisting, quarantine periods for newly published package versions, and dependency-confusion protection by scoping internal package names so they can never resolve upstream.
Deploy behavioral supply-chain scanning. Tools that flag install scripts, network calls, and filesystem access in packages (Socket, Snyk, or equivalent) catch PhantomRaven-class behavior regardless of payload regeneration — essential against LLM-iterated variants.
Lock down CI/CD secrets. Build runners should use short-lived, workload-identity-federated credentials (OIDC) rather than long-lived tokens in environment variables. Scope npm tokens to read-only and per-project. A PhantomRaven compromise of a build agent should yield nothing reusable.
Egress filtering on build infrastructure. Build agents need npmjs and your internal proxy — not arbitrary internet HTTPS. Deny-by-default egress converts successful infostealer execution into a failed exfiltration.
Respond decisively on detection. If any detection above fires: isolate the host, capture the offending package name/version and report it to npm security and GitHub's advisory database, rotate every credential class the host could reach, and audit ~/.npm/_logs and package-lock diffs for when the package entered the dependency tree.

The LLM-authored nature of PhantomRaven is the real story for defenders. Expect a rising tide of mediocre-but-functional, rapidly regenerated supply-chain malware. Invest in behavioral detection and pipeline hardening — those controls don't care who, or what, wrote the payload.

Related Resources

Security Arsenal Penetration Testing Services AlertMonitor Platform Book a SOC Assessment vulnerability-management Intel Hub