admin/AlloySecureGroup-BlinkLinkSentiennel
1
0
Fork 0
mirror of https://github.com/AlloySecureGroup/BlinkLinkSentiennel synced 2026-08-09 11:57:38 +00:00
Code Issues Packages Projects Releases Wiki Activity

Add files via upload

Browse Source
This commit is contained in:
Alloy Secure Group
2026-07-22 10:08:10 -06:00
committed by GitHub
parent c60c5f0150
commit 5719c89f0a
1 changed files with 27 additions and 3 deletions
Download Patch File Download Diff File Expand all files Collapse all files
README.md
+27 -3
View File
@@ -29,8 +29,9 @@ The attacker's stealth depends on defenders trusting reported paths and never as
| --- | --- | --- |
| `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. |
Both share the same design and configuration model. Pick whichever fits your deployment.
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
@@ -87,9 +88,32 @@ The highest-fidelity detection is enumerating live bind-link mappings, both glob
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.
## Lab testing
## Testing
To validate that the sensor fires, reproduce the technique in an isolated lab with Bitdefender's official toolset, then point BindlinkSentinel at the affected paths.
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:
1. **Signature checker sanity.** A genuine signed system binary verifies, and a random blob does not.
2. **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.
3. **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.