EDR-Redir: a new way to blind endpoint defenses by abusing Windows Bind Links
A new technique — surfaced in a tool called EDR-Redir — demonstrates how attackers can quietly redirect or isolate the executable folders used by popular Endpoint Detection and Response (EDR) products. The result: EDR agents can be starved of the files they expect to run or be redirected to inert copies, effectively neutering protections without needing kernel-level exploits.
Below I summarize what’s known about the technique, why it matters, how attackers can leverage it, and — crucially — how defenders and vendors should respond. (I don’t have live web access here; this article is built from the details you supplied plus general Windows and EDR knowledge.)
What EDR-Redir does (high level)
EDR-Redir uses Windows’ Bind Link feature (introduced in Windows 11 24H2) to perform filesystem namespace redirection. Bind Links are virtual path redirections implemented and enforced by the Bind Filter minifilter (bindflt.sys) and the Cloud Filter minifilter (cldflt.sys) in Windows. By creating Bind Links that target the directories where EDR products keep their executables and agents, an attacker can:
-
Redirect the EDR’s expected executable folder to another location the attacker controls, or
-
Isolate EDR binaries behind a virtual path so the running agent or the system’s service manager can’t find or update them.
Crucially, this approach does not require kernel-level code execution — it leverages a legitimate Windows feature and minifilter behavior to manipulate the apparent filesystem namespace.
Why this matters
-
Bypasses protections without kernel exploits. Many sophisticated defenses rely on the security stack (kernel drivers, code integrity checks, protected processes) to prevent tampering. EDR-Redir instead uses a benign OS feature to hide or redirect files so the EDR never sees them — a different attack surface that bypasses expectations about where tampering would come from.
-
Targets the last line of defense. EDR products are designed to detect and block intrusions. Removing or isolating the EDR’s own executables can turn a monitored host into a blind host.
-
Wide impact surface. If Bind Links are available in the environment and attackers can create or modify them (via misconfigurations, overprivileged services, or lateral movement), many endpoints could be affected.
-
Stealthy and durable. Because the technique manipulates namespace resolution rather than deleting files, it can be quiet (few hostile file deletion events) and persist until detected or the Bind Links are removed.
Technical outline (conceptual — no exploit details)
-
Feature used: Windows 11 Bind Link (24H2) — provides virtual path redirection at the filesystem namespace level and is serviced by minifilter drivers (
bindflt.sys,cldflt.sys). -
Attack vector: Create or modify Bind Links that map an EDR’s real executable folder path to a different target (for example, an empty folder or attacker-controlled files). When the OS or service manager looks up the EDR service binary, the redirected path is used — causing the service to fail to load the real agent or to load a manipulated binary (depending on protections in place).
-
Privilege model: Because Bind Links are an OS feature, the exact privileges required to create or change them depend on configuration; in some scenarios attackers who already have local access or lateral movement capabilities — even without kernel access — can abuse this to neutralize EDR controls.
-
Why kernel-level access isn’t needed: The method leverages user-mode operations that cause the minifilter to present a different namespace; it does not require loading a custom driver or executing code at ring-0.
Important: I won’t provide step-by-step exploit instructions. The goal here is to explain the threat and help defenders respond.
Indicators of compromise (what to look for)
Detecting Bind Link misuse requires monitoring for unusual filesystem namespace activity and for failures/changes in EDR behavior:
-
Sudden loss of EDR process(es), service startup failures, or repeated service crashes without corresponding file deletion events.
-
Unexpected file path mismatches — locations reported by the EDR for its binaries do not match the binaries actually on disk.
-
Creation of reparse points / namespace redirections that target EDR paths (audit file system changes and watch for new reparse points against typical EDR install directories).
-
Unusual or new usage of minifilter drivers (
bindflt.sys,cldflt.sys) or events tied to minifilter activity in host logging. -
Abnormal process activity that attempts to read EDR files but receives unexpected contents or errors.
-
Network indicators or lateral movement that precede a change in EDR status.
Note: Many environments don’t currently log Bind Link creation explicitly, so enhancing file system and host telemetry is critical.
Immediate mitigation and detection recommendations (for defenders)
These actions reduce risk now while more permanent fixes are pursued:
-
Assess exposure. Inventory endpoints running Windows 11 24H2 (and later) and identify hosts where Bind Links can be created by non-trusted principals (interactive users, local non-privileged services).
-
Harden privileged accounts and services. Enforce least privilege on services and scheduled tasks; remove unnecessary local admin rights. Ensure service accounts cannot be trivially abused to create or alter Bind Links.
-
Protect EDR files and services.
-
Ensure EDR binaries are stored in protected locations with strict ACLs and are subject to Windows Code Integrity and Driver/Executable signing checks where supported (WDAC/AppLocker).
-
Use vendor-provided hardening options that make agent binaries non-replaceable and services resistant to tampering (protected processes, service hardening).
-
-
Network and segmentation controls. Limit lateral movement that would allow an attacker to reach endpoints from which Bind Links could be abused.
-
Improve logging and host telemetry.
-
Capture file system events for changes to EDR install directories, reparse point creation, and service failures.
-
Monitor for minifilter anomalies and unexpected use of
bindflt.sys/cldflt.sysbehavior where possible.
-
-
EDR vendor coordination. Ask your vendor about patches or mitigations they can deploy (for example, agents that verify their path/residency and refuse to start if redirected; or kernel-level integrity checks that detect namespace tampering).
-
Restrict creation of Bind Links where feasible. If an organizational policy or configuration can prevent non-admin users or services from creating Bind Links, apply it. (Exact controls depend on your environment; consult Microsoft and your OS hardening guidance.)
-
Patch and update. Track updates from Microsoft about Bind Link behavior and from EDR vendors for agent updates that mitigate this class of attack.
Guidance for vendors and Microsoft
-
EDR vendors should add self-integrity checks that detect when the agent binary or its install folder has been namespace-redirected or is not the expected file; fail-safe behavior should prevent silent disabling. Consider verifying the on-disk path/version against a trusted kernel-mode view or using a small, protected kernel component that validates agent residency.
-
Microsoft should consider tighter controls or clearer privilege boundaries around Bind Link creation, and provide audit events for Bind Link lifecycle operations to make detection easier.
-
Both vendors and platform maintainers should publish guidance and patches quickly, since this technique subverts assumptions many defenders hold about file-system integrity.
Risk profile and urgency
Because EDR-Redir doesn’t require a kernel exploit and targets the defender’s last line of visibility, it is a high-risk technique in environments where attackers can achieve local access or lateral movement. Organizations that host high-value assets should treat the issue as urgent: verify EDR integrity, restrict privilege, and coordinate with vendors for patches or agent hardening.
Conclusion
EDR-Redir exposes an important class of attacks that misuse legitimate OS functionality — Windows Bind Links and associated minifilter behavior — to blind endpoint defenses. The good news is that awareness, improved telemetry, vendor hardening, and immediate access/privilege restrictions can greatly reduce exposure. The bad news is that many environments currently lack the telemetry, ACL discipline, or vendor mitigations needed to detect or prevent this technique.

Comments
Post a Comment