On July 10, 2014, I first wrote about Windows Local Security Authority (LSA) in the article Windows passwords – a well-known secret?. Over the last five years, Microsoft has made several improvements in this area. Nonetheless, credentials can still be extracted from the memory in 2019. This article summarizes the developments over the last few years and presents options for hardening.

The Local Security Authority Subsystem Service (LSASS) is responsible for implementing the security policy, verifying users, processing password changes, creating access tokens and managing smart cards. To do so, various security modules called Security Support Providers (SSP) are loaded into the LSASS process. These security modules include Kerberos, NTLM (MSV1), TLS/SSL (Schannel) and Digest (WDigest). Passwords stored in the memory can be accessed via these security modules.

Times were grim for password security in the memory prior to Microsoft Security Advisory 2871997. The passwords were stored as plain text by the Kerberos or WDigest modules. Tools such as Mimikatz or Windows Credentials Editor (WCE) had no trouble at all extracting these passwords.

Once Advisory 2871997 had been published, it was possible to harden the system so that passwords were no longer stored as plain text. For WDigest, the registry key UseLogonCredential=dword:00000000 can be set under HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\SecurityProviders\WDigest.

The Credential Delegation function also affects whether passwords can be read from the LSASS memory as plain text. You can preventively disallow this by configuring the following settings:

• Computer Configuration\Administrative Templates\System\Credentials Delegation\Allow delegation default credentials to Disabled (tspkg)
• Computer Configuration\Administrative Templates\System\Credentials Delegation\Encryption Oracle Remediation to Enabled: Force Updated Clients

A missed opportunity

With Windows 8.1 and Windows Server 2012 R2, Microsoft introduced the Additional LSA Protection function. This makes it possible to configure the LSASS process as a Protected Process Light. To do so, the registry key RunAsPPL=dword:00000001 must be set under HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa. After that, the security modules must be signed by Microsoft and additonally non-protected processes are no longer able to access the LSASS store and therefore the credentials.

As noted in the article Monitoring – detecting attacks with MITRE ATT&CK, Mimikatz can still be used to access the LSASS process and extract credentials. To do this, Mimikatz must be used to load a driver that has been signed correctly for running in kernel mode, thereby raising the bar for access. A Security Operations Center can also monitor Windows event logs to detect this attack and respond accordingly.

According to our observations during assessments, the LSA Protection function is used surprisingly little, neither on servers nor on client systems.

Credential Guard

Credential Guard was introduced with Windows 10 and Windows Server 2016. In the article Credential and Device Guard – is the tide turning?, I concluded that it will probably take years until Credential Guard is widely used. The higher requirements for operating Virtual Secure Mode (VSM), licensing requirements (Windows Enterprise), and incompatibilities with applications further delay implementation. In contrast to the LSA Protection function, however, we increasingly come across Credential Guard being used in practice.

Credential Guard protects domain credentials. Local accounts, Microsoft accounts and smart card PIN codes remain unprotected. For local administrator credentials, solutions such as the Local Administrator Password Solution (LAPS) or third-party products are available to ensure that all local administrator accounts have unique passwords on all systems.

As of November 2019, there has been no publicly known direct attack on Credential Guard. There are workarounds like using Mimikatz to load a security module, which logs the credentials of all locally authenticated accounts. However, this can be made more difficult by activating LSA Protection as this allows only SSPs signed by Microsoft to be loaded, or Mimikatz must first be used to remove this protection.

Other hardening options

In addition to the already mentioned LSA Protection and Credential Guard functions, additional security components can help protect credentials. On most systems, administrator debug privileges (SeDebugPrivilege) can be revoked. These rights are required in order to use a debugger for any process or the kernel. These rights are rarely used in normal operation. Tools like Mimikatz need these rights to interact with the LSASS process. This right can be revoked from the local administrator group under Computer Configuration\Windows Settings\Security Settings\Local Policies\User Rights Assignment\Debug programs with a group policy.

Using an application whitelisting solution offers further protection against malware and implementing an extensive monitoring solution helps detect possible abuse.

Conclusion

The functions and hardening measures introduced by Microsoft improve the protection of the LSASS process. Successful implementation of the listed measures in a system makes it significantly harder to extract credentials. This is particularly important because many malware programs use credential dumping and utilize Mimikatz or WCE components to do so. By combining the listed measures, secrets can be stored safely in the Local Security Authority where they are now protected from such attacks.

About the Author

Michael Schneider has been in IT since 2000. Since 2010 he is focused on information security. He is an expert at penetration testing, hardening and the detection of vulnerabilities in operating systems. He is well-known for a variety of tools written in PowerShell to find, exploit, and mitigate weaknesses. (ORCID 0000-0003-0772-9761)

Links

• https://adsecurity.org/?p=1760
• https://attack.mitre.org/techniques/T1003/
• https://docs.microsoft.com/en-us/security-updates/SecurityAdvisories/2016/2871997
• https://github.com/gentilkiwi/mimikatz
• https://www.ampliasecurity.com/research/windows-credentials-editor/