Abusing MiniFilter Altitude to blind EDR

27 March 2024
Eito Tamura

tl;dr

If you gain local admin privilege access to a host with an EDR solution, you can potentially evade detection by blinding the kernel callbacks that the EDR relies on. This can be achieved by exploiting a minifilter driver, such as the Sysmon driver. Although a reboot of the host is required, this approach is far easier than finding a new Bring Your Own Vulnerable Driver (BYOVD) or attempting unsigned driver exploitation, which is not always an option.

Introduction

By design, Endpoint Detection and Response (EDR) solutions are designed to operate persistently and autonomously, making it difficult for adversaries to disable them, even with local admin or system-level access to an endpoint. When navigating to Windows Security settings, the traditional slide bar used to disable Windows Defender is replaced with alternative settings, such as the following.

However, despite these safeguards, adversaries have devised techniques to 'blind' EDR systems, including:

• Abuse vulnerable kernel-mode driver (BYOVD) to remove kernel callbacks for EDR solutions.
• Load unsigned driver in Windows Test mode using bcdedit /set testsigning on or bcdedit /set nointegritychecks off and remove EDR kernel callbacks.

Achieving these methods is not straightforward. Known vulnerable kernel-mode drivers, often employed in evasion tactics, can be flagged and blocked by EDR solutions. Additionally, the second method is frequently protected by Secure Boot mechanisms. Disabling Secure Boot typically requires access to UEFI Firmware Settings during boot time, necessitating physical or console access to the device.

Abusing MiniFilter Altitude

When I wrote my previous post on Sysmon, I mentioned about minifilter altitude and how it can be modified in Sysmon installation option section, specifically: The value can also be updated from the registry. However, it should be approached with caution, as if you use the same value twice in the system, one of the services would not start.

While working on the previous post, I put my red team hat back on and asked myself: "Can I set the Sysmon altitude value to match that of the EDR, potentially blinding the EDR's kernel callbacks?". To test this hypothesis, I modified the Sysmon altitude value using registry editor:

I received the following alert from the EDR (a well-known vendor, which I won't name) and registry editor was terminated immediately. It appeared that the EDR is strictly monitoring any services trying to use their altitude value.

The Bypass

After revisiting this scenario, it became apparent that the EDR system has a static detection rule configured for a specific value in the registry. A registry entry typically consists of three components: Name, Type, and Data. Upon investigation, I discovered that changing the Type attribute can bypass the static detection rule implemented by the EDR. The following steps outline this bypass technique:

1. First obtain the Altitude value for the EDR.
   
   
   
   
2. Rename the Sysmon altitude registry entry to AltitudeOld. Then, create a new registry entry named Altitude, specifying the type as REG_MULTI_SZ. Set the data of this new entry to match the EDR's altitude value. Observe that the modification is accepted without terminating the process. If you can't find Sysmon on the host, you can simply install it or possibly find other minifilter to use. Note: REG_SZ is a null-terminated string and REG_MULTI_SZ is a sequence of null-terminated strings.
   
   
   
   
3. Reboot the host.
   
4. Run fltMC.exe to verify the Sysmon driver is now using EDR's altitude value. Notice the instance number is now showing "0" which means the Sysmon driver is not registered to any kernel callbacks. This is probably caused by using REG_MULTI_SZ but it is not important thing here.
   
   

Results

This is the outcome of the bypass. The EDR service is running normally as shown below:

Furthermore, the EDR management console still indicates that the endpoint is online, with no accompanying alerts. Additionally, the traditional Windows Defender control panel has reappeared, allowing for the disabling of real-time protection with local administrator privileges.

As the proof of concept, Mimikatz was copied to the host and performed credential dump:

Microsoft Defender for Endpoint (MDE)

We also applied the same methodology to MDE. First, we acquired the altitude value from MDE using the 'fltMC.exe' command with administrative privileges:

After copying the altitude value and assigning it to the Sysmon driver, it was notable that no alerts have been detected, unlike in previous instances with the other EDR system.

The MDE's minifilter MsSecFlt was overwritten by SysmonDrv and MDE services are still running as expected.

However there was an issue, I navigated to Windows Security setting and found that the setting is still under MDE's control and it cannot be disabled:

Further investigation revealed that WdFilter is utilised by Microsoft Defender. I was determined to disable it as well, but the question arose: which driver can I use to overwrite the minifilter? After examining the minifilter load order (link), I opted for FileInfo for two main reasons. Firstly, it typically loads first due to its low value (40500), and secondly, even in the event of failure to start, the OS would still initiate, as indicated by this article. I modified the FileInfo's altitude value and rebooted the host again. The result was as shown below; both minifilter drivers have been overwritten:

From this point, I could disable Windows Defender Real-time protection and run Mimikatz to dump the credentials as shown in below screenshots. During this process, no alerts were observed.

Summary

This presents an interesting and straightforward approach to bypassing EDR solutions. Utilising the Sysmon driver for exploitation proved to be effective since it avoids detection and incorporates a minifilter driver. While existing minifilter drivers could also be used, it's important to exercise caution due to the potential risk of triggering a Blue Screen of Death (BSOD). For mitigation, you can write sigma rules for Sysmon Event ID 13 - Registry Value Set and Event ID 14 - Registry Key and Value Rename. I am not sure if MDE has telemetry for this as Olaf Hartong pointed out in this article that MDE has filter applied for registry value changes so not complete. We have tested against two EDR solutions and it'd be interesting to see how it behaves against others.