Sysmon Event ID 22 is logged when a process performs a DNS query, whether the lookup succeeds or fails and whether the result comes from cache or not. It is used to spot suspicious domain lookups, fast-flux infrastructure, and unusual parent-child process behaviour. Sysmon must be installed and DNS query logging enabled.
What Event ID 22 tells you about DNS activity
Sysmon Event ID 22 is the visibility point for DNS lookups made by a process, so the event is about resolving domains rather than proving that a connection was ultimately made. That matters because the lookup itself can reveal suspicious tooling, command-and-control discovery, or malware staging behaviour even when the network session never leaves the host.
For triage, the useful question is not just “did the query succeed?”, but “which process asked, what domain was queried, and does that name fit the process role?” A browser asking for a normal content domain is far less interesting than a script host, Office process, or admin tool querying an unusual domain at startup. See the Sysmon Guide for configuration and event-ID context, and the MITRE ATT&CK Enterprise Matrix for the kinds of discovery and command-and-control behaviours DNS telemetry can help surface.
How to read the event in context
Event ID 22 becomes useful when you correlate it with parent process, command line, timing, and follow-on network activity. A single DNS query is rarely enough to conclude malicious activity, but repeated lookups, algorithmically generated domains, odd subdomains, or queries from processes that normally never resolve names can raise confidence quickly. Event 22 is often strongest when paired with process creation, script execution, or other host telemetry that explains why the lookup happened.
The cache detail also matters operationally. Cached and uncached lookups both tell you something about intent, because the process still attempted name resolution and that attempt is itself observable. If the same process repeatedly resolves similar domains, or if multiple child processes inherit the same unusual lookup pattern, the event can help separate normal application behaviour from beaconing, domain generation, or failed infrastructure discovery.
For defenders who want broader Windows telemetry around related host behaviour, the Windows Event Log Guide is useful for correlating Sysmon with native event logs. If the suspicious process is PowerShell or another script host, the PowerShell Security Guide helps explain how script execution patterns can line up with DNS-driven discovery or staging.
What to do when Event ID 22 looks suspicious
Start with the process tree and the queried domain, then decide whether the query is expected for that application, user, or system role. Focus on the executable path, command line, parent process, and whether the domain resembles a newly registered, randomly generated, or rarely seen name. If the lookup is tied to a script, macro, or unusual admin tool, treat it as a lead rather than a standalone alert.
When DNS queries are part of a wider compromise chain, the practical response is to check for adjacent host events that show execution, persistence, or outbound connectivity. If the same process also created child processes, loaded suspicious modules, or launched network connections soon after the lookup, you have a much stronger case for escalation. If the telemetry supports it, preserve the process context and DNS evidence before containment actions disrupt the timeline.
Risk and Threat Considerations
DNS telemetry is valuable because it exposes a common pre-connection step that attackers and malware often use for discovery, staging, and command-and-control selection. The main risk is false comfort: a benign-looking domain lookup can still be the first visible sign of malicious tooling, especially when the query comes from an unusual parent process or appears in bursts.
Failure mechanism: Adversaries abuse normal name resolution to hide reconnaissance, validate infrastructure, or test reachability while blending into legitimate DNS noise. If defenders only watch for failed lookups or only review network connections, they can miss the process-level behaviour that precedes a later compromise step.
Impact: Missed or delayed detection can allow malware to stage infrastructure discovery, maintain persistence, or continue beaconing with low friction. In investigations, incomplete DNS context can also make it harder to prove which host or process initiated the first suspicious action.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK addresses the attack and risk surface, while CIS Controls v8 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| MITRE ATT&CK | T1071.004 — Application Layer Protocol: DNS | DNS queries are a common command-and-control and discovery signal. |
| Recommendation — Map suspicious lookups to DNS tradecraft and hunt for related beaconing activity. | ||
| CIS Controls v8 | CIS-8 — Audit Log Management | Sysmon Event ID 22 is a logging and detection use case. |
| Recommendation — Centralise Sysmon DNS telemetry and alert on unusual process-domain patterns. | ||
| NIST SP 800-53 Rev 5 | AU-12 — Audit Record Generation | Event ID 22 depends on generating host audit records for DNS activity. |
| AU-6 — Audit Record Review, Analysis, and Reporting | DNS events need review and correlation to identify suspicious process behaviour. | |
| Recommendation — Enable host audit generation for DNS events and retain the telemetry for investigation. Correlate DNS events with process context and escalate anomalous query patterns. | ||
Practitioner Guidance
What to verify: Confirm that Sysmon is installed, DNS query logging is enabled, and the event pipeline preserves the process name, parent process, and queried domain. Without those three elements, Event ID 22 is much less useful for triage.
What to prioritise: Investigate Event ID 22 first when the querying process is unexpected for the host role, the domain is rare or generated, or the query pattern repeats across short intervals. Those are the cases most likely to distinguish normal application noise from adversarial behaviour.
Practitioner takeaway: Treat Event ID 22 as a process-centric DNS signal, not a simple “domain queried” log, because the investigative value comes from who asked, what was asked for, and whether that behaviour fits the host’s normal execution pattern.