Intro

On the 15^th of October 2024 Trendmicro has published an article titled “Red Team Tool EDRSilencer Disrupting Endpoint Security Solutions” (https://www.trendmicro.com/en_us/research/24/j/edrsilencer-disrupting-endpoint-security-solutions.html). It describes a tool used by red teams and adversaries to disrupt EDR solutions by cutting off their communication, using WFP (Windows Filtering Platform) – the same mechanism Windows Firewall service uses to manage and enforce traffic policy.

The approach of attacking EDR communications instead of shutting the sensor down with techniques such as Bring Your Own Vulnerable Driver is a simple but effective alternative. While it does not eliminate sensor’s on-host detective and preventive mechanisms, it practically stops the detection and response capabilities, as even though the sensor is still able to detect numerous malicious activities, neither alerts nor base events will reach the security monitoring staff. Once communications are cut off, adversaries no longer need to be cautious about their actions potentially being detected. From their perspective the worst-case scenario is the sensor blocking their payload, and in such case, they will simply keep modifying it or trying alternatives, until something works, without worrying about their actions triggering a response. At the same time, using built-in network management mechanisms such as WFP does not require arbitrary code execution in kernel mode, making this technique more accessible.

When I read the article, I was a little surprised by how many products could (and probably still can) be disrupted like this in 2024. And I immediately thought about an alternative although very similar attack – null routing.

Null routing

Null routing is a routing policy rule resulting in packets being routed to nowhere (dropped). It is also referred to as blackhole filtering. The concept applies to all routed networks.

For all the examples presented in this writeup I am using Windows, therefore all the OS-specific technical details pertain to this system. The whole problem, however, is universal to all operating systems and EDR solutions.

EDR disruption

So, after reading the article from Trendmicro and thinking about null routing, I did a search to see if there are any public tools or articles mentioning application of null routing against EDRs, and came across this short article: https://medium.com/@s12deff/blocking-edr-outgoing-connections-using-the-routing-table-f29e040c9567. Still, I started realizing that a large portion of the cybersecurity industry was at the time unaware of this threat despite the technique being publicly mentioned.

Proof of concept

On Windows, the simplest way to null route a particular IP address is to simply invoke the built in route.exe command, instructing it to add a route to 0.0.0.0. In all the examples below I will use one of Google’s public DNS IP addresses, because it is easy to remember and it is convenient to demonstrate the results by pinging it before and after route changes.

The syntax to null route a particular IP address using route.exe is as follows:

route -p add <IP ADDRESS> mask 255.255.255.255 0.0.0.0 if <INTERFACE INDEX>

The -p flag is optional; it only instructs the command to make the route persistent across reboots.

The interface index is the natural number assigned to the network interface (NIC) providing the default gateway. One way to check it is to compare and match outputs from ipconfig and route. In the example demonstrated below, the NIC serving as default gateway has index 5:

Let’s give it a try:

So, without using Windows Firewall, we successfully cut off all outbound traffic to 8.8.8.8.

Let’s have a look at the routing table and also confirm that we can still ping other hosts, such as 1.1.1.1:

The same can be done with IP addresses of an EDR infrastructure. I experimentally confirmed this by null routing all the IP addresses of a couple of top-tier EDR solutions. As a result, base events and alerts from those sensors were no longer arriving to operator consoles, despite sensors running and other network connectivity working just fine. Also, these malicious routing table changes were not alerted upon even after communications were restored. Which lead me to the conclusion that null routing was still a viable alternative to firewall based EDR disruption, and it must be assumed that threat actors are aware of it.

Note: this article was originally written in October 2024, while the final decision to publish was made in February 2025.

Null routing – technical caveats

Null routing versus firewalling, process names versus IP addresses

From now on, let’s carry on by looking at this subject from an attacker’s perspective. In the case of maliciously utilizing Windows Filtering Platform to silence security solutions, as shown in the article, a notable difference as if compared to null routing is the ability to selectively block all outbound traffic for specific user mode applications, just by knowing their names. In such case we do not need to know or care about the IP addresses of the EDR infrastructure; the process name is all we need.

Hermetic null routing policy

To perform effective null routing, however, the full list of relevant IP addresses must be known, so each one of them is individually blocked from leaving the NIC. Missing just one means that the sensor maintains its full capabilities, as we as attackers fail to silence it.

This creates a couple of challenges:

1.      Obtaining and maintaining the full up to date list of IP addresses is more challenging than knowing process names. Some vendors provide lists of their EDR infrastructure IP addresses to their customers, with the intention of having them whitelisted by customers in their own firewall rules. Ironically, the same information can be used by attackers to perform effective null routing. While not as easily available as process names which usually are publicly attainable knowledge, if customers can access that information, so can sophisticated and capable threat actors.

2.     It is fairly easy for EDR vendors to change EDR infrastructure IP addresses, at least way easier than changing the name of the user mode process or other properties that would allow identifying it. Keeping up with that list requires continuous customer-level access to product information.

These problems, at least to some extent, can be overcome by broader and more strict null routing policies and/or targeted information gathering.

Semi-selective blocking or blocking everything by default

First and foremost, we don’t really have to target specific IP addresses, one by one. We can as well block them by null routing entire IP address ranges they belong to. For instance, if we know that the EDR solution we want to silence uses infrastructure of one particular cloud service provider, we can just null route an entire set of CIDRs. Depending on the range and relevance of the cloud service provider, this would introduce some risk of disrupting non-EDR traffic organically occurring in our target, which is also not perfect from the OPSEC perspective, however it is definitely the risk we as attackers would choose as an alternative to the EDR sensor still being able to call home.

If we want to be super aggressive about it, we could even null route everything by default, and from that point only punch holes in our network traffic policy by adding allowed exceptions, one by one, starting with our C2 infrastructure, effectively implementing malicious network containment, similar to the functionality provided by many EDR sensors.

Targeted information gathering

Obviously, if we block our target from exchanging regular traffic, we disrupt its normal operations, which is usually against our objectives. Thus, it seems reasonable to create some sort of baseline of “safe” traffic that we would be willing to allow and extend that list of CIDRs with additional information gathered by monitoring and profiling network connections on the target to adjust the blocking policy before activating it.

Depending on the EDR solution, there might be a way to extract the list from binaries or other solution-specific resources.

Another option is dynamic information gathering from live processes, using API such as GetExtendedTcpTable(), and filtering out entries that belong to the EDR sensor process.

Detection

Now, switching back to defenders’ perspective. There are several layers on which such malicious changes could be detected:

·        use of specific commands such as route.exe,

·        use of specific APIs, such as IP Helper API functions such as CreateIpForwardEntry(),

·        relevant data structures in kernel memory.

Although it is very easy to monitor commands and it is fairly easy to hook and monitor user mode APIs, it would be equally easy to bypass such detections. I am not advocating against these measures, I am only emphasizing that in terms of proper detection, eventually what we are interested in is the actual system-wide routing table and the data structures that represent it in kernel memory.

Keep in mind that from an attacker perspective, we are only considering scenarios entirely based on user-mode. The alternative is BYOVD, which is well covered and beyond the scope of this write up.

Now, sticking to user-mode attacks only, we should also take into account a situation where malicious changes in the routing table are not conducted by malware directly, but instead are triggered by:

·        enabling Routing and Remote Access Service (RRAS) and activating support for specific routing protocols (such as OSPF) in it,

·        by using raw sockets, crafting OSPF Link State Advertisements (LSAs) that announce routes to null for a particular subnet or IP (like 8.8.8.8/32).

This scenario, although avoiding direct modification by malicious software (eventually it would be the RRAS process invoking those changes), can be detected if we monitor in the right place.

Racing and pushing against attacker

Detecting malicious route changes will not do much good if the relevant detection events do not leave the endpoint in result of effective null routing. However, even if null routing of the entire EDR infrastructure can be performed in an atomic manner, in the sense that all EDR communication is cut off with just one change in the routing table, the sensor could still simply try to revert it by removing such malicious routing table entries after detecting them whenever it encounters communication issues. Also, usually EDR infrastructures are redundant, using multiple IP addresses matched by different CIDRs, making it impossible to perform null routing in an atomic manner, at least by using standard API from user mode.

Potential for false positives

It is important to distinguish between legitimate changes of the system-wide routing table that happen whenever networking changes occur on the endpoint, either triggered by physical events or programmatically (e.g. DHCP). The basic rule for classifying a route change as malicious would be the null destination (0.0.0.0, sticking just to IPv4 for simplicity) and the target IP address or network range matching at least one of the EDR infrastructure addresses.

Although in theory it would be possible to introduce incorrect routes other than 0.0.0.0, such as insertions of routing to non-existent IP addresses or valid reachable IP addresses that do not act as gateways, my initial experiments with this approach showed that by default after encountering the first routing error Windows will choose an alternative route and get the packet delivered:

However, I assume this behavior could be changed with some further adjustments, only to achieve the same result while simultaneously avoiding to explicitly use the null route.

Another way to maliciously apply routing to block EDR communication that does not explicitly involve null routing on the endpoint is hijacking the default gateway with separate NIC.

Prevention

Timeouts, routing table checks and automated reverts

The simplest approach preventing this technique from being successful is simply trying to check and fix the routing table whenever the sensor encounters communication problems. It might not be the most elegant solution, but it is very simple to implement and eventually effective, because even if we only restore the communication for a short instance, or end up in intermittently disrupted communication, detections – including the one about malicious null routing – would still arrive home.

Bypassing the system-wide routing table

In addition to effective detection, architectural solutions potentially allowing to avoid this problem entirely can also be imagined. For example, an EDR solution might be using its own network stack implementation, bypassing the system-wide routing table entirely, and having its structures explicitly protected within its self-protection scope.

Default gateway hijacking with separate NIC

Instead of null routing directly on endpoint, it is also possible to implement malicious traffic control policy on an attacker-controlled hop, after quietly deploying legitimate VPN software such as OpenVPN, and making an attacker’s server the default gateway.

While prevention of this scenario might not be feasible, it could still be detected by alerting upon VPN software deployment followed by loss of event inflow/sensor heartbeat. Although most such detections would be false positives (legitimate deployments), the total number of such alerts should be low, making the total volume manageable and thus viable to build detection of malicious route manipulations.