DNS Resolution Against an Unexpected Nameserver

How the attack works

An agent or a spawned process opens a network connection to port 53, the standard DNS port, on a specific host. The rule checks that host against a list of approved resolvers. If the destination isn't approved, it's flagged as suspicious, because attackers use rogue or attacker-controlled DNS servers to tunnel stolen data out disguised as DNS queries. This detection looks only at the destination of the connection, not at the contents of the DNS traffic or the command that triggered it.

Netzilo detection

Why it matters

This single connection could be the transport channel for data exfiltration — sensitive files, credentials, or other data leaving the network encoded inside DNS traffic. On its own, this only confirms unusual DNS routing, not that exfiltration actually happened.

What you can do

• →Build and maintain an accurate list of the resolvers your network legitimately uses, including corporate VPN and container-runtime resolvers, before treating this as high-confidence.
• →When this fires, check what data (if any) was queried or transferred around the same time, not just the connection itself.
• →Review DHCP-assigned resolvers and split-horizon DNS setups so they don't create constant false alarms.
• →Do not auto-block on this signal until your approved-resolver list is verified — blocking prematurely can break name resolution for the whole endpoint.

Known benign look-alikes

• An endpoint whose DHCP-assigned resolver is a public IP not in PUBLIC_RESOLVERS
• VPN or split-horizon DNS pointing at a corporate resolver on a public address
• Container runtimes with a resolver outside the RFC1918 and link-local ranges
• Applications bundling their own stub resolver aimed at a specific upstream

References

• https://attack.mitre.org/techniques/T1071/004/
• https://attack.mitre.org/techniques/T1048/

Related threats