AV-11 · DNS abuse, tunneling, and command-and-control

Attackers abuse DNS for reconnaissance, payload staging, command-and-control signaling, and covert data movement because DNS is widely allowed and often weakly monitored.

$ action: Centralize DNS logs, baseline query behavior, monitor resolver paths, and detect anomalous domains, query volume, and tunneling-like patterns.

1. Why DNS Is a Common Abuse Channel

DNS is essential infrastructure and often allowed across networks, which makes it an attractive channel for attackers. Defenders who do not monitor DNS closely lose one of the best sources of early evidence.

Attackers use DNS for normal-looking reconnaissance (domain resolution), callback signaling, domain generation, and in some cases tunneling or data staging. Even when payloads are encrypted elsewhere, DNS metadata can still reveal suspicious patterns.

This threat persists because many teams collect DNS logs inconsistently or lack baselines for normal query volume, query types, resolver paths, and common destinations.

2. What Attackers Can Do with DNS Abuse

Attackers can hide command-and-control beacons in frequent small queries, rotate domains quickly, use dynamic or algorithmic subdomains, and send encoded data fragments in query names. They can also abuse split-DNS confusion or rogue resolvers to bypass security controls.

Not every unusual DNS pattern is malicious. Software updates, cloud services, CDNs, and telemetry agents can produce noisy or high-volume DNS activity. Defenders need baselines and context to separate legitimate patterns from abuse.

DNS abuse often appears alongside other behaviors: suspicious outbound HTTPS, process anomalies, or unusual authentication. Correlation improves confidence and response quality.

3. How Defenders Mitigate DNS Abuse Risk

Centralize resolver logs and standardize which resolvers clients use. Rogue or direct-to-internet DNS paths reduce visibility and make policy enforcement harder.

Baseline normal DNS behavior by host role, subnet, and time. Monitor for rare domains, high-entropy labels, unusual query bursts, uncommon record types, and resolver path changes.

Use DNS filtering/policy controls where appropriate, but keep visibility first. Blocking helps only when you can measure what is being blocked and what is bypassing policy.

detection-signals

$High-volume or periodic queries to rare/unseen domains from a single host.
$Long/high-entropy subdomains or unusual label patterns suggesting encoded data.
$Unexpected DNS query types or resolver destinations by host role.
$Hosts bypassing approved resolvers or switching to unapproved DNS paths.
$Correlation between suspicious DNS and unusual outbound connections/processes.

telemetry-sources

$Enterprise DNS resolver logs and query telemetry.
$Zeek DNS logs and packet captures for deep protocol validation.
$Firewall/proxy logs for DNS egress path validation and related outbound traffic.
$Endpoint telemetry to identify processes generating suspicious DNS traffic.
$Threat intel/domain reputation inputs (used carefully, not as sole signal).

recommended-tools-and-guides

open Zeek Rich DNS protocol logs support baseline analysis and anomaly hunting. open Wireshark / TShark Inspect DNS packet details and validate tunneling hypotheses. open tcpdump Capture focused DNS traffic samples from affected hosts or sensors. open Suricata Alert on known suspicious DNS patterns and policy violations. open dnsrecon Learn normal DNS behavior and authorized reconnaissance patterns to improve defender context.

lab-safe-detection-workflows

These commands are for learning, validation, and defensive triage in your own lab or authorized environment. Adapt to your tooling and log locations.

DNS traffic validation and anomaly inspection

tshark -r dns-suspect.pcap -Y dns -T fields -e frame.time -e ip.src -e dns.qry.name -e dns.qry.type | head -n 80
zeek -r dns-suspect.pcap local
zeek-cut ts id.orig_h query qtype_name rcode_name < dns.log | head -n 80

$ why: Use both packet-level and NSM-level DNS views to inspect query names, types, response codes, and host patterns before labeling activity as tunneling.

Resolver-path policy check (lab / host review)

grep -E '^nameserver' /etc/resolv.conf || true
dig +short example.org
tcpdump -ni any -c 100 udp port 53

$ why: Validate which resolvers a host is actually using and confirm DNS traffic paths match policy and monitoring expectations.

triage-questions

?Is the querying host using approved resolvers and expected DNS paths?
?Do the query names/types/timing match known software behavior for this host role?
?Is there corroborating evidence of suspicious processes or outbound connections?
?Can packet inspection confirm or disprove a tunneling hypothesis?
?What immediate mitigation is appropriate (block domain, isolate host, force resolver path, increase monitoring)?

defender-actions.checklist

$Centralize DNS logging and standardize resolver usage.
$Baseline DNS behavior by subnet/role and monitor anomalies.
$Alert on resolver bypass and suspicious query patterns.
$Correlate DNS signals with endpoint and network telemetry.
$Practice DNS-focused triage with packet captures and Zeek DNS logs.

study-workflow

Learn what normal behavior looks like for this area (auth, exposure, config, or internal traffic).
Identify the logs and telemetry that should show the behavior.
Practice one safe validation in a lab or authorized environment.
Write a short playbook for detection, triage, and response.
Review the related tool guides under /learning/tools.

<- previous threat AV-10 · Cloud misconfiguration and identity abuse -> next threat AV-12 · Wireless rogue access and evil twin attacks