Sysmon Event ID 22 is the DNSEvent, or DNS query, event. It is generated when a process performs a DNS query, whether successful or failed and whether cached or not. Use it to spot suspicious domain lookups, command-and-control discovery and unusual resolver activity, especially from high-risk processes.
What Sysmon Event ID 22 captures
Sysmon Event ID 22 records DNS queries made by a process, including successful and failed lookups and cached requests. That makes it a process-level view of name resolution, not just a network log.
For defenders, the value is in seeing which executable asked for which domain, which helps separate normal application behavior from suspicious discovery, callback preparation or resolver abuse. In practice, the event is most useful when paired with process lineage and command-line context so the DNS lookup can be tied to the initiating activity.
Why DNS query telemetry matters
DNS is a common control plane for both legitimate application behavior and malicious infrastructure discovery. Attackers often rely on ordinary-looking lookups to find command-and-control endpoints, stage follow-on activity, or test whether a host can resolve external names. Because DNS is ubiquitous, suspicious queries can blend into routine traffic unless you can attribute them to the process that generated them.
Event ID 22 is especially useful when high-risk tools, script hosts or newly spawned binaries begin resolving uncommon domains, newly registered names or lookalike infrastructure. The event also helps surface unusual resolver patterns, such as repeated failures, bursts of lookups or queries from processes that should not normally perform outbound name resolution.
For broader Sysmon deployment and filtering context, the Sysmon Guide covers event IDs, configuration and detection use cases in more depth.
How analysts use Event ID 22 in investigations
Analysts use the event as a pivot point: start with the domain, then trace back to the process, parent process and execution context. That workflow helps distinguish a browser or update service performing expected resolution from a script host, Office child process or administrative utility performing unexpected lookups.
When the DNS event lines up with other telemetry, it becomes far more actionable. Correlating it with process creation, PowerShell activity, service creation or suspicious logon activity can reveal whether the query was part of initial execution, discovery, lateral movement or post-exploitation staging.
The surrounding Windows event ecosystem matters here as well. The Windows Event Log Guide provides the log context needed to connect DNS activity to logons, service changes, task creation and other operational signals.
Detection value and tuning considerations
Event ID 22 is most useful when it is filtered and contextualized, not collected blindly. High-volume enterprise environments generate large volumes of benign DNS activity, so detection should focus on process rarity, domain reputation, lookup failure patterns and whether the initiating process normally belongs on that host. DNS telemetry without tuning can create noise, but tuned carefully it becomes a strong indicator of abnormal behavior.
The event also benefits from endpoint baselining. Processes that suddenly begin issuing DNS queries, query patterns that do not match the host role, and repeated lookups to infrastructure that has no business purpose are all worth scrutiny. DNS telemetry is often an early clue rather than a stand-alone verdict, so it works best as part of layered endpoint detection.
PowerShell-driven activity is a common example of that layering, because script-based tradecraft frequently includes discovery and callback resolution. The PowerShell Security Guide is a useful companion when you want to connect suspicious DNS events to scripting and execution abuse.
Risk and Threat Considerations
DNS query logging can expose early signs of command-and-control discovery, domain generation activity and covert infrastructure checks. The same visibility also means defenders may miss compromise if they ignore failed queries, cached lookups or low-and-slow resolver behavior that sits outside normal application patterns.
Failure mechanism: An attacker runs code under a legitimate process context, then uses ordinary DNS lookups to locate or validate remote infrastructure before making network contact. If monitoring only inspects connections and not queries, that discovery step can remain hidden.
Impact: The result can be delayed detection of malware staging, harder attribution of suspicious process behavior, and missed evidence of the infrastructure used for follow-on execution or exfiltration.
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 NIST CSF 2.0 and CIS Controls v8 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 C2 and discovery channel on endpoints. |
| T1046 — Network Service Scanning | Suspicious query bursts can indicate reconnaissance and internal discovery. | |
| Recommendation — Map DNS lookup patterns to T1071.004 and hunt for command-and-control or discovery behavior. Correlate unusual resolver activity with T1046-style reconnaissance and investigate scanning sequences. | ||
| NIST CSF 2.0 | DE.CM-01 — Networks and systems are monitored to detect anomalies, indicators of compromise, and other potentially adverse events | Sysmon DNS events support continuous monitoring and anomaly detection on endpoints. |
| Recommendation — Use DE.CM-01 to monitor endpoint DNS activity for anomalies and indicators of compromise. | ||
| CIS Controls v8 | CIS-8 — Audit Log Management | Sysmon Event ID 22 is a log source for security monitoring and investigation. |
| CIS-10 — Malware Defenses | DNS telemetry helps detect malware callbacks, staging, and suspicious domain use. | |
| Recommendation — Centralize and review Sysmon DNS logs under CIS-8 for investigation and alerting. Use CIS-10 detections to flag suspicious DNS activity from high-risk processes. | ||
Practitioner Guidance
What to watch for: Treat Event ID 22 as a process attribution signal first, not just a domain list. Focus on unusual parents, rare binaries, repeated failures and domains that do not match the host role or application purpose.
Practitioner takeaway: The strongest detections come from pairing DNS query telemetry with process lineage and endpoint context, because the lookup alone rarely tells the full story.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 18, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org