In today’s cybersecurity landscape, the complexity of the solutions implemented to protect against growing threats is constantly increasing. Because of this, both malicious actors, who seek to compromise organizations and systems for their own benefit, and Red Team operators, whose mission is to identify and report vulnerabilities for later remediation, are driven to identify and exploit new weaknesses in systems, adapting their methods and developing new TTPs that allow them to evade existing defenses.
The tools developed by both operators and hostile attackers are designed for evasion of security solutions such as EDRs. This is because keeping the operation off the Blue Team’s radar is of vital importance. Being detected would result in the defense team obtaining IOCs, which they would use to dismantle an entire operation, blocking IP addresses and domains, creating YARAs for artifacts or implementing the latest updates to all their security solutions.
These actions, in addition to increasing the Blue Team’s alert level, would mean the end or restart of an attack or operation, as the entry vector could be mitigated or directly blocked and the infrastructure would need to be almost completely reassembled. This is why maintaining the OPSEC of an operation is of vital importance, avoiding the generation of alerts that could notify the defenders and thus meet the objective without being detected.
In this article we intend to discuss a technique with a different objective from the rest, since the approach it proposes is not something commonly seen. Unlike the rest of the tools or techniques which have a specific objective to fulfill, such as executing a malicious shellcode, creating persistence in an asset or lateral movement in a network, this tool could be categorized as a support, that is, a tool whose purpose is to make sure to keep the operation off the radar by silencing the alerts that a security solution could generate after detecting suspicious activity. This is why the tool is categorized as a support tool, since its main objective is to block the “noise” that other tools or techniques may generate.
Specifically, we are talking about EDRSilencer, a tool developed in C that, taking advantage of the Windows Filtering Platform or WFP, which will be presented below, blocks the outgoing communication from an EDR agent to the central, thus preventing the collection of telemetry from the asset that is trying to be compromised or that has already been compromised.
The purpose of the EDRSilencer, as its name suggests, is to silence the alerts generated by an EDR agent when it detects malicious activity, thus preventing the notification from reaching the central station and alerting the Blue Team. This makes this tool the perfect complement when performing actions such as credential dumping.
A practical example of its application is the combination with the use of Mimikatz or procdump, tools commonly used for credential extraction that have nowadays lost their effectiveness due to the improvements implemented in security solutions. The installed AVs and EDRs have a greater detection and mitigation capacity in the face of malicious actions.
In addition, during the Local Security Authority Subsystem Service process dump, better known as lsass, the assets are not only protected by AVs and EDRs, but also by the implementation of measures such as Protected Process Light or PPLs that can also block the dump, so evading these solutions would not be the only problem to solve.
Because of this, this dump process often requires the installation of a vulnerable driver in order to bypass these security measures. This type of activity is often detected as suspicious by EDR agents who send telemetry to the central station, alerting defenders and increasing the risk of the operation being discovered.
Using this tool as an add-on, an attacker has the ability to block outbound communication from the EDR agent installed on the asset being targeted while, at the same time, executing actions such as PPL evasion using tools such as PPLKiller, which require the installation of a vulnerable driver.
As mentioned above, the tool silences the EDR agent by applying Windows Filtering Platform (WFP) filters which is a set of API services that enable the management and monitoring of network traffic giving the ability to intercept, filter and inspect packets.
This platform is used by multiple security solutions such as:
- Firewall: Uses WFP mainly in the application of filters that determine which network traffic is allowed and which is blocked.
- AVs and EDRs: Use WFP to scan network traffic for malicious patterns.
- VPNs: WFP is responsible for encrypting and decrypting IPSec packets.
The main components of this platform are as follows:
- Applications: These are user-run applications that can send and receive network traffic.
- Callout: Extensions that allow developers to create more complex operations for packet processing than Filter Engine can implement by itself.
- Filter: A rule that defines the criteria for packet processing.
- Filter Engine: It is the core of the WFP, which is in charge of evaluating the packets it receives based on the implemented filters.
- Network Stack: The set of software that manages and processes incoming and outgoing network traffic.
- Network Hardware: The physical components through which network traffic flows.
Having made this brief introduction to WFP, we can understand how it is integrated into the different security solutions. But, to clarify any possible doubts, in the case of parental control applications, the flow would be as follows:
Once the application is installed, it will register and implement a series of filters in the Filter Engine. These filters will process the network traffic flowing through the physical devices of the Network Hardware and limit the communication with the user applications. This communication between the applications and the physical devices requires the software that composes the Network Stack in order to be carried out.
On this occasion, EDRSilencer performs an action similar to the operation that a firewall could have, which, in this case, tries to block the outgoing communications of a process. Unlike a firewall, EDRSilencer blocks a process that is executing an EDR agent, thus, by intercepting the communication, it prevents the alert from being transmitted to the head office, preventing the Blue Team from being notified in case of detection of malicious activity.
To achieve this, the tool implements a new filter in the WFP FilterEngine, which identifies the process to be silenced and restricts outgoing traffic from the latter.
The flow of the tool when executed is as follows:
- The tool verifies the integrity level of the running process to confirm that it has a High or SYSTEM level, since in order to add filters to the WFP Filter Engine it is necessary to have, at least, administrator privileges. This is achieved by obtaining the access token, using the GetTokenInformation function. This function collects as a parameter the integrity level of the process in the structure called TokenIntegrityLevel.
2. Once it has been verified that sufficient privileges are available to include the new filter, the next phase is to identify the processes to be muted. For this purpose, the tool has an array of process names generated by agents of different EDRs, including MicrosoftDefender, ElasticEDR, SentinelOne, FortiEDR, CortexEDR and others. It is worth mentioning that the tool facilitates process communication blocking by specifying the path to its executable.
3. In the case of the implementation made in C, in order to obtain the identifier of the process to which the filter is to be applied, it is necessary to activate the SeDebugPrivilege flag in the access token, thus allowing interaction with any process or thread regardless of the security descriptors. For this purpose, the tool makes use of the AdjustTokenPrivileges function and modifies the value of the SeDebugPrivilege flag in the structure passed as a parameter with the name tokenPrivileges.
4. Subsequently, the tool continues by obtaining the identifier necessary for the implementation of the WFP filter, which is called AppId. This identifier is generated from the path to the executable. Specifically, it is generated from the path to the EDR agent executable in NT format.
5. Obtaining the path, which is generally acquired through the CreateFileW function, is the most critical phase of the tool, since on multiple occasions this function is usually hooked. This is because access to the path of executables categorized as highly critical is usually limited or monitored by the EDR. This is why the tool implements a different approach to obtain the AppId.
6. Finally, using the methods and structures provided by the fwpmu.h API that implements WFP, start the Filter Engine and define (1) and add (2) the WFP filter using the FwpmFilterAdd0 function.
This flow of actions is repeated for each process related to each EDR agent detected in the asset, thus completely blocking any communication between an agent and the EDR central office.
In the following, we intend to show a PoC using the .NET Framework, specifically version 4.8. The purpose of the development is to provide a Red Team with a tool capable of silencing the “noise” that may be generated in an asset while it is being compromised during an exercise. In addition, the tool has been adapted for application in other types of environments, where execution through an execute-assembly is necessary or proves to be more reliable.
The development required the use of P/Invoke, a technology that facilitates interaction with Windows APIs and, in this particular case, allows access to specific structures and methods of the Windows Filtering Platform (WFP), which has given the tool advanced capabilities to manage filters used to block EDR agents.
It is important to emphasize that there is currently no official documentation for the P/Invokes related to the WFP and, furthermore, with the transition to the new web portal, much of the documentation on the APIs has been lost. Therefore, it has been necessary to obtain structures and methods from different public sources.
On the other hand, as far as the execution flow is concerned, the phases have not changed, that is to say, although multiple changes have been made in terms of the code, both for the adaptation to the .NET Framework and for the improvement of the operation itself, the stages previously shown in the diagram are still applied.
That is why the proposed strategy is as follows. First, the access token of the process is obtained and its integrity level is verified. In case it is High or System, the next step is the activation of the SeDebugPrivilege flag that allows the interaction with other processes. Thanks to this, it is possible to obtain the executable and its transformation to NT format to obtain the AppId. Finally, the necessary structures are initialized for the creation of the filter that is applied on this process.
For the verification of this strategy, different scenarios have been considered using the same Windows 10 Pro environment. In the first, a Microsoft Defender agent was used for testing. The objective was to block outgoing communications, thus preventing it from communicating with the outside world and preventing it from being updated. On the other hand, as a second scenario, a BitDefender agent was used for the same purpose.
The results obtained show how it has been possible to block outgoing communications of the MsMpEng.exe process, also known as Microsoft Antimalware Service Executable, which, as its name suggests, is the process responsible for running the AV installed in new versions of Windows.
Once the tool has been executed, the outgoing traffic of the Defender process has been blocked, preventing this agent from communicating with the control panel and disabling the option of applying new updates.
On the other hand, it should be noted that the network traffic of the rest of the processes is still enabled to avoid suspicion on the victim’s side.
In conclusion, EDRSilencer is a high-value tool for situations where avoiding detection of security solutions is a must. In addition, integration with other exploitation tools makes this tool an essential complement to any operation. This is due to its ability to block notifications generated by suspicious behavior, thus avoiding alerting the Blue Team. On the other hand, the adaptation of the tool to the .NET Framework will be published once the code is restructured.
