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.
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:
- Restrict and protect high privileged domain accounts
- Separate administrative accounts from user accounts for administrative personnel
- Create specific administrative workstation hosts for administrators
- Restrict server and workstation logon access
- Disable the account delegation right for privileged accounts
- Restrict and protect local accounts with administrative privileges
- Enforce local account restrictions for remote access
- Deny network logon to all local accounts
- Create unique passwords for privileged local accounts
- Restrict inbound traffic using the Windows Firewall
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:
NT AUTHORITY\Local account
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
For domain accounts, LSASS offers these protection mechanisms in Windows 8.1 and Windows Server 2012 R2:
- 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.
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.
The latter two protection mechanisms result in the following table, indicating the availability of reusable credentials as seen in the Pass-the-Hash: How Attackers Spread and How To Stop Them presentation by Mark Russinovich and Nathan Ide at Microsoft TechEd North America 2014:
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
Afterwards, reboot the device.
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…
Security Thoughts: Pass the Hash and other Credential Theft
Local Security Authority Sybsystem Service
Intercepting pass-the-hash attacks
Stop pass-the-hash attacks before they begin
Dissecting the Pass the Hash Attack
Tools used in the TechEd session by Marcus Murray and Hasain Alshakarti
TechEd: Pass the Hash: Preventing Lateral Movement (ATC-B210)
Password Cracking ‘Pass The Hash’ style
New Guidance to Mitigate Determined Adversaries’ Favorite Attack: Pass-the-Hash
Pass The Hash
Hardening your Windows Client
Mitigating "Pass the Hash"…