Saturday, April 1, 2017

Chronicles of a Threat Hunter: Hunting for In-Memory Mimikatz with Sysmon, Win Event Logs, and ELK - Part III (Overpass-the-Hash - EIDs 10, 4624, 4648, 4768)

In my last posts about hunting for In-memory mimikatz that you can read here and here, I showed you that even though Mimikatz is executed without touching disk, it was still loading the same modules/Images and accessing Lsass.exe with the same permissions as if it would have done so. My goal with this research has been primarily to develop a strong fingerprint to detect In-memory mimikatz without focusing on the name of the script, command lines, strings of code, or even its hash, but its patterns of behavior. 

In this post, I will show you how we can also hunt for Mimikatz when it is used to move laterally in the network. Mimikatz uses a technique named "Overpass the Hash" which places a compromised hash into the MSV1_0 and Kerberos service provider to then run a process under different credentials and access other remote systems that the stolen token has access toAs usual, I will be using Sysmon to get extra visibility on the endpoint and my ELK Stack to parse our logs and have a better visualization of them. In addition, I will add Windows Event logs to our detection technique because it can provide more context to our fingerprint and helps us to reduce the number of false positives.


  • Sysmon Installed (I have version 6 installed)
  • Winlogbeat forwarding logs to an ELK Server
  • I recommend to read my series "Setting up a Pentesting.. I mean, a Threat Hunting Lab" specifically part 5 & 6 to help you set up your environment if you haven't set up one yet.
  • Mimikatz Binary (Version 20170328)
  • I also recommend reading Part I  and Part II of Hunting for In-Memory Mimikatz to understand the methodology.
  • Basic understanding of Access rights for process objects. You can learn about it here or here (Part II of hunting for In-Memory Mimikatz)


Mimikatz can perform the well-known operation 'Pass-The-Hash' to run a process under another credentials with NTLM hash of the user's password, instead of its real password.[Source] . When the user logs in, Windows creates a long term key for each encryption method supported by the client OS before requesting/obtaining a TGT. Multiple encryption types are normally available. The client should choose the strongest mutually-supported encryption type, but of course an attacker can produce a downgrade attack and choose weaker encryption. Here's a brief summary of possible encryption types:[Source]

  • DES-CBC-CRC (disabled by default in Vista/2008)
  • DES-CBC-MD5 (disabled by default in Vista/2008)
  • RC4-HMAC (XP & 2003 default, as well as the strongest encryption they support)
  • AES128-CTS-HMAC-SHA1-96 (introduced with Vista/2008)
  • AES256-CTS-HMAC-SHA1-96 (default in Vista/2008 and higher)

As you can see above, Windows 7 systems support the newer AES. However, it can also still support older RC4 algorithms. As we know, Microsoft uses the NT (NTLM) hash for Kerberos RC4 encryption which is why this attack is very easy to do. All it takes is to inject the compromised NTLM hash into a new process, downgrade the level of encryption to RC4 and obtain a TGT.

Ticket Encryption Types

Encryption Type




(legacy) Windows 2000+




not supported in Windows


(legacy) Windows 2000+


not supported in Windows


not supported in Windows


Windows Vista/2008+


Windows Vista/2008+


Windows 2000+


Windows 2000+

Event ID 4624: An Account was successfully logged on

This is a highly valuable event since it documents each and every successful attempt to logon to the local computer regardless of logon type, location of the user or type of account. [Source]

Logon Types

Logon Type

Interactive (2)

Intended for users who are interactively using the machine, such as a user being logged on by a terminal server, remote shell, or similar process. Logon at keyboard and screen of system.

Network (3)

Intended for high-performance servers to authenticate clear text passwords. LogonUser does not cache credentials for this logon type. (i.e. connection to shared folder on the computer from elsewhere on network)

Batch (4)

Intended for batch servers, where processes can be executed on behalf of a user without their direct intervention; or for higher performance servers that process many clear-text authentication attempts at a time, such as mail or web server. LogonUser does not cache credentias for this logon type.

Service (5)

Indicates a service-type logon. The account provided must have the service privileged enabled.

Proxy (6)

Indicates a proxy-type logon.

Unlock (7)

This logon type is intended for GINA DLLs logging on users who are interactively using the machine. This logon type allows a unique audit record to be generated that shows when the workstation was unlocked

NetworkClearText (8)

Preserves the name and password in the authentication packages, allowing the server to make connections to other network servers while impersonating the client. This allows a server to accept clear text credentials from a client, call LogonUser, verify that the user can access the system across the network, and still communicate with other servers.

NewCredentials (9)

Allows the caller to clone its current token and specify new credentials for outbound connections. The new logon session has the same local identify, but uses different credentials for other network connections.

RemoteInteractive (10)

Terminal Services session that is both remote and interactive.

CachedInteractive (11)

Attempt cached credentials without accessing the network.

CachedRemoteInteractive (12)

Same as RemoteInteractive. This is used for internal auditing.

CachedUnlock (13)

Workstation logon.

Getting ready to hunt for Mimikatz

Getting a Sysmon Config ready

Again, we need a basic Sysmon config to ONLY monitor for "Process Creation" and "ProcessAccess" (Targeting Lsass.exe) events. 

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 use the configuration you just downloaded. Run the following commands:

Sysmon.exe -c [Sysmon config xml file]

Then, confirm if your new config is running by typing the following:

sysmon.exe -c [Sysmon config xml file]

Getting a Kibana dashboard ready

As always, instead of looking at all the Sysmon logs created in the event viewer console, I prefer to have all my logs in different visualizations under one dashboard. It makes the analysis way easier allowing me to look at all the data at once and filter out noise. Make sure you add Windows event logs to it. 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. OverPassTheHash Dashboard

Delete/Clean your Index 

In order to reduce the number of logs before and during executing Mimikatz, 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 Mimikatz against your compromised computer.

Figure 2. Deleting/Clearing Index.

Hunting for Mimikatz

Download the latest Mimikatz Trunk 

Download the latest binary from here. As I showed you before, running Mimikatz on disk or in memory should provide the same behavior. In both scenarios the mimikatz module is used with the difference that when done in memory, it is reflectively loaded in memory without touching disk. Modules/Images and permissions are the same. 


Your box got compromised and unfortunately your manager logged on interactively to your computer with domain admin credentials, but your sys admins are superstarts and disabled WDIGEST to not allow plaintext passwords stored in lsass. Great!, wait, but the adversary was able to still get the NTLM hash of the domain admin account in your box. What can they do?

Run OverPass-The-Hash

Open cmd.exe as administrator, and first try to get a directory listing from the Domain Controller in your environment. In my network it is named Run the following commands as shown in figure 3 below. 

dir \\\c$

Figure 3. Access denied to the DC.

As you can see in figure 3 above, if the adversary tries to get to the DC with your permissions/Token, he or she will not succeed. 

Next, it is time to run "OverPass-The-Hash" (Make sure you delete/clean your index seconds before you run Mimikatz). Let's assume you have the hash of the DA account already (if not, use sekurlsa::logonpasswords to get hashes from memory). Then, in your same shell run as admin, run the following commands:

mimikatz.exe "privilege::debug" "sekurlsa::pth /user:<username> /domain:<domain name> /ntlm:<NTLM hash>" Exit

Figure 4. Running Mimikatz PTH module.

As you can see in figure 4 above, we were able to start another cmd.exe process but with the NTLM hash of our DA hf\pdulce. Also, our preferred encryption algorithm is now only RC4 as explained before (Encryption Downgrade to obtain TGTs with our compromised NTLM). Finally, try to get a directory list of the DC again. You will see that with the new cmd.exe shell running as hf\pdulce, you can successfully do it.

Figure 5. Access to DC with cmd running as DA account.

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 relevant things:

  • EID 1 (Process Create)
  • EID 4688 (A new Process)
  • EID 10 (Process Access)
  • EID 4624 (An account was successfully logged on)
  • EID 4648 (A logon was attempted using explicit credentials)
  • EID 4656 (A handle to an object was requested)
  • EID 4672 (Special privileges assigned to new logon)
  • Logon Type 9 (NewCredentials)
  • GrantedAccess codes/permissions: 0x1010 & 0x1038

Figure 6. OverPass-The-Hash dashboard.

In figure 6 on the visualization located at the bottom of the dashboard, we can see a timeline of events which can help us understand step by step what happened when we executed the OverPass-the-Hash technique. 

Filter potential Noise

  • EID 4688 and EID 1 are technically the same with the difference that EID 4688 provides information about the token type which can help us understand when a new process has been launched with a high elevated privilege. However, there are applications or modules in the system also that get started automatically with this token type such as taskhost.exe, dllhost.exe, etc. Basically everything as Local System (S-1-5-18). 
  • EID 1: We cannot assume that the adversary will use cmd.exe everytime it uses this technique. Therefore, I wont consider that as part of the fingerprint. We can consider this as a filter when the process is very suspicious (i.e. powershell running notepad or explorer.exe or svchost or vice-versa). 
  • EID 4672: Special privileges assigned to new logon. This could turn very noisy since it is part of every authentication process and the privileges assigned are not unique.
  • EID 4656: A handle to an object was requested. Very noisy too for this case. Part of the custom auditing that I enabled in my environment. This technique does not create a handle to SAM. This event shows PlugPlayManager as the object. This specific log is created a lot by other events.

EID 4624 with Logon Type 9 (New Credentials)?

This is good! Right at the same millisecond that we spawn the new cmd.exe with the compromised NTLM hash, we can see this log. Lets remember what Logon Type 9 means:

 "Allows the caller to clone its current token and specify new credentials for outbound connections. The new logon session has the same local identify, but uses different credentials for other network connections."

This matches the OverPass-the-Hash behavior. 

EID 10 with Granted Access 0x1010 & 0x1038?

Do you remember part II of Hunting for In-Memory Mimikatz? 0x1010 permissions were needed to access the memory contents of lsass and obtain credentials. We can see the same happening in here, but we now have an extra GrantedAccess code: 0x1038. If you are not familiar with these permissions, you can read about them here .

GrantedAccess: 0x1038:

  • 0x0010: PROCESS_VM_READ
  • 0x0020: PROCESS_VM_WRITE (Required to write to memory in a process using WriteProcessMemory)
  • 0x0008: PROCESS_VM_OPERATION (Required to perform an operation on the address space of a process)

I decided to test 0x1038 in a bigger dev environment to see how this basic fingerprint would scale. Processes Accessing Lsass.exe only, I found the following:

Total Events

There were more than 2M events (Event ID 10) in a 30 days period, and as you can see in the small table above, GrantedAccess 0x1010 & 0x1038 make this hunt way easier than expected. 0x1038 was Mimikatz executing the OverPass-the-Hash technique. Remember also that old version of Mimikatz use permission 0x1410 to access Lsass. Therefore, there needs to be some more filtering going on to get to Mimikatz. Once again, we are focusing on the permissions and not on the code or name of the script. Happy with the results so far.

EID 4648: A logon was attempted using explicit credentials?

Yes, the idea of OverPash-the-hash is to use compromised NTLM hashes to obtain a TGT degrading the encryption algorithm used for the challenge to then run a new process as the compromised user. This new process can then be used to access resources that the original user might not have access to. This is why we see EID 4648. This event is created when we obtained a directory list from the DC as hf\pdulce. You can see in figure 7 below how our compromised local user hf\cbrown is accessing the DC as hf\pdulce (our DA account).

Figure 7. Logon attempted using explicit credentials.

Where did you get EID 4768 from?

I went to my DC and looked for the TGT request at the same time I asked for a directory list of the DC c$. (12:25:37 AM), and found the TGT request with Ticket Encryption Type: 0x17 which according with our table at the beginning of this article, it means RC4 Encryption. Bingo! Encryption Type downgrade behavior captured by the DC. This event will require a lot of filtering if you have old applications or systems using out of date encryption to respond to challenges and request TGTs. I would use this event to filter out the noise that I might get with other events. This will give me more context that an adversary in fact downgraded the encryption type to use the compromised NTLM hash.

Figure 8. Encryption downgrade and TGT request.

Final Thoughts

The more I test Mimikatz, the more impressed I get to see all the logs that it generates when it runs (disk or in-memory). Once again, I was able to find unique patterns behavior that could be really helpful to detect it and hunt for it. I would say that the following fingerprint can be generated based on the findings of this article:

  • EID 4624 + Logon Type 9
  • EID 4648 (Explicit Credentials)
  • EID 10 : GrantedAccess 0x1010 & 0x1038
  • EID 4768: Ticket Encryption Type 0x17 (RC4)

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.

We could group all those chains of events, looked for them happening in a short period of time (seconds) or start searching for a few of them and start filtering out noise by adding the rest. I would start with GrantedAccess: 0x1038 since it is the one that I got one hit in millions of records (EID 10 - TargetImage: lsass.exe). I will keep testing more commands in my next posts and keep adding to the in-memory mimikatz fingerprint.

Feedback is greatly appreciated! Thank you. 


  1. This is a really, really superb series. As someone who has recently taken a strong interest in using Sysmon to the edge of its capabilities to help detect in-memory-only malware, I find this especially interesting and useful. I'm going to fire up my lab setup and look at what kind of post-filtering results I get in sorting Event 10 messages by the GrantedAccess values you discuss. Till now my experimentation has largely been about trying to find exclusions for ProcessAccess to put in the actual Sysmon config that will reduce the log volume for Event 10 that gets created in the first place.

    1. Thank you very much for your feedback synopsys19! I am happy to hear that you will be setting up your lab and testing the GrantedAccess values of this post. Please let me know how it goes ! I would like to hear the results Also, if you dont mind sharing your exclusions at the end for EID 10, it would be great!.

  2. Impeccable post. Never seen the 0x1038.
    Would try it out.

  3. Thanks a lot for sharing this excellent info! I am looking forward to seeing more posts by you as soon as possible! I have judged that you do not compromise on quality.

  4. Today i really very happy to getting this good quality resources, thanks
    visit my site

  5. What a fantabulous post this has been. Never seen this kind of useful post. I am grateful to you and expect more number of posts like these. Thank you very much.

  6. Thanks a lot for sharing this excellent info! I am looking forward to seeing more posts by you as soon as possible! I have judged that you do not compromise on quality. A Hunt To Remember: Taking A Look At Big Game Hunting

  7. I would like to say that this blog really convinced me to do it! Thanks, very good post. check it out