a blog by Sander Berkouwer

I’ve written about Pass-the-Hash (PtH) attacks before. Today, I’m writing on the cleanup mechanisms to remove lingering password(hashe)s from Windows, that Microsoft has introduced with Windows 8.1 and Windows Server 2012 R2. These mechanisms help protect against Pass-the-Hash (PtH) attacks.

About LSASS

Let’s zoom out first, and see what happens under the hood, when a person logs on to a device: the credentials are sent to the Local Security Authority Subsystem Service (lsass.exe). This service is responsible for providing the single sign-on experience for the person. LSASS hosts a number of plug-ins, representing the protocols that Windows supports, including NTLM authentication, Digest authentication and Kerberos. Credentials are presented to each of these plugins, producing one-way hashes and tickets in the memory space of LSASS, that would remain there for the duration of the user session.

About Pass-the-Hash (PtH) attacks

Last year, I detailed the whitepaper that Microsoft has published in December 2012 with information on Pass-the-Hash attacks and how to to prevent lateral movement throughout a networking environment and privilege escalation though credential theft.

The whitepaper points out the following main tasks to mitigate Pass-the-Hash (PtH) attacks:

Basically, these security best practices should avoid malicious persons from gaining access to hashes that are stored by the Local Security Authority Subsystem Service (lsass.exe).

These hashes can be used, just as LSASS would use them to authenticate to resources. There’s no need (or possibility) to revert these hashes back to the password.

Introducing LSASS protection

Now, for small to medium-sized organizations, applying these best practices is hard and costly. Organizations want their people to access resources after they’ve logged on to a device and not need to authenticate each and every time they need access to additional resources. The Local Security Authority Subsystem Service (lsass.exe) allows for this type of single sign-on by storing hashes in its memory.

What if the Local Security Authority Subsystem Service (lsass.exe) could be taught a new trick and not keep these hashes around longer than strictly needed, so we can prevent credential harvesting and Pass-the-Hash attacks spreading throughout these networks?

In Windows 8.1 and Windows Server 2012 R2, Microsoft made changes to lsass.exe to make it do precisely that:

1. LSASS as a protected process

The Local Security Authority Subsystem Service (lsass.exe) can be run as a protected process, protecting it against access from improperly signed binaries.

2. Protection mechanisms for local accounts

Additionally, two well-known groups have been introduced in Windows 8.1 and Windows Server 2012 R2:

S-1-5-113
NT AUTHORITY\Local account

S-1-5-114
NT AUTHORITY\Local account and member of Administrators group

Membership to these groups is added by the system automatically. Membership of these built-in Administrators group no longer allows network traversal. This type of protection prevents lateral movement with local accounts.

3. Protection mechanisms for domain accounts

The Local Security Authority Subsystem Service (lsass.exe) removes LM hashes from its memory space.

The Local Security Authority Subsystem Service (lsass.exe) removes Kerberos tickets for domain accounts from its memory space.

The Local Security Authority Subsystem Service (lsass.exe) removes plaintext-equivalent passwords (for domain credentials) from its memory space. These include TSPkg, WDigest, Kerberos, LiveSSP and 3rd party SSP plugins to LSASS.

Note:
TSPkg is off by default in Windows 8.1 and Windows Server 2012 R2.

The Local Security Authority Subsystem Service (lsass.exe) enforces credential removal after logoff.

The Local Security Authority Subsystem Service (lsass.exe) aggressively tries to end sessions.

This way, credentials that would normally be left lingering on devices are now cleaned up. Credential reuse is no longer available, and, thus, the Active Directory environment is more secure. These protections prevent both lateral movement with domain accounts and privilege escalation using harvested credentials of privileged domain accounts.

Requirements

This new removing lingering credentials behavior for the Local Security Authority Subsystem Service (lsass.exe) does not require any configuration. It, also, doesn’t require a specific Domain Controller version, Domain Functional Level (DFL) or Forest Functional Level (FFL). These new Local Security Authority Subsystem Service (lsass.exe) protection mechanisms are on, by default.

To make the Local Security Authority Subsystem Service (lsass.exe) run as a protected process, make a change in the Windows Registry using regedit.exe (or any other registry tool you might prefer): Create a REG_DWORD value for RunAsPPL with 1 as its data in

HKLM\SYSTEM\CurrentControlSet\Control\Lsa

Afterwards, reboot the device.

Concluding

Microsoft has built several cleanup mechanisms to remove lingering password(hashes) from Windows in Windows 8.1 and Windows Server 2012 R2.

When you have no 3rd party authentication providers hooking into the the Local Security Authority Subsystem Service (lsass.exe) and are looking for extended protection against tools like the Windows Credentials Editor (wce.exe) and Mimikatz, I recommend to seriously look at running lsass.exe as a protected process.

Of course, none of these protections fully protect against credentials theft; a keylogger could still steal passwords…

Archives

Categories

The information on this website is provided for informational purposes only and the authors make no warranties, either express or implied. Information in these documents, including URL and other Internet Web site references, is subject to change without notice. The entire risk of the use or the results from the use of this document remains with the user.Active Directory, Microsoft, MS-DOS, Windows, Windows NT, and Windows Server are either registered trademarks or trademarks of Microsoft Corporation in the United States and/or other countries. All other trademarks are property of their respective owners.