WeaselBiscuit — npm-Distributed JavaScript Infostealer with Low-to-Moderate DPRK Overlap

WeaselBiscuit is a previously undocumented, self-contained JavaScript infostealer disclosed 2026-09-18 by OpenSourceMalware (researcher Paul McCarty, aka 6mile, with co-founder Jenn Gile), found bundled inside a cluster of 13-17 malicious npm packages first seen between 2026-09-12 and 2026-09-16. Unlike a typosquat that rides an npm install lifecycle hook, WeaselBiscuit has no preinstall/postinstall script at all — it fires when the package is actually imported or required by an application, or manually started, which is the single most important operational detail in this pack and the reason several install-time controls that work against other npm stealers (e.g. npm config set ignore-scripts true) do not stop this one. On import, the package auto-spawns a detached Node.js loader process, writes its PID to a local .pid marker, and retrieves a Base64-encoded second stage from a hardcoded Npoint.io dead-drop URL, executing it in memory via new Function — the payload never touches disk. The second stage resolves its C2 configuration from a second, shared Npoint URL, which in every recovered sample points to the same plain Express HTTP control plane at 103.170.217.184:8787.

Once live, WeaselBiscuit profiles the host (hostname, user, OS, CPU/RAM, local and public IP with a nested api.ipify.org → ip-api.com geolocation lookup) and uploads every readable, nonempty file under Chrome's Local Extension Settings LevelDB store — the directory where extensions like MetaMask cache signing/session state — on Windows, macOS, and Linux. On operator command only, it can also capture clipboard contents (Get-Clipboard / pbpaste) and, Windows-only, log keystrokes via a temporary PowerShell script written to %TEMP%\kb-monitor\keyboard-monitor-*.ps1. Each install is tagged with a numeric campaign identifier baked into the package name and every upload (10, 12, 79, 95, 99 confirmed at the payload level; 44 appears only in package naming — see §2).

The researcher explicitly frames this as behaviorally, not conclusively, DPRK-linked: the code borrows structural tradecraft from the DPRK's Contagious Interview tooling (BeaverTail and OtterCookie) — the Npoint dead-drop pattern, the nested public-IP/geolocation lookup, and a numeric per-install campaign marker resembling the PolinRider cluster — but is deliberately stripped down: no wallet-draining code, no browser-credential decryption, no seed-phrase sweep, no InvisibleFerret/Python second stage, no screenshots, and no Socket.IO/remote shell. OpenSourceMalware itself rates DPRK attribution "Low to moderate" and calls the DPRK-strain hypothesis "an analytic hypothesis, not a confirmed attribution." This pack treats that caveat as binding: nothing here is shipped at Prevent-tier severity on the strength of attribution, and every indicator below traces to a single primary-research lineage (see §2).

Single-primary-source limitation — read before treating anything here as Prevent-tier. Sources [01], [03], [04] and [05] are all authored/published by the same research organization (OpenSourceMalware); [02] is press syndication of that same research with direct quotes from the same two people. There is, as of this pack's build date, no independent second research organization that has separately recovered or corroborated any WeaselBiscuit indicator. Per this pipeline's two-source rule, that means every atomic indicator in this pack ships at Detect, never Prevent, and severity is capped below Critical in the Falcon IOC CSV (§10) regardless of how the primary researcher characterizes the threat in prose. This is stated once here and enforced mechanically: the §4 IOC table's Action column and the §10 CSV's action column agree exactly, and both read detect throughout.

Research decisions

• Package-count discrepancy across (and within) sources. The GitHub README lists "16 packages we've found so far" and enumerates exactly 16 names. The OpenSourceMalware blog's own intro paragraph says "11 npm packages" but its table lists the same 16 names as the README — an apparent editing artifact where the count grew as research continued but the intro sentence wasn't updated. The Hacker News headline and body say "13 npm packages" and name exactly 13 of those 16 (omitting laycot, @vibecheck-polid/process-runtime-utils, and @railone/image-utils). A 17th name, swnwall@1.2.10, appears in both [01] and [03] only inside the campaign-structure/resolver table, never in either source's headline package list. This pack ships the full union of 17 distinct names (§10) rather than picking one source's count, and reports the discrepancy here rather than silently reconciling it.
• The 7th Npoint resolver's identifier is genuinely unconfirmed. https://api.npoint.io/24c12c4b66a29747764f is hardcoded inside id79-client's code but returned HTTP 404 when the researcher retrieved it, so its embedded stage identifier is listed as "Unknown" in the README/blog prose. The campaign-infrastructure YARA rule's own comment labels this same UUID // ID 44 — almost certainly the researcher's own inference by elimination (six @biz44/id*-client packages map to six numeric IDs; five of six resolvers were independently confirmed with identifiers 99/10/79/12/95, leaving 44 as the remaining candidate) — but that inference is not stated as confirmed in the prose itself. This pack ships that resolver at low confidence/severity with the ambiguity spelled out, rather than asserting "44" as confirmed.
• Confirmed vs. clustered package linkage. Only four packages (process-tailwind@1.1.99, engin1@1.3.99, swnwall@1.2.10, id79-client@1.1.79) have an individually-documented, direct Npoint-resolver delivery link in the source material. The remaining thirteen names were "grouped together" by the researcher's own automation "as they shared IOCs" — a real and useful signal, but a different (weaker) evidentiary tier than the four confirmed names. §4 and §8 (Q1 vs. Q2) keep these two tiers separate rather than treating all seventeen names as equally confirmed.
• Malware-sample handling. The GitHub repository hosts live, attacker-authored files (a deobfuscated second-stage JS sample and its raw counterpart) as research artifacts. Per this pack's build instructions, the deobfuscated sample was fetched and read as inert plain text only — never executed, imported, or evaluated in any interpreter — solely to confirm specific literal strings (route paths, the kb-monitor temp-directory name, the identifier field) against the primary artifact rather than taking the prose write-up on faith. The raw (non-deobfuscated) payload file and the two logo/attack-chain images in the repository were not fetched; they add no citable technical detail beyond what [01]/[03]/[04]/[05] already establish.
• Prompt-injection check. All five fetched sources — including the README, all three YARA rule files, and the deobfuscated malware sample text — were reviewed for embedded instructions directed at an AI agent (hidden text, comments claiming authorization, "note to the AI," redirection to fetch additional URLs, or instructions to skip a step or execute something). None was found in any of the five snapshots. See §18 for the full statement.

Every row below is single-primary-sourced (see §2). Action is capped at detect throughout — none of these indicators are shipped at prevent, and this table's Action column agrees exactly with the §10 CSV.

No Persistence-tactic technique is mapped. Per the primary source, WeaselBiscuit has "no persistence beyond the detached Node process and .pid file" — it does not survive a reboot on its own. This is deliberately left out rather than force-mapped to a Persistence ID that isn't supported by the evidence.

The largest coverage gaps in this pack — SaaS-hosted CI compute, the pre-eval Base64/new Function step, and the pre-import registry-side detection problem (§5) — have no Falcon-sensor answer at all. These native, non-CQL checks are the only available coverage for those surfaces, and a useful supplement everywhere else.

npm / dependency-tree audit (all platforms)

• Run an SCA scan (Socket.dev, Snyk, npm audit equivalent, or an internal registry-side scanner) across every repository's package.json/package-lock.json/yarn.lock for the 17 named packages in §10 — by name and, where known, version.
• Because there is no lifecycle hook to gate, npm config get ignore-scripts auditing (useful against other npm stealers) provides no protection against WeaselBiscuit specifically — do not rely on it as a compensating control here.
• Grep the dependency tree for any package whose index.js or top-level module unconditionally spawns a detached child process on import — a generic static-analysis heuristic that would catch this family and future clones of it.

Windows Endpoint Security / Sysmon (where Falcon FileOpenInfo/FileReadInfo licensing is unavailable)

• Sysmon Event ID 11 (FileCreate) / 15, filtered for *kb-monitor\keyboard-monitor-*.ps1 under any user's %TEMP%.
• Sysmon Event ID 1 (ProcessCreate), filtered for a node.exe parent spawning powershell.exe with Get-Clipboard in the command line.

Linux / macOS endpoint (auditd / Endpoint Security Framework)

• Linux auditd watch rule on the Chrome extension-settings path, independent of Falcon licensing for FileOpenInfo/FileReadInfo:
  -w /home/*/.config/google-chrome/*/Local\ Extension\ Settings -p r -k weaselbiscuit_ext_read
• macOS Endpoint Security Framework file-open events on the equivalent Chrome profile path, or as a fallback: log show --predicate 'eventMessage contains "Local Extension Settings"' --last 1h
• macOS: watch for a node-parented pbpaste child process (ps -ef | grep pbpaste spot-check, or an ESF process-exec hook) — the source material confirms pbpaste as the macOS clipboard-capture mechanism but names no Linux-specific clipboard tool, so Linux clipboard capture is unconfirmed by any cited source and should not be assumed present.

Filesystem spot-check for the .pid marker (all platforms)

• No generic Falcon file-write event maps cleanly to an arbitrary non-executable file write, so this is a manual/RTR check rather than a CQL query: search under every node_modules/<package>/ directory matching the §10 package list for a .pid file, and correlate its contents (a PID) against currently running or recently-exited node processes.

Three queries are strong Custom IOA candidates; the remaining seven stay Investigate/Hunt-only pending tuning, because their host service is legitimate (Npoint, ipify, ip-api), or because they are deliberately broad triage feeds.

Q4 (Npoint DNS) and Q10 (rare-domain hunt) are intentionally not recommended for Custom IOA promotion — both host services (Npoint.io, and the open-ended rare-domain model) are legitimately used by unrelated developer tooling. Q2, Q3, Q6, Q7, and Q9 remain Investigate/Hunt-only until a fleet-specific benign baseline is established (see §11).

Action-tier mapping — read before bulk import. Falcon IOC Management supports only prevent, detect, allow and no_action; it has no hunt, enrich or pivot action. Those three are analyst-workflow tiers used in the §4 table, and they are encoded here as detect at reduced severity, exactly per §4. Because every indicator in this pack is single-primary-sourced (§2), nothing below ships at prevent — every row is detect, capped at high severity (never critical), regardless of how urgently the primary researcher frames the threat in prose. npm package names are not a Falcon IOC-Management importable type and are shipped separately below, not in this CSV.

type,value,action,severity,expiration,description,tags
ipv4,103.170.217.184,detect,high,2026-12-20,Shared WeaselBiscuit HTTP C2 -- polling Express API on TCP/8787 -- single-sourced (OpenSourceMalware),campaign:WeaselBiscuit
sha256,7b15605f23b131b3eeea57e031ae7cb32fc4b78c7bbb2025aa7a561ea5ae5159,detect,high,2026-12-20,Confirmed WeaselBiscuit second-stage infostealer payload -- delivered via Npoint dead-drop + Base64 + new Function -- single-sourced,campaign:WeaselBiscuit
url,https://api.npoint.io/24c25d5f5fcbb0992a4f,detect,high,2026-12-20,WeaselBiscuit Npoint resolver -- confirmed process-tailwind@1.1.99 delivery -- embedded stage identifier 99,campaign:WeaselBiscuit
url,https://api.npoint.io/641d37178a880b1e8b8f,detect,high,2026-12-20,WeaselBiscuit Npoint resolver -- confirmed swnwall@1.2.10 delivery -- embedded stage identifier 10,campaign:WeaselBiscuit
url,https://api.npoint.io/33e8d008c334b060adad,detect,high,2026-12-20,WeaselBiscuit Npoint resolver -- confirmed clone payload -- embedded stage identifier 79,campaign:WeaselBiscuit
url,https://api.npoint.io/ddae72efbb6714fae922,detect,high,2026-12-20,WeaselBiscuit Npoint resolver -- confirmed clone payload -- embedded stage identifier 12,campaign:WeaselBiscuit
url,https://api.npoint.io/933a731a5e97f4b45249,detect,high,2026-12-20,WeaselBiscuit Npoint resolver -- confirmed clone payload -- embedded stage identifier 95,campaign:WeaselBiscuit
url,https://api.npoint.io/37c0a0c68bf7a94ed731,detect,high,2026-12-20,Shared WeaselBiscuit C2-configuration resolver -- all five confirmed stages retrieve C2 103.170.217.184:8787 from this URL,campaign:WeaselBiscuit
url,https://api.npoint.io/24c12c4b66a29747764f,detect,low,2026-10-20,Hard-coded fallback resolver referenced in id79-client -- returned HTTP 404 at research time -- embedded identifier unconfirmed (see report §2),campaign:WeaselBiscuit

# Not literal IOCs -- paste into a hunt runbook or SOAR playbook as review criteria
1. npm package has NO preinstall/install/postinstall lifecycle hook and instead auto-runs
   a detached child "node loader.js" process the moment it is imported/required -- see Q3
2. Detached loader retrieves JSON from a hardcoded api.npoint.io/<uuid> URL, Base64-decodes
   a "code" field, and executes it via new Function() -- payload never touches disk
3. Second stage retrieves its C2 config from a SECOND Npoint URL -- watch for any process
   making two sequential api.npoint.io requests moments apart -- see Q4
4. A .pid file appears directly inside the importing package's own node_modules directory
   (not a project-root PID file) -- manual/RTR filesystem check, see section 7
5. Client polls /api/clipboard-status/<hostname> and /api/keyboard-mouse-status/<hostname>
   every ~5 seconds -- both return {"isMonitoring": false} until the operator flips a switch
6. Exfiltration route pattern confirmed in the recovered sample: /api/system-info,
   /api/upload-local-extension-settings, /api/clipboard-data, /api/keyboard-mouse-data
   (all on the C2 host -- see Q5)
7. Numeric identifier field ("identifier": "10"/"12"/"79"/"95"/"99") present in uploaded
   system-info and extension-storage multipart form data -- confirmed at the payload level;
   useful as a post-hoc pivot/grouping key, not as a standalone detection
8. npm account / package-naming pattern: short, generic-sounding utility names (engin1,
   process-mite, laycot) or a numbered scope (@biz44/id10-client .. id99-client) with little
   or no legitimate publishing history -- registry-side signal, not endpoint telemetry

# Confirmed direct Npoint-resolver delivery link (highest confidence, 4 names):
process-tailwind@1.1.99      (ID-99 Client Module -- byte-identical to engin1)
engin1@1.3.99                (ID-99 Client Module -- byte-identical to process-tailwind)
swnwall@1.2.10                (ID-10 Client Module)
id79-client@1.1.79            (ID-79 Client Module)

# Clustered by shared IOCs / researcher automation (medium confidence, 13 names):
laycot@1.3.10
process-mite
process-lhpm
@biz44/id10-client
@biz44/id12-client
@biz44/id44-client
@biz44/id79-client
@biz44/id95-client
@biz44/id99-client
@biz44/process-runtime-utils
@biz44/runtime-utils
@vibecheck-polid/process-runtime-utils
@railone/image-utils

# 17 names total (union across all cited sources -- see report section 2 for the
# 11 vs. 13 vs. 16 vs. 17 count discrepancy across and within the primary sources).
# Screen your dependency tree against this list via your SCA tool of choice
# (Socket.dev, Snyk, npm audit equivalent, or an internal registry-side scanner).

[ ] SCA scan of every repo's package.json/package-lock.json/yarn.lock against the
    17-name list above (Named Malicious npm Packages block)
[ ] Pre-merge dependency-review gate requires human sign-off on any brand-new
    or low-download-count npm package before it reaches application code
[ ] NOTE: npm config set ignore-scripts=true provides NO protection against this
    threat -- WeaselBiscuit has no lifecycle hook, it runs on import/require
[ ] Fleet-wide search for a .pid file directly inside a node_modules/<pkg>/ directory
[ ] Egress allowlist review: is 103.170.217.184 reachable from dev/CI networks today?
[ ] Chrome profile "Local Extension Settings" directory permissions reviewed on
    workstations that also hold cryptocurrency wallet browser extensions
[ ] CI/CD runner egress allowlisted (self-hosted); SaaS-hosted runner gap documented

Read this before reusing another npm-stealer pack's hardening list against this threat. WeaselBiscuit has no npm lifecycle hook — the code runs when the package is imported/required by application code, not when npm install runs. npm config set ignore-scripts true, the single most effective control against a preinstall/postinstall-hook stealer, does nothing against WeaselBiscuit. Controls below are chosen accordingly: the leverage point is stopping the package from ever entering the dependency tree, plus runtime/network detection of the behavior that follows import.

Playbook A — Pre-Merge Dependency Vetting & C2 Egress Containment

MITRE: T1195.001, T1071.001 → M1013, M1033, M1037   Estimated deploy time: 2-4 hours for the egress rule; 1-2 days to wire the SCA gate into CI branch protection   Prerequisites: CI platform admin rights for branch-protection rules; an SCA tool (Socket.dev, Snyk, or equivalent) already licensed or evaluable; cloud/firewall admin access for egress rules   Reboot required: No

Step 1 — Add the 17 known package names to your SCA tool's custom denylist

What it does: Fails an SCA scan (and therefore the merge gate) the moment any of the confirmed WeaselBiscuit-associated package names appears in a lockfile. Why it works: stops the package from ever entering the dependency tree — the only point where WeaselBiscuit can be prevented outright, since it has no install-time hook to block later.

# Example: Socket.dev / Snyk-style custom policy denylist (adapt to your tool's config format)
denylist:
  - laycot
  - process-mite
  - process-lhpm
  - process-tailwind
  - engin1
  - swnwall
  - id79-client
  - "@biz44/id10-client"
  - "@biz44/id12-client"
  - "@biz44/id44-client"
  - "@biz44/id79-client"
  - "@biz44/id95-client"
  - "@biz44/id99-client"
  - "@biz44/process-runtime-utils"
  - "@biz44/runtime-utils"
  - "@vibecheck-polid/process-runtime-utils"
  - "@railone/image-utils"

Verify: a test branch that adds any denylisted name to package.json fails the SCA check and cannot merge.

Rollback: remove the denylist entries if your tool's policy engine conflicts with an unrelated legitimate internal package that happens to share a name — verify no false collision exists before rolling back rather than disabling the whole gate.

Step 2 — Block the confirmed C2 IP at the network egress layer

What it does: Denies outbound connectivity to 103.170.217.184 from developer and CI networks. Why it works: even if a compromised package is imported and runs, the exfiltration and second-stage-config fetch cannot reach the operator.

# Example: cloud security-group egress deny (adapt to your firewall/VPC tooling)
aws ec2 authorize-security-group-egress --group-id sg-0123456789abcdef0 \
  --protocol tcp --port 8787 --cidr 103.170.217.184/32 --rule-action deny

# Or on a traditional perimeter firewall, an explicit deny rule ordered ABOVE any broad allow:
# deny tcp any any -> 103.170.217.184 8787

Verify: curl -m 5 http://103.170.217.184:8787 from an affected network times out; firewall logs show the denied attempt.

Rollback: remove the specific deny rule if it is later confirmed to collide with unrelated infrastructure sharing that IP — verify current ownership before assuming that risk, since this is a small non-cloud-hosted IP with no other documented legitimate use as of this pack's build date.

Playbook B — Runtime Burn-In for Detached Node Child Processes

MITRE: T1059.007, T1005 → M1040, M1022   Estimated deploy time: 1-2 hours to schedule the searches; 14 days for the burn-in window itself   Prerequisites: Falcon Investigate/Scheduled Search access; two analysts available to review daily hit output   Reboot required: No

Step 1 — Schedule Q1, Q3, and Q8 as Falcon Scheduled Searches at Detect-only

What it does: Runs the confirmed-package, detached-loader, and keylogger-script queries on a recurring schedule and routes hits to a review queue rather than an auto-response action. Why it works: establishes a real fleet-specific benign baseline before any query is considered for further tuning, without risking a false isolation action on legitimate developer tooling.

# Falcon Next-Gen SIEM / Scheduled Search (conceptual -- configure via the Falcon console
# Investigate > Scheduled Searches UI, using the Q1/Q3/Q8 CQL from section 8 as the query body)
Schedule:    Every 6 hours
Query:       
Action:      Log to review queue -- NO automated containment action during burn-in
Retention:   30 days of hit history for baseline comparison

Verify: the Scheduled Search shows a run history with hit counts for each 6-hour window; a review-queue entry exists for every hit during the burn-in period.

Rollback: disable the Scheduled Search if hit volume is unmanageable for the review team — reduce scope (e.g., to a pilot ring of hosts) rather than abandoning the burn-in entirely.

Step 2 — Two-analyst review before any promotion decision

What it does: Requires a second analyst to independently confirm each candidate true-positive before a query is proposed for Custom IOA promotion. Why it works: matches this pack's own Detection Validation Gates (§11) and avoids a single analyst's misjudgment promoting a query that later floods the SOC with false positives.

# Review checklist per hit (paste into your ticketing/SOAR tool)
[ ] CommandLine matches an EXACT confirmed package path (Q1) or loader.js/kb-monitor
    pattern (Q3/Q8), not a substring collision
[ ] No known legitimate build tool, browser-automation harness, or internal package
    explains the hit
[ ] Second analyst independently reaches the same true/false-positive conclusion
[ ] Decision and rationale logged before any promotion to Custom IOA

Verify: every review-queue entry has a logged two-analyst decision before the 14-day window closes.

Rollback: none required — this is a review process control with no endpoint state change.

See §11 for the full Detection Validation Gates this coverage assumes: telemetry readiness, a 7-14 day benign baseline, lab-only positive testing, and the specific promotion criteria for each query.

Security note on source [05]: the GitHub repository hosts a live, attacker-authored JavaScript sample as a research artifact. This pack's build process fetched that file and read it strictly as plain text for citation/verification purposes — confirming specific literal strings against the prose write-up — and at no point executed, imported, ran, or evaluated it in any interpreter or sandbox. The repository's raw (non-deobfuscated) payload file and its two image assets were not fetched, since they add no citable technical detail beyond what [01]/[03]/[04]/[05] already establish.

Prompt-injection check: all five fetched sources — the OpenSourceMalware blog [01], The Hacker News article [02], the GitHub README [03], all three YARA rule files [04], and the deobfuscated malware sample text [05] — were reviewed for embedded instructions directed at an AI agent (hidden text, HTML comments, "note to the AI," claims of user/Anthropic/administrator authorization, redirection to fetch an additional URL because "the real IOCs are here," or instructions to change this pack's output path or skip a build step). None was found in any of the five snapshots. All content in every fetched source was either ordinary site chrome/navigation, the cited research prose itself, or (for [04]/[05]) literal YARA rule syntax and JavaScript malware logic with no embedded natural-language directives aimed at an AI reader. No source attempted to redirect this research, claim authorization to skip a step, or influence a Prevent-tier IOC decision — and even if one had, this pack's design (Detect-only, single-primary-source caveat throughout) does not depend on trusting the source's own framing of its urgency.