How to validate whether your EDR actually stops an attack
Your EDR is on the attacker's checklist. Here are five questions that prove whether it blocks, alerts, survives and responds, and how to test them like they do.
Nov 2, 2026@Melly9 min read
TL;DR
01
Ransomware crews now plan to switch your EDR off. ESET counted 54 EDR killer tools that abuse vulnerable signed drivers.
02
An installed agent proves nothing. You need to know it is everywhere, on a prevention policy, tamper resistant and wired to the SOC.
03
Further down: the exact queries and checks to verify each of those today, without running a single piece of malware.
An EDR agent on every endpoint is not the same thing as an EDR that stops attacks. Coverage gaps, permissive policies, exclusions and tampering all sit between the purchase order and the outcome. And attackers know it: ransomware crews now treat the EDR as a target in its own right, and disable it before they encrypt. This note sets out five questions that, together, prove EDR effectiveness, and a safe way to test each one in production.
Key findings
EDR KILLERS USING DRIVERS
54 / ~90
EDR killer tools documented by ESET abuse vulnerable signed drivers, 35 distinct drivers in all.
INDUSTRIALIZED, JUNE 2026
GentleKiller
The Gentlemen ransomware operation ships affiliates a standardized EDR killer suite instead of leaving it to each affiliate.
ATT&CK V19, APRIL 2026
Defense Impairment
Defense Evasion split into Stealth and Defense Impairment, giving attacks on security tools their own tactic.
SYSTEM INTRUSION BREACHES
60%
Of breaches in the 2026 DBIR. Ransomware appeared in 77% of those.
The endpoint is where breaches end, and the EDR is now the first thing attackers go after when they get there.
If attackers plan for your EDR, your validation has to plan for their plan.
Why EDR fails quietly
Here is the uncomfortable part: most EDR failures produce no error message at all. The agent reports healthy while one of these is true.
Coverage gaps
Servers built from an old image, short-lived cloud instances and contractor laptops run without an agent, or with a stale one.
Detect-only policies
Prevention was switched off during rollout to avoid false positives, and never switched back on.
Exclusions
Folders, processes and hashes excluded for performance become safe places for attackers to work.
Tampering
A vulnerable driver, a stopped service or a removed callback blinds the agent while the console still shows it as installed.
Broken hand-offs
The EDR alerts, but the alert never reaches the SIEM, or reaches it after the attacker has moved on.
Where EDR has to win
Follow an intrusion across the endpoint and there are five places your EDR has to come through.
FIVE STAGES, ONE AGENT
01
Present
Healthy agent, right policy
02
Block
Prevents the technique
03 · UNTESTED
Survive
Resists impairment
04
See and say
Alert reaches the SOC
05
Respond
Isolate, kill, quarantine
Stage 3 is the one most programs never test. If the agent can be switched off quietly, every check after it fails without a trace.
The method: five questions that prove EDR effectiveness
01
Is it everywhere it should be?
Reconcile the EDR console with your asset inventory, cloud APIs and identity logs. Every asset on a path to a crown jewel needs a healthy agent on the expected policy.
02
Does it block?
Run safe behaviors for the techniques ransomware relies on: credential access, discovery, lateral tool transfer and signed binary proxy execution. Record prevented or not prevented for each.
03
Does it see and say?
For every behavior not blocked, check that telemetry was recorded, that an alert fired and how long the alert took to reach the SOC.
04
Does it survive?
Test tamper resistance with safe, approved checks: is tamper protection on, is the vulnerable driver blocklist enforced, and does an impairment attempt raise a high-priority alert?
Never run real EDR killer code in production.
05
Does it respond?
Confirm that host isolation, process kill and quarantine actually execute within your response target when triggered.
Run all five on a schedule, after every agent or policy change, and whenever a new EDR killer technique is published.
Worked example: checks you can run this afternoon
Let's turn the questions into real checks. The examples use Microsoft Defender for Endpoint on Windows, because the same ideas map cleanly to other EDR platforms.
Question 1: is the agent everywhere it should be?
Start with the devices the EDR knows about but does not protect.
KQL · Defender advanced hunting
// Defender advanced hunting: devices seen but not fully onboarded
DeviceInfo
| summarize arg_max(Timestamp, *) by DeviceId
| where OnboardingStatus != "Onboarded" or SensorHealthState != "Active"
| project DeviceName, OSPlatform, OnboardingStatus, SensorHealthState, Timestamp
Then diff the onboarded list against your asset inventory and cloud APIs. The devices missing from both lists are the ones attackers find first.
Question 4: will it survive an impairment attempt?
Good news: you do not need an EDR killer to test this. Check the two settings most BYOVD attacks depend on being off.
PowerShell
# Is tamper protection on?
Get-MpComputerStatus | Select-Object IsTamperProtected
# Is the Microsoft vulnerable driver blocklist enforced?
Get-ItemProperty 'HKLM:\SYSTEM\CurrentControlSet\Control\CI\Config' |
Select-Object VulnerableDriverBlocklistEnable # expect 1
Run both across every server on a path to a crown jewel, not just a sample. One host with tamper protection off is all an affiliate with a standardized kit needs.
Question 3: does an impairment attempt reach the SOC?
Check that tampering produces an alert someone actually sees, not just a log line.
KQL · last 30 days
// Tamper and sensor-disable events in the last 30 days
AlertInfo
| where Timestamp > ago(30d)
| where Title has_any ("tamper", "disable", "vulnerable driver")
| join kind=inner AlertEvidence on AlertId
| summarize alerts = dcount(AlertId) by DeviceName, Severity
If your approved impairment checks ran last week and this query returns nothing, question 3 failed: the attempt happened and nobody was told.
The numbers are illustrative, but the pattern is common. Coverage looks fine. Meanwhile, the hosts missing the driver blocklist and the silent impairment alerts are exactly what a GentleKiller-style kit needs.
How to measure the outcome
Five numbers that say more about your EDR than any install count.
Effective coverage
The share of crown-jewel-path assets with a healthy agent on a prevention policy. Install counts do not count.
Prevention rate by tactic
Prevented behaviors per ATT&CK tactic, with Defense Impairment reported on its own line.
Alert latency
Median seconds from behavior to SOC alert for behaviors that were detected but not blocked.
Tamper alert rate
The share of approved impairment checks that raised a high-priority alert.
Exclusion exposure
The number of exclusions a validated behavior was able to abuse.
How Hayrok approaches EDR validation
Hayrok tests the EDR as part of the attack, not in isolation.
Records four outcomes for each run (prevented, detected, logged only or missed) with alert latency.
AGIE
Shows what an attacker could reach from every endpoint where a behavior got through, turning an EDR gap into a named path to a named asset.
And because tests rerun on every agent update and policy change, a silent downgrade shows up as a failed assertion the same day. For the method behind that loop, see How to Validate Security Controls Continuously.
FAQ
How do I test whether my EDR actually works?
Run safe, ATT&CK-mapped behaviors on real endpoints and record whether the EDR prevented, detected, logged or missed each one. Then check alert delivery, tamper alerts and response actions.
Is it safe to test EDR in production?
Yes, with non-destructive behaviors, approved scope and a kill switch. Never use live EDR killer tools or malware in production.
What is BYOVD and why does it matter for EDR?
Bring your own vulnerable driver is a technique where an attacker loads a legitimate but flawed signed driver to gain kernel access and switch off security tools. It is the most common way EDR killers work.
How often should EDR be validated?
After every agent update, policy change or exclusion change, and on a fixed cadence for everything else.
Can EDR validation replace public evaluations such as MITRE ATT&CK Evaluations?
No. Public evaluations test products in a lab. Validation tests your deployment, your policies and your exclusions in your environment.
See what gets past your EDR
We will run a safe EDR validation on a sample of your endpoints and show what was blocked, what was missed and what each miss could reach.