EDR Telemetry Blocking via Person-in-the-Middle Attacks

23 July 2024
Eito Tamura

tl;dr

You can block EDR telemetry reaching its cloud servers by performing a Person-in-the-Middle (PitM) attack and filtering telemetry packets, effectively hiding alerts from the SOC team. This can be achieved by conducting ARP poisoning against target host(s) and configuring iptables. Instead of blocking a wide range of IP subnets, we can use Server Name Indication (SNI) in the TLS Client Hello packets to identify specific IP addresses to block. While unsent alerts get cached on the host, they are cleared upon reboot.

Introduction

ARP spoofing is a well-known attack that has been used by attackers for many years. It is commonly employed in PitM attacks to steal credentials through cleartext protocols. Some of the popular tools including bettercap, PCredz with arpspoof.
In this blog, we will explain how PitM attack via ARP spoofing can be applied to block EDR telemetry traffic to its remote APIs in order to silence alerts. The advantage of this approach over network filtering attacks on the host, such as manipulating firewall rules or the Windows Filtering Platform (WFP), is that it does not require administrative privileges or access to the victim host. However, it does necessitate an attacker-controlled machine on the same network as the victim host.

ARP Spoofing

The concept of ARP spoofing is widely discussed, so we will not go into too much detail. ARP spoofing (or poisoning) operates at OSI layer 2, where MAC addresses are used for routing. The diagram below illustrates the lab setup:

When the victim host needs to connect outside the network it needs to route through the gateway at 192.168.10.1. The host will try to find out the MAC address of the gateway by sending ARP request broadcast packet. The attacker machine continuously sends ARP replies claiming that the gateway 192.168.10.1 is at MAC address 00:0c:29:39:33:63, which belongs to the attacker host. This action poisons the ARP table on the victim host, causing it to believe that the attacker machine is the gateway. Note that this is not a full duplex setup, meaning only the ARP table on the victim host is poisoned, not the gateway's ARP table. This makes the attack harder to detect. Only the outbound traffic from the victim host is affected.

How to PitM Attack with ARP Spoofing

In this example, the command was:
sudo arpspoof -i ens34 -t 192.168.10.52 192.168.10.1

The following screenshot shows the output of arpspoof tool:

The screenshot below shows the ARP table of the victim host. The MAC address of the gateway 192.168.10.1 has been updated (poisoned) from original e0:e1:a9:eb:26:41 to 00:0C:2939:33:63.

You can confirm the traffic flow by browsing a website on the victim host and observing the outbound traffic on the attacker machine (which is performing PitM) with tcpdump:
tcpdump -i <interface> host <victim ip>

On the victim host, browse a website to generate traffic:

Observe the outbound traffic from the victim host on the attacker machine:

Blocking EDR Telemetry

During a PitM attack, traffic can be dropped using iptables by configuring rules in the FORWARD table, which controls packets that are being routed through the host. We can write DROP rules based on destination IP addresses or subnets. However, a significant challenge exists.
Write-ups on EDR telemetry filtering on victim host, such as those from EDRPrison, highlight the difficulty of covering IP addresses, stating that "some EDR products communicate with hundreds or even thousands of contact servers, making it difficult to include every contact server while remaining stealthy". To address this, their solution involves hardcoding process names and blocking any outbound traffic generated by those processes. Unfortunately, this technique cannot be applied to the PitM scenario because the attacker machine would not know which process generated the traffic.

TLS Handshake

One thing we know is that the majority of EDR vendors use TLS encryption over port 443 to communicate with their remote APIs. While TLS is designed to secure communication, some aspects of the initial key exchange traffic are readable. For example, the "Client Hello" message, which is part of the initial handshake process, contains human-readable information such as the Server Name Indication (SNI), as shown below:

The initial idea was to block the "Client Hello" packet using iptables, preventing the TLS key exchange from completing. To apply iptables rules, you could use a string match against the server name and block Client Hello packets.

However, an issue arose. Although the initial approach seemed effective, we noticed some packets were missed over time which resulted EDR console receiving telemetry and raising alerts. This is most likely due to the way parsing was handled and the high volume of traffic. String matching with iptables is less efficient compared to dropping packets based on IP addresses or ports.

Tool: EDR Telemetry Blocker - edr_blocker.py

The tool can be downloaded from here. The proof-of-concept video of the tool running against a host with Microsoft Defender for Endpoint:

As the built-in iptables with string match solution being not so effective, we decided to come up with our own PoC tool using Python Scapy. The tool includes the following functionalities.

EDR Telemetry Blocking Technique

The Python Scapy library supports parsing TLS handshakes, including SNI, and it appears to offer better performance than iptables string matching, even though Scapy operates in user mode rather than kernel mode. The library cannot drop packets, so the idea is to parse the SNI in the Client Hello packets and check it against a wordlist. If a match is found, iptables is updated with a more efficient rule to drop packets based on their destination IP address. We tested Scapy running in asynchronous sniffing mode and observed no packet loss, even during 4K video streaming. When the tool is terminated, it flushes the iptables rules that were created.

Built-in ARP Spoofing

Scapy has the ability to generate custom packets, including ARP Reply. Therefore, we could embed ARP spoofing functionality within the same code. The tool takes the target host IP address(es) and the gateway IP address, and send spoofed ARP replies to the target(s) to impersonate the gateway and perform a PitM attack. When the tool is terminated, it sends correct ARP replies to the target to restore the poisoned ARP table.

Other Functionalities

Some other functionalities are present, such as:

• Ensure packet forwarding is enabled on the attacker machine, i.e. checks with sysctl -n net.ipv4.ip_forward
• Monitor mode - it does not create an iptables rule when the SNI contains a blocked entry
• Verbose mode - outputs all server name in Client Hello packets
• Input file - it takes a file path of a file containing a wordlist to match against the server name of the SNI for a TLS handshake

Blocking Microsoft Defender for Endpoint Telemetry

Microsoft Defender for Endpoint or Windows initiates TLS handshakes regularly when communicating with the remote API. Based on our observations, we have created the following word list to be used to block server names:

• events.data.microsoft.com
• wd.microsoft.com
• wdcpalt.microsoft.com
• wdcp.microsoft.com
• blob.core.windows.net
• winatp-gw-cus
• automatedirstrprdcus
• endpoint.security.microsoft.com
• smartscreen.microsoft.com

Blocking these TLS should not impact other Microsoft services, such as Teams, Outlook, or O365. But you should always test it before you use the tool. Any events or alerts that occur while the cloud servers are unreachable will be cached locally. However, the local cache is cleared upon reboot, resulting in a loss of visibility.

Blocking CrowdStrike Telemetry

While on a client engagement, with permission from them, we have tested the tool against CrowdStrike.
CrowdStrike does not perform TLS handshakes as frequently as MDE. There are three methods to capture the TLS handshake:

Option 1: Simply run the tool in verbose mode and wait for a while, typically 30 min ~ 1 hour.
Option 2: Restart the machine while the tool is running. ARP poisoning will occur before the CrowdStrike's initial TLS handshake occurs, and the tool will be able to capture it and start blocking.
Option 3: Since CrowdStrike's API hosts are known to be hosted on AWS, you can use tcpdump on the attacker machine to identify the IP address associated with AWS, which should look like below:

The following screenshot shows the SNI that was observed for CrowdStrike:

We observed two server names which both ended with cloudsink.net. Therefore, only the following top parent domain was used for CrowdStrike:

• cloudsink.net

If you are using the tool, do not perform any action that might result in alerts being triggered until at least one IP address is blocked.

Mitigation

This technique relies on a PitM attack using ARP Spoofing. Even if your network has ARP poisoning-aware devices, detecting the attack can be difficult if only the host is targeted. Utilising VPNs or other private network technologies can help mitigate PitM attacks and prevent attackers from blocking EDR telemetry.

One technique an attacker might use to gain access to the internal network is by deploying a physical implant. Configuring your network devices to enable 802.1X authentication can help mitigate this risk.