Introduction: The Truth That EDR Story Fails to Capture

There is a version of this story that most organisations tell themselves: we have an EDR, it’s managed, the console shows green, we’re covered. It’s a reasonable story. It’s also often wrong. Because if often fails to answer this question: if an adversary ran the breach and attack simulation in your environment right now, would your controls catch it? Not in a vendor demo. Not in a lab. In your environment, against your configuration, with your current policy state.

Over four months, SISA Sappers – the digital forensics unit of SISA, ran that test across five enterprise endpoint security products in three separate client environments. We were not looking for product flaws. We were testing whether the defences each organisation believed they had were actually functioning the way they assumed. In two cases, they weren’t. The consequences are worth understanding.

The Gap Between Installed and Working

Security controls degrade quietly. Policies drift from enforce mode into audit mode - sometimes deliberately, sometimes after a troubleshooting session that never got reversed. Exclusion lists accumulate entries that made sense once but now carve large blind spots through the detection logic. The EDR agent updates; the policy template doesn’t. None of this shows up on a dashboard. The console still shows the endpoint as protected.

This is the environment we simulate into. Not the vendor’s test lab. Not a clean demo setup. The actual production environment, in its current configuration state, with whatever drift has accumulated since deployment. And the reality isn’t reassuring: The gap between ‘EDR installed’ and ‘EDR working’ is real, it is common, and it is invisible without continuous validation.

Key Findings from SISA’s Adversary Simulation Exercises

Across our simulation programme this quarter, we documented two distinct findings. They have different root causes, different implications, and different fixes. But they share the same underlying problem: organisations were trusting their endpoint security without verifying it.

Finding A: A kernel-level bypass that works regardless of which EDR you’re running

Every enterprise EDR worth its licence fee protects its own processes. Try to kill the EDR agent from a standard Windows session and tamper protection will stop you. This is well understood and, in normal circumstances, effective. What’s less well understood is that this protection has a ceiling. It operates in user space. Anything happening in the kernel is effectively invisible to it.

A Windows kernel driver, once loaded, can call operating system functions that terminate any process on the system, including the EDR. Because the termination originates at the kernel level, user-mode tamper protection has nothing to intercept. The EDR processes stop immediately and silently.

The driver we used to demonstrate this - wsftprm.sys, is not a custom tool. It’s a legitimately signed Windows kernel driver publicly documented on loldrivers.io as exploitable for exactly this purpose. It carries a valid Microsoft-accepted digital signature, which means it passes Windows driver verification and loads without complaint. None of the five EDR products we tested flagged it on disk, on load, or in operation.

This technique is called Bring Your Own Vulnerable Driver, or BYOVD. It’s been documented in incident reports from Lazarus Group, BlackByte, and other threat actors. It is not theoretical.

The architectural control that closes this gap is called Hypervisor-Protected Code Integrity (HVCI), sometimes called Memory Integrity in Windows settings. When enforced, it prevents unsigned or known-vulnerable kernel drivers from loading at all. It was not enabled on any endpoint we tested, which is consistent with what we see across enterprise environments broadly. Enabling HVCI requires driver compatibility validation first, and many teams defer it indefinitely.

Finding B: Zero detections across a full 90-minute attack simulation while the console showed green

The second finding is in some ways more troubling, because it has nothing to do with architectural limitations. It is a story about configuration drift and the gap between what a management console reports and what is actually happening on the endpoint.

In one client engagement, we executed a full 90-minute adversary simulation against an endpoint where the EDR was active and reported as policy-compliant. We ran fourteen attack techniques: PowerShell obfuscation, credential dumping, process injection, ransomware-style file encryption, data exfiltration to cloud storage. Every technique ran to completion. The EDR produced no alerts. No blocks. No log entries.

Our independent detection layer - a SIEM receiving Windows event logs through a separate forwarding path - alerted on all eleven techniques where Windows telemetry was available. The attack activity was detectable. The EDR just wasn’t detecting it.

The evidence points to policy misconfiguration rather than product failure. Several of the techniques that went undetected are baseline capabilities of the product - features named and documented in the vendor’s own literature, such as process injection detection, script control, ransomware behavioural protection to name a few. When these produce no output at all against techniques they are specifically designed to catch, the most likely explanation is that the relevant modules were not in enforce mode.

What Organizations Must Do: SISA-Recommended Remedial Measures

Both findings resolve to the same underlying discipline: you cannot assume your controls are working. You have to verify them. Continuously, not once at deployment.

1. For Finding A, the architectural fix is HVCI. Enable it. Before you can, audit your drivers for compatibility - some older hardware and software drivers will conflict. Add wsftprm.sys and other known-vulnerable drivers from loldrivers.io to your deny list via Windows Defender Application Control. Validate that tamper protection actually covers every process associated with your EDR, not just the primary agent.

2. For Finding B, the operational fix is policy hygiene. Export your active EDR policy and read it. Verify that behavioural detection, script control, process injection detection, and ransomware protection are all set to enforce - not audit, not disabled. Review your exclusion list. Every entry should have a current business justification and the narrowest possible scope.

For both findings, the systemic fix is continuous validation. A dashboard is not evidence. Running controlled adversary simulations, mapped to the techniques your threat model actually cares about, gives you evidence. It tells you whether your configuration is enforcing the detection you think it is, in your environment, right now.

SISA Sappers exists to find out which version of your EDR is true. As the forensics arm of SISA, our Breach and Attack Simulation (BAS) practice does one thing: we replicate the techniques, tools, and behaviours of real-world threat actors inside your environment to determine whether your defences are actually working, not just present. Unlike penetration testing, which looks for a path to compromise, BAS tests the efficacy of your detection, prevention, and monitoring ecosystem. Every simulation maps to the MITRE ATT&CK framework. Every claim is scoped to what the evidence supports, not what the dashboard reports.

‍