Sysmon Event ID 22 shows that a process executed a DNS query, whether the lookup succeeded or failed and whether it was cached or not. It helps uncover command-and-control, malicious domain lookups and unusual resolver behaviour. Monitor the process making the query, the domain requested and repeated failures, and filter to control volume. It requires Sysmon on Windows 8.1 or later.
Why Event ID 22 is valuable telemetry, not just background noise
Sysmon Event ID 22 matters because it turns DNS activity into process-level evidence. That lets security teams answer a question normal DNS logs often cannot: which executable asked for the lookup, and whether the query was part of a suspicious pattern such as beaconing, domain generation, or a failed lookup sequence that keeps repeating.
Its value is highest when you treat it as context, not as a standalone alert. A single DNS query may be harmless, but when the same process queries unusual domains, resolves names that do not fit the host role, or repeatedly fails against newly observed infrastructure, the event becomes a strong investigative pivot for detection engineering and triage.
Because Event ID 22 includes both successful and failed lookups, it also helps distinguish normal application behaviour from early-stage malicious tradecraft. That matters when an endpoint is still only probing infrastructure, because DNS is often the first observable step before command-and-control communication becomes more obvious.
How to use DNS query events in investigation and tuning
Analysts should read Event ID 22 alongside process creation, parent-child process chains, and the destination domain itself. The most useful review pattern is usually process first, then domain, then frequency, then failure mode. If a process that should not browse the internet is generating DNS lookups, or a user-facing process is resolving domains that never appear in normal business traffic, the event deserves immediate context building.
Filtering is also part of the operational value. DNS telemetry can become noisy fast, especially on busy endpoints or in environments with recursive resolvers and cached answers. The practical approach is to tune for high-signal processes, known-good resolvers, and repeated failure patterns while keeping enough coverage to see new domains, one-off lookups, and low-and-slow staging activity.
Security teams also get more out of the event when they preserve the surrounding context in the SIEM, rather than only storing the domain string. A useful alert usually needs the host, process name, command line or image path, the queried domain, the result pattern, and whether the lookup aligns with the asset’s expected role.
What Event ID 22 does not tell you by itself
Event ID 22 shows DNS behaviour, not intent. It can indicate malicious domain resolution, but it can also reflect software updates, content delivery networks, telemetry services, misconfigured applications, or routine name resolution failures. The event becomes meaningful when it is correlated with the process lineage and the wider endpoint story, not when it is judged in isolation.
That is why it is best used as a detection building block. Event ID 22 is often one of the earliest signs that a host is reaching for an external dependency, but it rarely proves compromise on its own. The useful question is whether the lookup is expected for that process, at that time, on that system, in that network segment.
For Windows-heavy environments, the event is especially useful because it gives defenders a native way to see DNS activity at the endpoint, rather than waiting for perimeter DNS logs or proxy logs that may not retain the same process attribution. That makes it valuable both for hunting and for validating whether a suspicious process actually tried to resolve its infrastructure.
Risk and Threat Considerations
DNS is a common control plane for attack staging, so process-level DNS telemetry can expose command-and-control setup, domain fronting attempts, fallback infrastructure, and repeated resolution failures that indicate a campaign is trying to connect. The risk is not just visibility loss, but missed early warning before an endpoint begins making more direct outbound connections.
Failure mechanism: If defenders do not correlate the DNS query with the originating process and its expected behaviour, malicious lookups blend into ordinary resolver traffic. Attackers can exploit that gap by using short-lived domains, low-volume beacons, or living-off-the-land processes that make DNS activity look routine.
Impact: Analysts may miss the first reliable indicator of staging or command-and-control, which delays containment and increases the chance that the same host is used for follow-on access, persistence, or lateral movement.
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 query telemetry helps detect DNS-based command-and-control and staging activity. |
| Recommendation — Map suspicious DNS activity to T1071.004 and hunt for beaconing, fallback domains, and resolver abuse. | ||
| NIST CSF 2.0 | DE.CM-01 — Monitor Assets and Systems | Sysmon Event ID 22 is endpoint monitoring telemetry used to spot anomalous DNS activity. |
| Recommendation — Collect and review endpoint telemetry that reveals unusual DNS behaviour from specific processes. | ||
| CIS Controls v8 | CIS-8 — Audit Log Management | Event ID 22 is a log source that must be collected, centralised, and tuned for detection use. |
| Recommendation — Centralise Sysmon DNS logs and tune them for high-signal detections and investigations. | ||
Practitioner Guidance
What to verify: Confirm that your Sysmon configuration actually captures Event ID 22 on the hosts you care about, and verify that you can still attribute the lookup to a meaningful process name and path after log forwarding and parsing. If the event is present but the process context is weak, the telemetry will be far less useful for hunting.
Common mistake: Treating every DNS event as equal. The practical threshold is whether the process should have made that query, whether the domain is expected, and whether the pattern repeats. One suspicious lookup is a clue, a repeated or role-inconsistent lookup pattern is usually the investigation trigger.
What practitioners underestimate: Volume control is part of the control, not an afterthought. If you cannot tune noise down enough to keep the signal readable, Event ID 22 will be present but operationally ignored, which defeats the point of collecting it in the first place.
Practitioner takeaway: Use Event ID 22 to connect DNS behaviour back to the process that caused it, because that is what turns generic name resolution into actionable detection evidence.