How To prevent Mimikatz From Reviling passwords

Mimikatz is a free application started in 2007 as a project finding weakness in microsoft password policy and to extract passwords from memory in clear-text by Benjamin Delpy. and now it mostly used by hackers to get the admin or users passwords in order to get control over the system. Once that been made all sorts of cyber threats can become a living nightmare . In order to make it harder for the mimikats gainning your passwords you need to harden security

add this key and set it to 0 . the WDigset mechanism will stop storing password in Clear text

reg add HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\WDigest /v UseLogonCredential /t REG_DWORD /d 0

If this key will be set to 1 the mimikats will be able to extract the password :

Add this key HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\TokenLeakDetectDelaySecs and set it to 30 seconds

reg add HKLM\SYSTEM\CurrentControlSet\Control\Lsa\TokenLeakDetectDelaySecs /v /t REG_DWORD /d 30

This will trigger the clearing of any credentials of logged off users after 30 seconds, regardless if there is a still a reference to it

Microsoft added a special User group called “protected users” in active directory, when the user is added to the protection of the user group, NTLM hash and plaintext password can not see.

Very good references I have found

https://medium.com/blue-team/preventing-mimikatz-attacks-ed283e7ebdd5

https://isc.sans.edu/forums/diary/Mitigations+against+Mimikatz+Style+Attacks/24612/

Ways to detect mimikatz activity on your network

This registry key is worth monitoring in your environment since an attacker may wish to set it to 1 to enable Digest password support which forces “clear-text” passwords to be placed in LSASS on any version of Windows from Windows 7/2008R2 up to Windows 10/2012R2. Windows 8.1/2012 R2 and newer do not have a “UseLogonCredential” DWORD value, so it would have to be created. The existence of this key on these systems may indicate a problem.

Sysmon for the Win

To conclusively detect pass-the-hash I used Sysmon, which helps to monitor process access events.  We used this in the honeypot detection as well so you can read up on how to set that up in that post.

With Sysmon in place when a pass-the-hash occurs you will see Event ID 10 showing access to the LSASS process from Mimikatz or your pass-the-hash tool of choice.

Building Detections for Pass-the-Hash

Now that we’ve looked at all the evidence, the simplest way to build detections for pass the hash is to look for:

• 4624 events on your workstations
  • Logon Type = 9
  • Authentication Package = Negotiate
  • Logon Process = seclogo
• Associated Sysmon 10 events for LSASS process access

With a custom event log filter you can easily see when these two things happen at the same exact time, you’ve got pass-the-hash activity on your network!

Here is a custom event filter you can use to surface that specific information.

<QueryList>
  <Query Id="0" Path="Security">
    <Select Path="Security">
     *[System[(EventID='4624')]
      and
     EventData[Data[@Name='LogonType']='9']
      and
     EventData[Data[@Name='LogonProcessName']='seclogo']
     and
     EventData[Data[@Name='AuthenticationPackageName']='Negotiate']
     ]
     </Select>
  </Query>
  <Query Id="0" Path="Microsoft-Windows-Sysmon/Operational">
    <Select Path="Microsoft-Windows-Sysmon/Operational">
    *[System[(EventID=10)]]
    and
    *[EventData[Data[@Name='GrantedAccess'] and (Data='0x1010' or Data='0x1038')]]
</Select>
  </Query>
</QueryList>