Easy Wins for Active Directory – Part 3

In part 1 of this three-part series, we covered vulnerabilities related to NetBIOS Name Service (NBNS) and Link-Local Multicast Name Resolution (LLMNR) protocols. In part 2, we discussed detection methods for Server Message Block (SMB) version 2 (SMB2) and related fixes. This final part of the series explains how to protect clear-text passwords in memory on Windows machines from attackers.

One of the most prevalent tools used in both real-world attacks and penetration tests to capture clear-text passwords is Mimikatz. We will be using snapshots from Mimikatz to describe how many attacks work, as well as pictures from Active Directory (AD) and Group Policy to describe how prevention is accomplished.

Windows software has mitigated many of these attacks on its own throughout the years. For example, starting with Windows 8.x, by default there are no passwords in memory. However, there are some edge cases to be aware of:

• When a domain controller (DC) is unreachable, Kerberos will keep passwords for future login attempts.
• When HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlSecurityProvidersWDigest, UseLogonCredential (DWORD) is set to 1, WDigest will retain credentials.
• When HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlLsaCredsspPolicyDefaults is set to allow, Credential Security Support Provider (CredSSP) will retain credentials
• When HKEY_LOCAL_MACHINESOFTWAREPoliciesMicrosoftWindowsCredentialsDelegation is set to allow, CredSSP/tspkgs will retain credentials.

Remove Windows Debug Permissions

For Mimikatz to be able to dump credentials from the Local Security Authority Subsystem Service (LSASS) process, it needs debug privileges or a SYSTEM account. Debug privileges allow a user to attach a debugger to a process or the kernel. By default, administrator accounts have this permission but, depending on the environment, other users may also possess this permission. Using the following command, Mimikatz will attempt to gain the needed level of permissions:

privilege::debug

The preceding screenshot shows Mimikatz successfully checking for debug privileges. The easiest way to mitigate this is to use Group Policy to remove all users and groups from the “Debug programs” policy in Group Policy at the following location:

Windows Settings -> Security Settings -> Local Policies -> User Rights Assignment -> Debug programs

Once the policy is configured and deployed, Mimikatz will fail even as an administrative user.

However, this does not stop an attacker who has gained control of the SYSTEM account.

Enable LSASS Protections

Previously, using Mimikatz on older versions of Windows, the following command could be run to retrieve clear-text/hashed passwords from the LSASS service:

sekurlsa::logonPasswords

Starting in Windows 8.1 and Windows Server 2012, Microsoft added additional protections to the LSASS process. Out of the box, however, this added protection is not enabled. Microsoft has published guidance on how to configure additional LSA protection. It is advised to read the guidance before making the following change, as the registry change could affect plug-ins or drivers. To enable the added protections, create the following Group Policy:

Computer Configuration -> Preferences -> Windows Settings -> Registry

Create a new registry item with the following:

HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlLsa

Value Name: RunAsPPL

Value Type: DWORD

Value: 00000001

Once the Group Policy is deployed and running, the same command in Mimikatz will fail to pull the password data from memory.

Disable WDigest

In earlier versions of Windows (starting in XP), Microsoft added WDigest. WDigest is an authentication protocol that works with Hypertext Transfer Protocol (HTTP) and the Simple Authentication and Security Layer (SASL) exchanges. It was mostly used for authentication to web applications. However, in the modern age, it has become obsolete and a major security risk, as WDigest holds user credentials in clear text. Using Mimikatz, the credentials can be extracted using the following command:

sekurlsa::wdigest

For versions later than Windows Server 2012 R2 and Windows 8.1, WDigest is disabled by default. On previous Windows operating systems, a patch from Microsoft is required. If your systems are up to date, the patch should already be installed. However, to disable WDigest, the following registry key must be updated/created:

HKEY_LOCAL_MACHINESystemCurrentControlSetControlSecurityProvidersWDigest
Value Name: UseLogonCredential
Value Type: DWORD
Value: 00000000

Once this registry key has been deployed via Group Policy, Mimikatz will fail to pull WDigest passwords from memory.

Disable Credential Caching

By default, Windows caches credentials for use in case a DC is unavailable. While these credentials are not stored in memory, they are stored in the Windows Registry and are readily accessible. These credentials can be dumped easily with Mimikatz with the following command:

lsadump::cache

The best way to mitigate this is by making a simple registry change:

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

However, it is important to note that you may want to have two different Group Policies for laptops and desktops, as not having credentials cached may leave some users stranded when their laptop is taken off site.

Once credential caching is disabled, Mimikatz will give the following error, stating that it is unable to open the registry keys:

Leverage “Protected Users” AD Group

Starting in Window Server 2012 R2, Microsoft introduced a new security group with the purpose of protecting users’ credentials named “Protected Users.” As a note, to get the most out of this group, a domain functional level of at least 2012 R2 is required. Users who are a part of this group have the following protections added:

• Default credential delegation (CredSSP) – clear-text credentials are not cached even when the Allow delegating default credentials policy is enabled
• WDigest – clear-text credentials are not cached even when enabled
• NT LAN Manager (NTLM) – NT One Way Function (NTOWF) is not cached
• Kerberos long-term keys – Kerberos ticket-granting ticket (TGT) is acquired at logon and cannot be re-acquired automatically
• Sign-on offline – the cached login verifier is not created

Additionally, with a functional domain level of at least 2012 R2, the following is no longer allowed:

• Authenticate by using NTLM authentication
• Use Data Encryption Standard (DES) or RC4 cipher suites in Kerberos pre-authentication
• Be delegated by using unconstrained or constrained delegation
• Renew user tickets (TGTs) beyond the initial four-hour lifetime

Before enabling and widely using this group, it is recommended to read Microsoft’s guidance, as there are some caveats.

Enable Restricted Admin Mode

In Windows Server 2012 R2 and later (8.1 included), Microsoft added support for Restricted Admin mode. This mode protects users’ credentials during Remote Desktop Protocol (RDP) sessions/connections. Normally when a user logs in via RDP, the user’s credentials are stored on the system to which the user is logging in. Using the Restricted Admin mode configuration will prevent the credentials from being stored during the authentication process. With this configuration enabled, users will have to call the RDP module via the command line with the following command to connect via RDP:

mstsc /restrictedadmin /v:

This might be a challenge for some users depending upon their skill level. There are also some other drawbacks to using this feature. Many tools, such as Server Manager and PSRemoting, will no longer function seamlessly, as the logging-on user’s credentials will not be passed. As always, you can look to Microsoft’s guidance around this security control.

Leverage Credential Guard

The most recent tool that Microsoft added to Windows 10 and Server 2017 (and later) is Windows Defender Credential Guard. This new tool leverages virtualization to encapsulate the LSA process, which Microsoft refers to as isolated LSA (LSAIso). Since this new process is isolated via virtualization, it is not accessible to the rest of the operating system.

As should be expected, there are limitations that using this tool creates. As an example, NTLMv1, MS-CHAPv2, WDigest, and CredSSP cannot use the signed-in credentials. This will break many single sign-on (SSO) implementations that use these protocols. Microsoft has generated a list of considerations that should be reviewed to understand how Credential Guard will interface with your environment. Also, be aware that there are some hardware requirements associated with using Credential Guard. However, most three-year-old or newer systems shouldn’t have issues. Credential Guard can be enabled by following this guidance from Microsoft.

Final Thoughts

As demonstrated, there are many ways to protect user credentials both in memory and at rest. While this post includes several common methods of doing so, this is not a comprehensive list. As always, research which solutions fit best into your environment. Start with the basics and then work your way up to more complex controls. Remember that a complex control does not help your environment if basic patching and vulnerability scanning is not in place.

If your organization has any questions about how to improve the security of your environment, you can always contact  Sikich’s team of cybersecurity experts for help.