Hunting Mimikatz Using Sysmon + ELK - Part 2 of Series

In my previous post we saw how useful sysmon logging and powershell enhanced logging along with visualization with ELK to detect malicious activities involving obfuscated powershell scripts used widely in recent attacks.

In this new blog post, I have described how to use sysmon and powershell enhanced logging + ELK to hunt for mimikatz running in the network somewhere. For this purpose I executed mimikatz on the endpoint using three different mechanisms:

1. Running the mimikatz binary from commandline, simulating a scenario where the attacker has been able to get the mimikatz binary on the subject endpoint, whereby the attacker runs the commands from the mimikatz prompt

2. Exploiting EternalBlue vulnerability MS17-010 (CVE-2017-0147) on the endpoint using metasploit, gaining meterpreter shell, loading mimikatz module and then running the commands

3. Running Powersploit "Invoke-Mimikatz.ps1" to use powershell remoting and reflective injection to reflectively load mimikatz DLL in memory of the endpoint and then dumping the credentials/hashes on the attacker powershell console.


After every scenario I analyzed the Sysmon and PS script block logs to figure out how to identify the events pertaining to the mimikatz attack (accessing the lsass.exe process and dumping credentials). Once I was certain of the relationship between the logs and the attack, I was able to put together some easy queries in Kibana to detect Mimikatz attack.

Scenario 1: Running compiled binary from command line:


First I execute the binary from command prompt and run the commands to dump credentials

Rest are interesting logs I captured from Event Viewer and are self explanatory:

Note the GrantedAccess:0x1010 When the malicious binary accesses the lsass.exe process:

Clean up / Delete Index

Next, I clean up the logs in my Elastic DB using the following command

curl -XDELETE '192.168.1.143:9200/winlogbeat-*?pretty'

I exploit the EternalBlue on the victim endpoint. Do note the ports when reverse https (8443) is established (49228)

I look for lsass.exe process so I can migrate my malicious code from spoolsvc.exe to lsass.exe

I run native hashdump of meterpreter and then loads mimkatz and run its commands

Again I looked at the events to find related logs:

We can see the lsass.exe connects to pipe \wkssvc

The wkssvc interface is used to manage the lanmanworkstation service. (Ref: http://www.hsc.fr/ressources/articles/win_net_srv/msrpc_wkssvc.html)

The malicious process also connects to the \wkssvc pipe for LPC based communication

Next we see the malicious process makes the reverse https connection to the kali box from source port 49228 (which we saw above during the exploitation phase). Can we make a correlation rule to detect Eternalblue: “If a process connects to pipe \wkssvc (Sysmon EventID 18) and then subsequently the same process establishes a network connection with a remote machine with SYSTEM user (Sysmon EventID 3)” And then the same process also creates a pipe (Sysmon EventID 17).

Some other related events to the pipe, which is, create above by the malicious process. The services process is setting values for a service “nmhupj” (same name as the pipe), the start value (manual) and the Imagepath. The imagepath is “cmd.exe /c echo nmhupj > \\.\pipe\nmhupj”. This is simply echoing the name of the pipe to the pipe itself??!

Note the command line (ImagePath) value of the service

 

The service Start value is set to Manual

I think this is where the Eternalblue exploitation ends and meterpreter session is obtained.

Next Sequence of events are related to running commands of Mimikatz module from meterpreter:

See the GrantedAccess values are 0x1400 OR 0x1410 OR 0x147a for commands executed remotely using mimikatz meterpreter module. This is in contrast to 0x1010 when mimikatz binary is executed from commandline.

Lastly we see the CreateRemotethread event (Event 8), where the TargetImage is lsass.exe. This is a high fidelity event and is almost always indicative of maliciousness:

Running mimikatz using Reflective dll injection (Powersploit Mimikatz module)

wsmprovhost.exe is the WinRM Remote Powershell session

We can see this process connecting to pipe \lsass

Some temporary powershell scripts and modules are created by the wsmprovhost.exe

Here we see the destination port 5985, which is used for powershell remoting using winrm

Ref: https://blogs.technet.microsoft.com/christwe/2012/06/20/what-port-does-powershell-remoting-use/

Next we see the wsmprovhost.exe accessing the lsass.exe process. The GrantedAccess value is 0x143a . This is again different when mimikatz runs from meterpreter  (0x1400 OR 0x1410 OR 0x147a) and 0x1010 when mimikatz binary is executed from commandline.

Let us also look at some ways to detect Mimikatz related PS ScriptBlock Logs:

The deobfuscated PS code which is injected into the memory can be seen below (Event ID 4104). Note the VirtualAlloc and memset

Also other PS logs like Event ID 800 can be seen calling System.Reflection function for creating an Assembly at runtime in memory. Please refer to my past blog post for details of reversing this.

The below Kibana queries are self-explanatory and are good value to detect malicious process accessing lsass.exe for dumping credentials.

Hope you liked the analysis and detection pointers. 

Next, we might delve into other offensive TTPs and then try to evaluate respective detection mechanisms.