The indexed-btree Malware Ran for 11 Weeks. Would Your Monitoring Catch It in 11 Minutes?

The Industry Just Learned a Hard Lesson About Static Defenses

Security researchers at Checkmarx have exposed a malicious npm package called indexed-btree that impersonates the legitimate sorted-btree library. The impersonation itself is nothing new — typosquatting is as old as package registries. What makes this campaign different is where the malware lives.

For years, the npm community's answer to supply-chain attacks was simple: block or audit preinstall and postinstall scripts. CI pipelines reject packages with install hooks. Developers run npm install --ignore-scripts. It was a clean, static control — and attackers just walked around it. indexed-btree hides its payload inside a core package function, so the malware executes only when an application legitimately calls the library at runtime. No install script to flag. No suspicious hook to reject.

The package was pulling nearly 2 million downloads per week before it was removed from the registry on September 3, 2026 — roughly 11 weeks after the first malicious version went live.

Eleven weeks.

Now ask yourself the uncomfortable question: if malicious code were running on one of your production servers right now — consuming CPU, writing to disk, quietly making outbound connections — how long would it take your team to notice? If your honest answer is longer than a few minutes, keep reading.

The Problem: Your Monitoring Has the Same Blind Spot npm Did

Here's the uncomfortable parallel. The npm ecosystem relied on a single static control — block install scripts — and it failed the moment attackers changed tactics. Most IT teams run on equally static monitoring, and it fails the same way.

Walk through what "monitoring" looks like at a typical mid-size IT shop or MSP:

• The RMM (NinjaOne, ConnectWise Automate, whatever you run) checks that services are "Running" and that Windows Update is enabled.
• The uptime tool (UptimeRobot, Pingdom) confirms the website returns a 200.
• The APM (Datadog, New Relic) belongs to the dev team, and its alerts land in a Slack channel nobody on the ops side watches.
• The helpdesk (ConnectWise Manage, Freshdesk, HaloPSA) is where you actually find out something is wrong — because a user opened a ticket saying "the portal is slow."

Five tools. Five alert streams. Zero correlation. Each one watches a narrow slice and asks a narrow question: is the thing I know about doing the thing I expect?

None of them asks the question that matters when prevention fails: what is actually running on this machine, and is it behaving normally?

A malicious Node.js process doesn't look like an incident to these tools. It looks like a Node.js process. The server stays up. The website responds. Disk sits at 62% until suddenly it doesn't. CPU is fine until it isn't. Meanwhile the payload does whatever it does, and your first signal arrives 40 minutes later as a ticket from an annoyed accountant.

Why these gaps exist

• Siloed architecture. Each tool was bought to solve one problem, by one team, at one point in time. They share no event model, so nothing can connect "new scheduled task created" plus "CPU baseline deviation" plus "unusual disk writes" into a single incident.
• Threshold-only alerting. Static rules ("alert if CPU > 90%") miss slow, abnormal behavior entirely. A process sitting at 30% CPU around the clock never trips a threshold — it just quietly steals capacity for weeks.
• Monitoring scoped to known-good. If your checks only cover services you explicitly configured, anything new running on the box is invisible by definition.

What it actually costs

• Dwell time. The npm package lived 11 weeks on the registry. In your environment, undetected runtime misbehavior becomes weeks of degraded performance, filling disks, and unexplained reboots — investigated only after users force the issue.
• SLA misses. When detection depends on user tickets, your response clock starts when the user gets frustrated, not when the problem starts. Good luck explaining that to a client with a one-hour response SLA.
• Technician burnout. Nothing demoralizes a sysadmin faster than a 2am page for a crash monitoring should have predicted — or worse, no page at all, followed by an angry user at 9am.

How AlertMonitor Closes the Runtime Visibility Gap

AlertMonitor is built on a simple premise: one agent, one pane of glass, one alert stream for the entire stack. Servers, services, applications, Windows workstations, scheduled tasks, and network topology — all monitored in real time, all correlated.

Here's what changes in practice:

1. You monitor what's actually running, not just what should be. AlertMonitor watches processes, services, and scheduled tasks on every server and workstation — including the ones you never explicitly configured. When something new or abnormal shows up, it's an alert, not a blind spot.

2. Baseline-aware alerting replaces static thresholds. A process at 30% CPU isn't an incident if that's its normal. If it's a 5x deviation from its own history, it is. AlertMonitor learns what normal looks like and pages on abnormal — exactly the behavior class static controls miss.

3. Intelligent correlation turns noise into one incident. CPU deviation plus a disk write burst plus a new scheduled task inside the same time window isn't three low-priority warnings scattered across three consoles — it's one high-priority incident with full context, because everything arrives in a single alert stream.

4. The alert becomes a ticket automatically. Because the helpdesk is integrated, the incident creates a ticket with the complete alert timeline attached. Postmortems stop being archaeology, and SLA reporting finally has one source of truth instead of a spreadsheet reconciling two systems that don't talk.

5. The right person is paged in seconds. Escalation policies route by severity, time of day, and assignment. A disk crossing 90% on DB01 pages the on-call tech in about 90 seconds — not discovered 40 minutes later by a user ticket.

The old workflow: user complains → ticket triage → tech guesses which server → RDP in → open four consoles → start investigating. You're 40–60 minutes in before you even understand the problem.

The AlertMonitor workflow: deviation detected → correlated incident → ticket created → correct tech paged → remediation begins. Under two minutes.

Practical Steps You Can Take Today

Even before you touch your tooling, run these three checks on your Windows estate. Each takes minutes, and each closes part of the "what is even running here?" gap this campaign exploited for 11 weeks.

1. Inventory what's actually executing on your servers:

# Inventory every Node.js process running on this server — know what's actually executing
Get-Process -Name node -ErrorAction SilentlyContinue |
    Select-Object Id, ProcessName, CPU, StartTime, Path |
    Sort-Object CPU -Descending |
    Format-Table -AutoSize

If you find Node processes with a Path you don't recognize, that's a conversation for today — not the next quarterly review.

2. Check disk headroom across the estate before it becomes a 2am page:

# Flag any server drive with less than 15% free space
$servers = "WEB01","DB01","APP01","FS01"
Get-CimInstance -ComputerName $servers -ClassName Win32_LogicalDisk -Filter "DriveType=3" |
    Select-Object @{n='Server';e={$_.PSComputerName}},
                  @{n='Drive';e={$_.DeviceID}},
                  @{n='FreeGB';e={[math]::Round($_.FreeSpace/1GB,1)}},
                  @{n='FreePct';e={[math]::Round(($_.FreeSpace/$_.Size)*100,1)}} |
    Where-Object { $_.FreePct -lt 15 } |
    Format-Table -AutoSize

3. Baseline your scheduled tasks so "new and unexpected" is actually detectable:

# Baseline every enabled scheduled task — re-run monthly and diff the CSV
Get-ScheduledTask | Where-Object { $_.State -ne 'Disabled' } |
    Select-Object TaskName, TaskPath, State |
    Export-Csv -Path "C:\Reports\TaskBaseline_$(Get-Date -Format yyyyMMdd).csv" -NoTypeInformation

Then stop doing this by hand. In AlertMonitor, deploying the agent once turns each of these into a permanent, real-time monitored item: disk headroom alerts fire at 85% and 92% with escalation, process and task baselines are tracked automatically, and every deviation lands in the same alert stream your helpdesk and patch management already live in. When the next indexed-btree-style campaign arrives — and it will — the question "how long was it running?" gets answered in minutes, not weeks.

The lesson of this npm campaign isn't "block more install scripts." Attackers will always route around the last control you added. The lesson is that when prevention fails — and it eventually always does — real-time visibility across your entire infrastructure is the difference between an 11-week incident and an 11-minute one.

Related Resources

AlertMonitor Infrastructure & Server Monitoring AlertMonitor Platform Overview Book a Demo Infrastructure & Server Monitoring Resources