Pass the hash is a technique used to steal credentials and enable lateral movement within a target network. In Windows networks, the challenge-response model used by NTLM security is abused to enable a malicious user to authenticate as a valid domain user without knowing their password. Even though Kerberos has replaced NTLM as the preferred authentication method for Windows domains, NTLM is still enabled in many Windows domains for compatibility reasons. And so, pass the hash attacks remain an effective tool in the hands of skilled attackers.
How NTLM authentication works
NTLM is a ‘challenge and response’ based protocol. A user is authenticated not with their password but with a hash of their password. The password hash is static – it only changes if the user changes their password. The password hash is stored in several places within the Windows network – if an attacker can obtain a copy of a user’s hash, they can impersonate that user and authenticate as that user.
When a user authenticates with NTLM, the following happens:
- The user enters their username and password.
- The client software generates a hash of password (and discards the cleartext password).
- The username is sent to the target system requesting authentication.
- A security challenge is returned which the client encrypts using the password hash and then sends back.
- The target system passes the encrypted response to the Domain Controller who also encrypts the challenge with its copy of the user’s password hash – if it matches then the user is authenticated.
If an attacker can obtain a copy of a user’s password hash, they are then able to commence an NTLM authentication starting from step 3 of the process above.
How Pass the hash attacks work
The attacker must first obtain access to the network through some other technique such as using phishing emails for credential theft. Pass the hash is a post-compromise technique for further credential theft and lateral movement.
Windows uses a Single Sign On model for user authentication. Once a user has provided their password once and the NTLM hash has been calculated, the hash is retained in memory for the rest of the session so subsequent authentication requests to different network resources do not need to keep prompting for the user’s credentials.
Because the NTLM hash is stored in memory, attackers can potentially extract the hash with the right tools, such as Mimikatz.
For logged on users, the NTLM hash is stored within the memory of the LSASS process on each computer. It is also retained in the memory of RDP server software. (The hash is retained by the RDP server until the user session logs out – but if the user simply disconnects the hash is retained and the user is still considered logged in. Thus, for RDP environments it is important to train users to Logoff their RDP sessions not simply disconnect.)
The NTLM hash is also stored within the NTDS.dit file on the domain controller or can be obtained by a DCSync attack which tricks a Domain Controller into syncing its store of hashes with malicious software impersonating another Domain Controller.
Attackers use the stolen credentials to further investigate the network and repeat the cycle of credential theft and lateral movement to ever increase their access footprint within the target network.
Tools such as PSExec can be used to execute commands on target systems using the stolen credentials to install malware or exfiltrate data.
What are Pass the Ticket Attacks
The Kerberos security system, which was intended to be the more secure replacement for NTLM in Active Directory, is vulnerable to a similar style of attack called Pass the Ticket.
Kerberos tickets, like NTLM hashes, can be used to authenticate access requests to network resources and can also be stolen from the memory of the LSASS process using tools such as Mimikatz. There are two kinds of Kerberos ticket: Ticket Service Tickets (TST) which grant access to a particular network resource (such as a file share) or Ticket Granting Tickets which can be used to request TST to any resource the user is authorised to access on the network.
Defending against pass the hash attacks
Pass the hash and Pass the Ticket attacks are hard to defend against and detect, because they make use of legitimate network protocols. The best defence is to make it harder for the compromised accounts to be used for lateral movement and escalation:
- Enable Windows Credential Guard – which protects the LSASS process by putting it into a secure sandbox using virtualisation – available on Windows 10 Enterprise and Server 2016 onwards.
- Extracting hashes from LSASS or another processes memory requires administrative privilege – so reducing the number of accounts with admin rights makes compromised accounts less useful to attackers.
- Use Microsoft Local Administrator Password Solutions (LAPS) to ensure the local admin account for every computer uses a different complex password, hindering lateral movement by attackers.
- In many environments, end user devices need to connect to file servers and domain controllers but not to other end user devices – so configure firewall rules to prevent these lateral connections and so hinder lateral movement of attackers.
- Security Awareness training will help your staff not fall for the initial phishing email or social engineering techniques used to obtain the first set of credentials needed for network access.
- Do not allow users to be local administrators for multiple systems
- Limit domain admin account permissions to domain controllers – delegate other admin functions to different accounts, thus limiting the value of any one compromised account.
- Monitor authorisation and access logs using SIEM tools to automatically detect unusual patterns of access which may indicate account compromise.
You can help assess the resilience of your network against lateral movement and pass the hash attacks through an internal penetration test or a Red Team exercise (where a team of penetration testers mimic the actions of malicious attackers in an attempt to find and compromise valuable assets in your network).
“We were very impressed with the service, I will say, the vulnerability found was one our previous organisation had not picked up, which does make you wonder if anything else was missed.”
Aim Ltd Chief Technology Officer (CTO)