By Henrique Pina

Vulnerability Management consists of the “cyclical practice of identifying, classifying, prioritizing, remedying and mitigating software vulnerabilities” (Wikipedia). Tempest’s Vulnerability Management team is responsible for activities that range from answering our clients’ questions about the vulnerability correction procedure to performing troubleshooting in the environment when applying security recommendations or vulnerability correction procedures. Therefore, in some cases, the team is questioned about procedures to mitigate specific attacks. Among the inquiries, for several times, we were questioned about how to block Mimikatz, which inspired this blog post.

Mimikatz is a tool that was made publicly available by the researcher Benjamin Delpy and, since then, has become indispensable in the arsenal used by both pentesters and attackers and malware in real compromising scenarios. Mimikatz is widely known for its credential extraction capabilities in Windows operating systems. Among its funcionalities, we highlight: extraction of flat text passwords stored in memory; password hashes stored in SAM; passwords stored in browsers such as Google Chrome and Microsoft Edge; and the creation of fake tickets for authentication via Kerberos.

It is understandable that this type of request, made by customers, is made with the intention of blocking the execution of Mimikatz and, consequently, preventing attackers from successfully extracting valuable credentials, often leading to the total compromise of Active Directory environments. However, considering Mimikatz execution blocking in isolation as an effective measure for the credential theft problem can generate a false sense of security. Due to its capabilities, all major antivirus manufacturers already have the signature (or should have) for its blocking. However, as already widely reported, simple modifications to the software code can make it impossible for the antivirus to block it. In addition, PowerShell makes it possible for Mimikatz to run in several different ways, increasing the chances of detection evasion.

It is important to mention that the malicious actions that can be performed with Mimikatz need a high level of permission. That is, to perform an attack with Mimikatz, it is necessary that the attacker already has a high permission level in the operating system. Thus, we consider that the measures to prevent the use of Mimikatz in the environment are not restricted only to the blocking of the software itself, but to a set of measures with the purpose of avoiding that unauthorized users obtain success in the execution of commands in an administrative way in any Windows asset of the environment. Far beyond blocking a binary, these measures involve:

1. Parameter setting in operating systems;

2. Changes in internal behavior of the environment administrators;

3. Constant adjustment of protection and monitoring processes.

We warn that, in this blog post, we will only deal with configuration parameters of operating systems. In addition, it is worth noting that each of the points listed below has specific configuration procedures, and different levels of complexity for their proper configuration. Therefore, it is important to point out that changes can, and probably will, generate incompatibility of communication and operation among different computers and some applications and systems; therefore, it is highly recommended that any change in the environment be tested and approved before its application in the production environment.

At the time of Mimikatz’s release in 2011, the most widely used desktop version of Windows was Windows XP. Only at the end of 2011, Windows 7 surpassed Windows XP, becoming the most used version until January 2018, when it lost the leadership for Windows 10. From Windows XP to Windows 10, much has changed. Windows 10 brought numerous innovations in the mechanisms for protecting valuable credentials.

Below, we list some configuration parameters available to make it difficult for an attacker to successfully use Mimikatz:

● Prevent the use of WDigest authentication protocol

WDigest is a challenge/response authentication protocol. It is used in many cases for web service authentication. As we can see in the image below, its protocol keeps a text-plain copy of the password in memory to facilitate the Single Sign-On (SSO) process:

The process to disable WDigest depends on the version of Windows that is being configured. This is because for Windows 7, Windows 8, Windows Server 2008R2 and Windows Server 2012 versions, the KB2871997 update package must first be applied. This KB adds to the operating system several features related to credential protection. After applying the KB, it is recommended to validate whether WDigest is disabled in the registry by looking at the registry key below:

Registration Key: [HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\SecurityProviders\WDigest\]

Registration entry: UseLogonCredential

Entry type: DWORD

Value: 0

Only after WDigest is deactivated is the flat text password no longer stored in system memory.

The latest versions of Windows (Windows 8.1 and Server 2012 R2 onwards) do not require patch installation and registry key configuration; as, by default, the use of WDigest in these versions is already disabled. However, it is important to monitor changes to the registry key, as its manual modification to the value ‘1’ will enable the protocol again.

● Enable LSASS protection mode

The Local Security Authority Subsystem Service — LSASS is the Windows process responsible for performing validations during local or remote authentication. Starting with Windows 8.1 / 2012 R2, LSASS protection has been added as a security measure, in order to prevent unreliable processes from being able to read your memory or inject code into the process. TheKB2871997 package adds this functionality to versions 7, 8, 2008R2 and 2012 of Windows.

Since this is a configuration that can generate many impacts on the operation of environmental applications, it is highly recommended that a prior approval process be performed, using the audit mode to identify plug-ins and drivers that need to be loaded by the lsass.exe process.

To enable audit mode for the lsass.exe process, you must configure the registry key below:

Registration Key: [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\LSASS.exe]

Registration Entry: AuditLevel

Entry Type: DWORD

Value: 8

After configuring the audit mode, you should analyze the occurrence of events 3065 and 3066 within the ‘Microsoft-Windows-Codeintegrity/Operational’ event log.

Event 3065: This event is recorded when a process (usually lsass.exe) has tried to load a driver that does not meet the security requirements for Shared Sections. However, since the operation mode is audit mode, the loading of the image is performed without any lock.

Event 3066: This event is recorded when a process (usually lsass.exe) has tried to load a driver that does not meet the driver signature requirements. However, since the operation mode is audit mode, the loading of the image is performed without any lock.

If, after a certain period of use of the systems in audit mode, no drivers essential to the operation of the operating system — and the applications used in the environment — are recorded in the logs, it is likely that enabling lsass.exe protection mode will not cause any problems to the environment. To enable lsass.exe protection mode, you should set the registry key below:

Registration Key: [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\LSA]

Registration Entry: RunAsPPL

Entry Type: DWORD

Value: 1

Therefore, after adding the protection to the lsass.exe process, as can be seen in the following image, it will not be possible to use Mimikatz to obtain the credential information in memory:

  • Enable “Restricted Admin Mode”

Starting with Windows Server 2012 R2, Microsoft has provided an authentication method for RDP sessions to prevent local administrator credentials from being kept in plain text by the LSASS process of the remote computer being accessed. This is the Restricted Admin Mode.

An RDP session is an interactive logon. This type of logon keeps the credentials in memory for later use, preventing the password from being subsequently requested from users while they access environment resources. Authentications performed from the local computer console, remote desktop via RDP, VNC, Citrix and even RunAs, are interactive type authentication methods.

The Restricted Admin Mode is a new type of interactive logon that, unlike the conventional types, does not send user credentials during the interactive logon process.

In the example below, user1 is connected via RDP to DC02 server:

While the user is logged in, it is possible to get, through Mimikatz, access to the user password hash:

To force client computers to make use of the Restricted Admin Mode when establishing RDP connections to their environment’s servers, you can configure the following directive:

Directive Path: Computer Configuration → Administrative Templates → System → Credential Delegation

Directive Name: Restrict delegation of credentials to remote servers

It is also worth mentioning the /RestrictedAdmin parameter; because, when establishing a new RDP session, this time using that parameter — /RestrictedAdmin — from the mstsc.exe client, the result obtained with the execution of Mimikatz is not the same, as we will see in the following two images:

Connecting to the server using the ‘RestrictedAdmin’ parameter:

Result of Mimikatz execution on the server where ‘user1’ connected itself:

You can see that sensitive information related to ‘user1’ no longer appears. Although ‘user1’ is the user associated with the remote interactive logon, the credentials that Mimikatz extracted are those of the DC02$ computer account, not the user’s credentials.

It is important to know that there is a trade-off between exposing the password hash of an administrator account or the password hash of the computer account to which the administrator user is establishing the RDP connection. As a result of exposing the computer account password hash, the computer in question becomes susceptible to pass-the-hash attacks for RDP connections. That is, an attacker with such a hash can connect to the computer via RDP. It happens that, as we have already stressed at the beginning of this blog post, the use of Mimikatz for credential extraction requires a privileged level of access to the system; that is, the attacker would already need to have privileged access on the server to obtain this hash of the computer account. Hash that, regardless of the existence or not of an RDP connection through the Restricted Admin Mode, would be available to the attacker with privileged access.

The purpose of the functionality is to protect and minimize the exposure of the credentials of users with administrative profile. In addition, permissions, rights and privileges are not normally granted to computer accounts, but to user accounts. However, each environment has specific features that will require specific settings. Therefore, it is important that the functionality is studied and evaluated internally in order to define the feasibility or not of the implementation.

● Avoid the reuse of administrator passwords on the stations and servers of the environment

It is common in corporate environments for administrators to automate the process of deploying workstations and servers from the use of images. The use of a single image usually results in the same local administrator credential for all workstations and/or servers in the environment. Once an attacker obtains privileged access to a workstation or server, and performs the extraction of that local credential, they can quickly gain access to an asset in which an environment administrator is logged on, thus achieving administrative domain permissions.

Microsoft provides a tool that performs the management of the operating system local administrator credential, the Local Administrator Password Solution — LAPS. From a client, LAPS performs the password change of the local account ‘Administrator’ and stores it in an attribute of the object ‘computer account’, in Active Directory. Reading permission in this attribute can be delegated to help desk analysts, environment administrators or other necessary users and groups.

  • Use the security group “Protected Users”

The Protected Users group has been added as a Windows Server 2012 R2 domain resource. User accounts in this group will receive additional, unmodifiable protections, which, in large part, are related to the non-storage of text-plain credentials. In short, user accounts that are part of this group can only perform authentication on the domain and environment services through Kerberos. Additionally, authentication via Kerberos now restricts the use of ciphers considered weak by current standards, giving preference to the use of AES.

  • Restrict the concession of the priviledge “Debug Privilege”

The user right “Debug Programs” is a very powerful one because it allows a user to use a debugger in operating system processes or in the kernel. This right is used by Mimikatz to perform credential extraction from the LSASS process.

The following image shows a user-initiated ‘lambao’ session. In it we can see which users belong to the local group ‘Administrator’ of the workstation; as well as to which groups the user ‘lambao’ belongs in the domain.

From the image above, you can also see that the user account ‘lambao’ does not belong to the local group ‘Administrators’;14 and, in the domain, it only belongs to the default group ‘Domain Users’. That is, it is not a credential with administrative privilege level.

On the same station, the user account ‘lambao’ has been assigned the user right ‘Debug programs’, as shown in the image below:

By running Mimikatz with the ‘lambao’ credential, it was possible to access the credentials stored on the workstation, as shown below:

  • Prevent caching of credentials

Caching credentials is also one of the methods verified by Mimikatz for credential extraction. Cached credentials are usually stored in order to enable authentication of domain users during the period when communication with domain controllers is not possible. This parameter can be configured and its initial value is 10 stored credentials.

To configure the operating system so that it does not allow cached user credentials to be stored, the following directive must be followed:

Directive Path: Computer Configuration → Windows Settings → Security Settings → Local Policies → Security Options

Directive Name: Interactive logon: Number of previous logons to cache (in case domain controller is not available)

When disabling credential caching, Mimikatz will not get any input.

  • Use of software restriction policies

The model normally used to carry out blockages of unwanted software, such as malware for example, is based on signatures. Periodically, the software used to carry out the blockings downloads a base of signatures made available by the manufacturer. From this database, a decision will be made about which applications cannot be run on the operating system. This approach is important and does much of the work of detecting and blocking malicious codes. However, for the level of threats currently encountered, and especially for cases of targeted attacks (where malicious artifacts are specifically created for the chosen target), the strategy will not be enough to detect and prevent the execution of malicious code in the operating system.

A different way to approach the problem is by operating in the opposite model, i.e. informing to the operating system what can be executed (.EXE, .DLL, .PS1, .BAT, etc.), while everything else will be immediately denied. Based on this dynamic, it is possible to ensure that a much larger number of malicious artifacts are blocked.

Some market solutions perform this kind of restriction. Microsoft also provides tools to perform this type of blocking such as AppLocker and, the latest, Windows Defender Application Control.

These are some, but not all, configuration options that can be performed on Windows systems in order to make it difficult to successfully run Mimikatz.

As we mentioned at the beginning of the post, there are aspects related to the behavior of administrators that need to be modified, avoiding some situations considered “normal” today. Monitoring systems also need special attention, being properly equipped with appropriate event logs and configured with effective alert generation mechanisms, so that containment measures are initiated as soon as possible, even in events where technical measures are not able to block the advance of an imminent attack.