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

Attackers abuse DNS for reconnaissance, C2 beaconing, and covert data movement because DNS traffic is almost universally allowed and rarely inspected closely. Missing DNS telemetry means missing one of the best early-warning signals available.

$ action: Centralize DNS logging, baseline query behavior by host role, monitor resolver paths, and build alerts for high-entropy domains, unusual query volumes, and resolver bypass.

1. Why DNS Is a Common Abuse Channel

DNS is essential infrastructure. It's allowed almost everywhere, including environments with strict outbound filtering. That ubiquity makes it a natural covert channel — an attacker can encode data in query names or use DNS responses to deliver C2 instructions while blending into the background noise of legitimate resolution traffic.

Attackers use DNS for reconnaissance queries, domain generation algorithm (DGA) callbacks, slow-and-low C2 beaconing, and in some cases actual data exfiltration via encoded subdomains. Even when the payload is encrypted in HTTPS, DNS metadata shows you what destinations a host is trying to reach.

The detection gap is usually a baseline problem, not a tooling problem. Most environments already have DNS resolver logs. The issue is that no one has defined what normal looks like for each subnet and host role, so anomalies don't stand out.

2. What Attackers Can Do with DNS Abuse

A C2 channel over DNS can hide in legitimate-looking query traffic. Small queries made periodically to a rare domain, high-entropy subdomains encoding command output, or TXT record abuse for data retrieval — these patterns can persist for extended periods if no one is baselining query behavior by host.

Not every unusual DNS pattern is malicious. Software updates, telemetry agents, CDNs, and cloud services all produce noisy or high-volume DNS. Defenders need baselines and corroborating evidence to separate abuse from noise — a suspicious domain alone isn't enough to escalate.

DNS abuse rarely stands alone. Correlate with endpoint process telemetry to see what's generating the queries, and with outbound HTTPS logs to see what follows the DNS resolution. That combination eliminates most false positives.

3. How Defenders Mitigate DNS Abuse Risk

Centralize resolver usage first. Hosts that bypass your DNS resolvers for direct internet queries remove themselves from your visibility completely. Every client should use a managed resolver, and resolver bypass should be detectable and alertable.

Baseline normal DNS behavior by host role and subnet. A database server resolves a small, stable set of domains. A developer workstation resolves hundreds. Those baselines are very different, and anomalies look different in each context.

DNS filtering helps, but only after you can measure what's being blocked and what's bypassing policy. Blocking without visibility gives defenders a false sense of control.

detection-signals

$A single internal host generates repeated periodic queries to a domain it has never resolved before — consistent with beaconing behavior rather than legitimate browsing.
$Query names contain long, high-entropy subdomains — strings that look encoded rather than human-readable — suggesting data is being embedded in DNS queries.
$A host is sending DNS queries to an IP that isn't a managed resolver — direct DNS to external servers, bypassing monitoring.
$Query type distribution is unusual for the host role: excessive TXT, NULL, or CNAME requests from hosts that should only be making A/AAAA queries.
$Suspicious DNS activity and an unusual outbound connection to the same destination appear within a short time window on the same host.

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.

related-learning-modules

Build fundamentals and workflows that directly support defending against this threat pattern.

open /learning/tcp-ip-dns-http-tls-routing-switching TCP/IP, DNS, HTTP, TLS, Routing and Switching Fundamentals open /learning/packet-capture-protocol-analysis-wireshark-tshark Packet Capture and Protocol Analysis with Wireshark / TShark open /learning/network-security-monitoring-zeek-suricata Network Security Monitoring with Zeek and Suricata

related-tool-pages

Use these detailed tool guides to practice safe validation, evidence collection, and triage workflows for this threat.

open /learning/tools/zeek Zeek open /learning/tools/wireshark-tshark Wireshark / TShark open /learning/tools/tcpdump tcpdump open /learning/tools/suricata Suricata open /learning/tools/dnsrecon dnsrecon

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 sending DNS traffic to managed resolvers, or bypassing them to reach external DNS servers directly?
?Do the query names, types, and timing match expected software behavior for this host's role — or are they anomalous in name entropy, frequency, or record type?
?Is there corroborating evidence from endpoint telemetry — a specific process generating the queries — or from outbound connection logs to the same destinations?
?Can packet inspection confirm or disprove a tunneling hypothesis by showing encoded data in subdomains or unusual response payloads?
?What mitigation makes sense given confidence level: block the specific domain, isolate the host, force resolver paths, or just increase monitoring while you gather more evidence?

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