Defending Windows Domain Against Mimikatz Attacks

The IT community remembered late June, 2017, due to massive infection of many largest companies and government institutions in Ukraine, Russia, Germany, France and some other countries with a new ransomware Petya (NotPetya). In most cases, after its penetration into a corporate network Petya quickly spread to all computers and servers of a domain, thus paralysing up to 70-100% of all Windows infrastructure. Though one of the methods Petya used to spread to the network computers was the EternalBlue exploit (like in case with WannaCry malware), but it was not the main channel of the ransomware distribution. Unlike WCry, spreading only due to the SMBv1 vulnerability, NotPetya had been designed to attack corporate networks. After the system had been infected, the malware obtained the credentials (passwords, hashes) of computer users with the help of the publicly available Mimikatz tool and used them to spread further in the network via WMI and PsExec, up to total control over the domain. So, to protect against it, it was not enough just to install MS17-010 security update.

In this article, we’ll look at the basic techniques for defending Windows systems in the Active Directory domain against Mimikatz-like tools attacks .

Using sekurlsa module, Mimikatz allows to extract passwords and hashes of the authenticated users that are stored in LSASS.EXE (Local Security Subsystem Service ) system process. We have already had an article giving the example of using mimikatz to get user passwords in clear text (from WDigest, LiveSSP and SSP).

How to Prevent Getting Debug Privileges

In the article following the link above, you can see how using the debug privilege allows Mimikatz to get access to LSASS system process and extract passwords from it.

By default, the permissions to use debug mode are given to the group of local administrators (BUILTIN\Administrators). Although in 99% of cases the administrators do not use this feature (as a rule, it is necessary for system programmers), so for the security purposes it is better to disable SeDebugPrivilege. You can do it using GPO (local or domain one). Go to Computer Configuration -> Windows Settings -> Security Settings -> Local Policies -> User Rights Assignment and enable the policy Debug Program. Add the domain group of users to it who may need debug privileges (as a rule, these are the developers) or leave this group empty so that nobody has these privileges.

Now if you try to get debug privileges using mimikatz, the following error will appear:

ERROR kuhl_m_privilege_simple ; RtlAdjustPrivilege (20) c0000061

Disabling WDigest

WDigest protocol appeared in Windows XP and was used to perform HTTP Digest Authentication that used user passwords in clear text. The feature to totally prohibit storing passwords in clear text in LSASS appeared in Windows 8.1 and Server 2012 R2. To prohibit storing WDigest in the memory, in these OSs there is the DWORD parameter with the name UseLogonCredential and the value 0 in the following branch of the registry: HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\SecurityProviders\WDigest.

If you want to completely disable WDigest authentication method, set the value of Negotiate parameter to 0 in the same registry branch (HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\SecurityProviders\WDigest).

To enable this feature in Windows 7, 8 and Windows Server 2008 R2 / 2012, install KB2871997 update and then set these keys in the registry. In the domain environment, it is easier to distribute the registry keys using GPO.

LSA Protection Against Connection of Third-Party Modules

In Windows 8.1 and Windows Server 2012 R2, there appeared an opportunity to enable LSA protection that provided LSA memory protection and prevented unprotected processes from accessing to it. To enable this type of protection, create RunAsPPL parameter with the value 1 in the following registry branch: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\LSA.

After this parameter has been applied, a hacker will not be able to get access to LSA memory, and mimikatz will return the following error to securlsa::logonpassword command:

ERROR kuhl_m_securlsa_acquireLSA : Handle on memory (0x00000005).

How to Disable LM and NTLM

An obsolete protocol of LM authentication, an storing LM hashes, respectively, should be disabled using Network Security: Do Not Store LAN Manager Hash Value On Next Password Change group policy (on the level of Default Domain Policy).

Then you should stop using at least NTLMv1 protocol (the policy in the section Computer Configuration -> Policies -> Windows Settings -> Security Settings -> Local Policies -> Security Options  —  Network Security: Restrict NTLM: NTLM authentication in this domain), or NTLMv2 as well, which is even better.

If disabling NTLMv1 usually goes without any problems, you will have to put some effort to disable NTLMv2. In the large infrastructures, as a rule, they come to the scenario of maximum restriction on using NTLMv2. It means, Kerberos authentication should be used wherever it is possible (you will have to spend some time setting Kerberos authentication on IIS and SQL), and the rest of the systems should retain NTLMv2.

How to Disable Reversible Encryption

You should explicitly prohibit storing user passwords in AD in clear text. To do it, enable the domain policy Store password using reversible encryption for all users in the domain in the Computer Configuration -> Windows Settings ->Security Settings -> Account Policies -> Password Policy section and set its value to Disabled.

Protected Users Security Group

When using the functional level of Windows Server 2012 R2 domain, you can use a special security group Protected Users to protect privileged users. In particular, these accounts are protected against compromise due to the fact that the members of the group can authenticate only using Kerberos (no NTLM, WDigest or CredSSP, etc.). Follow the link above to get more information. It is better to add the accounts of domain and servers administrators, to this group. This feature is available on the servers and will be available in Windows Server 2012 R2 (for Windows Server 2008 R2 you will have to install the above mentioned KB2871997 update).

How Prevent the use of saved passwords

You can prevent domain users from storing their passwords in Credential Manager to access the network resources.

To do it, enable Network access: Do not allow storage of passwords and credentials for network authentication policy in the Computer Configuration -> Windows Settings ->Security Settings ->Local Policies ->Security Options section.

How to Disable Credential Caching

One of mimikatz features is getting hashes of user passwords from HKEY_LOCAL_MACHINE\SECURITY\Cache key of the registry, where the password hashes of last 10 (by default) logged on domain users are saved. Usually these hashes can be used to authenticate users in the system if the domain controller is not available.

It is recommended to prohibit storing the cached credentials by enabling Interactive Logon: Number of previous logons to cache (in case domain controller is not available) policy in Computer Configuration -> Windows Settings -> Local Policy -> Security Options by changing the value of its parameter to 0.

Also, to accelerate LSASS memory clear from the credentials of logged off users, create a DWORD parameter with the name TokenLeakDetectDelaySecs and the value of 30 in HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa. It means that the memory will be cleared in 30 seconds after the user has logged off. In Windows 7, 8/ Server 2008R2, 2012, you will have to install the above-mentioned KB2871997 update to make this key work.

Credential Guard

In Windows 10 Enterprise, Windows Server 2016 a new component, Credential Guard, has appeared that allows to isolate and protect LSASS from unauthorized access. For more information, click here.

Conclusion

The methods considered above allow to considerably restrict the opportunities of mimikatz and other tools to obtain passwords and hashes of the administrators from LSASS and the system registry. Anyway, if you decided to implement these policies and methods, you should do it step-by-step with mandatory testing.

In the next article we’ll consider the best practices to improve safety in Windows networks due to the restrictions of using administrator accounts that should improve the protection of Windows domain against such attacks on the technical and organizational levels. Watch for updates!