Strengthen the security of your environment against hackers!

 Michal Švec

Nowadays, when it is possible to find a large number of tools and instructions on the open Internet on how to break the security restrictions of a computer and thus take control of it or obtain the credentials of another account, almost anyone can become a hacker. One of such very common utilities is Mimikatz. Mimikatz is very effective for various techniques of account compromising, and in a poorly secured computer, you can use it to, for example, obtain credentials of a privileged domain account or escalate your own authorization.

Here are some recommendations how to mitigate these risks as a domain administrator:

1. Restrictions of debugging authorization

The authorization to connect the debugger to the process is mostly needed only for programmers and from the point of view of the system it is not necessary otherwise. But thanks to this option, Mimikatz can manipulate a sensitive process such as LSASS through the local administrator's account. By default, the right for the Administrators group is set in Windows.

I therefore recommend enforcing a policy for the end stations where a special or no group will be defined for this right.

Computer Configuration -> Windows Settings -> Security Settings -> Local Policies -> User Rights Assignment -> Debug programs -> Define these policy settings:


2. Turning off the WDigest protocol

It is an outdated protocol for HTTP authentication that allows an attacker to obtain passwords from LSASS in a readable form. As of OS Windows 8.1 / Windows Server 2012 R2, this feature is disabled by default, however, for older systems, it is necessary to install patch KB2871997 and then disable this protocol using the registry.

Therefore, it is recommended that you enforce these settings on system registries:


Negotiate = 0 (REG_DWORD)

UseLogonCredential = 0 (REG_DWORD)

Of course, a potential attacker can easily change this key as needed, so it is advisable to monitor the status of this key and consider the changes as a potential attack.

3. LSA Protection

The critical LSASS process, which is responsible for validating user logins, has received an additional level of protection against abuse from Windows 8.1 so that the passwords cannot be read directly from RAM. Older systems can enable LSA protection by adding a registry key:



4. Restricted Admin Mode

With the arrival of Microsoft Windows Server 2012 R2, the "Restricted Admin Mode" feature has been introduced to prevent the administrator credentials from being exposed in a readable form through an RDP connection. For older systems, the feature is accessible again via update KB2871997.

I recommend enforcing this feature wherever administrator accounts are used through an RDP connection. The complete Restricted Admin Mode setting is done in two steps:

  1. Enabling the feature for incoming RDP connections

    The following registry key must be created on servers and endpoints that accept RDP connections:


    DisableRestrictedAdmin = 0 (REG_DWORD)

  2. Enforcing the feature for all outgoing RDP connections

    On devices from which you will use admin accounts to manage other computers, turn on policy assistance so that Restricted Admin Mode is always required:

    Computer Configuration -> Administrative Templates -> System -> Credentials Delegation -> Restrict delegation of credentials to remote servers -> Enabled / Require Restricted Admin



The RDP connection in Restricted Admin Mode is then made using the command:

mstsc /restrictedadmin

5. Credential Caching

When a computer has an unavailable domain controller, it is set by default to authenticate the data that are stored in the local cache. By default, this cache stores the last 10 password hashes. Again, Mimikatz can easily obtain and use these hashes.

Where possible, I recommend disabling this cache. The settings are made using the Group Policy Manager and the policy applied to the end stations:

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

6. Protected User Groups

Microsoft Windows Server 2012 R2 has introduced a new security group "Protected Users". This group sets stronger security rules, especially for privileged accounts. Including an account in this group significantly enhances security against abuse through the multiple techniques that Mimikatz allows. The list of settings and restrictions given by this group is given here:

It is recommended that you add all sensitive accounts to the Protected Users AD group.

Share on social media



Didn't find what you were looking for? Send us a message and we will stay in touch with you.

* Required field. We will only use personal data to prepare an answer to your inquiry. Privacy Terms.

* Data processing consent

map us
map eu