18 September 2024
Eito Tamura
Introduction
About six months ago, I wrote a blog on how Windows MiniFilter Altitude can be abused to blind EDR here. The blog attracted the attention of security professionals, and some vendors have since developed mitigations. We've decided to explore these mitigations and attempt to bypass them.
Background
While testing Sysmon in our detection lab, I discovered that a MiniFilter driver, such as the Sysmon driver, can be abused to prevent EDR drivers from loading. This effectively blinds the telemetry by blocking kernel callbacks. This exploits the load order of MiniFilters and the requirement that each MiniFilter's Altitude must be unique to its driver. By assigning the EDR driver's Altitude to another MiniFilter that loads before the target filter, it prevents the EDR driver from registering with the Filter Manager. The diagram below illustrates the Filter Manager architecture.
Microsoft Defender for Endpoint (MDE)
Some mitigations have been implemented by Microsoft. While attempting to modify the Altitude of the Sysmon driver to match the MDE driver's (WdFilter) Altitude in order to prevent it from loading, the regedit process was terminated, and an alert was raised as shown in the screenshots below.
One of the behaviours observed after an alert popped up on the desktop was that when I returned to the Sysmon driver registry, the Altitude entry had been removed, as shown in the screenshot below. This effectively disables Sysmon unless you restore the Altitude manually.
As I mentioned in the original blog, other MiniFilter drivers can also be used, including default ones already present on the system, such as FileInfo. I attempted the same attack to see if a similar defence mechanism would trigger. To our surprise, the change was not blocked, successfully assigning the same Altitude as MDE (328010) to Sysmon driver as shown below.
Upon reboot, the FileInfo driver was loaded using the Altitude (328010), preventing WdFilter from loading. With WdFilter unloaded, which manages real-time file system protection, an administrator can disable real-time protection and run malicious tool such as Mimikatz without getting blocked.
If you need to unload MsSecFlt driver (385600) which handles functionalities related to security policy enforcement or network traffic monitoring, you could use other MiniFilter driver which already exists on the system such as npsvctrig.
EDR vendor X
In the original blog, I explained that this major EDR vendor had detections for other drivers using their Altitude. However, I was able to bypass this by using different registry types, such as REG_MULTI_SZ. This vulnerability has since been mitigated, and it can no longer be bypassed. Additionally, the Altitude they use now includes a dot (".") followed by five digits, which is supported by MiniFilter — i.e. XXXXX.YYYYY. The YYYYY portion is dynamically assigned and changes every time it is loaded. This prevents attackers from assigning the same Altitude to other MiniFilter drivers.
Playing with MiniFilter Loading order
Some EDR vendors mitigated the issue by adjusting the load order of their MiniFilter drivers, ensuring that their drivers are loaded before the Sysmon driver. However, security researcher Patrik Jokela (Insta) was able to bypass this mitigation by not only modifying the Altitude but also altering several other registry values that play a key role in determining the driver load order. I decided to carry out my own investigation to explore this further.
Key factors influencing driver loading
Apart from Altitude, these are the key registry values that can affect the MiniFilter load order.
- Group - this determines which load order group the MiniFilter driver belongs to. MiniFilter drivers are typically assigned to specific groups like FSFilter (File System Filter) subgroups (e.g., FSFilter Activity Monitor, FSFilter Top, etc.). The load order within the group depends on the order specified in the GroupOrderList.
- Start - this defines when the driver or service is loaded. It can have values such as 0 (BOOT_START), 1 (SYSTEM_START) etc.
- Type - this defines the service type (e.g., kernel driver or user mode driver)
- Tag - this is a numeric value that provides finer control within a group to specify the exact load order of drivers.
Optimising the settings
Group : REG_SZ : FSFilter Infrastructure
This group is used for FltMgr (Filter Manager) which should be the one that gets loaded before any MiniFilter drivers. Many MiniFilter drivers list it as a dependency (DependOnService) to ensure it is loaded before them. Including your MiniFilter driver in this group ensures it loads at an early stage.
Start: REG_DWORD : 0 (BOOT_START)
This must be set to 0 (BOOT_START); otherwise, even if it's in the FSFilter Infrastructure group, it will likely be loaded after other MiniFilter drivers with a BOOT_START setting."
Type: REG_DWORD : 1 (SERVICE_KERNEL_DRIVER) or 2 (SERVICE_FILE_SYSTEM_DRIVER)
I found that this can be set to 1 (SERVICE_KERNEL_DRIVER) or 2 (SERVICE_FILE_SYSTEM_DRIVER), as both are for kernel-mode drivers. It shouldn't be set to 3 or 4, which are for user-mode drivers, since MiniFilters are kernel-mode drivers.
Tag: REG_DWORD : 2 or Not required
Tag applies within the specified group, in this case FSFilter Infrastructure. As FltMgr already has Tag : 1 assigned, FltMgr will get loaded first then the other drivers.
POC: Changing loading order of Sysmon driver
In this section, I will demonstrate how we can modify the Sysmon driver registry settings to ensure Sysmon loads earlier and effectively prevents WdFilter from loading.
First, I modified the Altitude of Sysmon to match WdFilter's and made no other changes to the driver registry values. Changed Sysmon driver Altitude to 328010 as shown below.
As shown in the screenshot below, WdFilter was loaded before Sysmon.
The Sysmon driver was already configured with Start set to 0 and Type set to 1. I created a registry key for the Group with REG_SZ value "FSFilter Infrastructure". The Tag was not created, as it is not required. The screenshots below show the updated Sysmon driver registry setting and how WdFilter was prevented to be loaded by it.
Summary
The vulnerability still affects some vendors, including MDE. Simply monitoring and blocking Sysmon abuse or altering the loading order of EDR MiniFilter drivers is insufficient. The mitigations implemented by the mentioned EDR vendor could offer a viable solution to this MiniFilter issue. SOC teams should continue monitoring for suspicious registry changes related to Altitude across all MiniFilters, not just Sysmon, and respond promptly.
Eito Tamura - Principal Consultant