Sysmon

Sysmon is a system service and kernel driver that records what a machine does and writes it to the event log. Every process that starts, with its full command line and the command line of its parent. Every driver and DLL that loads, with hash and signature. Every network connection, DNS query, registry write, named pipe and file creation, if you ask for them. It stays resident across reboots, starts early enough in boot to see kernel-mode malware, and runs as a protected process so ordinary user-mode tools cannot stop it.

It belongs to the same family as Process Explorer and Autoruns, but where those show you the machine right now, Sysmon is a recorder. The built-in security audit can log process starts too, but by default without command lines and without parent context. This tool is what defenders install to get the story of an intrusion after the fact.

Twenty-nine event types in one log channel

Sysmon writes everything to a dedicated channel under Applications and Services Logs, with timestamps in UTC rather than local time, which trips up newcomers reading an incident timeline. Each event type has a numeric ID, from 1 (process creation) through 29 (executable file detected), plus 255 for the service’s own errors. Event 4 reports the service starting or stopping and event 16 records every configuration change, and neither of those can be filtered away, which is the point.

Two fields make the whole log usable. ProcessGuid is a unique value per process, so events can be tied together even after the system recycles a process ID, and LogonGuid does the same for a logon session. Without them you would be matching on PID and hoping.

Process creation and injection

Event ID 1 is the one that earns Sysmon its reputation. A new process, its image path, the full command line, the user, the parent process and the parent’s command line, plus a hash of the executable. SHA1 is the default hash, and you can add MD5, SHA256 and IMPHASH (a hash of the import table that survives recompilation) at the same time by setting HashAlgorithms to an asterisk. A PowerShell launched by a Word document with an encoded command shows up as exactly that, which is the pattern half of all detection rules look for.

Around it sit the injection events. ID 8 fires when a process creates a thread inside another one and records the start address and module. ID 10 fires when a process opens a handle to another process, which is how credential dumpers reach into lsass.exe. ID 25 catches process hollowing and similar image-swapping tricks. And ID 10 will bury you if you enable it without exclusions, because every diagnostic tool and antivirus engine on the box opens processes constantly.

Network connections and DNS, and why they are off by default

Event ID 3 is where Sysmon logs each TCP or UDP connection with the owning process, the addresses and ports at both ends, and the resolved hostnames. It is disabled unless your configuration turns it on, because an unfiltered workstation produces thousands of these an hour. Event ID 22 logs DNS queries per process, whether they succeed or fail, which is a cheaper way to catch a beacon calling home than logging every connection.

One setting to know. DnsLookup is on by default and makes the driver reverse-resolve every address it logs, which slows logging and adds traffic. Turn it off on anything busy.

Note that these events record that a connection happened and who made it, not what went over it. For the payload you still need a packet analyzer running alongside.

Files, the registry and the deleted-file archive

ID 11 logs file creation and is normally scoped to the places malware drops things, such as Startup folders plus temp and download directories. ID 15 is more specific and catches files that arrive with a Zone.Identifier stream, the mark of the web a browser attaches to downloads, and hashes them. IDs 12 through 14 cover registry key creation, value writes and renames, which is how you watch the Run keys and other autostart locations that Autoruns enumerates by hand.

The deletion events are the unusual part. ID 26 simply logs that a file was deleted. ID 23 goes further and copies the deleted file into an archive folder at the root of the volume, protected by a System ACL so you need SYSTEM rights to read it.

That means a dropper that runs and deletes itself is still sitting there for you to pull apart. It also means the folder grows without limit under ordinary use, so scope the rule to executables or specific processes, or use ID 26 and accept losing the sample.

The configuration file is the real product

Installed with no configuration, Sysmon logs process creation hashed with SHA1 and almost nothing else. Everything useful comes from an XML file with an EventFiltering section and one tag per event type. Each tag carries onmatch=”include” or onmatch=”exclude” and a list of field rules. Exclude rules always win over include rules for the same event, rules on the same field OR together and rules on different fields AND together, and a RuleGroup wrapper lets you override that with an explicit groupRelation.

There are sixteen match conditions, from is and contains through begin with, end with, less than and image, the last of which matches a bare filename against a full path. Give a rule a name attribute and the RuleName field in every resulting event tells you which rule caught it, which is invaluable when tuning.

Almost nobody writes this from scratch. The community starter configuration is a single heavily commented file that excludes known-good noise and includes the suspicious patterns, and a modular community project breaks the same idea into hundreds of small files you assemble per environment. Start with one of those, read it, and then cut. One quirk when you edit. A bare ampersand breaks the XML parser, so write it as the escaped entity.

Updating live, and why removing it can fight back

Updating a running configuration is one command, the -c switch followed by the file, and it applies immediately with no reboot. Running -c alone dumps the active configuration, -s prints the full schema with every event’s fields, and -u removes the service and driver. Reload does occasionally misbehave, and there are reports of the service pinning a CPU core and dropping file events after a configuration change until a restart, so watch event 255 after each push.

Removing Sysmon is where people get stuck. Because the service runs protected, it refuses to be stopped by tools that would stop anything else, and reports of “access denied” on uninstall are common on the forums. The answer is to run the uninstall with the same executable name that installed it, add force if components are missing, and run it as SYSTEM through PsExec if an administrator prompt is refused.

If an earlier copy was installed under a different filename, you now have two instances, and your rules will appear to be ignored until the stray one is removed.

What it needs alongside it

Sysmon on a single machine is useful to a forensics-minded person with Event Viewer open. Across a network it needs a collector, either the built-in event forwarding or a SIEM agent, because a tuned configuration still produces far more than anyone reads by hand. Budget for the volume, since a default configuration can triple the log traffic a workstation sends.

It also pairs with rather than replaces the standard security audit, which still owns logons, privilege use and policy changes. And it has no interface of its own. If you want to watch connections in a live window rather than read them from a log afterwards, a per-application firewall with a connection history is the better tool for that job, and the two coexist without trouble.

Conclusion

Sysmon is for blue teams, incident responders and anyone building a home lab who wants to see what a machine actually did rather than what it is doing now. Paired with a good configuration and a place to send the events, it turns an ordinary endpoint into a witness that remembers command lines, parents and hashes long after the process is gone.

It asks for effort in return. You will spend more time in the configuration file than in the tool, the first week of logs will be mostly noise you have to learn to exclude, and nothing in it will ever tell you something is wrong. Accept that division of labour and there is no cheaper way to record what happened on a machine.