Forum Discussion
Azure ATP Sensor tries to connect to public IPs
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.
- EliOfek
Microsoft
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.
EliOfek- 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.
- EliOfek
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.
