IP Address Device Algorithm and False Positive Detections?

For devices discovered using L2 discovery, what is the algorithm/process that ExtraHop uses to determine ‘on device’ IP addresses? Is there any way to force ExtraHop to rediscover an IP address for a device?

Our Reveal(x) device generated a DCSync detection for a domain controller from an internal IP address. The address turned out to be assigned (via DNS A record) to another domain controller in the same domain; for some reason ExtraHop did not see the IP address as being assigned to the domain controller and created the detection.

I’m hoping there’s a way to prevent this going forward.

The association of IP addresses to L2 devices is described in this document.

I’m not clear on the behavior you’re seeing. It sounds like ExtraHop has the incorrect IP address associated with one of your domain controllers? The DNS records are used for name association and not IP addresses.

For product defects, I would encourage you to open a support case. Otherwise, please try to provide additional information about what you’re seeing. Thanks!

I did review that article before posting here, but thanks for including the link; I believe my question is about this part of the article:

The ExtraHop system creates a device entry for every local MAC address discovered over the wire. IP addresses are mapped to the MAC address, but metrics are stored with the device MAC address even if the IP address changes.

How are IP addresses mapped to MAC addresses of devices? Is the process different depending on whether the device is using DHCP or has a statically assigned IP? I ask because the answer to your question:

is that ExtraHop did not associate the IP address with the domain controller to which it is statically assigned, at the date and time it generated the DCSync detection.

Given a DCSync detection with offender IP address A and domain controller victim foo, with bar as another domain controller in the same domain as foo. foo and bar are devices in ExtraHop.

ExtraHop should not have generated the DCSync detection because A is the static IP address assigned to bar, but ExtraHop…for whatever reason…did not have associated A with bar, and generated the detection.

I hope the above makes sense and clarifies my ask. I posted here first as I already have a number of open support cases and want to weed out user error/inexperience before opening a new one.

The mapping of IP addresses is described at the top of the article:

Device IPv4 and IPv6 addresses are learned from Address Resolution Protocol (ARP) messages, the Neighbor Discovery Protocol (NDP) responses, local broadcasts, or local subnet multicast traffic.

ExtraHop should correctly associate the IP address with the domain controller even if it’s statically assigned. What version of the firmware are you running? Are you using a packet broker that might be filtering out some of the traffic like ARPs and multicast?

We are running the latest version of the firmware and are using TAPs that do not filter out ARP and DHCP. I can double-check with our networking team, but they are aware that ExtraHop requires ARP/DHCP traffic in order for device discovery and functionality to work correctly and have configured the tapaggs accordingly.

It would be good to verify the ExtraHhop is seeing the DC device is sending out ARPs. You can look at “Frame Types Out” on that device’s network metrics, e.g.:

ARP frames in/out of the device with the un-associated IP address:

On that same page, can you check for multicast packets, under packet types? If that device is responding to ARPs for the IP in question and/or it is sending out some local multicast packets with the IP as the source, the IP absolutely should be associated with the device.

I am assuming when you look at records for the device the IP shows up?

No visible multicast packets, just unicast packets.

If I search for records by IP address, the device shows up and if I search for records by device name the IP shows up.

It sure sounds like the IP should be associated with the domain controller device… At this point, a support case is probably warranted so we can get more details.

Thanks! I’ll open a support case as soon as possible