Preventing Mimikatz Attacks

Panagiotis Gkatziroulis
Blue Team
Published in
7 min readAug 9, 2018

Mimikatz is playing a vital role in every internal penetration test or red team engagement mainly for its capability to extract passwords from memory in clear-text. It is also known that adversaries are using Mimikatz heavily in their operations. Even though that Microsoft introduced a security patch which can be applied even in older operating systems such as Windows 2008 Server still Mimikatz is effective and in a lot of cases it can lead to lateral movement and domain escalation. It should be noted that Mimikatz can only dump credentials and password hashes if it is executed from the context of a privilege user like local administrator.

Debug Privilege

The debug privilege according to Microsoft determines which users can attach a debugger to any process or to the kernel. By default this privilege is given to Local Administrators. However it is highly unlikely that a Local Administrator will need this privilege unless he is a system programmer.

Debug programs privilege — Local Administrators

In a default installation of Windows Server 2016 the group policy is not defined which means that only Local Administrators have this permission.

Debug programs privilege — Group Policy

From the attackers perspective this check can be performed through Mimikatz with the following command:

privilege::debug
Check to validate debug privilege

Mimikatz requires this privilege as it interacts with processes such as LSASS. It is therefore important to set this privilege only to the specific group of people that will need this permission and remove it from the Local Administrators. The SeDebugPrivilege can be disabled by defining the policy to contain no users or groups.

Group Policy Management Editor -> Windows Settings -> Security Settings -> Local Policies -> User Rights Assignment -> Debug programs -> Define these policy settings:
Disable the SeDebugPrivilege

When the new policy is applied across the domain an attacker that has managed to escalate his privilege to local administrator he will not be able to use this permission. Mimikatz will respond with the following message:

Mimikatz — Debug Privilege Disabled

WDigest

WDigest protocol was introduced in Windows XP and was designed to be used with HTTP Protocol for authentication. Microsoft has this protocol enabled by default in multiple versions of Windows (Windows XP — Windows 8.0 and Windows Server 2003 — Windows Server 2012) which means that plain-text passwords are stored in the LSASS (Local Security Authority Subsystem Service). Mimikatz can interact with the LSASS allowing an attacker to retrieve these credentials through the following command:

sekurlsa::wdigest
Mimikatz — WDigest

Microsoft in Windows 8.1, Windows 10, Windows Server 2012 R2 and Windows Server 2016 has disabled this protocol by default. However if your organisation is using older operating systems such as Windows 7 and Windows Server 2008 etc. Microsoft has released a patch (KB2871997) which allows administrators to enable or disable the WDigest protocol. After applying the patch it is recommended to validate that the WDigest is disabled from the registry.

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\SecurityProviders\WDigest
WDigest — Disabled

The Negotiate and UseLogonCredential registry keys values should be set to 0 to completely disable this protocol. It should be noted that in newer operating systems (Windows Server 2016, Windows 10 etc.) the UseLogonCredential registry key doesn’t exist. Of course an attacker with Local Administrator privileges can modify the registry to enable WDigest and grab credentials as it has been explained greatly by Dave Kennedy in his blog. Therefore if these values are set to 1 after disabling this protocol then this is an indication of an attack. Registry modification should be constantly monitoring to get the alert at an early stage and catch the threat.

Attacker attempts to retrieve the plain-text credentials from WDigest will fail if this protocol is disabled:

Mimikatz — WDigest Disabled

LSA Protection

The Local Security Authority Server Service (LSASS) validates users for local and remote sign-ins and enforces local security policies. Microsoft in Windows 8.1 and later has provided additional protection for the LSA to prevent untrusted processes from being able to read its memory or to inject code. Attackers were able to execute the following Mimikatz command in order to interact with the LSA and retrieve clear-text passwords that were stored in the memory of the LSA.

sekurlsa::logonPasswords
Mimikatz — Interact with LSA

It is advised that systems prior to Windows Server 2012 R2 and Windows 8.1 should enable the LSA protection to prevent Mimikatz from accessing a specific memory location of the LSASS process. This protection can be enabled by creating the registry key RunAsPPL and setting the value 1 in the following registry location.

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\LSA
LSA Protection Enabled

In a system that has enabled the LSA protection the attacker will get the following error:

Mimikatz — LSA Protection

Restricted Admin Mode

Microsoft has introduced in Windows Server 2012 R2 an additional security feature which can prevent plain-text credentials of Local Administrators to be stored in LSASS during an RDP session. Even though LSA protection can prevent Mimikatz from retrieving the credentials it is advised to use this feature as an additional layer of security in case an attacker disables the LSA protection.

The “DisableRestrictedAdmin” registry key should be created in the following location with the value 0 in the systems in the network that will be allowed to receive RDP sessions in restricted admin mode. Furthermore, the “DisableRestrictedAdminOutboundCreds” registry key should be created with the value 1 to disallow network authentication from inside the system that the admin has performed the RDP. Absence of this key it means that Admin outbound credentials are enabled.

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Lsa
Restricted Admin Mode — Enabled

The “Restrict delegation of credentials to remote servers” policy needs to be enforced across the domain to ensure all outbound RDP sessions are using the “RestrictedAdmin” mode and therefore credentials are not leaked.

Restrict Delegation of Credentials — Group Policy

The policy needs to be enabled with the “Require Restricted Admin” setting.

Restrict Delegation of Credential — Enabled Restricted Admin

Once this policy is enforced, Administrators can RDP remotely to workstations and servers that have the required registry key with the following switch from windows run.

Restricted Admin Mode Switch — Run

Or executing it directly from a command prompt.

Restricted Admin Mode Switch — Command Prompt

For older operating systems prior to Windows 2012 R2 and Windows 8.1 this option is part of KB2871997 Microsoft patch.

Credential Caching

In the event that the domain controller is unavailable Windows will check the last password hashes that has been cached in order to authenticate the user with the system. These password hashes are cached in the following registry setting:

HKEY_LOCAL_MACHINE\SECURITY\Cache

Mimikatz can retrieve these hashes if the following command is executed:

lsadump::cache

By default Windows are caching the last 10 password hashes. It is recommended to prevent local caching of password by changing the following security setting to 0.

Computer Configuration -> Windows Settings -> Local Policy -> Security Options -> Interactive Logon: Number of previous logons to cache -> 0
Interactive Logon — Do not cache logons

Attacker attempts to retrieve these password hashes with Mimikatz will fail:

Mimikatz — Credential Caching Disabled

Protected Users Group

Microsoft in Windows Server 2012 and later has introduced a new security group which is called “Protected Users”. This group enables domain administrators to protect privilege users like Local Administrators as any account that is part of this group can authenticate with the domain only via Kerberos. This would assist to prevent leakage of NTLM password hashes or plain-text credentials in the LSASS for sensitive accounts that typically attackers would aim.

The “Protected Users” security group can be found in the Active Directory Users and Computers.

Active Directory — Protected Users Security Group

Accounts that will be part of this security group will automatically fall into the Kerberos policy in terms of authentication which by default is configured as below:

Kerberos Default Policy

Alternatively accounts can be added into the “Protected Users” group from PowerShell by executing the following command:

Add-ADGroupMember –Identity 'Protected Users' –Members Jane
Protected Users Group — Add Accounts via PowerShell

Older operating systems like Windows Server 2008 can still have this security group by applying the patch KB2871997 from Microsoft.

Conclusion

Adding another layer of security by using an effective endpoint solution combined with Application Whitelisting like AppLocker to prevent portable executables, PowerShell and command prompt from execution it is also recommended. Even if a cyber attacker has achieved to bypass these controls, perform registry modifications (certain registry keys should be monitored by the blue team) in order to fully utilize Mimikatz for credential dumping a number of events will be generated during this process which can assist to detect the attack.

--

--