No alerts fired. That was the problem.

The SOC dashboard is clean. No red, no amber, nothing queued in triage. If you hunt for a living, that's not always good news, it's sometimes exactly the moment you should be paying closer attention, because the tools that would catch a loud attacker are built to catch loud attackers, and someone who read the same detection rules you did knows how to stay under them.

This is where threat hunting starts: not from an alert, but from a hypothesis. Given what MITRE ATT&CK documents about how adversaries actually move once they're in, what would command-and-control traffic look like if it were deliberately built to avoid tripping anything? DNS is a classic answer (T1071.004), because almost nobody blocks it and almost nobody inspects it closely.

The hypothesis alone doesn't find anything. What finds something is pulling the raw DNS query logs for a segment of the network, not the summarized version a SIEM dashboard shows you, and building a baseline first: how long are legitimate queries in this environment, how much entropy do normal subdomains carry, how many unique subdomains does a host query in an hour under ordinary use. CDNs and telemetry beacons already generate a lot of long, odd-looking subdomains, so the naive version of this hunt, "find high-entropy DNS," drowns in false positives on hour one. Tunnelling looks similar to that noise on purpose.

What separates them is volume and shape over time, not any single query. One high-entropy DNS request an hour from a workstation is probably a CDN edge node. Hundreds of long, high-entropy queries to the same second-level domain at a steady interval, encoding what turns out to be structured data across the query names, is not that. This has to be done by hand the first several times: there's no clean signature to alert on yet, only a pattern you're building a feel for.

Once the pattern holds, the hunt pivots to the host: what process actually issued those DNS calls, and does it have any legitimate reason to be resolving at that volume. A browser doing it is unremarkable. A scheduled task or an unsigned binary in a temp directory doing it is the finding, and it's the process ancestry, not the DNS traffic alone, that turns a suspicious pattern into something you can escalate.

It's a repeatable method, not a one-off query: hypothesis from a known ATT&CK technique, baseline your own environment, look for the pattern a summary alert would never surface, then pivot to host and process to confirm it's real. Codelivly's free threat hunting, ATT&CK mapping and DNS tunnelling detection labs let you run this exercise hands-on. The Hands-On Threat Hunting Book covers the full methodology end to end, across Windows, Linux, network and cloud.