Bitdefender researchers have disclosed that a legitimate Windows component, the Bind Filter driver (bindflt.sys), can be abused by attackers with local administrator privileges to make endpoint security tools overlook malicious activity. The techniques, published on July 15, let malware run under the identity of trusted Windows processes while antivirus and EDR solutions see only a clean, signed file. Microsoft has added a partial mitigation in Windows 11 version 24H2, but Bitdefender warns it falls short of a complete fix.
How an attacker turns a trusted file path into a lie
The core issue is simple: many security products decide whether to trust, block, scan, or log an action based on the file path a program reports—the location of the executable or DLL. A bind link lets an attacker with admin rights create a false trail.
Windows bind links are an official filesystem redirection feature, handled by the bindflt.sys minifilter driver and fully documented by Microsoft. They are used legitimately for Windows containers, Windows Sandbox, and application virtualization. Unlike symbolic links or junction points, a bind link does not have to leave a visible marker on disk. It can shadow an existing file, keeping the original intact, signed, and hash-verified. But when a program opens that path, the kernel silently redirects the request to an attacker-controlled file.
Because the redirected mapping lives only in the Bind Filter’s in-memory state, it disappears after a restart. And when a security tool later scans the same path, it might re‑examine the clean original, not the malicious payload that actually ran. The result: a forensic mismatch that gives attackers room to operate unseen.
Bitdefender’s research names three concrete evasion techniques, each escalating in sophistication.
File-Binding: swapping DLLs and scripts under a trusted name
The first method, File-Binding, targets a file or DLL path that a security component implicitly trusts. Instead of tampering with the original file—which would change its hash and trigger alerts—the attacker redirects that trusted path to a malicious copy. The legitimate DLL remains untouched. When a service loads the DLL by its usual name, Windows hands it the rogue file.
This can interfere with the Antimalware Scan Interface (AMSI), which is used by PowerShell, script hosts, and Office macros. AMSI ordinarily calls into amsi.dll, but a bind link could swap in a dummy DLL that simply returns “clean” results. The same technique works against user-mode EDR sensor DLLs, Event Tracing for Windows providers, and forensic tools that rely on path-based collection.
Process-Binding: impersonating a legitimate executable
Process-Binding extends the idea to executable images. The attacker maps a well-known, trusted process path (say, C:\Windows\System32\svchost.exe) to a different executable. When the process is launched normally, its reported image path will point to the legitimate location, but the actual code running comes from the attacker’s file.
This is not process injection or hollowing, which leave their own forensic footprints. Here, the process starts through a clean launch flow, but there is a gap between the “who I am” that some observers see and the “what I really am.” That gap matters for any control that allows or blocks activity based on an executable’s location, publisher certificate, or path-derived reputation—AppLocker policies, Windows Firewall rules, EDR exclusions, and software allowlists all become vulnerable.
However, plain Process-Binding has a weakness: because the binding is global, a different tool might later reopen the path and notice something is off. That brings us to the third and most dangerous technique.
Silo-Binding: a split reality for security products
Silo-Binding uses Windows silos—an isolation mechanism tied to containers—to create completely different filesystem views. Inside the silo, a trusted-looking path resolves to the attacker’s payload. Outside the silo, any security product that inspects that path is redirected to the clean original.
The attacker runs the malicious process inside the silo. EDR, AppLocker, Sysmon, or a firewall rule running in the host context sees only the legitimate file. Bitdefender demonstrated the technique by making Mimikatz, a credential-theft tool, appear to run as tiworker.exe (the Windows Modules Installer Worker) while defenses outside the silo observed a harmless system file.
This breaks a fundamental assumption: that re‑opening a file and re‑hashing it will confirm what ran at process creation time. Under Silo-Binding, the same filename can yield different answers depending on who is asking and from which execution context.
The limited 24H2 fix—and why it’s not enough
Microsoft added a bind-link veto capability in Windows 11 version 24H2. A minifilter driver (such as an antivirus filter) can reject a proposed bind link for paths it protects, blocking redirection before it takes effect. The documentation confirms that the filter must sit below Bind Filter to intercept the relevant request, and the veto only works on the system’s boot partition.
Bitdefender describes this as a partial mitigation, not a universal remedy. The creation‑time veto can be bypassed in some scenarios, and the restriction to the boot partition leaves other drives unprotected. Moreover, the veto requires the security product to be specifically architected to query and validate the actual backing file—something many current EDR solutions may not do. Organizations that simply upgrade to 24H2 will not automatically inoculate themselves unless their endpoint protection stack includes and enables the new safeguard.
Older Windows versions—including Windows 10 1803 through current releases before 24H2—receive no such mechanism at all.
What this means for you, depending on your role
For home users
A remote attacker cannot walk in and immediately exploit bind links. The techniques require local administrator rights on your PC first. That means your main defense remains the basics: keep Windows and your browsers updated, use strong, unique passwords, and do not run with admin privileges daily. If someone does manage to gain admin access—through a Trojan, a malicious script you ran, or weak credentials—these evasion methods could let them hide from your antivirus. The good news: no evidence of active criminal use of these specific techniques has yet appeared in public reporting.
For business administrators and IT teams
In a managed environment, the bar is lower than it looks. Attackers routinely escalate from a foothold to local admin as a prelude to credential theft and lateral movement. The Bitdefender research shows that once an attacker has admin rights, the security tools you rely on to detect that compromise may instantly go blind.
This is reminiscent of bring-your-own-vulnerable-driver (BYOVD) attacks, except it requires no third-party driver—only a built-in Windows feature. The immediate priorities are:
- Verify that your EDR vendor can detect and block malicious bind-link creation, especially silo-based bindings.
- Ask whether the product resolves the true backing file at process-creation time and again during subsequent scans, hashing, and quarantine actions.
- Review any AppLocker policies, firewall rules, or EDR exclusions that rely on file paths. A bind link can cause a malicious process to inherit a trusted path and bypass them.
For developers and DevOps engineers
A separate finding from Bitdefender involves Docker Desktop. The local docker-users group—often granted to non-administrative developers—can be used to reach SYSTEM privileges through Windows container bind mounts. Docker has updated its documentation to warn that group members can elevate to administrator on the host. If your organization runs Docker on Windows, audit who belongs to docker-users and treat unexpected membership as a potential security incident.
How we got here: a feature becomes a threat vector
Windows bind links have been present since Windows 10 version 1803 (released in April 2018). Microsoft designed them to support container and sandbox isolation, giving an OS a lightweight way to present different filesystem views to different processes. In those legitimate scenarios, transparency is the whole point: an application inside a container should not know that its system32 folder is really being served from a backing image.
The security community has long known that filesystem redirection can subvert path-based trust. Symbolic links, mount points, and directory junctions have all been used in evasion techniques before. But bind links escaped deeper scrutiny because they lacked a public, documented API for attackers to exploit—they were used internally by container and sandbox components. Over time, the necessary system calls and structures became better understood, and researchers at Bitdefender Labs realized the attack surface was effectively unmonitored.
When Bitdefender disclosed the findings to Microsoft, the company classified them as low severity because of the administrator prerequisite. That assessment is consistent with Microsoft’s traditional boundary, but it downplays the post-compromise reality: attackers who obtain admin rights should not automatically gain a way to blind all endpoint defenses. The same thinking drove the eventual tightening of vulnerable driver policies, and a similar reckoning may now be needed for bind links.
The addition of the veto mechanism in 24H2 is an acknowledgment of the problem, but the narrow scope—boot partition only, requires a filter below BindFlt—suggests Microsoft views this as a first step rather than a final one.
What to do now
For everyone: Treat local administrator access as a serious boundary. If an attacker gains admin on a single machine, assume any existing endpoint protection may be compromised. Investigate immediately, even if telemetry looks quiet.
For security teams:
1. Engage your EDR vendor with specific questions:
- Does the product enumate active bind-link mappings, including those scoped to silos?
- At process start, does it retrieve the backing file object (using an approach like FltGetFileNameInformation with FLT_FILE_NAME_OPENED) to ensure the reported path matches the actual file being executed?
- Does the same verification occur during subsequent scans, hashing operations, and quarantine attempts?
2. Audit path-based policies: Look at AppLocker rules, firewall rules, EDR exclusions, DLP rules, and software allowlists. Any rule that says “trust C:\Program Files\MyApp\tool.exe” could be bypassed by a bind link that remaps that path to something else. Consider shifting to publisher- or hash-based rules where feasible.
3. Monitor for unexpected admin privilege escalation and treat quiet telemetry as suspicious. If a machine suddenly stops sending EDR events after a privilege escalation, that may itself be a signal.
4. Review Docker Desktop deployments: Check membership of the local docker-users group. Docker’s updated documentation warns that group members can elevate to administrator. Remove unnecessary users and watch for additions.
For Microsoft and the broader industry: Clearer telemetry around bind-link creation would help defenders. A new Event Tracing for Windows provider or Sysmon event for bind-link operations could allow security operations centers to detect the technique in progress, even if the primary EDR sensor is blinded.
The path forward
The Bitdefender research does not describe a new vulnerability so much as an overlooked property of a decade-old API. It surfaces a hard truth for endpoint defense: a file path is not the same as a file identity, and on Windows, they can be deliberately split. Security products that assume they are the same will continue to be fooled.
The Windows 11 24H2 veto offers a lever for vendors to pull, but the real work lies in getting EDR engines to treat the backing object as the source of truth at every security decision. Expect to see a wave of updates from endpoint protection platforms as word of the binding techniques spreads. In the meantime, treat local admin accounts with extreme care—and verify that the file your tools say is running is really the one being executed.