Sysmon is free (https://learn.microsoft.com/en-us/sysinternals/downloads/sysmon#usage), takes a little work to deploy and configure, but if you want to add some data sources to help with IT troubleshooting and root cause investigation.

Samples below show data from a default and quick setup on a sample machine. While this contains a lot of entries, the data shown only spans a couple of weeks.

Typically this is enough for either troubleshooting or investigating.  An advanced or ideal next step after deploying Sysmon would be for organizations to ship this logging elsewhere and retain it (90 days would be about right), in case of an incident.  If logs on a host are overwritten or deleted, the data will still be accessible. 

Having that capability is important in intrusions because without knowing exactly how the threat actor got in and what they did, you could inadvertently leave an opening without working down to root cause of the incident.

Types of entries in Sysmon:

Especially for incident response and root cause determination-these are crucial.  As a systems admin, you don’t need to go in and look at the logs necessarily.  Ship ‘em and save ‘em.  As an investigator, the logs will contain key items (sample below) of activity that can inform as to the actions on the system. Check the known timeline or keywords to discover things like: files created, processes created, network connections, DNS queries. They can be key pieces of evidence to start sketching out the timeline of events on a host.

When you open Sysmon logs with the Windows Event Viewer, you can filter by
the items below.  Most likely, you will
start with the date of any known indicators cropping up.  

A handy filter for IR is the preset timespans:

There is also an option to manually edit an XML query-maybe you’ll develop some favorites to paste into here (or script the query without using Event Viewer).

Note that search in Windows Event Viewer is not case sensitive, so if you do not capitalize a name, you will still get results.  Below is a search for “Wave” that returned all values of “wave”, whether upper or lower case.

One of the most interesting rules and entries relates to .exe file creation as shown below. 

Executable files created on a system during a relevant timeframe may spell out malicious or suspicious actions on a host. 

Other entries of note for Incident Response include “Registry value set”.  Software installation, malware activity, system manipulation can show up in the rich database  of the Registry.  Values that were created or changed during the incident should be reviewed to glean additional context and information relevant to the event.

DNS queries are also logged by Sysmon.  DNS queries can show things such as users browsing to websites, suspicious processes beaconing out, or unexpected connections to outside resources. Is the query normal, expected activity or does something stand out?

If it stands out, is it a possible IOC that can be used in a centralized EDR to query for other machines performing the same communications?  Is this valuable intelligence to someone? 

DNS Query details show the resource queried and the XXX “image” performing the query.  Is malware.exe reaching out to iambeaconing[.]biz? 

Event ID 3 in Sysmon tracks network connections.  Again, reviewing this information for suspicious connections, ports, destinations and processes can reveal suspicious and malicious activity.

Were devices connected during the event?  Look for this particular Registry value- “device connected or updated”. Did someone connect a USB drive prior to possibly copying intellectual property or executing a file?  Finding all of this information in the Sysmon log makes the picture more clear and efficient versus  switching back and forth between multiple data sources.  This will also add context to the timeline you’re building from one log

An additional indicator of activity is the termination of processes.  Did the Windows Defender process terminate during an incident?  Filter through the known time period of the event to cut down on the noise and look at terminated processes specifically.  The one below is just that of an annoyed user (me!)  stopping a process that was hogging limited resources.  Looking at your own Sysmon entries over and over will help you learn normal from abnormal. It also helps pass the time while otherwise cooped up with nothing else to do. But really-take the time to experiment, download some files, fire off an executable, stop a service and see how those actions show up in Sysmon!

Thanks for coming along for the ride.