I’d like to thank my coauthors, Andrei-Marius Muntea, Andrei Mermeze, Radu-Marian Portase, and Vlad Lazar, for their invaluable contributions to this research.
TL;DR: Windows includes a file-system virtualization feature that can redirect one local path to another without modifying the original file or leaving a persistent filesystem artifact. It is implemented by bindflt.sys, the Bind Filter minifilter driver, and used legitimately by Store apps, Windows Sandbox, and Windows containers. Bitdefender Labs documented and named three new techniques that an attacker running as a local administrator can use to blind EDR sensors and bypass built-in Windows defenses such as AMSI and AppLocker.
Every time Windows ships a new capability, researchers at Bitdefender Labs ask the same question: how does it change the threat model? Many of us teach at universities and publish academic research, and we bring that habit to product security: study a feature in depth before anyone weaponizes it, so we can neutralize a technique rather than react to it after an incident. Bind links are a case in point. When we first looked at them, they seemed like a narrow file-hijacking trick. They are not.
A bind link is a building block that an attacker can combine into larger attacks. We documented and named three such techniques, each more advanced than the last. Pointed at a DLL, it becomes File-Binding: a process loads an attacker's file from a path it trusts. Pointed at an executable, it becomes Process-Binding: the operating system reports one image path while the code runs from another file. Scoped to a Windows silo, it becomes Silo-Binding: one filesystem view inside the silo, a different view outside of it. A process inside the silo executes attacker-controlled code while every tool outside the silo re-opens the same paths and sees clean files.
This breaks assumptions relied on by many EDR sensors, AppLocker, path-based firewall rules, hash-based telemetry, asynchronous scanners, and forensic tooling.
| Technique | What It Shadows | What It Defeats | End Result |
| File-Binding | a trusted file or DLL path | AMSI, EDR user-mode sensors, forensic artifacts | a trusted path returns attacker-controlled content |
| Process-Binding | a trusted executable path | image-path allowlisting, signature and policy checks | the operating system reports one image while another runs |
| Silo-Binding | the same path, inside vs. outside a silo | AppLocker, Windows Firewall, Sysmon hashing, async re-scans | the payload runs inside the silo while tools outside see a clean file |
Each technique builds on the one before it, and each closes a weakness left exposed by the previous one.
After our responsible disclosure, Microsoft assessed the severity as low because it requires administrator access. Our position aligns with how the industry already treats Bring Your Own Vulnerable Driver (BYOVD): admin is not game over. The bind-link attack surface is now part of Bitdefender’s product threat model, and this publication provides detection guidance for the broader security community.
A lot of Windows security logic starts with a path. A process is created and a driver receives an image path. A security product opens that path to hash the file. AppLocker checks a path, hash, or publisher rule. A firewall rule decides whether a process may connect based on its executable path. An EDR sensor injects a DLL from a trusted product directory. PowerShell loads amsi.dll from System32 and assumes it received the real AMSI library.
The assumption behind every one of these decisions is the same: the path being evaluated maps to the file everyone thinks it maps to. Breaking that assumption is the essence of process impersonation: a family of techniques that make a process's visible identity, its name, path, and on-disk hash, disagree with what is actually running. Bind links are the newest entry, and the one that subverts the path itself rather than the process's memory. For the broader family and the detection signals that cut across it, see our explainer What is Process Impersonation.
Bind links break that assumption. A bind link makes one path resolve to another file. The source path is what the caller opens; the backing path is what the kernel actually returns. The redirection happens inside the file-system minifilter stack (the layer of kernel drivers that can intercept file operations as they happen), not through an on-disk reparse point (the mechanism behind symbolic links), so the original source file can remain untouched. It still exists on disk and it still looks clean when enumerated. The redirection lives in memory, inside bindflt.sys.
That makes bind links different from ordinary symbolic links in exactly the places that matter for detection:
The result is not classic process injection, hollowing, or DLL search-order abuse. The attacker does not modify the trusted file, does not write into another process, and does not patch an EDR hook. The attacker changes file resolution and lets a trusted Windows component do the rest.
Every Windows 10 RS4+ and Windows 11 system is exposed once an attacker has administrator access on it. Every AV and EDR that trusts the image-file path returned by standard process-notification routines is affected. Every Sysmon deployment can be deceived, and Sysmon is now built into Windows 11 and Windows Server 2025 (though not enabled by default).
The assumptions for this research mirror BYOVD attacks: the host is already compromised, code execution is available, and administrative privileges are available to talk to bindflt.sys. The operational goals are detection evasion, low noise, and a minimal forensic footprint, similar to BYOVD.
It is worth being precise about why that matters, because BYOVD is routinely underestimated. Most "EDR killers" traded in the criminal ecosystem are built on it: the attacker loads a legitimately signed but vulnerable driver and uses it to blind or disable the endpoint agent from the kernel. The technique is often waved away because it requires local administrator rights. But attacker behavior tells a different story.
This is not a nation-state level of sophistication: by now, most professional ransomware groups have an EDR killer in their toolkit and reach for it as a standard step before encryption. Bind-link abuse hands those same attackers another way to blind the endpoint agent that needs no vulnerable driver at all, only a documented Windows feature and the administrator rights they already have.
And bind links are not only an evasion tool. We also found and reported a privilege-escalation scenario in Docker Desktop, where a member of the docker-users group, who is not a local administrator on the host, can use a bind link to reach SYSTEM (the full mechanics are in our research paper). After we reported it, Docker updated its own documentation to warn that members of docker-users can elevate to administrator on the host. This is the one such path we found and disclosed, and we are confident it is not the only way bind links can be weaponized beyond detection evasion.
A bind link redirects a source path to a backing path. Open the source path, and the caller receives the backing file instead, usually believing it opened the original. The redirection is implemented by bindflt.sys, a Windows minifilter driver present on modern systems and used for legitimate virtualization.
The main components are:
The user-mode components are optional. Tools can send commands to the driver directly from any process running as administrator, which is how our bindutil utility works on older Windows versions that lack the API DLLs.
The easiest way to understand bind links is to compare them with symbolic links, where a few subtle differences matter a great deal.
A symbolic link is an object on disk, visible to filesystem tools. If it exists, file enumeration can show that something unusual sits at the source path. A bind link is different. The redirection lives in bindflt.sys’s internal mapping table. It is not a file and not a reparse point. It disappears on reboot or when the mapping is removed, and most filesystem enumeration will not reveal that a bind link is present.
The second difference is more important: a bind link can shadow an existing file. A symlink normally requires the source to be created as a link object. With a bind link, the source file can already exist. The real file stays on disk, byte for byte, and the bind link simply intercepts opens for that path and returns the backing file.
That is the primitive everything else builds on.
*Hidden from normal file enumeration; visible only to tools that query the Bind Filter driver. Orange marks the properties that are benefiting attackers.
There are two useful ways to think about bind links: anchorless links and shadow links.
In an anchorless bind link, the source path does not exist before the mapping is created. After it exists, opening the source path returns content from the backing path.
Virtual.txt is never created on disk. The program opens that path, and Bind Filter, returns the contents of backing.txt.
Here virtual.txt is never created as a normal file; the path is virtualized by the bind link, and a program that opens it receives the contents of backing.txt. This is close to the mental model of a symlink, except the mapping is managed by bindflt.sys rather than represented as a persistent reparse point on disk.
A shadow bind link in Windows creates a virtual path that binds to an already existing directory because both files already exist. After the link is created, a program that opens and reads virtualized.txt receives ABC, the content of backing.txt. The original virtualized.txt still exists, and its on-disk content is still 123. Remove the mapping, and reading the same path returns 123 again.
A shadow bind link sits over a file that already exists. Reading virtualized.txt returns ABC from backing.txt, while the real file on disk still holds 123, untouched.
This is what makes bind links powerful from an attacker’s perspective. A trusted path can stay present, signed, clean, and apparently untouched, while the file actually returned to a caller is different. From here, we get the first abuse technique.
File-Binding is path hijacking. The attacker chooses a file path that another component trusts and creates a bind link from that trusted source to an attacker-controlled backing file. Any process that opens the trusted path receives the attacker’s file instead.
The source file does not have to be deleted. The trusted directory does not have to be modified. The attacker does not patch the target process. The application opens the path it always opens, and a component running in the kernel hands it a different file. That single move has direct consequences for anti-malware and EDR products and the Windows technologies they rely on.
AMSI, the Antimalware Scan Interface, is a good first example because so many Windows components use it: PowerShell, Windows Script Host, the JavaScript and VBScript engines, and Office macro execution paths.
The core of AMSI lives in amsi.dll. PowerShell starts, loads C:\Windows\System32\amsi.dll, and calls AMSI functions to scan script content before execution. If an attacker creates a bind link from the real AMSI path to a replacement DLL exporting the same functions, PowerShell still believes it loaded AMSI from System32, but the code mapped into the process is attacker-controlled.
File-Binding in action: PowerShell loads amsi.dll as always, but the bind link hands it the attacker's DLL, which exports the same functions and scans nothing. Every scan returns clean, so malicious scripts run uninspected — without patching PowerShell or amsi.dll on disk.
Two things matter here. First, AMSI is neutralized without patching PowerShell, without patching amsi.dll on disk, and without classic remote-injection APIs. Second, this is not specific to AMSI. Any DLL path another process trusts can be targeted: user-mode EDR sensor DLLs, plugin DLLs, ETW provider DLLs, or application components loaded from predictable locations. The technique turns “load a trusted DLL” into “load whatever the bind link returns.”
Many EDR products inject user-mode sensor DLLs into monitored processes to collect API telemetry, capture context, and talk to the product’s service or kernel driver.
If the attacker knows the sensor DLL path, File-Binding can redirect it to a no-op replacement. When the EDR tries to load its sensor, the process receives the attacker’s DLL. From the EDR’s perspective, the load can look successful: the path is correct, the export names are present, the target process keeps running. But the expected telemetry never arrives. This is not a bypass of the kernel driver; it is an attack on the trust relationship between a path and the file returned from that path.
The same primitive applies to artifacts. If a forensic tool opens an event log at its standard .evtx path, a bind link can return a manipulated log. If an asynchronous scanner re-opens a file later, it may not receive the same file used during the original operation. The recurring pattern is simple:
File-Binding is already useful. It becomes more interesting when the source path is an executable, leading to a technique we’ve named Process-Binding.
Process-Binding is File-Binding applied to executable images. The attacker creates a shadow bind link where the source is a trusted executable and the backing is another executable, then launches the source. In the demonstrated case:
A user or process launches winver.exe. The file-resolution layer returns cmd.exe. The process that runs is backed by cmd.exe, but parts of the process-creation telemetry still identify it as winver.exe.
This is process impersonation by path virtualization. The process was created normally, but the image path used for identity and the file used for execution diverged. That matters because so many security controls treat process identity as a path. A kernel process-creation callback fires, a product records the image path, a policy engine checks whether that path is trusted, and a UI tool displays the process by the path it got from the kernel. If the reported path is the source path, the process appears to be the trusted executable.
Plain Process-Binding has one important limitation: the link is global. A global bind link from winver.exe to cmd.exe is visible to other tools. A scanner, analyst, or EDR component that reopens paths can notice the inconsistency. Some views report the trusted source; others expose the backing file. In Process Explorer, the process list may show one name while the image details or loaded-module list reveal another.
That weakness points directly at the next step. To hide the mismatch, the attacker needs two filesystem views: one in which the trusted name resolves to the payload, and another in which the payload path resolves back to the clean file. That is exactly what Silo-Binding provides.
Silo-Binding is the most advanced of the three techniques. The result is a clean split between two views of the same filesystem. Inside an isolated container, a trusted-looking process runs attacker-controlled code. Outside it, every tool that inspects that process sees a clean, legitimate file: an EDR re-opening the file to hash or scan it, AppLocker checking a rule, a firewall evaluating the connection, Sysmon recording a hash. The malware executes in plain sight while leaving the rest of the system a consistent, and false, picture.
How is that possible? It takes two pieces of background: how Bind Filter represents a redirected file internally, and how a bind link can be scoped to a specific silo.
To understand the jump from Process-Binding to Silo-Binding, it helps to see what bindflt.sys does internally. When Bind Filter redirects a file, it does not swap one file for another. It keeps both as two separate file objects:
The catch for defenders is that asking "what file is this?" can return either answer, depending on which API you call, and the calls most security tools rely on return the shadow path.
Let’s look at our winver.exe -> cmd.exe binding example from the Process-Binding chapter. The standard process-creation signals all reported the trusted source: ImageFileName, SeLocateImageName, and CreateInfo all reported winver.exe. Only PsReferenceProcessFilePointer, a less common call that reaches the real image behind the process, returned the truth: cmd.exe. The kernel debugger demonstrates this split perfectly: its !process view labeled the process winver.exe, while inspecting the actually-mapped image with !vad showed cmd.exe.
So a product that trusts the process-creation notification records winver.exe and never sees cmd.exe. That gap depends only on how you ask. The second concept is about where you ask from: the answer to "what file is this?" can change depending on which part of the system the question comes from, not just how it is asked.
The boundary that makes the same path resolve in two ways is a Windows silo, so it is worth a moment on what a silo actually is. Windows lets the kernel manage a group of processes as a single unit called a job object: it is the mechanism behind features like applying a single shared CPU or memory limit across a set of processes and stopping them together. A silo is a stronger version of a job object.
On top of grouping processes, it gives them an isolated view of the system: their own file paths, registry, and object names, walled off from everything outside. If you have ever run a Windows container, you have already used a silo without knowing the name. It is the kernel feature underneath Windows containers, packaged-app isolation, and Windows Sandbox.
What matters for the attack is that a bind link can be tied to a single silo. A global link applies to the entire machine; a silo-scoped link applies only to processes within that silo. So the same path can resolve to one file inside the silo and a different file everywhere else.
On its own, a silo-scoped link is only half the trick. It hides the payload inside the silo, but the payload file still sits on disk where anything scanning from outside could find it. To close that gap, the attacker adds a second link pointing the other way:
The two links describe opposite journeys for the same pair of files, and the bindflt.sys decides which one applies depending on the execution context. Inside the silo, opening the trusted path gives the payload, so the malicious code runs. Outside the silo, any tool that goes looking for the payload is quietly redirected to the clean original.
On one PC: inside the silo the attacker runs trusted.exe, which is redirected so malware.exe executes. Outside, the EDR scans malware.exe and is redirected back to the clean trusted.exe.
Applying this to our previous example:
A process launched inside the silo, as winver.exe, actually runs cmd.exe. A scanner outside that opens cmd.exe is handed winver.exe instead. The process list shows winver.exe, and when the security product later re-opens the file to inspect it, that lookup happens outside the silo and lands on the clean winver.exe, while the code that actually ran stays hidden behind the inverse global link. That is Silo-Binding: malicious code runs inside while the rest of the system sees a clean image.
A path is not an identity. A file object may be virtualized. And reopening the same path from elsewhere can return a different file.
To demonstrate this concept in action, we’ll use it to bypass several built-in Windows security controls.
AppLocker is the built-in Windows feature many administrators use to control which applications, installers, scripts, and DLLs are allowed to run. Picture a simple policy with two programs: trusted.exe is permitted to run, and malware.exe is not. In a real environment, the forbidden program is often a legitimate but abusable tool such as the script host wscript.exe, a favorite malware launcher.
With Silo-Binding, that block is straightforward to step around. Inside the silo, the attacker links trusted.exe to malware.exe; the inverse global link points malware.exe's path back to trusted.exe for everyone outside. The attacker then launches trusted.exe from inside the silo. malware.exe actually runs, but AppLocker makes its decision based on what it sees: the name trusted.exe, or the clean file it finds when it checks from outside the silo. The rule passes, malware.exe runs, no policy was changed, and nothing unusual was written to disk.
Windows Firewall rules can be written per program: allow this application to reach the network, block that one. A common setup allows an approved program (trusted.exe, say a browser) to connect out while blocking general-purpose tools that an attacker could use to move data off the machine.
Silo-Binding defeats these rules with the same move. Inside the silo, the attacker gives malware.exe the identity of trusted.exe. When malware.exe opens a network connection, the firewall checks the program's identity, sees trusted.exe, and lets the traffic through. As before, the specific programs do not matter. The weakness is that the firewall trusts a program's path as a reliable identity, and Silo-Binding turns that identity into something the attacker controls.
Sysmon is a widely used Windows logging tool, now built into Windows 11 and Windows Server 2025, that records detailed security events: process starts, loaded DLLs, network connections, and more. Importantly, it records the hash of each program and DLL, and threat hunters lean on those hashes to sweep an environment for known-malicious files.
Silo-Binding makes Sysmon record the hash of the wrong file. Inside the silo, trusted.exe runs malware.exe, so the malicious code executes. But Sysmon runs outside the silo, so when it opens the file to calculate the hash, it follows the inverse global link to trusted.exe, the clean original. The event written to the log shows trusted.exe and the correct hash for that clean program.
The effect is quiet but serious: a hunt for malware.exe's hash finds nothing, and the log looks entirely normal. This is not a weakness specific to Sysmon. Any tool that records an event first and then re-opens the file to hash, scan, or verify it can be fooled the same way.
The examples so far have defeated the controls built into Windows, but the same technique can work against an EDR/XDR solution. These tools do not judge a program by its file alone; they also weigh which program is running and what launched it, and Silo-Binding lets an attacker forge exactly that.
We tested it with Invoke-Mimikatz, a well-known credential-stealing script that antivirus and EDR tools reliably catch. Run normally, it was blocked the moment it executed, which is the baseline we wanted: with nothing hiding it, the protection worked.
We then ran the identical script again, but from inside a silo where the name of a trusted Windows program (tiworker.exe) was mapped to PowerShell. Launching that trusted name ran PowerShell with the Mimikatz script, but to the antivirus, the activity now appeared to come from a trusted system process rather than a suspicious script. It was allowed to run. Nothing about the script changed between the two attempts; only its apparent identity did.
Bind links are legitimate Windows functionality, built for path-virtualization scenarios such as Store apps, Windows Sandbox, and Windows containers. The same primitive gives attackers a strong post-compromise evasion tool.
File-Binding creates a trusted path that returns attacker-controlled content. Process-Binding turns that into process impersonation, where the system reports a trusted executable path while the backing image is something else. Silo-Binding splits the filesystem into two views, so the payload executes inside the silo while security tools inspect clean files outside it. Each step fixes the weakness of the one before it.
The threat model requires local administrator privileges, but, as with BYOVD, that does not make it irrelevant. An attacker should not earn a free pass on detection simply for reaching the administrator. What to do about it depends on who you are.
If you run Bitdefender GravityZone, you are already protected, and that is the point of this research. Studying attack surfaces like bind links in depth, ahead of widespread abuse, is how we build our security layers: a research-driven, prevention-first approach that aims to stop techniques before they lead to an incident, not just detect them afterward.
Bind-link abuse is an EDR-bypass and tampering technique, and GravityZone's anti-tampering protection already covers this class of attack. As with our other anti-bypass defenses, we do not publish the implementation details, but the protection is in place today, and no action is required on your part.
If you build endpoint defenses, we strongly recommend reading the full whitepaper. It covers the bind filter internals, the kernel APIs for resolving the real backing file (IoGetShadowFileInformation, PsReferenceProcessFilePointer, and parsing bindflt's internal structures), the veto mechanism and its limits, and the vendor-side detection options in full. The short version follows.
Consider asking your vendor whether they are aware of this research and how their product handles bind-link resolution: specifically, whether it validates the real backing file at process creation and re-open rather than trusting the reported image path. Understanding how your security tools address this type of technique can help you make informed decisions about your endpoint protection strategy.
This is a fair question to put to any EDR or AV provider, and the answer tells you whether the techniques in this article would be visible on your endpoints.
The full research whitepaper and the bindutil utility are available on Bitdefender's official GitHub repository. The bindutil utility is provided for research and defensive testing purposes only. It builds bind-link requests manually against bindflt.sys, so it works on multiple Windows versions without requiring any other libraries. Users are responsible for ensuring their use of this tool complies with applicable laws and organizational policies.
This research is part of Ctrl-Alt-DECODE, Bitdefender’s threat intelligence initiative.
Subscribe to the Newsletter: Get exclusive threat intelligence, original research, and actionable advisories directly from Bitdefender Labs and MDR teams:
https://www.linkedin.com/newsletters/7371216616015036416/
Watch the Livestreams: You can also watch our previous Ctrl-Alt-DECODE Live episodes on YouTube.
Bind-link abuse does not map cleanly to a single MITRE ATT&CK technique because the primitive lies beneath many behaviors. Depending on the target, it supports several tactics. Each behavior below was verified against the corresponding ATT&CK entry.
| Tactic | Technique | Name | Observed |
| Defense Evasion | T1562.001 | Impair Defenses: Disable or Modify Tools | File-Binding hijacks EDR sensors and ETW provider DLLs; Silo-Binding defeats AppLocker, Windows Firewall, and Sysmon |
| Defense Evasion | T1574.001 | Hijack Execution Flow: DLL Search Order Hijacking | AMSI DLL bind link, EDR sensor DLL bind link |
| Defense Evasion | T1574.002 | Hijack Execution Flow: DLL Side-Loading | ETW provider DLL replaced via File-Binding |
| Defense Evasion | T1036.005 | Masquerading: Match Legitimate Name or Location | Process-Binding and Silo-Binding make malware appear as legitimate executables |
| Defense Evasion | T1055 | Process Injection | Related: Process-Binding spoofs process identity without injection but achieves similar evasion goals |
| Defense Evasion | T1070.001 | Indicator Removal: Clear Windows Event Logs | .evtx bind link hides or manipulates event logs |
| Credential Access | T1003.002 | OS Credential Dumping: Security Account Manager | Invoke-Mimikatz executed under a spoofed identity via Silo-Binding |
| No Clean Mapping | NEW | Container Bind-Link Privilege Escalation | docker-users to SYSTEM via a bind mount over a host protected directory. This is not a container escape (T1611) but the documented behavior of Windows-container bind mounts combined with the docker-users permissions model, so no existing technique fits cleanly. |