This article is the first part of a series on analyzing Sysmon threats. All other parts of the series:
Part 1. Introduction to 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 work in information security, you often have to deal with ongoing attacks. If you have a trained eye, you might look for unusual activity in the 'raw' unprocessed logs — for example, a PowerShell script with the executed command, or a VBS script masquerading as a Word file, by simply scrolling through the latest activity in the Windows Event Log. But this can be a real headache. Fortunately, Microsoft created Sysmon to make attack analysis much simpler.
Do you want to understand the basic ideas behind the threats displayed in the Sysmon log? Download our guide and you will realize how insiders can discreetly monitor other employees. The main issue with the Windows Event Log is the lack of information about parent processes, meaning you can't understand the hierarchy of processes. In contrast, Sysmon log entries contain the parent process ID, its name, and the command line being executed. Thank you, Microsoft.
In the first part of our series, we will look at what can be done with the basic information from Sysmon. In the second part, we will fully leverage the information about parent processes to create more complex matching structures known as threat graphs. In the third part, we will explore a simple algorithm that scans the threat graph for unusual activity by analyzing the 'weight' of the graph. And finally, as a reward, you will be presented with a neat (and understandable) probabilistic threat detection method.
Part 1: Introduction to Sysmon Log Analysis
What can help navigate the complexities of the event log? Ultimately – SIEM. It normalizes events and simplifies subsequent analysis. However, we don’t necessarily need to go that far, at least not initially. At the beginning, to understand the principles of SIEM, it’s enough to try the wonderful free utility Sysmon. And surprisingly, it’s easy to work with. Well done, Microsoft!
What capabilities does Sysmon have?
In short – useful and readable information about processes (see images below). You will discover a bunch of useful details that are not present in the Windows event log, but most importantly – the following fields:
- Process ID (in decimal form, not hex!)
- Parent process ID
- Process command line
- Parent process command line
- File image hash
- File image names
Sysmon installs simultaneously as a device driver and as a service – more details Its key advantage is the ability to analyze logs from multiple sources, correlate information, and output the resulting values into a single event log folder located at Microsoft -> Windows -> Sysmon -> Operational. In my own investigations of Windows logs, which often left me hair-raising, I constantly had to switch between, say, the PowerShell log folder and the 'Security' folder, scrolling through event logs in a heroic effort to somehow correlate values between them. This is by no means an easy task, and as I later realized, it would have been wise to stock up on aspirin in advance.
Sysmon, however, makes a significant leap forward, providing useful (or as vendors like to say – actionable) information to help understand the fundamental processes. For example, I launched a hidden session , simulating the movement of a clever insider within the network. Here’s what you will see in the Windows event log:
The Windows log shows some information about the process, but it is of little use. Plus, the process IDs are in hexadecimal form???
A professional IT specialist with an understanding of the basics of hacking should be suspicious of the command line. Using cmd.exe to subsequently launch another command with redirected output to a file with a strange name clearly resembles actions of monitoring and control software. : this method creates a pseudo-shell using WMI services.
Now let's take a look at the equivalent entry from Sysmon, noting how much additional information it provides us:
Sysmon capabilities in one screenshot: detailed process information in a readable form
You not only see the command line, but also the file name, the path to the executable application, what Windows knows about it ("Windows Command Processor"), the identifier of the parent process, the command line of the parent, which launched the cmd shell, as well as the actual name of the parent process file. Everything in one place, finally!
From the Sysmon log, we can conclude that it is highly likely this suspicious command line we saw in the 'raw' logs is not the result of normal employee activity. On the contrary, it was generated by a C2-like process — wmiexec, as I mentioned earlier — and was directly spawned by the WMI service process (WmiPrvSe). Now we have an indicator that a remote attacker or insider is probing the corporate infrastructure.
Introducing Get-Sysmonlogs
It's definitely great when Sysmon has logs in one place. But it would probably be even better if we could access individual log fields programmatically — for example, through PowerShell commands. In this case, one could write a small PowerShell script that automates the search for potential threats!
I'm not the first to have such an idea. And it's good that there are some forum posts and GitHub that already explain how to use PowerShell to parse Sysmon logs. In my case, I wanted to avoid having to write separate parsing script lines for each Sysmon field. So I applied the lazy person's principle, and, as it seems to me, ended up coming up with something interesting.
The first important point is the capability of the command to read Sysmon logs, filter the necessary events, and output the result to a PS variable, like this:
$events = Get-WinEvent -LogName "Microsoft-Windows-Sysmon/Operational" | where { $_.id -eq 1 -or $_.id -eq 11}
If you want to check the team's work on your own, you can retrieve a series of text strings with a very simple format from the content displayed in the first element of the array $events, $events[0].Message: field name Sysmon, a colon, and then the value itself.
Hooray! Sysmon log output ready in JSON format.
Are you thinking what I am thinking? With a little more effort, the output can be converted into a formatted JSON string and then loaded directly into a PS object using a powerful command. .
I will show the PowerShell code for conversion—it's very simple—in the next part. But for now, let's take a look at what my new command called get-sysmonlogs, which I installed as a PS module, can do.
Instead of delving into analyzing Sysmon logs through the cumbersome event log interface, we can easily search for incremental activity directly from a PowerShell session, as well as use the PS command (alias – "?") to shorten the output results:
List of cmd shells running through WMI. Affordable threat analysis with our own Get-Sysmonlogs command.
Amazing! I created a Sysmon log polling tool as if it were a database. In our article on it was noted that this function would be performed by the cool utility described in it, although formally through a real SQL-like interface. Yes, EQL is elegant, but we will touch on it in the third part.
Sysmon and graph analysis
Let’s abstract and think about what we just created. Essentially, we now have a database of Windows events accessible through PowerShell. As I noted earlier, there are connections or links between the records—via ParentProcessId—so we can get a complete hierarchy of processes.
If you read the series then you know that hackers love to create complex multi-stage attacks where each process plays its small role and prepares the ground for the next step. Such things are extremely difficult to catch just from a "raw" log.
But with my Get-Sysmonlogs command and the additional data structure we will discuss later in the text (of course, this is a graph), we will have a practical way to detect threats – requiring only the right search through the vertices.
As always in our DYI blog projects, the more you work on analyzing threats in a small scale, the better you realize how complex threat detection is at the organizational level. This awareness is crucial. a key point.
We will encounter the first interesting challenges in the second part of the article, where we will start linking Sysmon events into much more complex structures.
Source: habr.com
