Endpoint Detection and Response systems (EDRs) are an essential part of modern cybersecurity strategies. EDR solutions gather and analyze data from endpoints to identify suspicious activities and provide real-time threat visibility. This allows security teams to respond quickly to incidents, investigate threats thoroughly, and mitigate the impact of potential breaches.
When attackers manage to disable or block EDR systems using tools like EDRSilencer or NimBlackout, it poses serious challenges to defenders. One major consequence is the loss of visibility into endpoint activities, which compromises the ability of cybersecurity teams to detect and respond to threats effectively. This diminished visibility can result in delayed detection of breaches, giving attackers more time to exfiltrate data or cause damage. Moreover, without the continuous monitoring and real-time alerts that EDRs provide, defenders are left with a reactive approach, often discovering incidents only after significant harm has been done. The ability of EDRs to facilitate immediate responses, such as isolating affected systems and stopping malicious processes, is also neutralized when these tools are blocked, leaving organizations more vulnerable to ongoing attacks. In such scenarios, the risk of prolonged, undetected breaches increases, complicating the efforts of defenders and escalating the potential damage to the organization's security posture.
This blog isn't going to cover every EDR based tool in an attackers arsenal, but there are some common ones that have been observed recently. Attackers and Defenders are in a constant game of cat and mouse when it comes to tools and techniques. Fortunately, with these techniques there are some common indicators that can still be detected irregardless of the tool used.
Here are the tools we will be taking a look at. Many of these have been observed in use in the wild.
EDRSilencer -- Inspired by the closed source FireBlock tool FireBlock from MdSec NightHawk, this tool was created with the aim of blocking the outbound traffic of running EDR processes using Windows Filtering Platform (WFP) APIs.
EDRSandBlast -- Written in C. It weaponizes a vulnerable signed driver to bypass EDR detections (Notify Routine callbacks, Object Callbacks and ETW TI provider) and LSASS protections. Multiple userland unhooking techniques are also implemented to evade userland monitoring.
NimBlackout -- An adaptation of the @Blackout project which consists of removing AV/EDRs using the gmer (BYOVD) driver.
AuKill -- The AuKill tool abuses an outdated version of the driver used by version 16.32 of the Microsoft utility, Process Explorer, to disable EDR processes before deploying either a backdoor or ransomware on the target system.
The main features of this tool is searching for running EDR processes and applying Windows Filtering Platform (WFP) filters to block outbound traffic, adding filters for specific processes, and removing filters either individually or globally. The tool includes a custom implementation to avoid file handle access issues with EDR processes by bypassing the CreateFileW API. It supports a wide range of EDRs, including Microsoft Defender, Carbon Black, SentinelOne, and more.
By creating custom WFP filters, attackers can selectively intercept and drop network packets sent by EDR processes, effectively preventing them from communicating with their management servers or security dashboards. This disruption stops the EDR from sending telemetry data, alerts, or incident logs, thereby silencing its ability to notify defenders of suspicious or malicious activities occurring on the endpoints. Such interference can be stealthy, as it can be crafted to target only specific processes or traffic patterns associated with the EDR, ensuring other legitimate network operations remain unaffected. By exploiting WFP in this manner, attackers can maintain prolonged access to a compromised system without detection, allowing them to escalate their attacks, exfiltrate data, or cause further damage without triggering the EDR's defensive mechanisms.
Fortunately, there are a few pieces of telemetry that sneak through before the EDR is silenced. One such piece is Windows Event 5447 which identifies when a WFP filter has been changed. In the case of EDRSilencer there is a very specific filter that is added.
EDRSilencer by default will create its filters with the FilterName of "Custom Outbound Filter". You can also see the process being filtered in the Condition Value, in this case msmpeng.exe (Defender).
Another detection opportunity is the command line arguments and process information from when the tool is launched. It is pretty unusual for a benign process to have a argument called blockedr.
For more logs, details, and detections, we have captured this activity in our platform here.
This tool can also use WFP to block communication of EDRs. It will enumerate EDRs and create filters for every service and process of the EDR.
This will create very similar logs as EDRSilencer in Windows Event 5447 but on a larger scale since it will do it for every subprocess of the EDR. However, since it is enumerating the EDR services it will access the EDR process in a way that is logged. In Sysmon this will be EventCode 10.
In addition to the methods of detection mentioned, you can also identify these WFP Filters through the registry. They will create an entry under HKLM\System\CurrentControlSet\Services\SharedAccess\Parameters\FirewallPolicy\FirewallRules\{GUID} as seen here.
For more logs, details, and detections, we have captured this activity in our platform here.
EDRSandBlast also has a technique to perform LSASS dumping without triggering Credential Dumping activity alerts. EDRSandBlast enumerates the Kernel "Notify Routines" callbacks and remove any callback routine linked to a predefined list of EDR drivers (more than 1000 drivers of security products supported, see the EDR driver detection section. The enumeration and removal are made possible through the exploitation of an arbitrary Kernel memory read / write primitive provided by the exploitation of a vulnerable driver (see Vulnerable drivers section).
Here we can see the tool creating the malicious service and loading the vulnerable driver.
Afterwards it uses this driver to remove those callback routines and make the process safe. Then lsass.exe is access and dumped to the current directory. Once done the service and driver are removed.
These activities will still create some logs despite the efforts of the tool to hide activity. The first we can look at is the service creation for the kernel driver (Windows Event 7045)
Here we can see the driver being loaded from an unusual location (C:\Users\localuser\gdrv.sys) as a kernel mode driver with a start type of auto start. The combination of auto start with kernel mode should be investigated but adding in a known vulnerable driver really makes this stand out. This technique is commonly referred to as a "bring your own vulnerable driver" (BYOVD) attack. The LOLDrivers project contains a massive list of information about these known drivers including names and hashes.
For more logs, details, and detections, we have captured this activity in our platform here.
These tools leverage a different driver, gmer, to effectively disable or kill EDRs and Antiviruses. It uses a very similar approach to EDRSandBlast by loading a kernel mode driver and then exploiting the vulnerable driver to accomplish something it normally wouldn't have permission to. In the particular case of this tool, it will repeatedly terminate the specified process over and over. Likely targets for this are EDR and AntiVirus products.
If you have telemetry for registry activity you can actually see the service creation keys as well with EventCode 13. These tools will both use the Blackout.sys driver as the ImagePath.
If you have telemetry for Windows Events you can monitor for termination of your EDR Processes. This is Event Id 4689, and here we can see the Defender process from our execution being killed.
For more logs, details, and detections, we have captured this activity in our platform here.
While all the tools covered so far have been open source tools, or educational experiments, these techniques are being actively used by threat actors. One such example is a tool dubbed AuKill by Sophos discussed here. However, this tool uses many of the techniques covered in this blog and includes many of the same detection opportunities.
The AuKill tool abuses an outdated version of the driver used by version 16.32 of the Microsoft utility, Process Explorer, to disable EDR processes before deploying either a backdoor or ransomware on the target system.
The method of abusing the Process Explorer driver to bypass EDR systems isn't new; it was implemented in many open-source tools. AuKill possibly uses multiple code snippets from, and built their malware around, the core technique introduced by Backstab. AuKill drops a driver named PROCEXP.SYS (from the release version 16.32 of process Explorer) into the C:\Windows\System32\drivers path. The legitimate Process Explorer driver is named PROCEXP152.sys, and normally is found in the same location. Both drivers can be present on a machine that has a copy of Process Explorer running. The AuKill installer also drops an executable copy of itself to either the System32 or the TEMP directory, which it runs as a service as seen below.
Another interesting thing that this tool does that we hadn't seen in many of the open source tools was disabling the Windows Update Service. This can be seen in a registry key change.
This value change disables the automatic starting of the update service. This can prevent future security updates that might mess with an attacker's access.
For more logs, details, and detections, we have captured this activity in our platform here.
T1562.001: Impair Defenses: Disable or Modify Tools
Adversaries may modify and/or disable security tools to avoid possible detection of their malware/tools and activities
T1562.004: Impair Defenses: Disable or Modify System Network Configurations
Adversaries may disable or modify system firewalls in order to bypass controls limiting network usage.
T1569: System Services
Adversaries may abuse system services or daemons to execute commands or programs.
T1112: Modify Registry
Adversaries may interact with the Windows Registry to hide configuration information within Registry keys, remove information as part of cleaning up, or as part of other techniques to aid in persistence and execution.
The tools and techniques used by attackers to bypass or disable EDRs underscore the continuous and evolving struggle between cybersecurity defenses and adversarial tactics. By exploiting legitimate system features, such as the Windows Filtering Platform, attackers can effectively neutralize critical EDR functions, creating blind spots. However, defenders are not without recourse. While these tools aim to obscure their activities, certain logs and registry modifications still offer valuable indicators of compromise. Monitoring for these signals -- like specific WFP filters, unusual process behaviors, or suspicious service creations -- can help defenders detect these evasive tactics. Having a strong detection workflow is paramount to catch these sorts of attacks, especially when they are attacking the EDRs themselves.
SnapAttack is the threat hunting, detection engineering, and detection validation platform for proactive threat-informed defense. Register for a FREE community account to access the tons of content included in this blog post, as well as thousands of other detections. Subscribers also get advanced features like a no-code detection builder, one-click deployments to leading SIEMs and EDRs like Chronicle, Sentinel, Splunk, CrowdStrike and SentinelOne, advanced threat profiles to prioritize relevant threats, and customized reports that track MITRE ATT&CK coverage and more!
Blinded by Silence was originally published in SnapAttack on Medium, where people are continuing the conversation by highlighting and responding to this story.