This post aims to demystify what can be done to restrict mimikatz from running successfully in Windows. Specifically how we can mitigate clear text credentials being dumped out of memory. My aim is to demonstrate what can be done to the operating system configuration to help reduce this from happening. In a follow up post perhaps we will look into how we might be able to identify if this has or is happening to a machine on the network.
Once a user logs on to a windows system the credentials are stored in the Local Security Authority Subsystem Service (LSASS). Once creds are cached, from here, with various tools, not just mimikatz, credentials in the form of clear text and hashed passwords can be extracted.
Mimikatz for a pen tester is a really great tool, like wise also unfortunately for hackers. Created by Benjamin Delphy ‘gentilkiwi’ allows one to dump clear text credentials out of memory. It can do all sorts of other pretty cool things like perform pass-the-hash, pass-the-ticket or build Golden tickets, among others. Some of which I may walk through in the future.
Mimikatz can be executed from different sources. Either directly from an executable and also from powershell. The later being the more desirable as no files are ever touching the hard disk drive. A typical screen shot of successful dumping would look like this, this is what we are trying to avoid:
Here you can see the local account ‘Adam’ and the clear text password being displayed. This is clearly bad news for organizations, and an IT teams worst nightmare. An adversary would have to initially compromise a workstation or server and gain admin or SYSTEM level privileges. This might be through a classic remote code execution vulnerability like MS08-069. Or through some other weakness in the software, or mis-configuration in the operating system. An attacker from here on would move laterally from system to system dumping creds. Ultimately with the aim of snagging a Domain Admin, or capturing that key piece of business data.
This post isn’t necessarily concerned with showing you how to use mimikatz, rather it’s, to better inform IT teams how they can prevent clear text credentials being dumped. Any tester worth their weight will already know how to use it.
I’m going to test by running mimikatz natively on a couple of Windows operating systems in my test environment, make changes to the system then re-run.
I’ll run through executing Mimikatz and the preventative measures we can use to stop the software interacting with LSASS and dumping creds. Lets start with Windows Server 2012 R2.
Windows Server 2012 R2
When we run Mimikatz on a fully up to date system we get the following results:
Note where the ‘Password’ field is for wdigest and kerberos , this would normally reveal the clear text password however in this case a ‘(null)’ value is displayed. This is default behavior in Windows Server 2012 R2 and Windows 8.1 and above, sadly for older operating systems such as Windows 7 the credentials are in displayed here in clear text. The NTLM hashes are still present here which still isn’t great and so can potentially be used in ‘pass the hash’ type attacks (PTH on the rid 500 account) or cracked offline using large password lists. Lets see what we can do to harden our systems further.
With Windows Server 2012 R2 and 8.1 there is a new feature called LSA (Local Security Authority) Protection according to the following Microsoft page we are able to run LSASS as a protected process. This essentially prevents mimikatz from working correctly out of the box. Although with some tweaking you can get mimikatz to run however a driver would need to added into the mix for it to work properly. The following registry change can be made at HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa adding a new DWORD entry of “RunAsPPL” with a value of 1. This does require a reboot however. Lets see this in action on the same Windows Server 2012 R2 Server. First the registry key:
Lets reboot, and now lets see what happens when Mimikatz is executed:
Thats more like it! Now we are getting somewhere. This is only going to slow attackers down. It is however also going to generate noise on the network when the attacker reboots the server.
Windows 7 Professional
A patch was released by Microsoft which allowed you to control the clear text credentials from the wdigest for earlier systems. This same functionality can be utilized by tweaking the registry for earlier versions of Windows. This is available for Windows 7,8,2008 and is kb2871997. Once this patch is installed it allows you control how WDigest credentials are stored in memory. According to the following Microsoft Security Advisor; to prevent WDigest credentials from being stored in memory. A reg key can be set via Group policy and thus applied to your estate. The registry key is new DWord with the name UseLogonCredential under the following subkey:
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\SecurityProviders\WDigest
If the UseLogonCredential value is set to 0, WDigest will not store credentials in memory.
If the UseLogonCredential value is set to 1, WDigest will store credentials in memory.
Lets see how this works in Windows 7, first we will run Mimikatz to verify default behavior then we will add the WDigest registry key, reboot, test, then add the RunAsPPL registry key, reboot one last time and test again, lets do this!:
As with the standard behavior below we get clear text creds and hashes:
Now lets add the HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\SecurityProviders\WDigest\ UseLogonCredential and set it 0:
Lets reboot, and retry Mimikatz.
As we can see the password fields no longer contain our clear text password, and have the (null) value instead. This is a significantly better position to be in, this still does however, reveal the NTLM hash which is still not ideal. Unfortunately the RunAsPPL registry key, cannot be utilized in Windows 7.
Windows Server 2008 R2
Lets try the same with Windows Server 2008 R2. When we run mimikatz natively this is the result:
As we can see the local administrators account password for the wdigest field is in displayed in clear text. Now lets see if we can apply the same HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\SecurityProviders\WDigest\ UseLogonCredential registry key and at least mitigate the clear text password. First the registry key then a reboot.
After a reboot we rerun mimikatz and as we can see from the below screenshot we have successfully mitigated from the at least the clear text password being displayed, although the hash is still available:
However… this wouldn’t stop an attacker from changing the reg key back logging off and waiting for credentials to be cached.
Conclusion:
So far we have tested using mimikatz natively from the windows server 2012 R2 and successfully stopped mimikatz from executing the same should apply here for Windows 8.1 and above, however you should carry out your own due diligence and try this out to satisfy yourself. Windows 7 and Windows Server 2008 are slightly different and we can only go so far in stopping or slowing down this type of attack, to not displaying the clear text password only the hash.
Unfortunately with different versions of Windows there are different fixes and varying degrees of success in reducing the impact of mimikatz being run on a system.
As you will agree though this is significantly better than allowing the default configuration to remain. I hope this helps slow down your adversaries!