An Old Windows Feature, A New Evasion Trick

Security researchers at Bitdefender have detailed a post-compromise evasion technique that abuses Windows bind links — a legitimate operating system feature — to make security tools believe they’re inspecting one file when a completely different, attacker-controlled file is actually running. The research, shared with Cyber Security News, doesn’t describe a new malware family or an active mass campaign. Instead, it’s a technique that ransomware operators and other intruders could fold into their playbook once they’ve already gained local administrator access on a Windows machine.

Bind links are managed by the Windows Bind Filter driver and normally support virtualization features such as Windows containers and Sandbox environments. Unlike a symbolic link, a bind link exists only in memory rather than as a visible object on disk, which means routine file-system enumeration — the kind many security tools rely on — is far less likely to spot it. In effect, an attacker can redirect a trusted file path to point somewhere else entirely, without ever creating a suspicious file that a scanner could flag.

Three Flavors of Redirection

Bitdefender’s researchers broke the technique into three related methods. The first, File-Binding, redirects a trusted DLL path to a substitute library that mimics the expected functions but skips the security checks the original performed. In one proof-of-concept, this caused PowerShell to load a fake AMSI component, letting malicious scripts sail through as “clean” without ever touching or patching the real, signed Windows file.

The second method, Process-Binding, applies the same redirection trick to an executable image rather than a DLL. Windows can report the original, trusted file path during process creation, even though a completely different backing executable is the one actually supplying the running code. That gap between “reported path” and “actual code” undermines any security control that leans on file paths as a marker of trust — including path-based allowlisting and signature validation.

The most sophisticated variant, Silo-Binding, layers in a Windows silo — the isolation boundary that underpins containers and sandboxed environments — so that the exact same file path resolves to two different things depending on where you’re standing. From inside the isolated process group, a trusted-looking path can lead straight to malicious code. From outside it, the same path resolves back to the legitimate, clean file, giving investigators, EDR platforms, and administrators an entirely false picture of what’s actually running.

Why This Matters for Detection and Logging

The practical impact lands squarely on the tools defenders depend on most. Silo-Binding in particular can affect AppLocker enforcement, Windows Firewall rules, and Sysmon’s file-hashing behavior — Sysmon may faithfully log the trusted program’s name and hash, while the code that actually executed inside the silo goes completely unrecorded. User-mode EDR sensors, event-tracing components, and forensic tools that reopen a file path later for analysis are similarly exposed, since the “later” read can return something different from what actually ran.

This isn’t the first time file-system internals have created blind spots for Windows defenders — earlier research into Windows MiniFilter EDR bypasses and low-privileged EDR evasion via path masquerading raised related concerns. What’s new here is that bind links shift the deception directly into how Windows resolves file paths at the kernel level, rather than relying on tricks layered on top of the file system. It also arrives alongside a separate, recently disclosed Microsoft AppLocker policy flaw, reinforcing a pattern where application-control assumptions keep leaving room for unauthorized code execution.

What Defenders Can Do

Because this technique requires local administrator privileges to begin with, the first line of defense remains limiting who can obtain that access and how. Beyond that, security teams should treat it as a reminder to:

• Reduce standing local administrator rights wherever operationally possible
• Monitor for unusual Bind Filter driver activity and silo creation on endpoints
• Avoid relying solely on file path or reported process name as a trust signal in detection logic
• Pair Sysmon and EDR telemetry with independent, kernel-level integrity checks where feasible
• Track vendor guidance from Bitdefender and Microsoft as detection signatures for this technique mature

As detection tooling grows more sophisticated, attackers are increasingly targeting the trust assumptions baked into that tooling itself — and bind link abuse is a clear example of how a legitimate, decades-old Windows feature can be repurposed into a serious blind spot once an intruder already has a foothold.