When the endpoint can't see it: hunting from the Windows DNS server's analytical log

Most DNS detection I inherit lives on the endpoint. Sysmon Event ID 22 gives you process-attributed queries, which is genuinely useful, and I lean on it. But it has a hole you feel the first time you chase a beacon: it only sees hosts you instrumented. The printer resolving something odd, the badge reader, the appliance nobody can put an agent on, the contractor laptop that never got Sysmon pushed to it, none of those show up. The one box that does see all of them is the resolver itself, and on a Windows network that is usually a domain controller running the DNS Server role. This is a note on hunting from that vantage point, using the analytical channel most teams never switch on.

I’m writing these against Windows Server 2022 acting as the internal resolver, with the events forwarded into Elastic. Specifics matter, and “our DNS box” tells you nothing.

Two logs, and only one is worth forwarding

Windows DNS Server ships two event channels. The Audit channel, Microsoft-Windows-DNS-Server/Audit, is on by default and records configuration changes: zone edits, new records, changes to server settings. Useful for catching someone tampering with the resolver, useless for catching what clients are asking it. The one I care about for hunting is the Analytical channel, Microsoft-Windows-DNS-Server/Analytical. It logs the query traffic itself, every request received and every answer sent, and it is disabled out of the box because it is chatty.

(Yes, it is an ETW analytic and debug log rather than a classic Windows log, which changes how you collect it. More on that below.)

Turning it on without melting the DC

Enabling it is a one-liner, but the log is hidden by default. In Event Viewer you turn on View, then Show Analytic and Debug Logs, find Applications and Services Logs under Microsoft, Windows, DNS-Server, and enable the Analytical log. The scripted equivalent is wevtutil set-log "Microsoft-Windows-DNS-Server/Analytical" /enabled:true. Microsoft’s own DNS Logging and Diagnostics guidance puts the cost at roughly five percent CPU at a hundred thousand queries per second, which on a normal internal resolver is noise. Because it is an ETW trace and not a classic channel, plain Windows Event Forwarding will not pick it up. You collect it with an agent that reads ETW or ships the rotating .etl. That collection detail is where most DNS-server hunts quietly die, so sort it before you write a single rule.

The events, and the fields that matter

Received queries land as Event ID 256, successful responses as 257, and outbound recursive queries as 260. For hunting, 256 is where I start. Each one carries the query name (the QNAME), the record type (the QTYPE), and the client’s source IP. The record type is the first thing I pivot on. A workstation subnet generating a steady stream of TXT or NULL lookups is not normal browsing; those record types are where tunneling and TXT-record command-and-control live, because they carry the most data per response. Long QNAMEs are the second pivot: encoded tunneling stuffs data into the leftmost labels, so query names pushing toward the 253-character limit with high-entropy labels stand out against the short dictionary-word hostnames that real traffic produces.

The 257 responses are worth keeping too, because the answer tells you something the query does not. Tunneling and staged loaders tend to resolve the same registered domain to a small, stable set of addresses over and over, while a legitimate CDN name resolves across a wide, rotating pool. Flip that around and you get the other end of the spectrum: one hostname resolving to dozens of addresses in a few minutes is the fast-flux pattern that fronts some botnets. Neither is proof on its own. Both are cheap to compute once the response events are already flowing into the same index as the queries.

What I actually hunt

Three shapes cover most of what I have caught. The first is one client resolving hundreds or thousands of distinct subdomains under a single registered domain in a short window. That fan-out is the signature of both tunneling tools and domain-generation malware, and it maps to T1071.004 and T1568.002. The second is a spike in TXT, NULL, or CNAME record types from a host that has no business asking for them. The third is an NXDOMAIN storm, visible as a run of 258 (response failure) events, which is what you see when generation-algorithm malware walks through candidate domains before one resolves. None of these is a signature you can hardcode. They are all “this host, compared to every other host on its subnet, is behaving differently,” which is why I score per-source-IP over a rolling window instead of alerting on any single query. Protocol tunneling as a category is T1572, and the server-side view is often the only place you will see it when the compromised host is not instrumented.

Where it fires wrong

The false positives are specific and worth knowing before you page anyone. Endpoint security products generate enormous, strange-looking DNS volume: reputation lookups, telemetry, cloud sandbox callbacks, and their QNAMEs are long and high-entropy by design. So do content delivery networks and some cloud storage SDKs. Update agents produce fan-out that reads like beaconing. The tuning is per-vendor and it is a one-time cost: you learn what your EDR’s DNS looks like, tune it out, and the rule goes quiet. Mine surfaces a real lead maybe once a month now. Rarely.

Where it sits in the stack

I do not run this instead of endpoint DNS telemetry, I run it underneath. Sysmon EID 22 gives me process attribution on the hosts I control, and I described how I scope that in the 2026 Sysmon baseline; the server analytical log gives me coverage of everything I do not control, which is always more of the network than anyone admits. When a server-side lead points at a host that is instrumented, the two views together hand you the domain and the process. When it points at something that is not, the resolver is the only witness you have, and that same “everything routes through one chokepoint” logic is what makes it pair well with the lateral-movement detections I keep current.

Turn on the log the clients can’t hide from. It sees the parts of your network you forgot you owned.