BYOVD to the next level. Blind EDR with Windows Symbolic Link

 I. INTRODUCTION

In this article, I will introduce you to a completely new method of exploiting the BYOVD technique. I have discovered that by using a combination with Windows symbolic links, We can exploit many more drivers, as long as these drivers have file-writing capabilities that we can actively trigger at a specific point in time.. This will elevate the BYOVD technique to a whole new level, while also expanding the number of drivers that can potentially be exploited.

To illustrate this new technique, I will demonstrate a practical concept of using it to remove Windows Defender on Windows 11.

II. CORE

1. The "Bring Your Own Vulnerable Driver" (BYOVD) technique

Bring Your Own Vulnerable Driver (BYOVD) is a security term referring to a technique where attackers exploit legitimate but vulnerable drivers to gain control over a system. Essentially, they bring their own driver that has known vulnerabilities, allowing them to bypass security measures and execute malicious code with elevated privileges.

The BYOVD technique has become a favored strategy among threat actors. Some real-world examples of cybercriminal groups using the BYOVD technique include:

• The Kasseika Ransomware group exploits the Martini Driver to terminate processes, including antivirus products, security tools, analysis tools, and system utility tools.
• Water Bakunawa uses EDRKillShifter to evade detection and disrupt security monitoring processes.
• BlackByte ransomware gang, which used a BYOVD technique to exploit a vulnerability in the MSI Afterburner RTCore64.sys driver. This allowed them to bypass security products and disable over 1,000 drivers relied upon by security solutions.

The limitation of the Bring Your Own Vulnerable Driver technique is that we must find drivers with exploitable vulnerabilities. These drivers are often found in Microsoft's vulnerable driver blocklist. With the regular updates to the blocklist, over time, the number of drivers with vulnerabilities that can be exploited for kernel exploits will increasingly diminish.

2. Exploiting the file writing function of any driver using Windows symbolic link

A. Data transfer flow of the collected logs from EDR

As we know, Endpoint Detection and Response (EDR) installs a Minifilter on the machine to collect events related to processes, files, and so on using this Minifilter. Of course, they will always operate in kernel mode.

Simplified I/O stack with the Filter Manager

A Minifilter is a type of driver that intercepts and monitors file system operations. EDR solutions use Minifilters to capture events such as file creation, modification, deletion, and access.

EDR Minifilters typically do not send collected logs directly to the server by themselves. Instead, they collect data and pass it to a user-mode service running on the endpoint. This user-mode service is responsible for processing, analyzing, and transmitting the data to the server

The implementation of such an operational model will help alleviate the load on the Minifilter and avoid the larger issue of potential kernel exploits if the Minifilter has to perform parsing and data analysis.

To blind EDR, there are typically only two methods:

• One is to attack the EDR's Minifilter: finding a way to unload it from the operating system, preventing Windows from loading the Minifilter.
• The second is to target the user-mode service, finding a way to terminate the process of this service. At this point, the EDR will no longer be able to send logs to the analysis server.

B. Leveraging the file writing function of a driver to destroy the user-mode service of EDR

Since the user-mode service of EDR is always started with Windows, the executable file of the service will always be in use and cannot be overwritten. Therefore, we must either terminate the process of this service first or perform the file writing before this service is executed.

If we follow the approach of terminating the process of the EDR service, we would be reverting to the BYOVD exploitation process as has always been done: that is, leveraging the kernel exploit of the driver to kill the EDR process.

Therefore, in this article, I will focus on the approach of destroying the executable file of the EDR service. Specifically, the main steps are as follows:

• Step 1: Search for Minifilters that have the capability to write files upon loading without requiring I/O control codes (IOCTLs), specifically those that call the ZwWriteFile API.
• Step 2: Reverse engineer or debug these Minifilters to determine the file paths being written.
• Step 3: Register a kernel service for the Minifilter so that it loads during startup.
• Step 4: Create a symbolic link from the output file of the Minifilter to the executable file of the EDR service.
• Step 5: Reboot Windows and check whether the executable file of the EDR service has been destroyed.

At Step 1. You can use the ZwCreateFile function, but since ZwWriteFile will definitely call ZwCreateFile at some point, if ZwWriteFile has been invoked, the target file will certainly be overwritten.

At Step 3. It must be ensured that this newly registered service is always loaded and executed before the service related to the executable file of the EDR.

How can it be ensured to always execute first?

The magic of creating a key to achieve victory in the race lies in the Registry path:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\ServiceGroupOrder

This registry key defines the sequence in which service groups are loaded during the system boot. Service groups are collections of services that the operating system loads in a specific order to ensure system stability and proper operation.

The key contains a value named "List" which is a multi-string (REG_MULTI_SZ) value. Each string in this list represents a service group name.

Simply modify the "Service Group Name" of the service to the "FSFilter ***" group, and it will always be loaded and executed before the user-mode service of the EDR.

If you can register a service with a group name above "FSFilter Anti-Virus" you could potentially destroy the EDR's Minifilter as well. However, this method is likely to cause a blue screen of death (BSOD) for Windows. 

At Step 4. A symbolic link (symlink) in Windows is an advanced type of shortcut that points to a file or directory in another location. It's useful for redirecting access to files and directories without changing their actual location. There are two main types of symbolic links in Windows: soft links and hard links. 

Currently, we are only concerned with Soft Link:

• Soft links redirect to the location where the files are stored.
• When you open a soft link, you are redirected to the target location.
• Soft links can point to both files and directories.

Practical example, if you have a file named example.txt in D:\Documents and you want to create a symbolic link to it in C:\Users\YourUser\Links, you would use the following command:

mklink "C:\Users\YourUser\Links\example.txt" "D:\Documents\example.txt"

This command creates a symbolic link called example.txt in the Links folder that points to the original example.txt file in the Documents folder. Accessing C:\Users\YourUser\Links\example.txt will now direct you to the file located at D:\Documents\example.txt.

C. Abuse the driver of Process Monitor and symbolic links to disable Windows Defender

I will conduct a proof of concept to disable Windows Defender on Windows 11 Version 24H2 (OS Build 26100.2894) with the update installed in January 2025.

Process Monitor provides the function of logging the Windows boot process. When using this feature, Process Monitor will register the service as follows:

The "Group" of PROCMON24 is named "FSFilter Activity Monitor" and the "Type" is 1, which means it will function as a Minifilter operating at the kernel level.

As for Windows Defender, the WinDefend service will call the Antimalware Service Executable (MsMpEng.exe).

The WinDefend service registry does not have a "Group" value, which means it will load last in the "ServiceGroupOrder" list.

Service “Type” Values:

• 0x01: Kernel device driver.
• 0x02: File system driver.
• 0x04: Adapter driver.
• 0x08: Recognizer driver.
• 0x10: Win32 own process. The service runs in its own process.
• 0x20: Win32 shared process. The service shares a process with other services.

From the information above, I can conclude that PROCMON24 will always be loaded before WinDefend. This means that when PROCMON24 is running, the Antimalware Service Executable will not yet be active, allowing for potential overwriting.

Process Monitor will log events of the boot process into the file "C:\Windows\Procmon.pmb". At this point, to disable Defender, after enabling the "Boot Logging" feature, I will create a symbolic link as follows:

mklink C:\Windows\Procmon.pmb "C:\ProgramData\Microsoft\Windows Defender\Platform\4.18.24090.11-0\MsMpEng.exe"

After creating the symbolic link, to activate the overwriting and destruction of the Antimalware Service Executable file, thereby directly removing Windows Defender, I will reboot Windows.

After rebooting Windows, I will check whether turning off Windows Defender was successful by examining the Antimalware Service Executable file. If the file has been altered, it will lose its signature, and the Windows Service Manager will not be able to run it. Alternatively, in a better outcome, it will lose the PE file format and become a log file of Process Monitor.

The Antimalware Service Executable file has been overwritten

Now, I have successfully disabled Windows Defender. The Antimalware Service Executable file has been destroyed because PROCMON24 has overwritten its contents. Checking in the Service Manager, WinDefend no longer has the "Running" status.

The Service Control Manager will report that it cannot run the WinDefend service in the event log:

There have been a few instances where I created a symbolic link and enabled boot logging with Process Monitor, but after rebooting, the overwriting failed. There may still be some race conditions that I need to perform kernel debugging to clarify.

III. Summary

Threat actors are always seeking new methods to blind the EDR to stay under the radar of System Administrators. By using the technique known as "Bring Your Own Vulnerable Driver," they gain kernel-level access. From there, they can conceal their activities by terminating the EDR process or interfering with the event log collection process of the Minifilter.

However, to successfully use the BYOVD technique, threat actors must identify vulnerable drivers to exploit. Microsoft continuously monitors and updates the list of these drivers to include them in a blocklist regularly.

With the new attack method that combines the file writing functionality of drivers and Windows Symbolic Links, attackers are relieved from the restriction of needing to find vulnerable drivers that are not yet on the blocklist to exploit. Instead, they only need to identify any driver that has file writing capabilities, such as logging, tracing, etc. Merging with the abuse of symbolic links, BYOVD technique will evolve to a new level.

With this new attack method, the number of drivers that can be abused will be greater and easier to find. Since file writing is a legitimate function of drivers, the effectiveness of finding and adding them to the blocklist will gradually diminish. This is partly due to the large number of drivers that would need to be blocked, and partly because of the risk of inadvertently blocking valid and important drivers, which could negatively impact user experience.

Driver developers should first check whether a file is a symbolic link before interacting with it, in order to prevent the driver from being exploited for malicious purposes.