What is Sysmon?
Sysmon is part of the Microsoft Sysinternal suite and logs extended system activity to the Windows event logs. Logged data includes network connections, file events, and process creation, such as loaded binary images. It provides a detailed view of your system. With the volume of data Sysmon can generate, you need to be careful not to overwhelm analysts.
Sysmon’s depth of provided data enhances your threat hunting and security program. Sysmon is a Windows system and device driver that you install as an operating system service, and that persists across reboots. Depending on how wide you want to expand your threat hunt or security monitoring program, you can also roll Sysmon out to an entire domain using Windows Group Policy settings. Sysmon stores logs in the Windows Event Logs.
Installing Sysmon On Windows 10
To start with Sysmon, you must first download the Sysmon binary from Microsoft’s Sysinternals website. If you’re using 64-bit like in this example, you’ll see Sysmon64.exe -accepteula -i. This setting loads the Sysmon service with the default configuration.
Viewing Sysmon Logs
Sysmon log data is stored within the Windows event logs if you go to Application and Services Logs/Microsoft/Windows/Sysmon/Operational. In the Windows event log, we can see that we’re getting process creation and process termination logged. The records shown here aren’t part of the standard Windows event log and can be very powerful, depending on your end goals.
Overview of Sysmon Log IDs
An important note in the image below is that these are the Sysmon default event codes. Event codes exist for process creation and termination, and network connections can be super powerful but also super loud if you don’t filter them down. You have things like event id six for when drivers are loaded. Other events can even get down to threads. As seen with event eight that covers CreateRemoteThread detected. You can look for process hollowing and some more advanced attack techniques. This situation is where Sysmon provides a ton of value because you could take a piece of malware, or you could take known TTPs from a given attacker and figure out what extended logging ids meet that given TTP. You even have things like DNS Queries, event id 22.
You can watch new content on the clipboard if you want to. While the unfiltered logging of this event would be loud. You can filter down to specific processes and understand what operating system processes usually write to the clipboard. You might also look at processes or applications launching out of suspicious directories. So even if you’re looking for things like clipboard activity, you can use Sysmon to go down into that event or behavior on this system. A lot of different attack groups heavily use tactics that generate WMI 19, 20, and 21 event ids. You have the ability here to monitor WMI at the host level at a very granular level. Keep in mind not all Sysmon events are enabled by default.
Understanding Sysmon’s Default Config
We’ve now loaded Sysmon, but not all settings are on by default. If you use the Sysmon -c flag, this will show you the currently logged configuration. The default configuration doesn’t have network monitoring turned on. This default setting is likely because network traffic can be noisy, especially if you have many applications using network resources. Advanced features like image loading are also disabled.
The image below shows the default settings enabled by SysMon. By default, DNS lookups log DNS resolutions. Depending on the quantity of DNS requests in your environment, this might be another setting you want to tweak to achieve the necessary system performance level.
Getting Started Writing Sysmon Rules
If the default configuration doesn’t fit your environment well and you want to create a custom config, you can do this Sysmon -? config flag. This config usage information is an excellent way to either get started or a great way to look up as you’re building out the config. We’re going to show a straightforward config to help you get started.
Writing Sysmon Rules to Detect Malicious Network Activity
Let’s say we wanted to turn on network connection monitoring, and we’re going to turn it on for traffic that’s not associated with a process called firefox.exe or iexplore.exe. From that config page we showed from the man page, we have to build the schema to look for network activity not associated with firefox.exe or iexplore.exe.
We’ve added a straightforward rule here and have a rule group in this group relation. It says “or” so we’re saying if it’s firefox.exe or iexplore.exe. We are looking for paths or process names that end with firefox or iexplore. If we go ahead and enable this, you’re going to use a Sysmon 64 -c, but this time, you’re going to give it the new configuration file. You’ll see on the right side of the image below now that network monitoring is enabled. You see our created rule at the bottom of this command prompt. So we know that this rule took, and we know it’s there.
Example Sysmon Rule
We used an example and stood up just a simple python HTTP server. In this case, what you can see here if you look at the image is C:\Users\test\AppData\Local\Programs\Python\Python310\python.exe. The rule we created matches the python.exe at the end. Now in the Sysmon logs, we have the source IP, destination IP, and hostnames, and we know the process that connected this. With that rule, we found a python simple HTTP server instance on the local machine. This rule is super powerful straight out of the box for potentially finding something that would be a weird network connection.
Depending on the context of your machine and what users do on the device, the number of different processes, and the variants from user a to user b in the systems they use, you’ll have to take that into account, especially as you design the Sysmon config for your enterprise. You might say, well, our design team uses photoshop, and we know photoshop makes a lot of internet connections out. So you might say for the Sysmon config that we’re sending to the graphic design team, we’re going to take photoshop out of the logs to reduce noise and not take up as much disk space or logging infrastructure bandwidth.
In Conclusion
Today we shared a quick overview of Sysmon, including how to get started, what the default configs look like, and the basics behind creating Sysmon rules. In a future post, we’ll dive into more advanced rules and look at how to connect Sysmon to finding an advanced attacker’s behavior based on what we know about their tools. Thanks for taking the time to read this post. Let us know what you think and if you have any suggestions for future posts.
