senzee1984/edrprisonLeverage a legitimate WFP callout driver to prevent EDR agents from sending telemetry
Co-Author: @oops4git(https://github.com/oops4git)
EDRPrison leverages a legitimate WFP callout driver, WinDivert, to effectively silence EDR systems. Drawing inspiration from tools like Shutter, FireBlock, and EDRSilencer, this project focuses on network-based evasion techniques. Unlike its predecessors, EDRPrison installs and loads an external legitimate WFP callout driver instead of relying solely on the built-in WFP. Additionally, it blocks outbound traffic from EDR processes by dynamically adding runtime filters without directly interacting with the EDR processes or their executables.
In summary, EDRPrison has the following key features and capabilities
Please refer to the article for more technical details: https://winslow1984.com/books/malware/page/edrprison-borrow-a-legitimate-driver-to-mute-edr-agent
Elevated privileges are required to run EDRPrison successfully. EDRPrison comprises the following three components:
EDRPrison offers several enhancements and improvements over its predecessors, making it a more robust and stealthy tool for network-based EDR evasion:
Due to the resources available to me, I have tested EDRPrison against Elastic Endpoint and Microsoft Defender for Endpoint (MDE) on my physical server so far.
Relevant processes for Elastic Endpoint and MDE are hardcoded in the source code. During the tests, neither the main program nor WinDivert was detected by the security systems.
I tested a few common malware samples, such as Mimikatz. These samples can still be detected because, even without internet connectivity, EDR systems retain basic detection capabilities such as hash-based signatures. After executing the malware, the number of packets increased, indicating that they contained alert data.
While some detections occur locally, they do not appear on the EDR panel. Without internet connectivity, EDR systems are unable to leverage advanced capabilities like machine learning and cloud computing to prevent more sophisticated malware attacks.
Modify the following code snippet to hardcode more EDR processes.
static void initData()
{
processDictionary.TryAdd("MsMpEng.exe", 1);
processDictionary.TryAdd("MsSense.exe", 1);
processDictionary.TryAdd("SenseIR.exe", 1);
processDictionary.TryAdd("SenseNdr.exe", 1);
processDictionary.TryAdd("SenseCncProxy.exe", 1);
processDictionary.TryAdd("SenseSampleUploader.exe", 1);
processDictionary.TryAdd("elastic-endpoint.exe", 1);
processDictionary.TryAdd("elastic-agent.exe", 1);
}
The following approaches can be used to detect or mitigate the use of EDRPrison. However, depending on the environment, some of these detections could result in false positives (FP).
If the WinDivert driver is not already installed on the system, EDRPrison will install the callout driver upon first execution. Both the OS and telemetry data will log this event.
EDRPrison and other programs dependent on WinDivert require the presence of WinDivert64.sys and WinDivert.dll on the disk. Monitoring for these files can help in detecting such programs.
Tools like WinDivertTool can detect processes that are currently utilizing the Windows Filtering Platform (WFP).
Elastic has a detection rule that can identify packet drop or block actions against security software processes, which can indicate the presence of EDRPrison.
Tool WFPExplorer assists administrators in reviewing active WFP sessions, registered callouts, and filters.
A potential future feature could add additional protections for driver installation, further enhancing the security against unauthorized use of drivers like WinDivert.
From a red team perspective, several strategies can be employed to subvert the aforementioned detections, depending on the environment's security configurations.
If WinDivert is considered malicious in the environment, alternative signed, open-source drivers can be used. These alternatives should have fewer records of malicious use and still support packet interception, reinjection, and other manipulation techniques.
In environments where external drivers are unauthorized unless approved, it is challenging but feasible to reverse-engineer an installed or built-in WFP callout driver. By reusing its callout functions, red teamers can leverage existing drivers. Many security software solutions include their own WFP callout drivers that can be repurposed.
Instead of blocking or dropping intercepted packets, red teamers can redirect or proxy them. This method can avoid detection rules focused on packet drop or block actions, while still achieving the desired interference with EDR processes.
The following resources inspired and helped me a lot during my research. I extend my thanks to all the authors: