Forum Discussion
Azure ATP Sensor tries to connect to public IPs
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.
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).
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.
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:
- Computer1 at user's home has nic with IP 1.1.1.1.
- User connects to VPN. Computer1 at user's home has VPN connection with IP 2.2.2.2.
- There exists a reverse lookup for 1.1.1.1 in the internal Active Directory DNS environment that points to Computer2, that still exists in Active Directory, though is not in use.
- User access a cifs resource through VPN tunnel on Computer1.
- Azure ATP resolves the source for the accessing of the cifs resource to Computer2 using a DNS lookup on 1.1.1.1.
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.
