Sysmon for beginners: the Windows visibility you are missing

Out of the box, Windows tells you surprisingly little about what runs on it. The Security log can record new processes, but only if the right audit policy is on, and even then you get no file hashes and no link between a process and the network connections it makes. When an investigation reaches a machine without good telemetry, the question "what actually ran here?" often has no answer.

Sysmon fills that gap. It is a free Microsoft Sysinternals tool that installs as a service and writes detailed events to the Windows event log: processes with full command lines and hashes, network connections, DNS queries, file creations and more. This guide explains what it records, how to install it with a configuration that keeps the noise down, and which events you will read most often.

What Sysmon adds to Windows logging

Sysmon does not replace an EDR. It does not block anything and it raises no alerts on its own. What it gives you is consistent, detailed telemetry that you can search locally or forward to a SIEM:

Process creation with context: the full command line, the parent process and its command line, the user, and hashes of the executable.
A process ID that survives: every process gets a ProcessGuid, which lets you follow one process across many events even when Windows reuses process IDs.
Network connections tied to processes: which program connected to which IP address and port.
Activity that the built-in logs miss: DNS queries per process, file creation, registry changes, named pipes and WMI event subscriptions.

That is why many detection rules and threat-hunting queries are written for Sysmon events, and why it is still common on servers and workstations without a commercial EDR.

Install it with a configuration

Sysmon's behavior is driven by an XML configuration file. Installing it without one logs only the basics. Writing a configuration from scratch is a project in itself, so most teams start from a well-known community configuration and adjust it:

SwiftOnSecurity sysmon-config: a single, heavily commented file that is a good first read.
sysmon-modular by Olaf Hartong: a modular configuration mapped to MITRE ATT&CK, with prebuilt variants of different verbosity.

Download Sysmon
Get it from the official Sysinternals page. The current version runs on Windows 11 and later, and on Windows Server 2019 and later. Use only the Microsoft download, never a copy from another site.
Pick and review a configuration
Download one of the configurations above and read it before using it. Pay attention to what it excludes: anything excluded is never logged, and exclusions are where a real attacker can hide.
Install from an elevated prompt
Open PowerShell as administrator in the folder that holds both files:
install-sysmon.ps1
```
.\Sysmon64.exe -accepteula -i .\sysmonconfig.xml
```
Check that events arrive
Open Event Viewer and go to Applications and Services Logs → Microsoft → Windows → Sysmon → Operational, or read the newest events from PowerShell:
read-sysmon.ps1
```
Get-WinEvent -LogName "Microsoft-Windows-Sysmon/Operational" -MaxEvents 10 |
    Select-Object TimeCreated, Id, Message
```
Update the configuration later
When you tune the configuration, apply the new file without reinstalling:
update-config.ps1
```
.\Sysmon64.exe -c .\sysmonconfig.xml
```

Test on a few machines first and watch the event volume. A configuration that is too verbose can flood your SIEM and its bill; one that is too strict hides the activity you installed Sysmon to see.

The event IDs you will read most

Sysmon defines close to thirty event types. These are the ones that come up in almost every investigation:

Event ID 1, process creation: the most valuable event. Read Image (what ran), CommandLine, ParentImage and ParentCommandLine (what started it), User and Hashes.
Event ID 3, network connection: Image, DestinationIp, DestinationPort and, if resolved, DestinationHostname. Many configurations log it only for selected programs because it is noisy.
Event ID 7, image loaded: a DLL loaded by a process. Useful for specific detections, very noisy if logged broadly.
Event ID 8, CreateRemoteThread: one process starting a thread inside another, a classic sign of code injection.
Event ID 10, process access: one process opening another. Access to lsass.exe by an unusual program is a common sign of credential dumping.
Event ID 11, file create: a file was created or overwritten, such as a new executable in a user's temporary folder.
Event IDs 12, 13 and 14, registry events: keys and values created, changed or renamed, which covers many persistence tricks such as Run keys.
Event ID 22, DNS query: the domain a process looked up, with the answer. It links a process to a domain name even when the connection itself goes to a shared cloud IP address.

The Sysmon page on Microsoft Learn describes every event type and its fields.

Reading a process creation event

Suppose a user reports that a document "did nothing" when they opened it. On their workstation you find this Sysmon event ID 1 (shortened):

sysmon-event-1.txt

UtcTime: 2026-10-14 09:42:17.310
Image: C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe
CommandLine: powershell.exe -nop -w hidden -enc SQBFAFgAIAAoAE4AZQB3AC0ATwBi...
ParentImage: C:\Program Files\Microsoft Office\root\Office16\WINWORD.EXE
User: CONTOSO\j.silva
Hashes: SHA256=...

The highlighted lines are the story. Word started PowerShell, and PowerShell was told to hide its window (-w hidden), skip the user's profile (-nop) and run a Base64-encoded command (-enc). Word has no business starting PowerShell, and legitimate scripts rarely hide themselves this way. The next step is to look for event ID 3 or 22 from the same ProcessGuid to see where that PowerShell process reached out, and to decode the command.

Getting Sysmon events into your SIEM

Reading events machine by machine does not scale. Forward them to a central place:

Microsoft Sentinel: collect the Microsoft-Windows-Sysmon/Operational channel with the Azure Monitor Agent and a data collection rule. The events land in the Event table.
Other SIEMs: Windows Event Forwarding, or the vendor's own agent, can collect the same channel.

A first query in Sentinel that lists recent process creations from Sysmon:

sysmon-process-creation.kql

Event
| where TimeGenerated > ago(1h)
| where Source == "Microsoft-Windows-Sysmon" and EventID == 1
| project TimeGenerated, Computer, RenderedDescription
| take 50

Extracting individual fields from the EventData column takes more work, and the Sentinel community publishes parsers for it. If your organization already runs Microsoft Defender for Endpoint, its own tables, such as DeviceProcessEvents, cover much of the same ground without Sysmon.

Why it matters for a SOC analyst

Sysmon teaches you to think in processes: what ran, who started it, what it touched and where it connected. Even if your organization uses a commercial EDR, the same questions and much of the same vocabulary apply. When you meet a host with no EDR, checking for Sysmon is one of the first things to do, because it may be the only record of what an attacker did there.

Attackers who prefer living off the land leave few files behind, but they cannot avoid creating processes, and processes are exactly what Sysmon records. That makes it a solid foundation for threat hunting.