In a network environment in one of our customers, we are using a Network Intrusion Detection System (NIDS). After deploying Defender for Identity (formerly known as Azure ATP) on one of our Domain Controllers, the NIDS observed several failed RDP attempts to our machines in the network. In this article, I want to give you some information about why this behavior is expected.
After we have gotten the alert from the NIDS that one of our Domain Controllers is trying to establish a Remote Desktop Connection over port 3389 to several machines, in several subnets, I have started an investigation to found out what is going on. Because RDP attempts from a Domain Controller to several machines in the network, is something you might want to investigate.
I started the investigation in the Microsoft 365 Defender portal and looked at the alerts and incidents related to the Domain Controller. None of the alerts we had in the Microsoft 365 Defender portal was network-related or had no signal at all that the server might have been compromised.
After checking the event information on the Domain Controler, it seems that
Microsoft.Tri.Sensor.exe is responsible for this behavior. This Windows service is being used by Defender for Identity (formerly known as Azure ATP/ATA). After further analysis, I observe that this service is not only responsible for
3389/tcp connections to several machines, but also for a bunch of
Network Name Resolution (NNR)
Time to take a dive into the documentation of Defender for Identity and I found that this is normal behavior! Defender for Identity is using NNR to resolve IP addresses to computer names, Defender for Identity sensors look up the IP addresses using the following methods:
- NTLM over RPC (TCP Port 135);
- NetBIOS (UDP port 137);
- RDP (TCP port 3389) – only the first packet of Client hello;
- Queries the DNS server using reverse DNS lookup of the IP address (UDP 53).
So, nothing to worry about!
It’s not advised to block these connections from the Domain Controller, because it will reduce the change of successful name resolution. Yes, you have a higher chance that any NIDS tool will detect this behavior and create a false positive alert. You can change your NIDS rule to only alert if there were several RDP connection attempts to several machines, but that’s up to you to decide.
I used this KQL query for the investigation, maybe it can be of good use to you.
DeviceNetworkEvents | where RemotePort == 3389 | where ActionType == "ConnectionFailed" and Protocol == "Tcp" | where DeviceId == "9kh8dc97a804ef2210b4dd56d9175c847c303cff"
For now, thanks for reading, and stay safe!