EDR Silencers and Beyond: Exploring Methods to Block EDR Communication - Part 1

For red teams and adversary alike it’s important to stay hidden. As many companies nowadays have EDR agents deployed those agents are always in focus and tools like EDRSilencer or EDRSandblast use different techniques to prevent further communications of the EDR agent with the log ingestion endpoint.

A few weeks ago Mehmet Ergene and I were discussing other ways to prevent agent communications and ways to detect such tampering. The idea for a a two part blog post was born. While I cover only one “novel” way to block EDR Mehmet has released part 2 which covers other angels.

Previous work

Since this topic is not new there are already great resources out there which I would like to reference as they are still valid ways to attack the EDR agent.

Windows firewall

The most obvious one, blocking the communication of the EDR agent using the Windows firewall, is already widely covered. Søren Fritzbøger published a great blog post back in 2021 and Bhabesh Raj covered this with a detection.

Windows Filtering Platform

Using the Windows Filtering Platform (WFP) like EDRSilencer does, is greatly covered in the “Silencing the EDR Silencers” post by Jonathan Johnson. It not only covers the attack itself but also ideas for EDR vendors how to detect and mitigate the problem.

Both of those techniques use the network layer of the Windows platform to prevent communication of the sensor with the cloud service. But when you worked with Windows long enough you will know that there are a lot more ways to tamper with the network layer of the operating system. One of those I will explore next:

The Name Resolution Policy Table

Since Windows 7 the Windows OS supports a feature called Name Resolution Policy Table (NRPT).

The main goal of this feature is to configure DNS settings based on a DNS suffix or FQDN and overwrites the system default DNS settings. e.g. if you want that a certain subdomain is always sent to a specific DNS server that supports DNSSEC validation you can add this to the policy table.

But before I go into the details, one last shout-out to Nathan McNulty, one of the biggest advocates for this feature for good.

Hush, little agent

One important fact about NRPT is the fact that the DNS client in Windows will always check the table and only if does not find any match it will use the default DNS server.

Glady Microsoft offers a complete list of URLs and domain names that are required by Microsoft Defender for Endpoint. An attacker could use e.g. the PowerShell cmdlet Add-DnsClientNrptRule to add two new entries which will redirect all DNS queries for the FQDN and all subdomains to localhost instead of the regular DNS server. Like many popular Adblockers this will result in failed DNS queries and therefore the MDE agent cannot send new events anymore. You could also send the DNS request to a different IP address, as long as the response is not the correct one.

Add-DnsClientNrptRule -Namespace ".endpoint.security.microsoft.com" -NameServers 127.0.0.1 -Comment "Silenced by Name Resolution Policy Table"
Add-DnsClientNrptRule -Namespace "endpoint.security.microsoft.com" -NameServers 127.0.0.1 -Comment "Silenced by Name Resolution Policy Table"
Clear-DnsClientCache

Of course just one domain is not enough, but when you add all the domain names required by the EDR agent, the timeline of the device will be empty after the execution.

Detection opportunities

PowerShell command execution

Depending on how fast the configuration is in affect, the commands executed could be captured and easily detected using a custom detection.

DeviceEvents
| where ActionType == @"PowerShellCommand"
| where AdditionalFields has "Add-DnsClientNrptRule"

In my testing the changes are applied so fast that not even the PowerShell command will be registered anymore. But there are edge cases where you might still glimpse one of the executions and as always in security, one technique can be detected by many different detections and it’s better to have different detections in place.

Registry changes

Of course PowerShell is not the only way to add entries to this configuration, a single detection based on the command executed is not enough. In the background the command creates new registry values in the registry key HKLM\System\CurrentControlSet\Services\Dnscache\Parameters\DnsPolicyConfig\{UUID} .

DeviceRegistryEvents
| where RegistryKey startswith @"HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Services\Dnscache\Parameters\DnsPolicyConfig\"

The registry values are not captured by Defender for Endpoint, making it hard to filter any further. One additional indicator that the entries were added using PowerShell is the InitiatingProcessVersionInfoInternalFileName which is Wmiprvse.exe.

Important registry values that are added are:

Known benign positive changes to those registry keys include VPN software like Tailscale, which use this feature to redirect your DNS traffic without changing the DNS server on any particular interface.

Afterthoughts

As the described method prevents the EDR agent from sending any data, relying on the agent for detections is not enough. As an industry there are a few thing vendors or you as detection engineers and security architects can do to detect and mitigate this attack.

What EDR vendors could do?

There are several angles that EDR vendors could tackle this attack.

1. Monitor changes to the NRPT table for certain domain suffixes and FQDN, revert them back and create an alert. The downside of this approach would be legitimate changes to this table.
2. Don’t rely only on the system DNS for name resolution. After onboarding the agent could receive backup IP addresses for the most important FQDNs and fall back on those if the OS DNS client is returning an error or the IP address returned is not responding.

What you can do?

You could establish a vendor agnostic backup alert channel, that informs you about changes to important registry keys and events from the EDR agent that indicate tampering or loss of communication in general.

You can implement this by using tools like Sysmon, only monitor a minimal set of registry entries and forward those events to your Log Analytics workspace.

More techniques

As already teased at the beginning, Mehmet Ergene has published even more ways to tamper with the EDR communication in his blog post here. Head over there and give it a read.

Additional information

• EDRSilencer
• EDRSandblast
• Silencing Microsoft Defender for Endpoint using firewall rules
• Detect Addition of New Firewall Rules in Defender Firewall
• Silencing the EDR Silencers
• SANS ISC - Sysmon’s RegistryEvent (Value Set)
• EDR Silencers and Beyond: Exploring Methods to Block EDR Communication - Part 1