DNS Hunting - The Undervalued Data Source

Ask a SOC what their highest-value log source is and you’ll hear EDR telemetry, maybe authentication logs, occasionally proxy data. Almost nobody says DNS, and that’s a genuine mistake, because DNS sits in a strange, useful position: nearly every piece of malware, every C2 channel, every phishing kit needs it at some point, and it’s one of the cheapest, most complete data sources most organizations already have sitting mostly unreviewed.

Here’s the thing that makes DNS particularly good for hunting specifically, as opposed to just detection: attackers can encrypt their C2 traffic, they can use legitimate cloud infrastructure to blend in, but they generally can’t avoid a DNS lookup happening somewhere before that connection gets made unless they’re hardcoding IPs, which creates its own detectable pattern.

Newly registered domains are still one of the strongest signals available

Domains registered in the last thirty days get queried by real users constantly for entirely legitimate reasons new product launches, fresh startups, whatever. But the ratio shifts hard when you’re looking at malware infrastructure, because attackers frequently spin up fresh domains close to campaign launch specifically to dodge reputation-based blocklists that haven’t caught up yet.

Cross-reference your DNS query logs against domain age from any WHOIS-backed threat intel feed, and flag queries to domains under fourteen days old originating from processes or hosts that don’t normally generate that kind of traffic. Say a print server a device that should have an extremely narrow, predictable set of DNS queries suddenly resolves a domain registered four days ago. That’s a five-second check that catches a meaningful amount of first-stage malware delivery and C2 setup, and it’s one of the better return-on-effort hunts in this entire list.

Query volume and entropy expose DNS tunneling fast

DNS tunneling using DNS queries themselves as a covert data channel, encoding stolen data into subdomain labels remains a favorite exfiltration technique specifically because so many organizations allow unrestricted outbound DNS without a second thought, treating port 53 as inherently trusted in a way they’d never treat port 443.

Two signals catch this reliably. First, volume: a host generating hundreds or thousands of DNS queries to the same parent domain in a short window is abnormal for basically any legitimate application. Second, and more specific: subdomain entropy. Legitimate subdomains are human-readable mail.company.com, cdn.service.com. Tunneling tools generate subdomains that look like random noise, because that’s literally encoded data something like x7fk2m9qzv4t.tunnel-domain.com. Calculating Shannon entropy on subdomain labels and flagging anything well above what your legitimate traffic baseline shows is a detection that’s cheap to build and catches tunneling tools regardless of which specific tool an attacker’s using.

Beaconing shows up in DNS before it shows up anywhere else

A lot of modern C2 frameworks use DNS as the initial check-in mechanism even when the actual command channel runs over HTTPS afterward, because DNS resolution is one of the few things that reliably gets through almost every network’s egress controls without inspection. That makes DNS query timing analysis a genuinely strong early-warning signal, sometimes earlier than anything you’d catch on the network layer proper.

Look for a host resolving the same domain at suspiciously regular intervals every four or five minutes, say, with some jitter thrown in to avoid looking too clean. This is the same beaconing pattern you’d hunt for in NetFlow data, just one layer earlier in the chain, which means you often catch it before the actual C2 connection even gets established. Building this as a standing analytic grouping DNS queries by source host and destination domain, then checking interval consistency over a rolling window is one of the higher-value detections you can add to a DNS hunting program without much ongoing tuning burden.

Fast flux and domain generation algorithms need pattern-based hunting, not blocklists

Some malware families rotate through resolved IPs for a single domain rapidly (fast flux) or generate large numbers of algorithmically produced domain names to make takedowns pointless (DGA-based C2). Blocklisting individual domains or IPs against either technique is close to useless you’re always a step behind whatever the algorithm generates next.

What works instead is pattern recognition on the domain names themselves. DGA-generated domains tend to have statistical properties that differ from human-registered ones unusual character distributions, lack of dictionary words, consistent length patterns within a single malware family’s generation window. A simple classifier looking at these characteristics, even a fairly basic one, catches a lot of DGA traffic that pure reputation-based approaches miss entirely, because it’s looking at the shape of the name rather than trying to keep a list current against an algorithm churning out thousands of candidates a day.

Making DNS hunting a habit instead of a one-off project

None of this requires exotic tooling. Most organizations already log DNS queries somewhere, whether through their resolver, an EDR agent, or a network sensor the data’s usually sitting there unreviewed rather than genuinely missing. The gap is analytical attention, not collection.

Start with the newly-registered-domain check since it’s the cheapest to stand up and delivers value almost immediately, then layer in entropy-based tunneling detection and beaconing interval analysis as your baseline matures. DNS won’t replace endpoint or network hunting, but treating it as a supporting afterthought instead of a primary hunt source leaves a genuinely useful data set sitting idle in most environments.