Chronicles of a Threat Hunter: Hunting for WMImplant with Sysmon and ELK - Part I (EID 1,12, 13, 17 & 18)

It was a normal day at work when all of the sudden I see the following on Twitter 







Apparently this new WMI RAT runs perfectly fine on Device Guard-enabled systems! It was Game ON ! I got very excited to test this tool BUT only to see how I could hunt for it, of course. Even though there might be different ways to detect the behavior of this new tool, I decided to use the tools I have been playing with for the past couple of months, Sysmon & ELK. 

Requirements:

• Sysmon Installed (I have version 6 installed)
• Winlogbeat forwarding logs to an ELK Server
• An ELK Stack set up (I recommend reading this and this to help you set up your environment)
• A Kibana Dashboard (I recommend reading this post to understand how you can create a dashboard in Kibana with Sysmon Logs)
• WMImplant Script
• Two Windows 7+ VMs (Victim & Attacker)
• Notepad ++ (Good to edit Sysmon configs)

What is WMImplant?

WMImplant is a PowerShell based tool developed by @christruncer that leverages WMI to both perform actions against targeted machines, but also as the C2 channel for issuing commands and receiving results. WMImplant will likely require local administrator permissions on the targeted machine.  It is designed to run both interactively and non-interactively. When using WMImplant interactively, it’s designed to have a menu of commands reminiscent of Meterpreter. [Source]

Getting ready to hunt for WMImplant

Getting a Sysmon Config ready

The main goal is to log for only logs related to WMIimplant and filter out all the noise. It is easy to say "Just log for WmiPrvSE.exe activity in your Sysmon config" or "read the source code to know what you can log for". However, I find it more interesting, easier and faster to filter out most of the normal activity in my gold image and then look for the abnormal. Then, you could reference the code to understand your findings (it is up to you how you approach this part). I used my StartLogging.xml sysmon config which I used as a basic first config to filter out noise on an initial Sysmon setup.





Download and save the Sysmon config in a preferred location of your choice. Then, update your Sysmon rules configuration. In order to do this, make sure you run cmd.exe as administrator, and update your Sysmon rules with the configuration you just downloaded by running the following commands:


Sysmon.exe -c [Sysmon config xml file]

Getting a Kibana dashboard ready

Instead of looking at all the Sysmon logs created in the event viewer console, I prefer to have all my logs in different visualizations on one dashboard. It makes the analysis way easier allowing me to look at all the data at once and filter out noise. If you want to learn the basics of how to build a Kibana dashboard, you can read about it here and here. Create one similar to the one shown in figure 1 below.

Figure 1. WMImplant Dashboard

Delete/Clean your Index 

In order to reduce the number of logs before and during executing WMImplant, make sure you delete/clear your Index by running the following command as shown in figure 2 below:

curl -XDELETE 'localhost:9200/[name of your index]?pretty'

Do this again a few seconds before you run WMIimplant against your compromised computer.

Figure 2. Deleting/Clearing Index

Hunting for WMImplant

Download WMImplant.ps1 and Run it on the Attackers VM

Download the script from here, and Import the functions to your Attackers VM. Then, run the main function Invoke-WMImplant to use it interactively as shown in figure 3 below.

Figure 3. Running WMImplant interactively.

Setting up a User to connect to remote systems

Let's say we have the password of a domain user and we want to use it to connect to his/her computer. Use the "Change_user" command as shown in figure 4 below.

Figure 4. Changing user to connect to remote systems.

Running Command Line commands: command_exec

Lets start with a basic command: whoami (make sure you delete/clear index seconds before executing this)

Figure 5. Running command_exec to execute whoami on remote system.

First Look at our Dashboard

Go to your dashboard and refresh it to show you what happened in the past 15 mins. Right away we can see a few things:

• Pipes: 2 <Anonymous Pipe> (PowerShell.exe Anonymous Pipes all the time)
• Parent Process: WmiPrvSe.exe
• Parent Process: PowerShell.exe
• Parent Command Line: powershell.(G`CM ('{1}e{0}'-f'x','i')) (L`S env:Osrv5).Value
• Command Line: powershell.(G`CM ('{1}e{0}'-f'x','i')) (L`S env:Osrv5).Value

Figure 6. First glance at WMImplant

Next, filter all your events to show only events that have "wmiprvse.exe" and "PowerShell.exe" as parents to see how WMImplant interacts with the compromised computer while running commands. Lets do one at the time and then we can combine them in a Query to see them in a timeline style on Kibana's Discovery view as shown in figure 9 below

Figure 7. Filtering everything to show Wmiprvse.exe as a parent only.

Figure 8. Filtering everything to show PowerShell.exe as a parent only.

Figure 9. Discovery View looking for Wmiprvse.exe and PowerShell.exe as parents.

Checking WMImplant Methodology and Code

Command_exec apparently executes Invoke-CommandExecution which follows the same methodology as explained in its documentation:

• Remotely query and obtain the original value for Win32_OSRecoveryConfiguration’s DebugFilePath property.
• Use WMImplant to execute a command on the targeted system (such as ifconfig), encode the output, and store the encoded results in the DebugFilePath property.
• Remotely query the targeted system’s DebugFilePath over WMI to receive the encoded results.
• Decode the results and display them to the console.
• Set the DebugFilePath property on the targeted system back to its original value.

I decided to look for the Win32_OSRecoveryConfiguration string and I found that it was being defined as part of a long command in a Registry Value as shown in figure 11 below.

Figure 10. Searching for Win32_OSRecoveryConfiguration.

Figure 11. Win32_OSRecoveryConfiguration in EID 13 (Setting Reg Value)

Running more commands: Ipconfig & Get-WmiObject

I decided to run two commands:

• ipconfig
• get-wmiobject win32_operatingsystem | select csname, @{LABEL='LastBootUpTime'; EXPRESSION={$_.ConverttoDateTime($_.lastbootuptime)}}

Figure 12. Running other commands.

Checking our Dashboard

We can see more of the same behavior in figures 13 and 14 below:

Figure 13. WMImpant execution.

Figure 14. WMImplant and Win32_OSRecoveryConfiguration fingerprint.

PowerShell Basic Obfuscation

We can see that there is obfuscation happening on PowerShell command. however, I see them all starting with "powershell" as you can see in figure 15 below. We could also look for :

• 'Get-C`hildItem'
• 'Get-C`ommand'
• 'Inv`oke-Ex`pression'
• 'IE`X'
• 'G`CI'
• 'env:'

Figure 15. Obfuscation.

What is this "Environment\XXXXX"?

I noticed that the Registry Objects being set followed the same pattern:

HKEY_USERS\(user)\Environment\(5 characters)

Therefore I decided to filter everything by the string "Environment". I got results with Event IDs 12 and 13 as shown in figure 16 below.

Figure 16. Registry events WMImplant Fingerprint.

I decided to take a look at the code and found out that WMImplant creates an Environment variable with a 5 character Random alphanumeric name as shown in figure 17 below.

Figure 17. Environment Variable name created.

The Environment variable is set and then deleted which explains Sysmon Event IDs 12

Figure 18. Setting Environment Variable.

Figure 19. Deleting Environment Variable.

Final Thoughts

Even though this was just part I of hunting for WMImplant, I was able to come up with a basic fingerprint that could help us to reduce the number of false positives when hunting for WMImplant. I would say that the following fingerprint could be created based on the initial findings:

• wmiprsve.exe spawning powershell.exe and executing obfuscated commands such as:
• 'Get-C`hildItem'
• 'Get-C`ommand'
• 'DI`R'
• 'L`S'
• 'Child`Item'
• 'Inv`oke-Ex`pression'
• 'IE`X'
• 'G`CI'
• env:
• 'Co`mmand'

• Environment Variable name on EIDs 12 and 13
• Pattern: \\Environment\\[a-zA-Z0-9]{5}

• <Anonymous Pipes> by PowerShell.exe

Hunting Techniques recommended

Grouping [Source]
"Grouping consists of taking a set of multiple unique artifacts and identifying when multiple of them appear together based on certain criteria. The major difference between grouping and clustering is that in grouping your input is an explicit set of items that are each already of interest. Discovered groups within these items of interest may potentially represent a tool or a TTP that an attacker might be using. An important aspect of using this technique consists of determining the specific criteria used to group the items, such as events having occurred during a specific time window.This technique works best when you are hunting for multiple, related instances of unique artifacts, such as the case of isolating specific reconnaissance commands that were executed within a specific timeframe."


Searching [Source]
The simplest method of hunting, searching is querying data for specific artifacts and can be performed in most tools. Unfortunately it may not always be the most effective method because it cannot produce outliers in the result set; you get exactly the results you searched for.Searching also requires a finely defined search criteria to prevent result overload. A search that is too broad will often flood an analyst with too many results to realistically process.


You can either group those events or look for specific strings that get created under several events. You can configure your Sysmon config to monitor for environment variables and anonymous pipes. This was just part I. I will test the rest of the commands available next week and let you know what I find.



Feedback is greatly appreciated!  Thank you.