This article is the first in a series on Sysmon threat analysis. All other parts of the series:
Part 1. Introducing Sysmon log analysis (we are here)
Part 2. Using data from Sysmon events to identify threats
Part 3. In-depth analysis of Sysmon threats using graphs
If you are engaged in information security, you will probably have to figure it out often in ongoing attacks. If you already have a good eye, you can look for non-standard activity in the raw raw logs - say, a PowerShell script running the DownloadString commandor a VBS script that pretends to be a Word file - just flipping through the latest activity in the Windows event log. But this is really a big headache. Fortunately, Microsoft created Sysmon, which makes attack analysis much simpler.
Want to understand the basic ideas behind the threats displayed in the Sysmon log? Download our WMI events guide as a spy tool and you will understand how insiders can quietly watch other employees. The main problem with working with the Windows event log is the lack of information about parent processes, i.e. one cannot understand the hierarchy of processes from it. In contrast, Sysmon log entries contain the parent's process ID, name, and the command line to run. Thank you, Microsoft.
In the first part of our series, we will see what can be done with basic information from Sysmon. In Part 2, we will take full advantage of parenting information to create more complex conformance structures known as threat graphs. In the third part, we will consider a simple algorithm that scans the threat graph to search for non-standard activity through the analysis of the “weight” of the graph. And in the end, you will receive a neat (and understandable) probabilistic method of detecting threats as a reward.
Part 1: Introducing Sysmon Log Analysis
What can help you understand the complexities of the event log? Ultimately - SIEM. It normalizes events and simplifies their subsequent analysis. But we don’t have to go that far, at least for the first time. In the beginning, to understand the principles of SIEM, it will be enough to try the wonderful free utility Sysmon. And she's surprisingly easy to work with. Way to go, Microsoft!
What features does Sysmon have?
In short, useful and readable information about the processes (see the pictures below). You will find a bunch of useful details that are not in the Windows event log, but most importantly, the following fields:
- Process ID (decimal, not hex!)
- Parent process ID
- Process command line
- The parent process command line
- File image hash
- File Image Names
Sysmon is installed both as a device driver and as a service - more details here. Its key advantage is the ability to analyze logs from several sources, correlate information and output the resulting values to one event log folder located along the Microsoft -> Windows -> Sysmon -> Operational path . In my own investigations of hair-growing Windows logs, I constantly had to switch between, say, the PowerShell logs folder and the Security folder, flipping through the event logs in a heroic attempt to somehow match the values between them. This is never an easy task, and as I later realized, it was better to immediately stock up on aspirin.
Sysmon also makes a quantum leap forward by providing useful (or as vendors like to say - effective) information to help understand the underlying processes. For example, I started a secret wmiexec session that simulates the movement of a smart insider within the network. Here's what you see in the Windows event log:
The Windows log shows some information about the process, but it is of little use. Plus process IDs in hex ???
A professional IT professional with an understanding of the basics of hacking should be suspicious of the command line. Using cmd.exe to subsequently run another command with redirecting the output to a file with a strange name - this is clearly similar to the command-and-control (C2) control and management software : in this way a pseudo-shell is created using WMI services.
Now let's take a look at the equivalent of a Sysmon entry, paying attention to how much additional information it gives us:
Opportunities Sysmon one screenshot: detailed information about the process in a readable form
you will not only see the command line, but the file name, the path to the executable application that Windows knows about it ( "Windows Command Processor"), the ID of the parent process, the command line is a parent that launched the cmd shell, as well as the real filename of the parent process. All in one place, finally!
From the Sysmon log, we can conclude that with a high degree of probability this suspicious command line, which we saw in the "raw" logs, is not the result of normal employee work. On the contrary, it was generated by a C2-like process - wmiexec, as I mentioned earlier - and was directly spawned by the service WMI process (WmiPrvSe). We now have an indicator that a remote attacker or insider is trying out corporate infrastructure.
Introducing Get-Sysmonlogs
Of course, it’s great when Sysmon has the logs in one place. But, probably, it would be even better if we could access individual log fields programmatically - for example, through PowerShell commands. In this case, you could write a small PowerShell script that would automate the search for potential threats!
It was not my first idea. It’s good that some forum posts and GitHub projects have already explained how to use PowerShell to parse the Sysmon log. In my case, I wanted to avoid having to write separate lines of parsing script for each Sysmon field. Therefore, I used the principle of a lazy person and, as it seems to me, as a result I came up with something interesting.
The first important point is the ability of the teamGet-WinEvent read Sysmon logs, filter the necessary events and output the result to a PS variable, as here:
$events = Get-WinEvent -LogName "Microsoft-Windows-Sysmon/Operational" | where { $_.id -eq 1 -or $_.id -eq 11}
If you want to test the command yourself, then by displaying the content in the first element of the $ events array, $ events [0] .Message, you can get a series of text strings with a very simple format: the name of the Sysmon field, a colon and then the value itself.
Hooray! Sysmon log output into JSON-ready format
Are you thinking the same thing as me? With a little more effort, you can convert the output to a JSON formatted string and then load it directly into the PS object using the powerful ConvertFrom-Json command .
I'll show you the PowerShell code for the conversion - it's very simple - in the next part. For now, let's see what my new command called get-sysmonlogs, which I installed as a PS module, can do.
Instead of delving into the analysis of Sysmon logs via the inconvenient event log interface, we can easily search for incremental activity directly from the PowerShell session and use the where PS command (alias - “?”) To reduce the output:
List of cmd shells launched via WMI. Threat analysis is cheap with our own Get-Sysmonlogs team
Amazing! I created a Sysmon log polling tool as if it were a database. In our article about EQL, it was noted that the cool utility described in it will perform this function, although formally it is still through a real SQL-like interface. Yes, EQL is nifty, but we'll touch on it in Part 3.
Sysmon and graph analysis
Let's abstract and think about what we just created. Essentially, we now have a Windows Event Database accessible through PowerShell. As I noted earlier, there are connections or connections between records - through ParentProcessId - so you can get a complete hierarchy of processes.
If you've read the Adventures of Elusive Malware series, you know that hackers love to create complex multi-stage attacks, in which each process plays its own small role and prepares a springboard for the next step. Such things are extremely difficult to catch simply from the "raw" log.
But with my Get-Sysmonlogs command and an additional data structure that we will look at later in the text (of course, this is a graph), we will have a practical way to detect threats - which only requires performing a correct vertex search.
As always in our DYI blog projects, the more you work on analyzing the details of threats on a small scale, the better you realize how difficult it is to detect threats at the organization level. And this awareness is extremely important .
We will meet the first interesting complications in the second part of the article, where we begin to link Sysmon events to each other in much more complex structures.