Aug 07 2019 07:26 AM
After installing Azure ATP Sensor on a domain controller for testing, I see a number of failed connection attempt to external IPs (specifically our public DNS IPs) on ports 3389, 135, 137 from that domain controller.
Ticket# 119080724001601
Aug 07 2019 09:36 AM
This is expected communication and is part of the NNR process AATP uses to resolve the IP address in the network traffic to a computer name.
https://docs.microsoft.com/en-us/azure-advanced-threat-protection/atp-prerequisites#ports
https://docs.microsoft.com/en-us/azure-advanced-threat-protection/atp-nnr-policy
Best
Gershon
Aug 07 2019 09:45 AM
@Gerson Levitz this makes sense for private IPs, i don't see why it would try to connect public IPs. that also generates a lot of noise on our firewalls / SIEM. it would be ideal to be able to select the IP ranges that i would want the agent to interrogate for this additional info.
Aug 07 2019 09:51 AM
Aug 07 2019 09:56 AM
@Gerson Levitz no. But after the agent installation i see these connection attempts to our public dns provider (configured on our domain controller dns for dns forwarding).
Aug 07 2019 10:11 PM
Is it possible that the public DNS server is communicating to the domain controller for some reason?
As described in the articles I previously linked to, the Sensor will attempt to communicate on these ports after it sees traffic from an IP address in the traffic of the domain controller.
Aug 12 2019 08:47 AM
support provided this doc:
https://docs.microsoft.com/en-us/azure-advanced-threat-protection/atp-nnr-policy
but i still think this is a noisy behavior.
Is it possible that the public DNS server is communicating to the domain controller for some reason?
-- the public DNS server is replying for the forwarded public DNS lookup.
being that the agent is sized based on packets/sec, i would assume any noisy traffic wouldn't help.
Aug 19 2019 10:58 AM
Is NNR done on the packet source? Or some value within the kerberos or NTLM or other auth mechanism? Or is there a combination?
We had an issue where AATP resolved a system at a users home to an errant static IP that was set within the environment. Here is what we saw:
Worth noting that Computer1 was OSX and I'm still not fully sure on the application(s) running that integrate with AD or if it had been "joined" to active directory. Also, 2.2.2.2 did not resolve, though I did not check to see if there was a lookup for it.
Just trying to see if implementation of authentication mechanisms can affect name resolution or if it's all coming from lower level networking information.
Aug 19 2019 03:25 PM
@archedmeerkat , For this reason (among others) DNS based resolution is only a fallback, and even than it's considered in the system as "low certainty".
We probably tried using netbios , NtlmRPC & TLS, and failed for all 3, then falled back to DNS as last resort.
The detections are considering this, so in some cases, since this is low certainty, it might affect the result of we decide to alert or not.
Aug 21 2019 07:33 AM
@Eli Ofek- So network name resolution is done on information in the packet, rather than what the source was on the network? Or is it a combination of both?
Knowing that the IP or name might be from the packet can at least assist in investigations so you don't go down the wrong rabbit hole.
Aug 21 2019 08:09 AM
@archedmeerkat No sure what you mean by "source on the network".
We inspect the packets and look on the source IP of the packet.
If the name appears in the packet as well we sometime use it too (we call it a "hint") and also rely on it to a degree as it can't always be trusted.
Anyway, knowing the IP alone we can't tell for sure if it's public or private or vpn etc... so we check anyway.
Aug 21 2019 08:45 AM
@Eli Ofek- Thanks, this answers my questions (specifically the "hint").
Sorry I wasn't clear by "source on the network", was just trying to specify between the source ip and any ip/name that would be inside the packet.
Mar 15 2023 06:12 AM
Mar 15 2023 02:33 PM
@AzureGuineaPig As long as the FW will refuse connection immediately and not act as a sink hole it should be fine.