On July 15, Bitdefender Labs published research that turns a core trust in Windows security on its head. The team found that a local administrator — already a prize for ransomware gangs — can redirect almost any trusted file path to an attacker-controlled replacement, using a legitimate Windows feature called bind links. The file on disk remains untouched, the signature stays valid, and to any security tool that relies on a file’s path or hash, the malicious code looks exactly like a signed Microsoft binary.

The research, first reported by CSO Online and detailed by Bitdefender, identifies three concrete techniques — File-Binding, Process-Binding, and Silo-Binding — that let malware execute under an assumed identity. Microsoft assessed the behavior as low severity because it requires administrator rights, but Bitdefender argues that admin access is not a free pass. In 2026, that debate matters more than ever: bind link abuse joins Bring Your Own Vulnerable Driver (BYOVD) attacks as a post-compromise tactic that can blind endpoint protection without needing a third-party driver.

Bind links are not a hack or an exploit in the traditional sense. They are a documented file-system virtualization feature, supported since Windows 10 version 1803 and implemented by the Bind Filter minifilter driver, bindflt.sys. Windows uses them for legitimate scenarios — Windows Sandbox, Windows containers, and packaged Store apps — to map one path to another in memory, without creating a permanent filesystem object. Unlike a symbolic link, the binding is not stored on disk; it disappears on reboot and can shadow an existing file without altering it.

The Bitdefender researchers discovered that an attacker with administrator rights can instruct bindflt.sys to create shadow bind links, turning a trusted path into a tunnel for malicious code. Because the original file remains in place, scanning it returns a clean hash even as a different file loads into memory.

File-Binding: Hijacking DLLs and Artifacts

The simplest technique targets a file or DLL that another process trusts. In a demonstration, the attacker creates a bind link from C:\\Windows\\System32\\amsi.dll to a custom library that exports the same functions but returns “clean” for every scan. PowerShell loads what it believes is the real Antimalware Scan Interface, but AMSI is effectively neutered — with no memory patching, no modified file, and no flag in standard process telemetry. The same approach can blind EDR user-mode sensor DLLs or feed manipulated forensic artifacts (event logs, registry hives) to investigative tools.

Process-Binding: Making Malware Wear a Trusted Name

When File-Binding is applied to an executable, the system reports the source path as the process image while the backing file executes. In one example, binding winver.exe to cmd.exe let a launch of Windows Version Reporter spawn a command prompt. Process-creation callbacks and process-explorer-style tools label the process as the trusted binary; only lower-level kernel APIs that resolve the underlying file object can spot the mismatch. This turns any path-based allowlist into a gap: AppLocker, Windows Firewall rules, and EDR telemetry that rely on image paths can all be fooled.

Silo-Binding: Creating Two Different Realities

The most advanced technique leverages a Windows silo — the isolation boundary used by containers and Sandbox — to build a split filesystem view. The attacker creates a silo-scoped bind link that redirects a trusted path to malicious code only inside the silo, while an inverse global link outside the silo redirects the payload’s path back to the clean file. The result: the malware executes under a trusted identity inside the silo, but any security tool operating outside — Sysmon, AppLocker, a firewall, or an EDR scanner — opens the same path and sees the legitimate, signed original. Bitdefender showed that Invoke-Mimikatz, normally blocked on sight, could run undetected when it appeared to come from a trusted Windows process such as tiworker.exe.

The research also uncovered a privilege escalation in Docker Desktop: a member of the docker-users group, who is not a local administrator, could exploit bind links to gain SYSTEM-level access. Docker has since updated its documentation to warn that docker-users members can elevate to administrator on the host.

Who Is at Risk?

Home users face a low immediate risk unless their device is already deeply compromised. The technique requires administrator privileges, so the standard advice of not running as admin and keeping accounts protected still applies. However, if a home machine is breached, bind link abuse could let malware hide for longer.

Power users who experiment with Windows Sandbox, containers, or Docker Desktop should note that silo-scoped bind links can turn these isolation features into evasion shields. Monitor any process that spawns unexpectedly from a sandboxed or containerized environment, and keep Docker Desktop updated.

IT administrators and SOC teams face the steepest challenge. Ransomware operators regularly harvest local admin rights to disable endpoint protection before executing payloads. The bind link technique gives them a weapon that relies on no vulnerable driver — only the inbox bindflt.sys. Every security control that trusts a file’s path or hash is potentially undermined:
- AppLocker and Windows Defender Application Control path rules.
- Sysmon (now built into Windows 11 and Server 2025) hashing of process images.
- Windows Firewall per-program rules.
- EDR / XDR products that verify files by reopening them or rely on process-creation callbacks alone.

Developers who ship software that uses Docker Desktop or any product that trusts path-based identities should audit whether an attacker who gains admin could weaponize a bind link against their security logic. The Docker privesc highlights that containers are not automatically host-safe.

How We Got Here

Bind links were introduced with Windows 10 version 1803 as part of the push toward containerization and virtualization. bindflt.sys shipped as a low-level building block, largely invisible to users and most security tools. For years it was considered an innocuous part of the file-system stack.

Bitdefender’s research, part of its Ctrl-Alt-DECODE initiative, asked a simple question: what happens if an attacker controls the bind filter’s mapping table? The answer turned out to be a family of attacks that subvert the fundamental assumption that a file’s path reliably identifies its contents. The team disclosed its findings to Microsoft responsibly, routing details for the Docker escalation through appropriate channels.

Microsoft’s severity classification echoes a broader industry blind spot. BYOVD attacks also require elevated rights, yet security vendors invest heavily in driver blocklists and monitoring because attackers use those techniques every day. The bind link research reframes a “low-severity” admin limitation into a real-world evasion primitive.

Practical Defenses You Can Deploy Right Now

If you run Bitdefender GravityZone

You are already protected. Bitdefender says its anti-tampering layer covers bind link abuse, and no further action is required.

For everyone else, start with the fundamentals

  • Reduce local administrator count. Audit and remove unnecessary admin rights. Implement LAPS for local admin password management.
  • Monitor for unusual container or silo activity. Tools that create Windows silos (e.g., container runtimes) must be authorized. Unexpected silo creation should be a high-fidelity alert.
  • Investigate EDR blind spots. When your endpoint agent shows a signed, trusted Microsoft binary loading an unexpected DLL or making an outbound connection, do not dismiss it as a false positive — correlate with other signals.
  • Update to Windows 11 version 24H2. The 2024 update introduced a veto mechanism that lets minifilter drivers block bind links to protected paths on the boot partition. However, Bitdefender notes it is incomplete (does not cover older Windows versions, can be sidestepped). Treat it as one layer, not a solution.
  • Validate your detection stack. Ask your EDR/AV vendor whether their product resolves the backing file object at process creation and re-open. If they rely solely on the caller-supplied image path, bind links may blind them.
  • Lock down Docker Desktop. If you run Docker, ensure that only trusted users belong to the docker-users group. Apply Docker’s updated guidance.

For detection engineers and advanced admins

  • Use Microsoft Defender for Endpoint or Sysmon to monitor for unusual DeviceIoControl calls to bindflt.sys. Any process other than a validated virtualization component sending requests to create bind links should raise an alert.
  • Enumerate active bind link mappings periodically. A process inside a silo that starts from a path normally associated with System32 but whose loaded modules do not match is a tell.
  • Do not reuse hashes or paths as sole proof of identity for security decisions. Where possible, verify the backing file with kernel-mode APIs such as IoGetShadowFileInformation.

What Comes Next

Bind link research is unlikely to stop here. The primitive — virtualizing a path in memory — is so fundamental that defenders and attackers will continue to find new applications. Microsoft may extend the veto feature in future Windows releases, but until file identity is bound to content rather than path, the same class of abuse will persist.

The security industry has a few painful but long-overdue tasks: moving from path-based allowlisting to certificate or hash-based policies when using WDAC; verifying the on-disk image before every security decision; and treating filesystem virtualization drivers as attacker-controlled surfaces after compromise. Bitdefender’s whitepaper — and the practical bindlink utility it released for defensive testing — give admins a chance to test those assumptions before an incident does.

For now, the bind link story underscores a timeless lesson: admin does not mean game over, and a trusted path is just a label.