ITKarma picture

This article is the first part of a Sysmon threat analysis series. All other parts of the series:

Part 1. Introducing Sysmon log analysis (here we are)
Part 2. Using data from Sysmon events to identify threats
Part 3. In-depth graph analysis of Sysmon threats

If you are engaged in information security, you probably often have to understand the ongoing attacks. If you already have a trained eye, you can look for non-standard activity in raw raw logs - say, a PowerShell script running with the DownloadString command or a VBS script pretending to be a Word file - just flipping through the last activity in the Windows event log. But this is really a big headache. Fortunately, Microsoft created Sysmon, which makes attack analysis a lot easier.

Want to understand the basic ideas behind the threats displayed in the Sysmon log? Download our WMI events as a spy tool and you will realize how insiders can stealthily Observe other employees. The main problem with working with the Windows event log is the lack of information about the parent processes, i.e. one cannot understand the hierarchy of processes from it. Sysmon log entries, on the contrary, contain the identifier of the parent process, its name and the command line that is launched. Thank you, Microsoft.

In the first part of our series, we will see what can be done with basic information from Sysmon. In the second part, we will take full advantage of the information about parent processes to create more complex compliance structures, which are known as threat graphs. In the third part, we will consider a simple algorithm that scans a threat graph to search for non-standard activity through analysis of the “weight” of the graph. And in the end, as a reward, you will find an accurate (and understandable) probabilistic method of detecting threats.


Part 1: Introducing Sysmon Log Analysis


What will help to 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 Sysmon utility. And it is surprisingly easy to work with. Way to go, Microsoft!

What are the features of Sysmon?


In short - useful and readable information about the processes (see 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 (in decimal, not hex!)
  • Parent Process ID
  • Process Command Line
  • Parent Process Command Line
  • File Image Hash
  • File Image Names

Sysmon is installed both as a device driver and as a service - more here. Its key advantage is the ability analyzing logs from several sources, correlating information and displaying the resulting values ​​in one event log folder located on the Microsoft - > Windows - > Sysmon - > Operational . In my own investigations of Windows logs that make my hair stand on end, I constantly had to switch between, say, the PowerShell log folder and the Security folder, flipping through the event logs in a heroic attempt to somehow compare 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 stealth session wmiexec that pretends moving a smart insider inside the network. Here's what you’ll see in the Windows event log:

Some information about the process is visible in the Windows log, but it is of little use. Plus process identifiers in hexadecimal form ???


Some information about the process is visible in the Windows log, but it is of little use. Plus process identifiers in hexadecimal ???

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 the output redirected to a file with a strange name is clearly similar to the control and management software command-and-control (C2) : this creates a pseudo-shell using WMI services.
Now let's take a look at the equivalent of a record from Sysmon, paying attention to how much additional information it gives us:

Sysmon features in one screenshot: detailed information about the process in a readable form


Sysmon features in one screenshot: detailed process information in readable form


You not only see the command line, but also the file name, the path to the executable application that Windows knows about (“Windows Command Processor”), the identifier of the parent process, the command line of the parent that launched the cmd shell, as well as the real file name 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 the normal work of the employee. Quite the contrary, it was generated by a C2-like process - wmiexec, as I mentioned earlier - and was directly generated by the WMI service process (WmiPrvSe). Now we have an indicator that a remote attacker or insider is trying the corporate infrastructure for the tooth.

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. And it's good that some forum posts and GitHub projects have already explained how to use PowerShell for parsing the sysmon log. In my case, I wanted to avoid the need to write separate lines of a 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 Get-WinEvent command to read Sysmon logs, filter the necessary events and display the result in 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 check the operation of the command yourself, then by displaying the content in the first element of the $ events, $ events [0].Message array, you can get a series of text strings with a very simple format: Sysmon field name, colon, and then the value itself.

Hurray! Sysmon log output to the JSON-ready format


Hooray! Sysmon log output ready for JSON format


Do you think about 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 command ConvertFrom-Json .
I will show the PowerShell code for conversion - it is very simple - in the next part. In the meantime, let's take a look at what my new command called get-sysmonlogs can do, which I installed as a PS module.
Instead of delving into analyzing Sysmon logs through the inconvenient event log interface, we can effortlessly search for incremental activity directly from a PowerShell session and use the PS command where (alias -"? ") to reduce output results:

A list of cmd shells launched through WMI. Threat analysis is cheap with using our own Get-Sysmonlogs team


List of cmd shells launched via WMI. Threat analysis cheaply 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 this function will be performed by the cool utility, although formally it is still 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 Windows event database available 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 read the Adventures of the Elusive Malvari series, you know that hackers like to create complex multi-stage attacks, in which each process fulfills its small role and prepares a springboard for the next step. Such things are extremely difficult to catch just from the "raw" log.
But with my Get-Sysmonlogs team and an additional data structure, which we will discuss later in the text (of course, this is a graph), we will have a practical way to detect threats - for which you only need to perform a correct search on the vertices.
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 an extremely important point .

We will meet the first interesting difficulties in the second part of the article, where we will begin to connect Sysmon events with each other into much more complex structures.

Source