This article is the first part of a series on analyzing Sysmon threats. All other parts of the series:
Part 1. Introduction to analyzing Sysmon logs (we are here)
Part 2. Using Data from Sysmon Events to Detect Threats
Part 3: Deep Sysmon Threat Analysis with Graphs
If you are involved 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 the "raw" raw logs - say, a PowerShell script running or a VBS script pretending to be a Word file just by scrolling through the latest activity in the Windows event log. But it's a really big headache. Fortunately, Microsoft has created Sysmon, which makes attack analysis much easier.
Want to understand the basic ideas behind the threats displayed in the Sysmon log? Download our guide and you realize how insiders can surreptitiously spy on other employees. The main problem with working with the Windows event log is the lack of information about parent processes, i.e. it is impossible to understand the hierarchy of processes from it. The Sysmon log entries, on the other hand, contain the parent's process ID, its name, and the command line being run. Thank you Microsoft.
In the first part of our series, we'll see what we can do with basic information from Sysmon. In part two, we'll take full advantage of parent process information to create more complex compliance structures known as threat graphs. In the third part, we will look at a simple algorithm that scans the threat graph for non-standard activity through the analysis of the “weight” of the graph. And in the end, as a reward, you will find a neat (and understandable) probabilistic method for 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 at first. In the beginning, to understand the principles of SIEM, it will be enough to try the wonderful free Sysmon utility. And she's surprisingly easy to work with. Keep it up, Microsoft!
What are the features of Sysmon?
In short, useful and readable information about processes (see pictures below). You'll find a bunch of useful details that aren't in the Windows event log, but the most important are 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 as both a device driver and a service at the same time - learn more Its key advantage is the ability to analyze logs from more sources, correlation of information and output of the resulting values in one folder of the event log, located along the path Microsoft -> Windows -> Sysmon -> Operational. In my own hair-raising investigations into the Windows logs, I constantly had to switch between, say, the PowerShell logs folder and the Security folder, scrolling through the event logs in a heroic attempt to somehow map 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, on the other hand, takes a qualitative leap forward by providing useful (or, as vendors like to say, actionable) information to help you understand the underlying processes. For example, I started a hidden session , which simulates the movement of a smart insider within the network. Here is what you will 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 IDs in hex???
For a professional IT professional with an understanding of the basics of hacking, the command line should be suspicious. Using cmd.exe to then run another command with output redirected to a file with a strange name - this is clearly similar to the actions of software for control and management : In this way, a pseudo shell is created using WMI services.
Now let's take a look at the equivalent of a Sysmon entry, noting how much extra information it gives us:
Sysmon features in one screenshot: detailed information about the process 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 parental process, command line parent, which 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 the employee's normal work. Rather, it was generated by a C2-like process - wmiexec, as I mentioned earlier - and was directly spawned by the service's WMI process (WmiPrvSe). Now we have an indicator that a remote attacker or insider is trying the corporate infrastructure for a tooth.
Introducing Get-Sysmonlogs
Of course, it's 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, it would be possible to write a small PowerShell script that would automate the search for potential threats!
I wasn't the first to have this idea. And it's good that in some forum posts and GitHub it has already been 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. So I used the lazy man principle and I think I came up with something interesting as a result.
The first important point is the ability of the command read Sysmon logs, filter the necessary events and display the result in 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 test the command yourself, by displaying the content in the first element of the $events array, $events[0].Message, you can output 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 in 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 a PS object with the powerful command .
I'll show the PowerShell code for the conversion - it's very simple - in the next part. 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 digging deeper into Sysmon log analysis through the awkward event log interface, we can effortlessly search for incremental activity directly from a PowerShell session, and also use the PS command (alias - "?") to shorten the search results:
List of cmd shells launched via WMI. Threat analysis cheap with our own Get-Sysmonlogs team
Marvelous! I created a Sysmon log polling tool as if it were a database. In our article about it was noted that this function will be performed by the cool utility described in it, although formally through a real SQL-like interface. Yes, ECL graceful, 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 accessible via PowerShell. As I noted earlier, there are connections or relationships between records - through ParentProcessId - so you can get a complete hierarchy of processes.
If you have read the series then you know that hackers love to create complex multi-stage attacks in which each process plays 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 command and an additional data structure that we'll look at later in the text (a graph, of course), we have a practical way to detect threats - which only requires doing a proper vertex search.
As always in our DYI blog projects, the more you work on analyzing the details of threats on a small scale, the more you will realize how difficult it is to detect threats at the organization level. And this realization is extremely important point.
We will encounter the first interesting complexities in the second part of the article, where we will begin to connect Sysmon events to each other into much more complex structures.
Source: habr.com