Pass the hash

In cryptanalysis and computer security, pass the hash is a hacking technique that allows an attacker to authenticate to a remote server/service by using the underlying NTLM and/or LanMan hash of a user's password, instead of requiring the associated plaintext password as is normally the case.

After an attacker obtains valid user name and user password hash values (somehow, using different methods and tools), they are then able to use that information to authenticate to a remote server/service using LM or NTLM authentication without the need to brute-force the hashes to obtain the cleartext password (as it was required before this technique was published). The attack exploits an implementation weakness in the authentication protocol in that the password hashes are not salted, and therefore remain static from session to session until the password is next changed.

This technique can be performed against any server/service accepting LM or NTLM authentication, whether it is running on a machine with Windows, Unix, or any other operating system.

Description

On systems/services using NTLM authentication, users' passwords are never sent in cleartext over the wire. Instead, they are provided to the requesting system, such as a domain controller, as a hash in a response to a challenge-response authentication scheme.^[1]

Native Windows applications ask users for the cleartext password, then call APIs like LsaLogonUser^[2] that convert that password to one or two hash values (the LM and/or NT hashes) and then send that to the remote server during NTLM authentication.^{[Notes 1][3]} Analysis of this mechanism has shown that the cleartext password is not required to complete network authentication successfully, only the hashes are needed.

If an attacker has the hashes of a user's password, they do not need to brute-force the cleartext password; they can simply use the hash of an arbitrary user account that they have harvested and execute a side channel attack to authenticate against a remote system and impersonate that user.^[4] In other words, from an attacker's perspective, hashes are functionally equivalent to the original passwords that they were generated from.

History

The pass the hash technique was originally published by Paul Ashton in 1997^[4] and consisted of a modified Samba SMB client that accepted user password hashes instead of cleartext passwords (Later versions of Samba and other third-party implementations of the SMB and NTLM procotols also included the functionality).

This implementation of the technique was based on an SMB stack created by a third-party (e.g.: Samba and others), and for this reason suffered from a series of limitations from a hacker's perspective, including limited and/or partial functionality: The SMB protocol has continued to evolve over the years, this means that third parties creating their own implementation of the SMB protocol need to implement changes and additions to the protocol after they are introduced by newer versions of Windows/SMB (historically by reverse engineering, which is very complex and time consuming). This means that even after performing NTLM authentication successfully using the pass the hash technique, tools like Samba's SMB client might not have implemented the functionality the attacker might want to use. This meant that it was difficult to attack Windows programs that use DCOM/RPC.

Also, because attackers were restricted to using third-party clients when carrying out attacks, it was not possible to use built-in Windows applications, like Net.exe or the Active Directory Users and Computers tool amongst others, because they asked the attacker/user to enter the cleartext password to authenticate, and not the corresponding password hash value.

In 2008, Hernan Ochoa published a tool called the "Pass-the-Hash Toolkit"^[5] that allowed 'pass the hash' to be performed natively on Windows. It allowed the user name, domain name, and password hashes cached in memory by the Local Security Authority to be changed at runtime after a user was authenticated — this made it possible to 'pass the hash' using standard Windows applications, and thereby to undermine fundamental authentication mechanisms built into the operating system.

The tool also introduced a new technique which allowed dumping password hashes cached in the memory of the lsass.exe process (not in persistent storage on disk), which quickly became widely used by penetration testers (and attackers). This hash harvesting technique is more advanced than previously used techniques (e.g. dumping the local Security Accounts Manager database (SAM) using pwdump and similar tools), mainly because usernames/domain/password hashes values stored in memory could include credentials of domain users (and domain administrators) that logged into the machine. For example, the hashes of authenticated domain users that are not stored persistently in the local SAM can also be dumped. This makes it possible for a penetration tester (or attacker) to compromise a whole Windows domain after compromising a single machine that was a member of that domain. Furthermore, the attack can be implemented instantaneously and without any requirement for expensive computing resources to carry out a brute force attack.

This toolkit has subsequently been superseded by "Windows Credential Editor", which extends the original tool's functionality and operating system support.^[6][7] Some antivirus vendors classify the toolkit as malware.^[8][9]

Hash harvesting

Before an attacker can carry out a pass-the-hash attack, they must obtain the password hashes of the target user accounts. To this end, penetration testers/attackers can harvest password hashes using a number of different methods:

• Cached hashes/credentials of users who have previously logged onto a machine (for example at the console or via RDP) can be read from the SAM by anyone who has Administrator-level privileges. The default behavior of caching hashes/credentials for offline use can be disabled by administrators, so this technique may not always work if a machine has been sufficiently hardened.
• Dumping the local users account database (SAM). This database only contains user accounts local to the particular machine that was compromised. For example, in a domain environment, the SAM database of a machine will not contain domain users, only users local to that machine that more likely will not be very useful to authenticate to other services on the domain. However, if the same local administrative account passwords are used across multiple systems the attacker can remotely access those systems using the local user account hashes.
• Sniffing LM and NTLM challenge-response dialogues between client and servers, and later brute-forcing captured encrypted hashes (since the hashes obtained in this way are encrypted, it is necessary to perform a brute-force attack to obtain the actual hashes).
• Dumping authenticated users' credentials stored by Windows in the memory of the lsass.exe process. The credentials dumped in this way may include those of domain users/administrators, such as those logged in via RDP. This technique may therefore be used to obtain credentials of user accounts that are not local to the compromised computer, but rather originate from the security domain that the machine is a member of.

Mitigations

Any system using LM or NTLM authentication in combination with any communication protocol (SMB, FTP, RPC, HTTP etc.) is at risk from this attack.^[1] The exploit is very difficult to defend against, because there are countless exploits in Windows and applications running on Windows that can be used by an attacker to elevate their privileges and then carry out the hash harvesting that facilitates the attack. Furthermore, it may only require one machine in a Windows domain to not be configured correctly or be missing a security patch for an attacker to find a way in. A wide range of penetration testing tools are furthermore available to automate the process of discovering a weakness on a machine.

There is no single defense against the technique, so standard defense in depth practices apply^[10] – for example use of firewalls, intrusion prevention systems, 802.1x authentication, IPsec, antivirus software, full disk encryption, reducing the number of people with elevated privileges,^[11] pro-active security patching^[12] etc. Preventing Windows from storing cached credentials may limit attackers to obtaining hashes from memory, which usually means that the target account must be logged into the machine when the attack is executed.^[13] Allowing domain administrators to log in to systems that may be compromised or untrusted will create a scenario where the administrators' hashes become the targets of attackers; limiting domain administrator logons to trusted domain controllers can therefore limit the opportunities for an attacker.^[10] The principle of least privilege suggests that a least user access (LUA) approach should be taken, in that users should not use accounts with more privileges than necessary to complete the task at hand.^[10] Configuring systems not to use LM or NTLM can also strengthen security, but newer exploits are able to forward Kerberos tickets in a similar way.^[14] Limiting the scope of debug privileges on system may frustrate some attacks that inject code or steal hashes from the memory of sensitive processes.^[10]

Restricted Admin Mode is a new Windows operating system feature introduced in 2014 via security bulletin 2871997 that is designed to reduce the effectiveness of the attack.^[15]

See also

• Reflection attack
• Metasploit Project
• SMBRelay

Notes

1. Note that Windows may use Kerberos authentication by default.

References

1. Chris Hummel (12 October 2009). "Why Crack When You Can Pass the Hash?". SANS Institute.
2. "LsaLogonUser". Microsoft. 7 September 2011. Retrieved 25 October 2011.
3. "How Interactive Logon Works". Microsoft. 22 January 2009. Retrieved 25 October 2011.
4. Daniel Stirnimann (9 August 2010). "Windows Attack — Gain Enterprise Admin Privileges in 5 Minutes" (PDF). Compass Security AG. Retrieved 10 October 2010.
5. Hernan Ochoa (2 July 2008). "What is Pass-The-Hash Toolkit?". Retrieved 20 October 2011.
6. Hernan Ochoa (2011). WCE Internals. RootedCON.
7. Hernan Ochoa (2011). "Windows Credentials Editor (WCE) F.A.Q.". Amplia Security. Retrieved 25 October 2011.
8. "SecurityRisk.WinCredEd". Symantec. 21 March 2011. Retrieved 25 October 2011.
9. "HackTool:Win32/Wincred.A". Microsoft. 1 October 2011. Retrieved 25 October 2011.
10. Bashar Ewaida (21 January 2010). "Pass-the-hash attacks: Tools and Mitigation". SANS Institute.
11. Roger Grimes (26 July 2011). "Stop pass-the-hash attacks before they begin". Infoworld. Retrieved 25 October 2011.
12. Rob Kraus, Brian Barber, Mike Borkin, Naomi Alpern (2010). Seven Deadliest Microsoft Attacks. Syngress. pp. 12–14. ISBN 1-59749-551-4.
13. "Preventing Pass-the-Hash Attacks and Cached Credential Attacks". Berkley Lab Computer Protection Program. Retrieved 20 October 2011.
14. "Microsoft Windows Kerberos 'Pass The Ticket' Replay Security Bypass Vulnerability". securityfocus.com. 13 August 2010. Retrieved 20 October 2010.
15. https://technet.microsoft.com/library/security/2871997

External links

• Microsoft Pass the Hash Mitigation Guidance
• Amplia Security
• SMBShell
• Patrick Jungles et al.: Mitigating Pass-the-Hash (PtH) Attacks and Other Credential Theft Techniques, Microsoft Corp., 2012, retrieved on Feb. 3, 2015
• Uninformed Break-the-hash paper
• Reducing the Effectiveness of Pass-the-Hash (NSA)
• CWE-836: Use of Password Hash Instead of Password for Authentication