Which attacks show up in Sysmon Event ID 22?

What Event ID 22 tells you about DNS activity

Sysmon Event ID 22 is useful because it shows DNS lookups at the process level, not just network traffic at the host level. That makes it easier to tie name resolution to the exact executable that generated it, which matters when you are trying to separate normal application behaviour from suspicious lookup patterns.

It is best thought of as a visibility event rather than a verdict. One DNS query by itself rarely proves malicious intent, but repeated failures, high query volume, odd domain structure, or lookups from an unexpected process can expose reconnaissance, callback behaviour, or malware trying to find its next hop.

Because the event records successful, failed, and cached lookups, it can also surface processes that are repeatedly probing names even when no connection is made. That is useful for detecting domain generation attempts, beaconing infrastructure checks, and malware that relies on DNS as a low-friction way to reach command-and-control infrastructure.

What attack patterns commonly appear in these logs

The most common malicious pattern is command-and-control activity, where a process repeatedly resolves the same domain or a cluster of related domains to maintain contact with an external service. A related pattern is domain generation, where malware generates many candidate domains and tries them until one resolves. Both tend to stand out in DNS telemetry when you compare frequency, failure rate, and the querying process.

Another useful pattern is suspicious resolution from a process that should not normally make outbound name lookups, such as a document viewer, script host, or administrative tool running outside its usual context. DNS is often the first observable step before any later network connection, so Event ID 22 can be an early indicator that a process is staging follow-on activity.

For deeper hunting, the event becomes much more valuable when you correlate it with process creation, parent process lineage, command-line arguments, and subsequent connections. The DNS query alone tells you that resolution happened, but the surrounding process context tells you whether the behaviour fits a legitimate application path or an abuse path.

How to investigate Event ID 22 without overcalling it

Start with the querying process, because that is the strongest clue to intent. A browser or updater may generate many lookups as part of normal activity, while a service binary, script interpreter, or unexpected child process making repeated external queries deserves closer review. The domain name also matters: algorithmic strings, newly seen domains, and unusual top-level domains are higher-signal than familiar business services.

Look for repetition and clustering. If the same host produces bursts of failed resolutions, especially across short intervals, that can indicate automated retry logic, fallback behaviour, or beaconing. If the lookups are spread across many similar domains, treat that as a stronger sign of domain generation or operational infrastructure churn.

Use broader Windows telemetry to confirm whether the DNS activity fits a known workflow. Process creation, script execution, and network events help you decide whether the lookup is a symptom of a normal application, a misconfiguration, or a compromise path worth escalating.

Risk and Threat Considerations

DNS events are attractive to defenders because they are lightweight, but they are also easy for malware to blend into ordinary host activity. A successful attacker often does not need to make noisy connections immediately, because repeated resolution attempts can already expose staging, callback discovery, or infrastructure fallback logic.

Failure mechanism: Malicious processes abuse name resolution as a low-noise discovery and reachability channel, then repeat lookups until they find live infrastructure or a working control path.

Impact: If you miss that pattern, you can overlook early command-and-control behaviour, underestimate the scope of compromise, and lose the chance to contain the host before later exfiltration or lateral movement begins.

Practitioner Guidance

What to verify: Treat the process name, parent-child process chain, and domain reputation as the first triage set. If the process is unexpected for that asset or user role, assume the DNS event is worth correlation rather than dismissal.

What to measure: Track repeated failures, query bursts, and unusual domain diversity from the same endpoint. Those signals are often more useful than a single suspicious lookup because they reveal behaviour patterns that normal applications rarely sustain.

Decision rule: If Event ID 22 aligns with an unusual process and an uncommon domain pattern, escalate to endpoint review and containment. If it matches a known application path, use the event as supporting context, not proof of compromise.

Practitioner takeaway: Event ID 22 is most valuable when you use it to connect DNS behaviour back to process intent, because the attack signal usually lives in repetition, context, and inconsistency rather than in one lookup alone.

Related resources from NHI Mgmt Group

• Which attacks show up in Event ID 4624?
• Which attacks show up in Event ID 4648?
• Which attacks show up in Event ID 4625?
• Which attacks show up in Event ID 4719?