Pass the hash (PtH) is a decades-old attack technique, but it remains a valuable tool in a cybercriminal’s arsenal to this day. Indeed, pass the hash is one of most difficult attacks to thwart. Why?
In a nutshell, pass the hash enables an adversary to compromise an Active Directory account — without ever knowing the account’s cleartext password (the actual string of characters that the user types to log in). Instead, all the hacker needs is the hash of the password. Using it, they can move laterally through the network while evading detection, stealthily elevating their privileges until they achieve their goal.
In this post, I’ll explain what a password hash is, how pass the hash attacks work and what steps you can take to defend your organization against them.
What is a password hash? What are they used for?
A password hash is an encrypted version of your password. For example, the cleartext password “password123” might have the hash “7383946155”. Password hashes are created by an algorithm that has two important features:
- It is repeatable — The same password will always generate the same hash.
- It is one-way— While it’s easy to transform a password into a hash, there is no way to transform the hash back into the password.
Password hashes provide a way to authenticate a user — determine whether they are who they claim to be — without sending their cleartext password across the network. In particular, password hashes are used by the Microsoft NTLM challenge-response authentication protocol. Here’s how NTLM authentication proceeds when I attempt to log on to my corporate network:
- I type in my username and cleartext password on my computer.
- My computer runs the password I typed through a standard hashing algorithm to get my password hash, which it will need in Step 5.
- My machine sends the nearest domain controller DC a logon request, which includes my username but not my password nor my password hash.
- The DC sends back a random number, which is known as a logon challenge.
- My computer encrypts the logon challenge using the hash of my password and sends the result (response) back to the DC.
- The DC has a database of password hashes for all the users in the domain, which were created using the same hashing algorithm that my client machine uses. Using the password hash for my username as sent in Step 3, it encrypts the logon challenge, and compares the result with the response my computer sent. If they match, that proves I entered the correct password, and I’m authenticated.
- To spare me from having to keep entering my password every time I want to access another IT resource, my computer stores my password hash in memory and uses it on my behalf to enable single sign-on (SSO).
Now you can see why NTLM is called a challenge-response protocol and why password hashes are essential to the NTLM authentication process.
How does a pass the hash attack work?
A pass the hash attack enables an adversary to skip steps 1 and 2 of this process. If they have the user’s password hash, they don’t need the cleartext password; they can use a hacking tool like mimikatz to send the logon request and respond properly to the DC’s logon challenge. Bingo! They are authenticated, and just like me, they enjoy the benefits of SSO.
Now the attacker is free to move laterally and escalate their privileges. Among other things, they can harvest other hashed passwords from the LSASS memory of the system they are logged into. Each new machine may have yet more hashes, including privileged ones. One way this happens is that an IT pro with a privileged account logs into a user’s machine locally or uses RDP to work remotely on an issue, leaving their password hashes behind in memory. If the adversary reaches a system where highly privileged admin or service accounts have logged in, the game is over — they gain access to the most critical areas of your Windows network. They can steal sensitive data, install remote access tools (RATs), change Group Policy to spread malware or ransomware, and more.
So, how does an adversary get a user’s password hash? Well, as the steps above illustrate, both my machine and the DC have the password hash. Specifically, password hashes are stored in the memory of the Local Security Authority Subsystem (LSASS) process of the local machine and in the ntds.dit database on the domain controller. If the adversary has compromised admin privileges on the computer, they can extract password hashes from the LSASS process memory; to get hashes from the DC, they can steal the file using a tool such as PowerSploit NinjaCopy and extract the hashes using the DSInternals PowerShell module.
How can I defend against pass the hash attacks?
Defending against pass the hash attacks is difficult for several reasons. One option might seem to simply get rid of NTLM authentication. After all, NTLMv1 dates back to 1993 and NTLMv2 was released just a few years later. Their weaknesses are well known and are not limited to pass the hash attacks. (For details, please see this blog post on NTLM authentication.) As a result, in Windows 2000, Microsoft replaced NTLM as the default authentication protocol with a much stronger protocol called Kerberos. However, many corporate applications still require NTLMv1 or NTLMv2 authentication, so organizations often cannot simply disable these protocols. Moreover, even when NTLM can be eliminated, Kerberos is vulnerable to a similar attack called pass the ticket, in which adversaries use stolen Kerberos tickets (rather than password hashes) to authenticate without having to know a user’s password.
Still, there are solid strategies that can help you defend your organization against pass the hash attacks. They include the following:
Keep attackers from getting a foothold to launch pass the hash attacks.
To perform a pass the hash attack, an adversary must have gained a foothold in your network. Therefore, everything you can do to keep them out is a plus. Best practices include using a tool that audits logon activity and alerts you about failed logon attempts and other possible attempts to penetrate your network. To learn more about identifying system weaknesses and setting up an appropriate plan, read the NIST Cybersecurity Framework.
Limit lateral movement with attack path management.
Using an account’s password hash, an adversary can access all the IT resources the user has permissions for, either directly or indirectly. Unfortunately, in many organizations, that means that an adversary can go from a compromised user account to Domain Admin in just a handful of steps, thanks to years of technical debt from previous builds of Windows Server, changes in IT staffing, deeply nested permissions and general lack of knowledge about securing Active Directory. The only way to understand and block these attack paths is through attack path management and attack path monitoring. For more information, see the ebook, “.”
Use firewalls everywhere.
Require all machines, including both servers and workstations, to have their firewall turned on, no exceptions. This will eliminate peer-to-peer subnet jumping from one host machine to others.
Audit traffic on endpoints.
User endpoints consume network resources; they should not be producing traffic. By monitoring your endpoints for traffic production, you can see pass the hash attacks being performed by a compromised host. Third-party solutions can automate the monitoring of authentication attempts on workstations and alert you to possible attacks.
Protect your Tier Zero assets.
Tier Zero assets include are domain controllers, backup servers and other servers that have high privileged accounts running in memory, such as service accounts that require Domain Admin membership. To keep these accounts from being compromised by adversaries in pass the hash attacks, be sure to place these assets in a protected subnet, use a firewall to manage traffic, and allow each server to communicate only with other servers and services they need to properly run. One place to start is Microsoft’s enterprise access model.
Consider implementing Credential Guard.
Introduced in Windows Server 2016, Windows Defender Credential Guard uses virtualization-based security to protect NTLM password hashes, as well as other “secrets” like Kerberos Ticket Granting Tickets and credentials stored by applications. These secrets are isolated where only privileged system software can access them.
Keep in mind that there are a number of prerequisites and drawbacks with Credential Guard. The devices’ BIOS must support virtualization extensions, and the service will work only on devices using Trusted Platform Module 2.0 and a Unified Extensible Firmware Interface lock. In addition, there are issues with applications that require Kerberos Data Encryption Standard and Kerberos unconstrained delegation, and both NTLMv1 and third-party security tools that require access to the hash will not work.
Say “RIP” to RDP.
Using Remote Desktop Protocol (RDP) to connect to any machine in your Windows network leaves your password hash behind in memory, where it could be retrieved by an adversary and used in a PtH attack. RDP is ubiquitous because it’s free, but it’s prudent to look for a more modern and secure remote access tool.
Use managed service accounts (MSAs).
The password hashes of service accounts can be used in PtH attacks. A good way to reduce this risk is to use standalone managed service accounts (sMSAs) or group managed service accounts (gMSAs). MSAs provide automatic password management to ensure that service account passwords (and their hashes) change on a regular basis, and gMSAs are restricted from being used interactively. As a result, they can make pass the hash attacks less useful.
Utilize Microsoft LAPS.
Microsoft’s Local Administrator Password Solution (LAPS) will greatly up your security game. Organizations often set the same password for local administrative access on all endpoints for simplicity. That’s a big security risk since an adversary who steals the hash of the local administrator on one machine can use it in pash the hash on every other machine. LAPS makes it easier to manage those passwords across your hundreds or thousands of devices, so it’s convenient to use a unique local admin password on each machine.
Use privileged access workstations (PAWs).
System administrators should not use their privileged accounts to log into workstations, not even their personal machines, since doing so leaves their password hash in memory for attackers to steal and use in pass the hash attacks. Instead, privileged accounts should only log into secure administrative workstations. These workstations can even be single-use virtual workstations that tear themselves down and start from a secure image in a controlled subnet. When the user logs out, the machine’s virtual footprint is destroyed, leaving no credentials behind for attackers to scrape. Access to the servers should be based on a user’s roles; for instance, SQL admins can access only SQL Server machines and not any other servers.
Be diligent about patching.
Stay up on the latest patches has been drummed into many admins over the years, for good reason: Keeping your endpoints patched gives attackers fewer opportunities to gain entry to them. Leveraging an automated patching and inventory solution helps to reduce your risk of a breach. You should also be sure to stay up to date on known vulnerabilities at the CISA site since sometimes it takes vendors a very long time to create and issue patches and you might need to take steps to protect your systems in the interim. Another site I would monitor is the SANS.edu Internet Storm Center, which provides information about attacks that researchers are currently seeing, which can help your team be ready for them.
Defending against pass the hash attacks — and many other cyberthreats — requires a layered approach to security. Microsoft provides some valuable free tools, but for a solid, defense-in-depth strategy, it’s vital to invest in third-party solutions. In particular, you need to be able to thoroughly audit logon activity and perform attack path management and attack path monitoring. Your goals should be to reduce the ability of adversaries to establish a foothold in your network, limit the damage they can do by stealing a given password hash, minimize the number of password hashes they can find in memory (especially those for powerful administrative accounts), and promptly detect and respond to activity that could indicate a Pass the hash attack in progress.