Introduction

Defender for Identity is a very important sensor to detect threats in an Active Directory environment. Therefore, it is important to make sure the sensors are performing well, and no health issues are being reported. When a sensor is in an unhealthy state, detections can be missed, or False Positives can lead to alert fatigue on the SOC.

In this blogpost, I wanted to talk about one of the important features of Defender for Identity, which in practice has a lot of dependencies for it to work properly. We will go over these dependencies, how you can spot unhealthy scenarios, and how you can identify possible pain points.

What is Defender for Identity analyzing?

Defender for Identity analyzes multiple data sources in order to throw alerts:

• Network traffic
• Windows Events
• Event Tracing for Windows (ETW)

In this post, we will zoom in more on the network traffic that is being inspected. More specifically, I want to talk about the Network Name Resolution (NNR) feature that is being used. But what is NNR?

Network Name Resolution

As Microsoft describes, “Network Name Resolution (NNR) is a main component of Microsoft Defender for Identity functionality”. NNR is used to correlate raw activities (which contains IP addresses), and the relevant computer involved in each activity. Without this, Defender for Identity is not able to profile entities and generate accurate security alerts for suspicious behavior.

In other words, Defender for Identity uses NNR to resolve IP addresses to computer names. This is done by using four methods, of which the primary used methods are the following:

• NTLM over RPC (TCP port 135)
• NetBIOS (UDP port 137)
• RDP (TCP port 3389) - Only uses the first ‘Client hello’ packet

One of the above methods is sufficient for NNR to work. When none of the above methods returned the computer name related to the IP address, or there is a conflict between at least two above methods, one last fallback method is used:

• DNS query using reverse DNS lookup of the IP address (UDP port 53)

Once the computer name is retrieved, Defender for Identity checks Active Directory and uses TCP fingerprints if there is a correlated computer object with the same computer name. This helps detect unregistered and non-windows devices. When a correlation is found, the IP address gets associated with the computer object. In cases where no name is retrieved, an unresolved computer profile by IP is created with the IP and the relevant detected activity.

For which threats is NNR data crucial?

NNR data is crucial for detecting the following threats:

• Suspected identity theft (pass-the-ticket)
• Suspected DCSync attack (replication of directory services)
• Network-mapping reconnaissance (DNS)

If you work in a SOC or you are actively checking your Defender for Identity alerts, you probably have seen these alerts before. These alerts often contain more information about the source device that triggered them, but sometimes information is missing or Defender for Identity seems to be flagging normal behavior. Changes are that NNR is not performing well in these cases. When NNR is not working properly, you might be encountering the following False Positives:

• Suspected identity theft (pass-the-ticket) – the alert was triggered for the same computer.
• Suspected DCSync attack (replication of directory services) – the alert was triggered from a domain controller.
• Network-mapping reconnaissance (DNS) – the alert was triggered from a DNS Server.

In fact, you can actually see when NNR is not working properly via the alert you are investigating. Defender XDR tells you this by providing the certainty a hostname got properly resolved from an IP address:

If you regularly encounter low mapping certainties here, there is probably something wrong.

Okay, let’s say you get a lot of False Positives for the alerts mentioned above. How can we fix these issues? Let’s go over how we can identify where the problem resides.

Primary methods

Since the primary methods are used first, we need to focus on these as a start. For the primary methods of NNR to work, the Defender for Identity sensors needs to have a connection to at least one of the three protocols to all network devices as described in the prerequisites:

This means that your network needs to be configured in such a way that all Defender for Identity sensors can reach all subnets over ports 135/TCP, 137UDP, and 3389/TCP. When this is not the case, this will in most cases be due to corporate firewalls. If you do not want to enable all ports, you can choose to allow only one of the three ports, since one should be sufficient for NNR to work. By default, all services should be enabled by default in an average Windows deployment. Make sure you verify this with your endpoint management team and set up appropriate and well-scoped rules based on your findings together with the networking team.

To help you identify which sensors were not able to reach certain subnets over port 135, 137, or 3389, my colleague Jani Vleurinck (https://www.linkedin.com/in/jani-vleurinck/) and I created a KQL query that you can use to identify this:

 1let networks = DeviceNetworkInfo
 2    // Expand all IPs
 3    | mv-expand todynamic(IPAddresses)
 4    // Get the network address related to the IP
 5    | extend NetworkAddress = format_ipv4(tostring(IPAddresses.IPAddress), tolong(IPAddresses.SubnetPrefix))
 6    // Build the IP with the CIDR notation
 7    | extend IPAddress = strcat(tostring(IPAddresses.IPAddress), "/", tolong(IPAddresses.SubnetPrefix))
 8    // Save the Prefix as an extra property
 9    | extend Prefix = tostring(IPAddresses.SubnetPrefix)
10    // Make a set of all the IP's belonging to the same subnet
11    | summarize make_set(IPAddress) by NetworkAddress, Prefix
12    // Count how many IPs there are in one subnet
13    | extend CountIPs = array_length(set_IPAddress)
14    | extend Joiner = 1;
15// Network Information
16let network_info = DeviceNetworkInfo
17    | mv-expand todynamic(IPAddresses)
18    | extend IPAddress = tostring(IPAddresses.IPAddress);
19// Ports used in NNR
20let nnr_ports = dynamic(["3389", "135", "137"]);
21let mdi_servers = dynamic([]);
22// Query network connections
23DeviceNetworkEvents
24// Get events from Defender for Identity sensors - fill in mdi-servers variable for more complete results
25| where InitiatingProcessFileName == "Microsoft.Tri.Sensor.exe" or DeviceName has_any (mdi_servers)
26// Check traffic for NNR ports
27| where RemotePort in (nnr_ports)
28// Join the network info for more destination context
29| join kind=inner network_info on $left.RemoteIP == $right.IPAddress
30// Get distinct values
31| project-rename RemoteDeviceName = DeviceName1
32| distinct DeviceName, ActionType, RemoteIP, RemotePort, RemoteDeviceName
33// Join all network addresses
34| extend Joiner = 1
35| join kind=inner networks on Joiner
36// Check if remote ip is in a certain network address
37| extend NetworkAddrPrefix = strcat(NetworkAddress, "/", Prefix)
38| where ipv4_is_in_range(RemoteIP, NetworkAddrPrefix)
39// Create Object to reuse later
40| extend Obj = pack(
41    "DeviceName", DeviceName,
42    "NetworkAddrPrefix", NetworkAddrPrefix,
43    "RemotePort", RemotePort,
44    "RemoteIP", RemoteIP
45)
46// Count amount of failed and succeeded logins
47| summarize FailedConnections = countif(ActionType == "ConnectionFailed"), 
48    SucceededConnections = countif(ActionType == "ConnectionSuccess") by tostring(Obj)
49// Extract the columns from the object again
50| extend Obj = todynamic(Obj)
51// Save the properties for later use
52| extend DeviceName = tostring(Obj.DeviceName),
53    NetworkAddrPrefix = tostring(Obj.NetworkAddrPrefix),
54    RemotePort = tostring(Obj.RemotePort),
55    RemoteIP = tostring(Obj.RemoteIP)
56// Create a new object to save the amount of failed and succeeded attempts per IP
57| extend Obj = pack(
58    "RemoteIP", RemoteIP,
59    "SucceededConnections", SucceededConnections,
60    "FailedConnections", FailedConnections
61)
62// Create a list of the remote ips and their connections by MDI sensor, destination subnet and RemoteIP
63// Subnets with only fails on both ports will fail in NNR
64| summarize ConnectionDetails = make_set(Obj), 
65    TotalSucceededConnections = sum(SucceededConnections), 
66    TotalFailedConnections = sum(FailedConnections) by DeviceName, NetworkAddrPrefix, RemotePort
67// Filter out /32 addresses
68| where NetworkAddrPrefix !contains "/32"
69// Sorting
70| sort by TotalFailedConnections desc
71// Reorder
72| project-reorder DeviceName, NetworkAddrPrefix, RemotePort, TotalSucceededConnections, TotalFailedConnections, ConnectionDetails

This query shows you which Defender for Identity sensors (DeviceName column) can or cannot connect to certain subnet ranges found in your environment, over ports 135 and 3389. You will find the total amount of failed and succeeded connections to the entire subnet, but also the amount of failed and succeeded connections for each IP in that subnet.

With the above insights, you should have all the information you need to troubleshoot together with the networking team why certain connections to certain subnets fail.

Secondary method

In the secondary method, Defender for Identity searches the hostname of the device via PRT DNS lookups. For this to work, a couple of things need to be correct:

• Defender for Identity needs to be able to reach the DNS server on port 53
• Reverse lookup zones need to be enabled
• Clients need to be enabled to dynamically register their PRT record to the same DNS server Defender for Identity is using

However, since these are specific dependencies that vary a lot in each environment, it is hard to create an auditing rule for this. I would recommend to make sure at least one of the primary methods discussed earlier works for all subnet ranges instead.

Health alerts

If you want to quickly check if your Defender for Identity sensors has any health alerts, you can log in to security.microsoft.com and navigate to Settings > Identities > Sensors. Here you will find your sensors and all their related health issues.

You will also be able to find the NNR health issues if a low success rate is detected:

A full list of all the health issues can be found at:

Monitoring MDI health

So we talked about the importance of NNR and the health issues in Defender for Identity. Now you are probably wondering, can I get an alert when a health issue is thrown? Fabian Bader wrote a great blog post on how you can accomplish this by monitoring the alerting mailbox you can configure in Defender for Identity:

However, since the recent launch of the Beta Graph API, you can now get your Defender for Identity alerts by using API calls.

This opens a lot of possibilities to monitor MDI health alerts more easily since you can create API integration using various technologies. One simple example would be a Logic App that periodically checks for MDI health alerts via the Graph API, which creates a Sentinel incident when a health alert is found. Sadly enough, I did not find the time yet to create such a Logic App. But if you create one yourself, feel free to share it with the community ?.