I. OVERVIEW
Continuing the series of studies on exploiting the Bindlink API to
tamper with Antivirus/EDRs. This time, I will use “bindflt.sys” to
prevent the Antivirus/EDR service from running during Windows
initialization.
You can revisit the previous articles on Bindlink exploitation.
https://www.zerosalarium.com/2025/10/DR-Redir-Break-EDR-Via-BindLink-Cloud-Filter.html
https://www.zerosalarium.com/2025/11/EDR-Redir-V2-Blind-EDR-With-Fake-Program-Files.html
In this article, I will experiment with
Windows Defender on Windows 11 25H2. I have also successfully tested it
with several commercial Antivirus/EDRs available in my lab system. Due to
concerns about negatively impacting these products, I will not specify their
names.
EDR (Endpoint Detection and Response)
AV (Antivirus)
Find me on X to get the latest pentest and red team tricks that I’ve been
researching: Two Seven One Three (@TwoSevenOneT) / X
II. MAIN SECTION
1. Some Basic Information About Antivirus/EDR Process Services
The services of Antivirus/EDRs function like any standard Windows service; the
key difference is that they are protected by kernel drivers. Characteristics
of an AV/EDR service include:
- Always running with high privileges on the machine (SYSTEM).
- Automatically starts with Windows (Auto Start).
- Always runs with Windows PPL (Protected Process Light).
-
Users in UserMode cannot modify the configuration information of this
service. -
The process of the service cannot be tampered with from UserMode (unless you
use certain tricks, such as
EDR-Freeze).
In general, once the AV/EDR service process is successfully launched, you (red
team) have limited options besides finding ways to evade your payload.
2. The Idea of Using Bindlink to Prevent Antivirus/EDR from Starting
Initially, I used Bindlink to redirect the folders of AV/EDRs to a folder I
control:
EDR-Redir: Break EDR Via BindLink.
Or going further, I could redirect the entire “Program Files”
folder:
EDR-Redir V2: Blind EDR With Fake Program Files
However, these actions occur after the EDR service has successfully started,
and vendors have methods to protect these folders.
This time, I will target a folder that every Windows process must use:
System32.
Every process on Windows relies on DLLs in the System32 folder to operate,
and EDRs are no exception.
Naturally, modifying the DLLs in System32 could lead to corruption of
Windows, so I need to use Bindlink to ensure safety and to allow only
the EDR process to load the modified DLL.
The main steps to carry out are as follows:
- Create a service that ensures it runs before the EDR service.
-
Use Bindlink to redirect a core DLL that the EDR will use to a
“corrupted” DLL. - Exploit the EDR service’s PPL protection to allow it to terminate itself.
-
After the EDR process has terminated, remove the Bindlink to allow other
processes to function normally.
For step 1, we need to know what service group the EDR belongs to in order to
create a higher priority service. I mentioned this technique in my article on
BYOVD in the section:
How can it be ensured to always execute first?
In step 2, I will copy the original DLL file from System32 to another
location, rendering the new DLL unsigned. This has two purposes:
to prevent the EDR process from loading the new DLL, and to ensure that if
any other program happens to use the redirected DLL, it will still
operate.
In step 3, since the new DLL is unsigned, the EDR process (protected by PPL)
will reject loading it and will terminate itself. You can refer to more
information about PPL in the article:
Countering EDRs With The Backing Of Protected Process Light.
Step 4 is simply about removing the redirect to ensure nothing unexpected
happens.
3. Introductions to the EDR StartupHinder tool: EDR Startup Blocker
To implement the above idea, I developed a tool concept called
EDRStartupHinder. You can download and experiment with it at the following
link:
https://github.com/TwoSevenOneT/EDRStartupHinder
EDRStartupHinder has the following parameters:
EDRStartupHinder will copy a DLL from System32 (OriginalLib) to
another location called FakeLib. It will then change one byte in the PE
header of this DLL to invalidate its signature. The next step is to register
itself as a Windows service with the name ServiceName and group
ServiceGroup.
When run in a service session, EDRStartupHinder will continuously check if the
EDR is running through the process name EDRProcess and will perform
redirect/remove-redirect when detecting that EDRProcess is active.
Some key points to note:
-
You need to find a DLL that the EDR process will terminate if it fails to
load. This DLL must be outside the KnownDLLs list to ensure it is not
preloaded: -
HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlSession
ManagerKnownDLLs - Use Process Monitor and Process Explorer to locate this DLL.
-
You’ll need to determine the group of the EDR service and then use a group
name with a higher priority: - HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlServiceGroupOrder
-
The simplest way is to use Process Monitor with BootLog to see which
services start before the EDR, and then use the group of those services.
4. Experimenting with EDRStartupHinder against Windows Defender
After researching on a lab machine, I identified that Defender will
load the DLL msvcp_win.dll at startup. Additionally, a service from the
TDI group will always start before Defender. The process of Defender I
want to block is MsMpEnd.exe.
I will run EDRStartupHinder with the following parameters:
After successfully executing, a new service named DusmSVC-01 will be
created.
When the machine restarts, EDRStartupHinder will run before Windows
Defender and redirect the DLL to the new location.
Since MsMpEng.exe runs with PPL protection, it will not load a DLL without a
signature. If this DLL is critical, it will terminate itself.
Experimental video:
III. SUMMARY
Antivirus/EDR services, while well-protected by kernel-level drivers, are
essentially just Windows services and processes. Instead of targeting these
services directly, attackers can focus on the one area that any Windows
process must utilize: System32.
EDRStartupHinder aims to exploit Windows Bindlink to redirect a DLL
from System32 to another location, alongside taking advantage of the function
that only loads DLLs signed by a program protected with Protected Process
Light (PPL) to prevent AV/EDR services from starting.
To safeguard the system against this type of attack, SysAdmins/Blue Teams must
closely monitor Bindlink usage through bindlink.dll, keep an eye on the
creation of suspicious Windows services, and implement defense-in-depth
strategies for the system.
Author of the article: Two Seven One Three





