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_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\KnownDLLs
- 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_MACHINE\SYSTEM\CurrentControlSet\Control\ServiceGroupOrder
- 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

Comments
Post a Comment