Diagnosing False Negatives in AI-Based Endpoint Detection (EDR)

Nothing erodes trust in a security stack faster than finding out, after the fact, that your AI-based EDR sat there quietly watching an intrusion unfold and never fired an alert. I've been called into three separate post-incident reviews in the last year where the EDR agent was running, licensed, and reporting healthy status in the console, yet a commodity loader and a credential dumper both walked straight through. Every time, the root cause was mundane. Nobody had to defeat the neural network with some exotic adversarial patch. The gaps were in configuration, telemetry, and tuning.

This runbook walks through how to actually diagnose false negatives in ML-driven endpoint detection, rather than just re-reading vendor marketing about model accuracy. If you manage a fleet with an agent like the one deployed across

sw-infrarunbook-01

and its peers, this is the checklist I now run every time detection coverage is questioned.

Symptoms

The pattern usually looks like this: a known-bad binary or behavior chain executed on an endpoint, and nothing showed up in the EDR console or SIEM. Sometimes you find it during a red team debrief, sometimes during a real incident when a forensic timeline shows the malware ran for eleven days before anyone noticed. Common symptoms include:

• The EDR console shows the endpoint as "protected" and "online" the entire time, with no detections logged for the compromise window.
• Manually running the same sample or technique on a lab machine triggers a clean detection, but the production host stayed silent.
• The vendor's threat intel feed later confirms the hash as malicious, yet the local detection engine never flagged it in real time.
• Detections exist for some stages of the attack chain (say, initial execution) but not for lateral movement or credential access that followed.
• Agent CPU and memory look normal, so nobody suspected a resource-starvation issue during triage.

None of these symptoms point to a single cause on their own. You have to work through the pipeline: telemetry collection, feature extraction, model scoring, and alerting policy, in that order.

Root Cause 1: Telemetry Collection Gaps (ETW, kernel callbacks, or eBPF disabled)

AI-based EDR models are only as good as the events they see. Most Windows agents depend on Event Tracing for Windows (ETW) providers, kernel minifilter drivers, and AMSI hooks. On Linux, it's typically eBPF probes or auditd. If any of these are disabled, either by group policy, by a conflicting security product, or by the malware itself unhooking the agent, the model never receives the features it needs to score the process as malicious.

I've seen this most often when a separate antivirus product coexists with the EDR agent and both try to register minifilter drivers. Windows silently deprioritizes one, and the EDR's visibility drops to almost nothing without any error surfacing in its own health dashboard.

To check ETW provider health on a Windows endpoint, run:

PS C:\> logman query providers | findstr /i "Threat-Intelligence"
Microsoft-Windows-Threat-Intelligence     {f4e1897c-bb5d-5668-f1d8-040f4d8dd344}

PS C:\> logman query "EDR-Telemetry-Session" -ets
Data Collector Set
- - -
Status:            Stopped
Error:             The specified session was not found.

A stopped or missing telemetry session is the smoking gun. On Linux hosts running an eBPF-based sensor, check whether the probes are actually attached:

$ sudo bpftool prog list | grep edr_sensor
142: kprobe  name execve_monitor  tag 3a9f0c1e2b8d1234  gpl
143: kprobe  name connect_monitor tag 9f1a2b3c4d5e6f70  gpl

$ sudo bpftool prog list | grep edr_sensor
(no output)

If the second command returns nothing on a host where it should show two probes, the sensor unloaded silently, often after a kernel update that the vendor's driver didn't support yet. The fix is straightforward but tedious at scale: audit driver load status fleet-wide, uninstall conflicting AV agents, and pin kernel versions to ones your EDR vendor has certified before you approve the patch ring.

Root Cause 2: Model Drift Against New Attack Techniques

Behavioral ML models are trained on a snapshot of attacker tradecraft. When adversaries shift technique, say moving from disk-based payloads to reflective DLL loading entirely in memory, the model's feature space may no longer capture the signal it was trained to weight heavily. This is classic model drift, and it's invisible until someone runs a technique the model has never scored before.

You can spot this by pulling the model's confidence scores for a known-bad process chain, even one that didn't trigger an alert:

$ edrctl detections query --host sw-infrarunbook-01 --pid 4821 --raw-scores
process: rundll32.exe -> memory-injected payload
model_version: 4.2.1 (trained: 2025-11-02)
behavioral_score: 0.41
threshold_for_alert: 0.70
verdict: benign (below threshold)

A score of 0.41 against a 0.70 threshold tells you the model saw something mildly suspicious but not enough to act. Compare that against the same technique scored by a newer model version in a lab environment, and if the newer model scores it at 0.85, you've confirmed drift. The fix here isn't something you can patch yourself; it requires pushing the vendor for a model update cadence and, in the interim, writing custom behavioral rules (most EDR platforms support YARA-L or a similar DSL) to backstop the specific technique until the vendor ships an updated model.

$ edrctl models list --host sw-infrarunbook-01
name                version   last_updated
behavioral-core      4.2.1     2025-11-02
credential-access     3.0.4     2025-06-14   <-- 8 months stale

That credential-access sub-model being eight months stale while the core model is current is exactly the kind of thing nobody checks until an incident forces the question.

Root Cause 3: Exclusion and Allowlist Sprawl

This is the single most common cause I find in real environments, and it's entirely self-inflicted. Someone added a broad exclusion to stop a false positive from a legitimate backup tool, and the exclusion path was too generic, covering a directory that attackers later staged payloads in.

$ edrctl policy show exclusions --host sw-infrarunbook-01
path: C:\Program Files\BackupAgent\*
path: C:\Windows\Temp\*
process: powershell.exe (all child processes excluded from behavioral scan)

That last line is the one that should make you nervous. Excluding all PowerShell child processes from behavioral scanning because a scheduled task generated noisy alerts means an attacker who drops a PowerShell-spawned payload gets a free pass, regardless of how sophisticated the ML model underneath is. The model literally never gets invoked on excluded paths or processes.

Audit exclusions quarterly, and for each one, ask whether it's scoped to a specific hash, signer, or exact file path rather than a wildcard directory or an entire process tree. Replace broad exclusions like the PowerShell one above with signer-based or path-and-hash-based exceptions:

$ edrctl policy update exclusions --host sw-infrarunbook-01 \
    --remove "process:powershell.exe:all-children" \
    --add "process:powershell.exe:signer=Microsoft Windows,path=C:\Windows\System32\WindowsPowerShell\v1.0\*"

Root Cause 4: Alert Threshold Tuned Too Conservatively

SOC teams under alert fatigue often push detection thresholds upward to cut noise, and this is a reasonable trade-off in theory. In practice, I've seen thresholds pushed so high that the model's own useful signal gets thrown out along with the noise. If your analysts raised the behavioral score threshold from 0.70 to 0.90 six months ago to kill a wave of false positives from a legitimate RMM tool, check whether that change also silenced real detections in the interim.

$ edrctl policy history --host sw-infrarunbook-01 --field alert_threshold
2025-09-12  changed by: infrarunbook-admin  old: 0.70  new: 0.90  reason: "RMM tool noise"

The better fix is almost always to suppress the specific noisy signature rather than raising the global threshold. Global threshold changes are a blunt instrument that degrades detection across every technique the model covers, not just the one causing noise.

Root Cause 5: Agent Resource Starvation Under Load

ML inference at the endpoint costs CPU cycles. On hosts running heavy workloads, batch jobs, database engines, build servers, the EDR agent may throttle its own inference pipeline to avoid impacting production performance. Some agents drop to a "lightweight" mode under sustained CPU pressure, and that lightweight mode often disables the full behavioral model in favor of static signature checks only.

$ edrctl agent status --host sw-infrarunbook-01 --verbose
agent_state: DEGRADED_LIGHTWEIGHT
reason: sustained_cpu_pressure (>85% for 20min)
active_engines: static-signature
disabled_engines: behavioral-ml, memory-scan

This state doesn't always surface in the main console, which shows the agent as "healthy" because it's still running and reporting heartbeat. Check verbose agent status specifically on build servers, database hosts, and anything running batch ETL, since these are exactly the machines attackers like to land on because they're often less monitored by humans and more likely to be under CPU load that suppresses ML detection.

Root Cause 6: Encrypted or Obfuscated Payloads Defeating Feature Extraction

Static ML models that score files based on extracted features (PE header entropy, import table structure, string patterns) can be defeated by packers and custom crypters that produce a stub with almost no discernible malicious features until it unpacks in memory. If your EDR relies heavily on pre-execution static scoring rather than in-memory behavioral scoring, a well-packed sample can slip through the static model and only get caught, if at all, by runtime behavior.

$ edrctl scan file --path "C:\Users\infrarunbook-admin\Downloads\update.exe" --engine static-ml
entropy: 7.91 (high, consistent with packing)
static_score: 0.38
verdict: benign

$ edrctl scan file --path "C:\Users\infrarunbook-admin\Downloads\update.exe" --engine behavioral-runtime --sandbox
runtime_score: 0.93
verdict: malicious (process hollowing detected)

High entropy alone should never be treated as a soft signal in a vacuum, but combined with an unsigned binary from a browser download path, it's a strong indicator worth escalating. Make sure your policy actually detonates suspicious static-ambiguous files in a runtime sandbox rather than trusting the static model's low score as final.

Root Cause 7: Time-Based or Environment-Aware Evasion

More advanced intrusions check for the presence of virtualization artifacts, sandbox timing anomalies, or simply sleep for extended periods before executing their payload, specifically to outlast automated analysis windows and to execute during off-hours when the model's contextual baseline (established during business-hours activity) is different. Some behavioral models score anomalies relative to a learned baseline of "normal" activity per host or per user, and activity occurring at 3 AM from an account that never logs in outside business hours should be scored as anomalous, but only if the model has actually built that baseline.

$ edrctl baseline show --host sw-infrarunbook-01 --user infrarunbook-admin
baseline_status: INSUFFICIENT_DATA
days_observed: 4
minimum_required: 14
confidence: low

New hosts, recently reimaged machines, or newly onboarded employee accounts frequently don't have enough historical data for the anomaly-detection layer to be effective, and attackers who target freshly provisioned systems (a common pattern after M&A or contractor onboarding) exploit exactly this gap. Check baseline maturity before trusting anomaly-based alerting on any host younger than the vendor's minimum observation window.

Prevention

Treat your EDR's detection pipeline as a system with multiple points of failure, not a black box you trust because it's labeled "AI-powered." Build a quarterly review that checks telemetry provider health across the fleet, audits every exclusion for scope creep, reviews alert threshold change history against detection volume trends, and validates model versions against the vendor's latest release notes. Run periodic purple-team exercises using current, not year-old, attacker tradecraft, specifically testing techniques your model hasn't been validated against recently. Track agent resource-starvation events as a first-class metric in your monitoring stack, not an afterthought, since a degraded agent on a critical server is arguably worse than no agent at all because it creates false confidence.

Most importantly, resist the urge to treat a clean EDR console as proof of a clean environment. Cross-validate with independent telemetry, network flow logs, DNS query logs, and authentication logs, especially on your highest-value hosts. The false negative that hurts you is never the one you expected.