A user-mode detection sensor prototype for bind-link abuse on Windows, the EDR-evasion class documented by Bitdefender Labs in Bind Link Abuse: One Windows Feature, Many Ways to Blind Your EDR (Martin Zugec and coauthors, July 15, 2026).

BindlinkSentinel is a defensive tool. It detects redirection of trusted paths, watches decoy lures, and confirms Bind Filter driver state. It does not create bind links and contains no evasion primitive. To exercise it in a lab, generate test mappings with Bitdefender's published bindutil toolset and point the sensor at the affected paths.

Background

Windows ships a file-system virtualization feature, the Bind Filter minifilter (bindflt.sys), that can redirect one local path to another in memory without touching the original file or leaving a persistent on-disk artifact. It is used legitimately by Store apps, Windows Sandbox, and Windows containers. Bitdefender documented three techniques an attacker with local administrator rights can build from this primitive:

File-Binding. A trusted file or DLL path returns attacker-controlled content. Defeats AMSI, user-mode EDR sensors, and forensic artifact collection.
Process-Binding. A trusted executable path is launched while a different image actually runs. Defeats image-path allowlisting and signature or policy checks.
Silo-Binding. A silo-scoped link plus an inverse global link split the filesystem into two views, so the payload runs inside the silo while tools outside re-open the same paths and see a clean file. Defeats AppLocker, Windows Firewall, Sysmon hashing, and asynchronous re-scans.

The common thread is that a lot of security logic starts from a path and assumes the path maps to the file everyone thinks it maps to. Bind links break that assumption.

The defensive idea

The attacker's stealth depends on defenders trusting reported paths and never asking the driver what mappings exist. BindlinkSentinel works the signals available from user mode:

Signature verification. Authenticode is checked on each watched trusted path with WinVerifyTrust. A redirect to an unsigned payload breaks validation. This is the most tamper-resistant signal, because forging a valid Microsoft signature over a payload is a much higher bar than swapping a hash.
Hash baseline comparison. Each watched path is hashed with SHA-256 and compared against a baseline captured from a known-clean image. A shadow bind link over a trusted file shows up as a hash that no longer matches.
Decoy monitoring. Bait files and directories are watched. Nothing legitimate should touch them, so any change is treated as an incident.
Driver presence. The sensor confirms the bindflt service state and provides a marked integration point for enumerating live mappings.

What is in this repository

File	Language	Purpose
`bindlink_sentinel.cpp`	C++ (Win32)	Native prototype. Uses `WinVerifyTrust`, BCrypt SHA-256, `ReadDirectoryChangesW`, and `fltlib`.
`BindlinkSentinel.cs`	C# 5 / .NET Framework 4.8	Managed port. Uses `WinVerifyTrust` via P/Invoke, `SHA256`, `FileSystemWatcher`, and `ServiceController`. No string interpolation.
`BindlinkSentinelSim.cs`	C# 5 / .NET Framework 4.8	Test harness. Emulates the file-layer effect of a shadow bind link in a temp sandbox and asserts the detection logic reacts. Creates no bind link, needs no admin.

The two sensors share the same design and configuration model. Pick whichever fits your deployment. The simulation is a standalone harness for validating the detection logic.

Detection signals and what they catch

Signal	Catches	Notes
Signature broken on a trusted path	File-Binding, Process-Binding to unsigned payload	Strongest single signal.
Hash diverges from baseline	Shadow bind link over a trusted file, or on-disk tamper	Requires a clean baseline.
Decoy touched	Reconnaissance or staging against bait	`FileSystemWatcher` catches create, modify, delete, and rename, not pure reads.
Live mapping enumeration	Any redirection, including the silo plus inverse-global pair	Highest fidelity, needs no baseline. Left as an integration point.

Build

C++

From an x64 Developer Command Prompt:

cl /EHsc /std:c++17 bindlink_sentinel.cpp ^
   wintrust.lib crypt32.lib bcrypt.lib fltlib.lib shlwapi.lib

C#

From a Developer Command Prompt, in the file's folder:

csc /langversion:5 /target:exe /out:BindlinkSentinel.exe ^
    /reference:System.ServiceProcess.dll BindlinkSentinel.cs

Usage

Run elevated. Capture a baseline on a trusted, known-clean system first, then monitor.

BindlinkSentinel.exe baseline
BindlinkSentinel.exe monitor

The C++ build uses the same two verbs.

Baseline data is written to C:\ProgramData\BindlinkSentinel\baseline.txt as path followed by hash|signed. Edit the watchlist and decoy lists at the top of the source to match your environment, including your EDR's sensor DLL directory and any product paths you care about.

Configuration

Both implementations expose two lists near the top of the source:

Watchlist. Trusted paths an attacker would shadow. Defaults include amsi.dll, ntdll.dll, and System32 masquerade binaries such as winver.exe, tiworker.exe, and wscript.exe.
Decoy directories. Plausible-looking bait you plant, such as a fake EDR sensor directory or a fake credential store.

The enumeration integration point

The highest-fidelity detection is enumerating live bind-link mappings, both global and silo-scoped, because it needs no baseline and catches the silo-scoped plus inverse-global pair that a baseline sweep misses. That function is intentionally left unimplemented in both files.

Enumeration requires connecting to bindflt's communication port and sending the enumeration control code, whose message layout is version-specific and not fully documented. The exact port name, control codes, and reply parsing should be taken from the bindutil source rather than guessed. The two fltlib P/Invokes are declared and ready in the C# file, and the equivalent hook is marked in the C++ file. Flag a mapping as suspicious when its source is a watched trusted path, when it is a shadow link over a signed system binary, or when a silo-scoped link is paired with an inverse global link for the same file pair.

Testing

Testing splits into two tiers. Tier one validates the detection logic and needs no admin, no bindflt, and no real bind link. Tier two validates the real driver path in an isolated lab.

Tier 1: the simulation harness

A shadow bind link over a trusted path is observable to a user-mode reader as bytes that no longer match a clean baseline and a signature that no longer validates. BindlinkSentinelSim.cs reproduces that observable effect in a temp sandbox by baselining a file and then swapping its contents, then asserts the sweep and decoy logic react. It creates no bind link and redirects no real system path.

Build and run:

csc /langversion:5 /target:exe /out:BindlinkSentinelSim.exe BindlinkSentinelSim.cs
BindlinkSentinelSim.exe

It runs three checks and prints PASS or FAIL per assertion, and exits non-zero if any fail, so it drops into CI cleanly:

Signature checker sanity. A genuine signed system binary verifies, and a random blob does not.
Trusted-path redirect emulation. A signed binary is copied into the sandbox and baselined as clean and signed. A clean sweep is silent. After the file is overwritten to emulate the redirect, the sweep raises both the hash-divergence and signature-invalid alerts.
Decoy watcher. Touching a bait file is detected.

Everything happens under %TEMP%\BindlinkSentinelSim and is removed on exit. The one way the emulation differs from a real bind link is that it replaces the on-disk bytes, whereas a real link leaves the file untouched and redirects reads in memory. That difference is invisible to the user-mode sensor, which sees the same divergent hash and broken signature either way. It does matter for the enumeration path, which is why that needs tier two.

Tier 2: the lab

To validate the real driver path, and the mapping-enumeration integration point once implemented, reproduce the technique in a disposable, snapshotted VM with Bitdefender's official toolset, then point BindlinkSentinel at the affected paths. Use a benign watched path and a harmless decoy backing file, never a path whose redirection would disable protection on the host, and never a machine you care about.

bindutil toolset: https://github.com/bitdefender/bindutil-toolset
The bindutil utility is provided for research and defensive testing only. It builds bind-link requests manually against bindflt.sys, so it works across Windows versions without extra libraries. You are responsible for ensuring your use complies with applicable laws and organizational policy.

Limitations

An attacker with local administrator rights can also kill or feed false data to a user-mode agent, so treat BindlinkSentinel as one layer, not the answer. A kernel-resident sensor with tamper protection is meaningfully stronger.
Hash comparison depends on a trustworthy baseline. Capture it on a clean image, ideally offline.
FileSystemWatcher and ReadDirectoryChangesW do not raise on pure reads. To detect an attacker merely opening a decoy, enable object-access auditing with a SACL on the bait plus the Security event log, or use a kernel component.
The Windows 24H2 veto that blocks bind links to protected paths is only a partial defense. It is absent on older Windows, fires only for links on the boot partition, and can be sidestepped. Keep your own agent files on the boot volume so the veto applies, and do not rely on it alone.
Treat every filesystem virtualization layer as attacker-controlled after compromise, not only bindflt.sys.

Scope

This project deliberately implements detection and deception only. It does not create bind links, shadow trusted binaries, or reproduce any of the three evasion techniques. Use bindutil for the create side when testing detections in a lab.

References

Bitdefender Labs, Bind Link Abuse: One Windows Feature, Many Ways to Blind Your EDR, July 15, 2026. https://www.bitdefender.com/en-us/blog/businessinsights/bind-link-abuses-windows-feature-edr-evasion-technique
Bitdefender, bindutil-toolset (research and defensive testing only). https://github.com/bitdefender/bindutil-toolset

MITRE ATT&CK context

Bind-link abuse spans several techniques rather than mapping to one. The controls BindlinkSentinel is designed to protect are targeted by, among others, T1562.001 (Impair Defenses), T1574.001 and T1574.002 (Hijack Execution Flow), T1036.005 (Masquerading), and T1070.001 (Indicator Removal: Clear Windows Event Logs).

Legal

Provided for defensive research and testing. You are responsible for ensuring your use complies with applicable laws and your organization's policies.