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 the exact 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 exactly 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 one of the classic answers (T1071.004), because almost nobody blocks it, almost nobody inspects it closely, and it crosses every firewall rule written to stop the things people actually worry about.
The hypothesis alone doesn't find anything. What finds something is going and 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: how long are legitimate queries for this environment, how much entropy do normal subdomains carry, how many unique subdomains does a given host query in an hour under ordinary use. Content delivery networks 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. A workstation making one high-entropy DNS request an hour is probably a CDN edge node or an app checking for updates. The same workstation making 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 part has to be done by hand the first several times, because there's no clean signature to alert on yet, only a pattern you're building a feel for: query length distribution, subdomain entropy, query frequency, and whether the destination domain has any legitimate reason to exist once you actually look it up.
Once that pattern holds, the hunt pivots again, this time to the host itself: what process actually issued those DNS calls, and does that process have any legitimate reason to be doing DNS resolution at that volume. A browser doing it is unremarkable. A scheduled task or an unsigned binary sitting 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 actually escalate.
None of this is a single query you run once. It's a repeatable method: form the hypothesis from a known ATT&CK technique, baseline what normal looks like in your own environment first, look for the pattern a summary alert would never surface, then pivot to the host and process level to confirm it's real before anyone acts on it. Codelivly's free threat hunting, ATT&CK mapping, and DNS tunnelling detection labs let you run exactly this exercise hands-on against a target built to hide from you. The Hands-On Threat Hunting Book is where the full methodology lives end to end, across Windows, Linux, network and cloud, not just the one technique above.
Top comments (0)