Microsoft Secure Tech Accelerator
Apr 03 2024, 07:00 AM - 11:00 AM (PDT)
Microsoft Tech Community

Azure ATP Sensor tries to connect to public IPs

Brass Contributor

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

 

 

13 Replies

@gd-29 

 

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

@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. 

 

@gd-29 

 

Do you have a domain controller with the sensor installed that have public IP addresses? 

@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). 

@gd-29 

 

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. 

@Gerson Levitz 

 

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.

 

@Gerson Levitz 

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.

@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. 

@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.

@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.

@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.

 

If we block outbound traffic from the domain controllers to ports 135, 137, & 3389 to our public DNS resolvers, will this cause an issue or generate any alerts for the Azure ATP sensor. We're looking to harden firewall traffic and only permit 53 outbound from the DC to trusted DNS servers.

@AzureGuineaPig As long as the FW will refuse connection immediately and not act as a sink hole it should be fine.