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
Part 2. Using data from Sysmon events to identify threats (we are here)
Part 3. In-depth graph analysis of Sysmon threats

In this section, we dig deeper and start using the detailed information that Sysmon provides us with. Here are three key points we will work on:

  1. Using PowerShell to directly access granular process information;
  2. Building and visualizing a process hierarchy is the first important step in finding threats;
  3. Using Sysmon metadata to generate important metrics useful in an in-depth threat investigation, such as counting the frequency at which specific processes start.

Using Get-Sysmonlogs


Let's take a closer look at my wonderful team, which converts Sysmon events to PowerShell objects. To some extent, I am proud that I did not have to manually write separate lines of code for each of the fields. And now, in fact, the great disclosure of the code:

$events=Get-WinEvent -LogName "Microsoft-Windows-Sysmon/Operational" | where { $_.id -eq 1 } foreach ($event in $events) { $ev=$event.Message -split "`r`n" $jsons="{ " foreach ($line in $ev) { $line=$line -replace "\\","\\" ` -replace "\{"," " ` -replace "\}"," " ` -replace '"','\"' ` -replace "`n"," " $line=$line -replace '(\s*[\w\s]+):\s*(.*)', '"$1":"$2",' $jsons=$jsons + $line } $jsons =$jsons + '"blah" : "blah" }' ConvertFrom-Json -InputObject $jsons } } 

All code is now available on GitHub and you can download and import it as a Sysmon module for your own project. The only instability is the removal of several unpleasant characters - brackets, backslashes, line-ending characters, quotation marks - to make the output close to JSON.
So, the classic intruder signal swarming around the system is the use of the whoami command, and often the one after the hostname. A hacker (or possibly an insider) who has got someone else's account wants to make sure that impersonalization works, so he often types the above commands as soon as he is on the victim’s server. For the rest, “whoami” and “hostname” are not the words that they will enter into the console of their own system, even if they ever use the command line.

With the help of my neat command, which gives access to all Sysmon log entries, we can easily concoct a chain filtering the process name (as we did in the first part ). At the same time, with Sysmon we can approach the issue even more granularly by looking at the command line of the parent process .

Usually, when a hacker penetrates the network and gets access to the command line, it is an outdated cmd - by the way, this is exactly what happens in the case of hacking with psexec or smbexec . Using the output of get-symonlogs, you can catch whoami processes that were spawned by these obsolete shells, and this will be good evidence of the threat.

Attention: Whoami launched through the outdated cmd shell


Attention: Whoami started via the outdated cmd shell


From a practical point of view, searching through the raw logs of the Windows event log and matching processes is simply impossible. As we just saw, Sysmon entries provide many opportunities for threat analysis. So let's continue our research by matching Sysmom data into more complex structures.

The basics of data structures: lists and graphs


Sysmon logs not only provide us with the command line of the parent process, but also the identifier of this process!

I think you already guessed what this means. But still: now we can combine processes in a hierarchy and, I’m not afraid to say this, networks. Recalling the basic concepts of computer science, one can discover natural data structures for obtaining such information - linked lists and graphs are the first to come to mind.

At first I thought that I would have to blow dust off my copy of “Data Structure for Poets and Sousse Chefs,” but here the Internet helped me out.I came across a gorgeous collection of basic Doug Finke algorithms at Gihub PowerShell Thank you, Doug!
After overcoming some learning curve, I was able to use its algorithms to structure my Sysmon events. I built the data structures in the form of a list and graph, and then, using the API, I wrote a PowerShell function to find the command and display the process hierarchy. Cool.

I called her show-threat-path . It searches in depth by the process hierarchy and displays the names of applications and their associated commands for the root application specified as an input parameter. As my first test, I searched for “whoami.exe”. And this is what I saw:

Process hierarchy: process 2452 looks suspicious!


Process hierarchy: process 2452 looks suspicious!


An additional bonus to those who noticed in the conclusion above that whoami associated with process 2452 was called through the outdated cmd shell, which in turn was already launched by an exe file with a strange name in the Windows folder.

Hmmm. If you are familiar with the psexec remote call mechanics described here , then mentally should already be ringing the bells. But I will tell you a little secret: playing the role of a hacker, I previously ran this whoami from a remote Linux server using Impacket python scripts.

The goal is to demonstrate that with the help of rich Sysmon logs and a small portion of PowerShell, you can prepare a very practical vulnerability detection tool, as I just did with show-threat-path .

Threat hunting with directed graphs


It's time to do weirder things. With all this process information from Sysmon, you can take a look at the links in a more general way. In other words, I want to consider running applications - PowerShell.exe, Explorer.exe, etc. - as the vertices of the graph and associate them with the application, which in turn launched them. The result is a diagram showing how the applications interact with each other (instead of creating a separate vertex on the each process instance).

Technically speaking, this is a directional graph , in which the way, so to speak, It is a one-way road from an application to its parent process.

At this stage, it would be nice to look at the visualization of what I'm talking about. Fortunately, there is a great graphs PowerShell visualization utility called GraphViz , which has extremely simple wrappers available through PSQuickGraph . Then with a small piece of code...

#Let's graph it!!! $gv=New-Graph -Type BiDirectionalGraph # PSQuickGraph foreach ($e in $g.getAllEdges() ) { $g from Doug Fink's functions $vs= $e.startvertex $ve= $e.endvertex PSQuickGraph\Add-Edge -From $vs.value.Key -To $ve.value.Key -Graph $gv |Out-Null } Show-GraphLayout -Graph $gv 

... you can visualize complex interactions between applications through the GraphViz interface:

GraphViz: PowerShell library for visualizing process hierarchies


GraphViz: PowerShell library for visualizing process hierarchies


What does it give? Essentially, this is a graphical way to identify threats. Instead of looking for a specific text signature, as we did before with the show-threat-path command, we can now try to find anomalies in the graph.

The idea is to understand what is a normal picture of the neighborhood of graphs and subgraphs - they usually look like connected structures on a visualization - and then try to find vertices that look more isolated. And in fact, our eyes are well adapted to this task. But fortunately, there are also a few simple neighborhood detection and threat detection algorithms.And once upon a time, your humble servant even wrote a post about using the technique of identifying neighborhoods in a social network associated with... famous hero of the US revolution .

The advantage of this approach in finding attackers is that hackers can change their techniques and obfuscate their attacks, but it’s not easy for them to hide their graph patterns.

In the third part of our review, we will delve into the analysis and application of algorithms and methods for searching for vulnerabilities. Stay with us!.

Source