DNS as a Weapon

DNS — The Protocol Every Attack Touches

If there's one protocol that touches nearly every cyberattack, it's DNS. Before malware can phone home to a C2 server, it needs to resolve the domain. Before stolen data can leave the network, it often gets encoded into DNS queries. Before a phishing page can load, the victim's browser queries DNS for the domain. DNS is the universal protocol — it's always allowed through firewalls, rarely inspected, and essential for virtually all network communication.

This makes DNS simultaneously the attacker's best friend and the defender's goldmine. Attackers abuse DNS because it's trusted and ubiquitous. Defenders monitor DNS because it reveals intent — the domains a host resolves tell you what it's trying to communicate with, even before a single byte of application data is exchanged.

In previous lessons, you learned how Suricata monitors network traffic and fires alerts based on rules (Lesson 3.2), and how protocol analysis reveals what's happening beneath the surface (Lesson 3.3). DNS analysis is a specific discipline within protocol analysis — and it deserves its own lesson because of how frequently DNS appears in attack chains and how rich the detection opportunities are.

DNS Tunneling — Hiding Data in Queries

DNS tunneling is one of the most effective data exfiltration techniques because it abuses a protocol that's almost never blocked. The technique encodes arbitrary data into DNS query labels (the subdomain portion), sends those queries to an attacker-controlled authoritative DNS server, which decodes the data from the queries and optionally returns data in DNS responses.

How It Works

A normal DNS query looks like this:

Query: www.google.com → A record → 142.250.80.4

A DNS tunneling query looks like this:

Query: dXNlcm5hbWU9YWRtaW4mcGFzc3dvcmQ9.exfil.badactor.com → TXT record

The subdomain dXNlcm5hbWU9YWRtaW4mcGFzc3dvcmQ9 is Base64-encoded data: username=admin&password=. The attacker's DNS server for badactor.com receives this query, decodes the subdomain, and extracts the stolen credential. The response can also carry encoded data back to the client, creating a bidirectional channel.

Click to enlarge

Why It's Effective

• DNS is almost never blocked — blocking DNS breaks all internet connectivity
• DNS is often unmonitored — many organizations don't log or inspect DNS queries
• DNS traverses firewalls — even heavily restricted networks allow outbound DNS (UDP/53)
• DNS responses can carry data back — TXT records can hold up to 255 characters per string, multiple strings per response

Detection Indicators

DGA Domains — Machine-Generated Throwaway Names

Domain Generation Algorithms (DGAs) are used by malware to dynamically generate domain names for C2 communication. Instead of hardcoding a single C2 domain (which defenders can block), the malware generates hundreds or thousands of domains using a seed value (often based on the current date). The attacker registers just one or a few of these domains, and the malware cycles through the list until it finds one that resolves.

How DGA Works

1. Malware runs its algorithm — input: current date + seed → output: list of domain names
2. Malware queries each domain — most return NXDOMAIN (not registered)
3. One domain resolves — the attacker pre-registered it → C2 connection established
4. Defenders block that domain — malware generates a new list tomorrow, attacker registers a different one

Characteristics of DGA Domains

DGA domains have distinctive properties that make them detectable:

Entropy as a Detection Tool

Shannon entropy measures the randomness of a string. Human-readable domain names have low entropy because they use common letter patterns. Machine-generated names have high entropy because they're algorithmically random.

Entropy calculation (simplified): For each character, calculate how "surprising" it is given the character distribution. More uniform distribution = higher entropy.

• google → entropy ~2.6 bits/char (repeated 'g' and 'o', common letters)
• xk7f9p → entropy ~2.6 bits/char per unique char but ~3.9 overall (mixed case, digits, no common patterns)

NXDOMAIN Spikes

One of the strongest DGA indicators is a sudden spike in NXDOMAIN responses (DNS response code indicating the domain doesn't exist). Normal hosts occasionally hit NXDOMAIN from typos or stale cache entries. A host generating 50+ NXDOMAIN responses per minute is likely running a DGA — it's cycling through generated domains, most of which the attacker hasn't registered.

Suspicious TLDs and Newly Registered Domains

Not all top-level domains are created equal. Some TLDs have earned a reputation for being disproportionately used in malicious activity, primarily because they offer free or extremely cheap registration with minimal verification.

High-Risk TLDs

Newly Registered Domains (NRDs)

Domains registered less than 30 days ago are statistically more likely to be malicious. Legitimate organizations typically register domains well in advance of use. Attackers register domains immediately before campaigns and discard them after.

Detection approaches:

• WHOIS lookups — Check domain creation date
• Threat intelligence feeds — Many feeds include NRD lists updated daily
• Suricata rules — Can flag queries to domains matching known-bad patterns or TLDs
• DNS response monitoring — New domains often have minimal DNS infrastructure (single A record, no MX, no SPF)

DNS over HTTPS (DoH) — The Visibility Problem

Traditional DNS operates over plaintext UDP port 53. Every DNS query and response is fully visible to any network device in the path — firewalls, NIDS sensors, DNS servers, even the ISP. This visibility is what makes DNS monitoring so powerful for defenders.

DNS over HTTPS (DoH) changes this equation fundamentally.

How DoH Works

Instead of sending DNS queries as plaintext UDP packets to a DNS server on port 53, DoH wraps DNS queries inside HTTPS connections to web-based resolvers:

The Impact on Security Monitoring

When a host uses DoH, the NIDS loses all DNS visibility for that host. No query names, no response codes, no TXT record abuse, no DGA detection, no tunneling detection. The DNS queries are encrypted inside HTTPS — they look identical to any other web traffic to the NIDS sensor.

This means:

• DNS tunneling detection fails — Tunneled queries go to the DoH resolver, not the monitored DNS server
• DGA detection fails — NXDOMAIN responses are inside the encrypted HTTPS stream
• Suspicious TLD monitoring fails — Query domains are not visible
• DNS logging is incomplete — Organizational DNS servers never see the queries

Detection and Mitigation Strategies

Despite the challenges, defenders aren't completely helpless against DoH:

The key insight: as DNS monitoring on the network becomes less reliable, endpoint-level DNS logging (via agents like Wazuh) becomes essential. The endpoint always sees the DNS query before it's encrypted — regardless of whether it goes over UDP/53 or HTTPS/443.

DNS Analysis in EveBox

Suricata logs DNS events in eve.json with the dns event type, and EveBox makes this data searchable. Understanding what fields are available and what patterns to look for turns DNS logs into a powerful investigation tool.

Key DNS Fields in EveBox

Investigation Patterns

Pattern 1: DNS Tunneling Hunt

1. Filter: event_type:dns + sort by query name length
2. Look for: Queries with subdomain labels > 60 characters
3. Check: Do all long queries go to the same parent domain? (e.g., *.exfil.badactor.com)
4. Correlate: Volume — hundreds of unique subdomains to one parent domain confirms tunneling

Pattern 2: DGA Detection

1. Filter: event_type:dns + response code NXDOMAIN
2. Look for: Single host generating many NXDOMAIN responses in a short window
3. Check: Do the queried domains look random? (high entropy, unusual TLDs)
4. Correlate: If one domain in the list eventually resolves, that's the active C2 domain

Pattern 3: Suspicious Domain Investigation

1. Start with an alert referencing a suspicious domain
2. Filter: event_type:dns + query name matching that domain
3. Check: When was it first queried? By how many hosts? What record type?
4. Correlate: Cross-reference with TLS logs (was there a TLS connection after resolution?) and flow logs (how long was the subsequent connection?)

What's Next

You've now covered the full spectrum of network monitoring and analysis: how NIDS sensors capture and process traffic (Lesson 3.1), how rules detect known threats (Lesson 3.2), how protocol analysis reveals suspicious behavior in HTTP, TLS, and SMB (Lesson 3.3), and how DNS exposes attacker infrastructure and data exfiltration (this lesson).

In Lesson 3.5 — Network + SIEM Correlation, you'll tie it all together. Network alerts from Suricata don't exist in isolation — they correlate with endpoint alerts from Wazuh agents, log sources from Windows Event Logs, and threat intelligence from MISP. The final lesson in this module teaches you to build a unified attack timeline by combining network and endpoint evidence, transforming individual alerts into a coherent investigation narrative. This is where the skills from Modules 2 and 3 converge into real-world incident analysis.