System Monitor

What is Sysmon?

System Monitor (Sysmon) is a free Microsoft Sysinternals service and device driver that records detailed endpoint telemetry, process creations, network connections, file and registry activity, and more.

The renamed binary, seen two ways4688 · PROCESS CREATEDNew Process Name: c:\temp\chrome.exeSYSMON EVENT ID 1 · SAME LAUNCHImage: c:\temp\chrome.exeOriginalFileName: procdump.exeSHA256: 337b1f… known toolParentCommandLine: powershell -enc JAB…the rename changed nothing
Enhanced Visibility

Modern auditing

Since NT 3.1, Windows has always provided auditing, especially for changes to the system. Each area of visibility needs its own switch: an audit policy for process creation, SACLs on each folder and registry key you want watched, Windows Filtering Platform auditing for network events that arrive in overwhelming volume. Whole categories, DNS by process, WMI persistence, named pipes, module loads, have no practical built-in auditing at all.

Sysmon, released by Microsoft's Sysinternals team in 2014, replaced that patchwork with one system service and driver, one XML configuration, and a dedicated event channel carrying about thirty event types. Process creation, an area increasingly relevant for security, is only one slice of it. EventSentry monitors all Sysmon events, with the full context of the system, and turns key patterns into email alerts and detailed reports.

Windows built-in auditing versus Sysmon
CategoryBuilt-in auditingSysmon
Process creation4688 + policyEvent ID 1: hashes, OriginalFileName, parent cmdline
Network connections5156 via WFP, very noisyEvent ID 3, per process
DNS queriesresolver logs, host-levelEvent ID 22, per process
File activity4663 + per-folder SACLsEvent IDs 11, 15, 23, 26
Registry changes4657 + per-key SACLsEvent IDs 12 to 14
Module and driver loads--Event IDs 6, 7 + signatures
Cross-process accessnot practicalEvent IDs 8, 10 + call trace
Named pipes--Event IDs 17, 18
WMI persistence--Event IDs 19 to 21
Payload swap after creation--Event ID 25
Sensor tamper protectionn/aprotected process, v15+
The facts
~30
event types from one service

Sysmon is one sensor where built-in auditing is a patchwork of switches

Before Sysmon, each kind of visibility had its own mechanism: an audit policy for process creation, SACLs on every folder and registry key you wanted watched, Windows Filtering Platform auditing for network events. Sysmon replaced the patchwork with one signed service and driver, configured by one XML file, writing about thirty event types, spanning processes, network connections, files, the registry, DNS, WMI, named pipes, and drivers, to a dedicated event channel your existing forwarding already carries.

MonitoringEventSentry monitors the whole channel, not just process events, and any rule match can send an email alert, trigger an automated response, or both, configured per rule.
1 field
that unmasks renamed tools

Rename procdump.exe to chrome.exe and name-based rules go quiet

Renaming the binary is the first thing an operator does, because built-in process auditing records only the path the attacker chose. Sysmon's process-creation event adds OriginalFileName, read from the executable's own version resource, plus MD5, SHA-256, and IMPHASH hashes and the parent's full command line. The tool can be called anything on disk; the telemetry still says procdump, and the hash still matches the known tool.

Monitoring EventSentry's filter rules can match on OriginalFileName and hash as well as the on-disk name, so a rename changes nothing: the match still emails the right team with the event attached.
0x1010
the handle mask that means credential theft

Credential dumping is one OpenProcess call, and Event ID 10 watches it happen

Stealing passwords from LSASS memory never creates a process, so process auditing sees nothing at all. Sysmon Event ID 10 records the handle open itself: which process touched lsass.exe, with what access mask, through what call stack. The masks are nearly fingerprints, 0x1010 for Mimikatz-style reads, and Microsoft's own detection guidance is built around catching this exact sequence.

Monitoring EventSentry can be configured to filter Event ID 10 against an allowlist of your AV and EDR agents. Anything else opening that handle emails the on-call admin instantly, and can trigger an automated account disable if the rule is armed.
12–21
Sysmon Event IDs · registry, pipes, WMI

Bad actors will hide persistence data in registry keys, WMI subscriptions, and named pipes, all the places built-in auditing barely reaches

The quiet autostarts live outside the process log: a run key, a scheduled WMI event consumer, a named pipe waiting for its operator. Built-in auditing needs a SACL on every registry key you thought to watch and has no practical story for WMI or pipes at all. Sysmon covers them as first-class events: registry create, set, and rename (Event IDs 12 to 14), pipe creation and connection (17 and 18), and the WMI filter, consumer, and binding trio (19 to 21).

MonitoringEventSentry provides full visibility into common persistence areas like new services, new registry keys, new browser extensions and new scheduled tasks.
22
Sysmon Event ID · DNS with a named requester

Command and control starts with a lookup, and Sysmon names the process that asked

Resolver and firewall logs say the host queried a domain. Sysmon Event ID 22 says powershell.exe queried it, under which user. That turns a reputation hit on a domain into a process and an account, not just a machine. Beaconing detection, DGA spotting, and newly-registered-domain rules all arrive with an owner attached before the investigation starts.

MonitoringEventSentry can monitor Event ID 22 for anomalies and alert with process, user, and host named, and full reporting.
3
Sysmon Event ID · connections with an owner

Firewall logs say an IP talked to an IP; Event ID 3 says which process did it

Sysmon's network connection event links every TCP and UDP connection to the process that made it and the user it ran as, with hostnames and ports on both ends. The built-in alternative, Windows Filtering Platform auditing, produces overwhelming volume with far less context. Event ID 3 ships disabled by default, so it costs nothing until you scope it to the ports and processes you care about.

MonitoringEventSentry joins Event ID 3 with flow records, so a suspicious destination becomes an email alert naming the owning binary, with an automated block-IP available per rule.
25
Sysmon Event ID · process tampering, v13+

Process hollowing exists to make process-creation logs lie

Hollowing and herpaderping launch a legitimate binary, then swap its code in memory. Every process-creation record faithfully describes the decoy. Event ID 25 was added precisely for this: it fires when a process image is changed after creation, flagging the moment the clean-looking svchost becomes something else. The technique's entire purpose is defeating the process log.

MonitoringEventSentry treats Event ID 25 as high severity by default. Legitimate software almost never rewrites its own image, so even the email-only configuration is a strong early warning; automated response is a per-rule choice.
ATT&CK
community configs, mapped and maintained

You do not have to design the configuration alone

The hardest part of Sysmon is deciding what to include and exclude, and the community already did the work in public. The sysmon-modular project maintains a modular configuration mapped to MITRE ATT&CK techniques, and the widely deployed SwiftOnSecurity baseline encodes years of tested excludes for common enterprise software. Starting from either means your first week of telemetry is signal, not a firehose.

Monitoring EventSentry provides a default configuration that is based on a template by SwiftOnSecurity.
Sysmon + EventSentry

Sysmon records. EventSentry monitors, alerts, and responds.

Sysmon deliberately stops at telemetry: it does not analyze or notify. EventSentry monitors the event stream, evaluates every event on arrival, and turns matches into email alerts and automated responses, with as much or as little automation as you want, per rule.

Every event type, one monitored channel

EventSentry monitors the full Sysmon event log, process, network, DNS, files, registry, WMI, pipes, and drivers, via the EventSentry agent, with per-host reporting health so a quiet sensor is visible immediately.

Email alerts with the event attached

A rule match notifies the right team, on-call, SOC inbox, or both, with the process, user, host, and raw event in the message. Thresholds, digests, and quiet hours keep the volume reasonable.

Automated responses where you arm them

Per rule, a match can also act: disable the account, isolate the host, stop the process, or run your script, each with simulation mode, approval gates, and rollback. Alert-only is always a valid configuration.

FAQ

Questions teams ask during an evaluation

System Monitor (Sysmon) is a free Windows system service and device driver from Microsoft's Sysinternals suite. Once installed, it stays resident across reboots and records detailed system activity, process creations with full command lines and hashes, network connections, driver and DLL loads, file and registry changes, DNS queries, and around thirty event types in total, to a dedicated Windows event log channel. What it records is controlled by a single XML configuration file, and the events travel to a SIEM over the Windows Event Forwarding you already run. Sysmon deliberately does not analyze its own output; it is a high-fidelity sensor, which is exactly why it pairs with a monitoring layer like EventSentry.

Because 4688 covers one event category, and the attacker playbook adapted to it. Renamed tools defeat name and command-line rules (Sysmon's OriginalFileName and hashes don't care). Credential theft from LSASS never creates a process (Event ID 10 records the handle open). Persistence lands in registry keys and WMI subscriptions (Event IDs 12 to 21). DNS beaconing produces no process event at all (Event ID 22 names the requester). 4688 remains valuable; Sysmon adds the other categories around it.

No, Sysmon is a free Microsoft Windows system service and device driver. You can think of Sysmon as an upgrade to native Windows logging. Sysmon does not include any EDR functionality. EventSentry gives you is deep visibility with filter rules, retention, and email alerting and automated responses based on Sysmon events.

Start from a community baseline rather than a blank file: sysmon-modular by Olaf Hartong is organized by MITRE ATT&CK technique, and the SwiftOnSecurity config is a proven general-purpose starting point. Deploy to a pilot ring, watch volume per event ID for a week, then tune excludes for your noisy line-of-business software. EventSentry monitors the resulting event telemetry directly, and the EventSentry Web Reports shows exactly which hosts are reporting which event IDs.

It is much harder than it used to be. Since version 15, Sysmon runs as a protected process, so even administrator-level code can't simply terminate or inject into it. The remaining tampering paths, driver unloads, config rewrites, and service stops, are themselves observable: Sysmon logs its own service-state changes (Event ID 4) and configuration changes (Event ID 16), and a host that stops reporting is its own alert. Monitor the monitor, and blinding attempts become email alerts too.