How To Easily Analyze Your Sysmon Logs

Windows Registry serves as the hub of all configurations on a typical Windows-based system. Be it services, applications, extensions, or all individual configurations, the registry holds it all. It’s why this hierarchical database serves to be one of the most fruitful artifacts during forensic analysis.

In this article, we’ll explore how Microsoft Sysmon, the Sysinternals-based logging utility, can be used for registry log analysis. It generates logs with several event IDs depending on the action performed in the registry. These logs can be massive; luckily Gigasheet has been built to handle datasets of massive size. Let’s first see a few logs in action.
‍

Registry Events in Sysmon

Sysmon can be used to log almost all system activity to log files in Windows. It includes Registry-based events as well. What does it log specifically in those events? Here’s a quick breakdown of a sample log:

RuleName: Sysmon events can be assigned rules which can further be used for event analysis using a SIEM, Event Viewer, or Gigasheet! We’ll get back to filtering logs based on rule names when we get down to analyzing these logs.

Process Information: It includes the ProcessId and Image of the process which launched this particular action on the system. In this case, it’s svchost.

TargetObject: This is the heart of the log - the actual object which was added or deleted. Depending on the event, we might see more data in these logs but that’s for the next section!  

Now, like I said, these events are logged based on the exact action. As such, Registry-based logs in Sysmon are divided into three event IDs:

Event ID 12: Object Create and Delete

This includes all objects (keys, values, etc.) which are created or deleted in the Registry. This is extremely handy if we wish to monitor creation of specific registry keys or modifications which are usually performed by threat actors to compromise the system.

Event ID 13: Value Set

This event includes all operations related to values being set in the registry. Simple as that.

Event ID 14: Key and Value Rename

Lastly, this event ID is used to log all operations related to rename operations in the registry.

If you’re looking for a handy guide on how to set up Sysmon for Registry analysis, take a look at the official documentation by Microsoft.

Set up Sysmon on your system? The default configuration isn’t the best to monitor your system with. It includes the bare minimum to make sure the driver operates. A much better version of the Sysmon Configuration is released by Florian Roth or SwiftOnSecurity.

Configured? Start making some noise on your test system by opening a few windows, spawning a few applications, and whatnot. You can now find the Sysmon log file under the standard file path: C:\Windows\System32\winevt\Logs\.

Pick up the log file and pass it on to Gigasheet by heading over to the Your Files page. That’s it. Gigasheet will take over the upload, the processing, and parsing of the file. Within a few seconds, you should be ready to analyze the log file.

Detecting Registry-based Attacks Using Sysmon

We’re done with the setup. Let’s get to the juicy bits where I’ll first perform an attack* and later see how we can detect that using Sysmon and Gigasheet!

*Most of these attacks are performed using helpful test utilities like the APT Simulator by Florian Roth or the Atomic Red Team project by Red Canary

Run Keys

Run keys (Run, RunOnce, and RunOnceEx) are typically used to execute programs at a user or system’s logon. Attackers can utilize these keys to execute their tools and persist malware across reboots. To get started with detecting run key modification, let’s filter our logs to the three event IDs we previously discussed – 11, 12, 13.

I’ve just filtered my dataset down to ~3K rows from a whopping ~190K logs. Moving forward, there are a few useful columns:

• TargetObject (which contains the target registry key)
• RuleName (depending on your configuration, this is the rule which was triggered on the log itself)

Since we’re talking about Run keys, the MITRE ATT&CK ID for the technique is T1547.001. We can also search Runkey in the RuleName field to see if the rule has triggered in our log dataset or not. A simple AND filter should work here.

That’s it – 35 rows. Now, some of these names appear to be quite common. However, we’ll have to take a look at the assigned value to say for sure. The values for the keys are in the Details column. Let’s move the columns a bit closer for our analysis. Two logs stick out – one references command prompt and (attempts to) downloads a binary to disk and other uses PowerShell to set the RunOnce key (with what appears to be a payload from GitHub).

Click to expand

Let’s also flag them as Bad so we don’t lose track of our analysis.

To continue your analysis, you can now look into the Details of the PowerShell command we saw earlier. If you’ve worked with the Atomic Red Team project, you’re likely going to ping your red-team for context into this activity. Both logs reference the project one way or another and are typically used for performing quick security tests.

Gigasheet also allows you to run regular expressions on your log files without stressing your system. For instance, we can run an expression to find URLs in our log file. Here it is:

https?:\/\/(www\.)?[-a-zA-Z0-9@:%._\+~#=]{1,256}\.[a-zA-Z0-9()]{1,6}\b([-a-zA-Z0-9()@:%_\+.~#?&//=]*)

Simply enter that in the top search field and enable regular expressions. This expression will also trigger on our two suspicious logs. URLs in the Runkey? Sounds suspicious for sure!  

Looking for test cases to perform by yourself? Take a look at the Atomic Red Team’s coverage of Registry Run keys here.

Scheduled Task Executing from Registry

This is an interesting one; the registry can be used as a container for threat actors to store their payloads for execution. In this particular attack, we’ll be hunting for registry modification where strange payloads for e.g. encoded strings, binary data, etc.

Let’s filter to SetValue (ID: 13) events again and see what events we can uncover from our second dataset. We have a little over ~2500 logs to review here. This doesn’t sound feasible at all. Since we’re looking for scheduled tasks, let’s also review the TaskScheduler log channel (which has to be enabled on Windows systems).

Filtering on the event ID 106 (Task Registration), we get just 30 logs from the system. Reviewing the list of logs, two logs are particularly close to our timeline and the name strikes me as well.

Falshupdate? That’s clumsy. SystemUpdate might be a legitimate task here but we need to validate that information. Moving forward, let’s search the two terms in Sysmon logs. Sadly, we don’t find traces of it with our filter. Perhaps it didn’t write to the registry at all? Removing the filters, we see:

Suspicious sysmon events

That’s definitely suspicious. It shares a lot of insight into the task itself which we can now use to pivot into performing extensive host forensics. Now, searching for, SystemUpdate, we find another log:

This task does indeed reference the registry and an encoded base-64 payload as well. Why didn’t it trigger on our Sysmon logs though? Valid question – Sysmon depends on the configuration which is used at the time of its installation. If the configuration doesn’t monitor certain paths in the Registry, we’ll have no visibility of the keys (as that happened in my case).

If you wish to monitor all hives, you should update your configuration. However, registry operations are too frequent and can cause a flurry of false positives in your environment.

Security Service Modification via Registry

We’ve already talked about how the Registry is practically the heart of Windows – in that it holds all configurations responsible to make the systems work together. This includes all security tooling deployed on the system as well. Threat actors have been known to disable or modify security services to bypass checks, execute malware, and exfiltrate data from the systems.

Let’s catch them in the act using Sysmon again.

Windows Firewall

Most small businesses and home computers rely on the host Windows Defender firewall to defend against network threats. It’s quite easy to disable the firewall with administrative privileges or add rules in it to enable protocols like RDP, SMB, etc.

We’ll start with two event IDs this time round – 12 (key creation and deletion) and 13 (SetValue). If you’re looking for quick analysis, the Find in File feature is your best chance. It quickly goes over the log file and highlights matches. We’ll first search for the word, Firewall.

There’s four. Sysmon logged one event where the attacker tried to disable the Windows Firewall for the Public profile. We can see the value is set to 0 thrice and to 1 (enable) just once. Perhaps the actor was attempting to test if the firewall was disabled or not.

We can also see the RuleName field populated with T1089 which corresponds to Impair Defenses: Disable or Modify Tools in the MITRE ATT&CK framework. Since Sysmon allows you to configure rules by yourself, you can always tune these rules and add in more detections based on your own research.

Windows Defender

Take a peek at the last screenshot again; there’s an attempt to disable Defender. The DisableAntiSpyware key is set to 1 which effectively disabled Defender on the system. If we search for the keyword, Disable, using the global search, we can see there’s one other log referencing DisableRealtimeMonitoring. It might as well be an attempt to enable the control. We’ll have to dig into the value of the key and the time (to reference it with other attempts performed by the adversary).

That’s not all. There are several other registry keys which can be used to disable or modify the capabilities of Defender on a system. Here are a few Sigma rules which cover those keys:

• Disabling defender in Registry
• Excluding Programs in Defender by modifying Registry
• Disabling Defenders’ Tamper Protection
• Disabling real-time monitoring by Defender

What's Next?

It’s time for you to get your hands dirty. Gigasheet is free for use! Do you have Sysmon logs to dissect? Flow logs to go through? We’ve got out-of-the-box integration with most file types to support you in your quest to protect your networks.

Get started by signing up to our platform today! It's free.