Pass the Hash: it's all a shell game

CyberSecurity Simplified
Aug 27, 2021
7 min read

Written by Jean-Camille LOISEAU & Anup Tripathi | Published 27 August 2021

Computers and servers are protected by a username & password in order to control and restrict their access. This has been for decades now the go-to default security mechanism for all systems from the desktop PC to the mighty Domain Controller.

This lock mechanism is a prime target for attack as controlling is controlling the kingdom.

Already back in 1997, Paul Ashton demonstrated a technique to enabling him to harvest user password hash and reuse them to carry out an authentication. That proof of concept however was cumbersome and only worked using modified third-party implementations of the SMB and NTLM protocols.

This changed in 2008, when Hernan Ochoa published a tool called the "Pass-the-Hash Toolkit". PTH Toolkit worked natively on Windows and enabled capture of all important user data including password hashes stored on a machine local memory.

Since Windows 2000, Microsoft Active Directory (AD) is based on the LDAPv3 protocol and Microsoft’s proprietary implementation of Kerberos is the default authentication method in AD environment and domain.

Even though Kerberos is now the default, the older NT LAN Manager (hereafter: NTLM) authentication protocol is still enabled as a fall back mechanism on many Windows domains to ensure compatibility with legacy technologies.

Nowadays, Pass the hash attack (T1550.002) can unfortunately be performed on any server or service accepting NTLM authentication, whether it runs on a machine with Windows, Unix, or any other operating system

Like Kerberos, NTLM security is based on at least in part on a challenge-response model but its security is weaker and one feature aimed at practical user use can be easily abused: credential cashing.

In short, in order to avoid constantly having to force the user to reauthenticate to every single resource they seek to access during their session on a computer, the user's password hash is stored locally in memory in a module called the Local Security Authorization Subsystem (LSASS) for the duration of the session.

What it a Pass the Hash attack?

The user is authenticated to resources not with heir password but with the its hash.

Pass The Hash consist in using methods to extract the user password hash from the LSASS module and then reuse it to move laterally or better obtain access to an account with more elevated rights.

Typically, an attacker will first gain access and initial foothold onto a machine within the domain they target. this can be done through a phishing attack, or through malware on a desktop pc.

Once in, they can stealthily cause issues that will trigger a support team member with an administrator account to check the machine. As the IT support employee logs on to the compromised device using their admin credentials, their user name and password hash are locally stored within the LSASS module.

Using attack tools such as Mimikatz, the attacker can scrape active memory and stealthily extract the admin account password hash and without needing to know the actual password behind the hash use that hash to create authentication requests to other systems and resources located on the network.

Why should I care about Pass the Hash attack?

Pass The Hash is a very dangerous technique for several reasons:

NTLM is everywhere and all systems that accept it are vulnerable
In the past, hackers had to actually decrypt password, PTH eliminates that need
The technique is extremely simple to execute and does not require any skill
PTH only need basic access to network and no elevated privilege to be carried out

Once an attacker successfully completed a PTH attack, there may be little to now signs of the attack ever occurring and the attacker may have gained access to different more discreet account or accounts with higher level of privileges that may enable them to carry out other attack. For example, if they compromise a domain admin account, they may be able to launch Shadow DC or DCSync attacks.

This technique is extremely easy and bypasses most defenses. To top it up, because it requires only minimal access that can be gained through phishing low level employees it has a wide surface of attack and will easily bypass set defenses.

How does a Pass the Hash attack unfold?

Once the attacker gained a foothold and compromised an account within the organization, they will begin by ensuring they gain unfettered access on compromised systems's LSASS module.

Their next goal can either be to lay low or to cause trouble to incite the machine's users to ask for IT support's help. Assuming the latter, the attacker can wait for an IT support operative with to remote to their PC and log on with their admin account to perform some task:

The admin inputs their user ID and password to authenticate on the client.
The client creates a hash of the password (and discards the cleartext).
The user ID is sent to the client's target system requesting authentication.
The target system returns a security challenge .
The client encrypts using the password hash using the security challenge .
The client sends the encrypted security challenge response back to the system.
The system sends the encrypted response AND the challenge to the DC.
The DC encrypts the challenge with its own copy of the user admin account's password.
The DC validates that the encrypted response it created and that which it received
The DC confirms the user authentication as the 2 encrypted responses match.

Meanwhile, the attacker scrapes the LSASS module and extracts the admin account's password hash created in step 2.

The attacker can then look to open another system on the network and launch authentication request injecting or "passing" the hash to encrypt any system's security challenge and thus gain authentication without ever having to know the password.

How do I prevent a Pass the Hash attack?

Pass the Hash is challenging to prevent and even harder to detect as they rely on misusing legitimates protocols, functions and systems.

The best prevention and defense against pass the hash technique is to enforce layers upon layers of defense in depth to make it all but the most tedious for an attacker to have a chance of success.

Your first course of action should always be to reduce the probability of the attacker being able to gain a foothold on any of your organization's computer through classic phishing attempt. To that end, make sure you train your all IT users against the dangers of phishing.

Next, assuming the attacker did compromise a machine, you want to make sure to make it hard for the attacker to collect any data from LSASS. You can achieve that in part by enabling Windows Credential Guard – which sandboxes the LSASS process and makes it more difficult to access.

Assuming LSASS got breached, you want to reduce the impact by ensuing LSASS only stores a limited amount of credentials. LSASS defaults cache 10 or more credentials. Modify the registry on all your systems by going to: HKEY_LOCAL_MACHINE\Software\Microsoft\WindowsNT\Current Version\Winlogon\

and set the value of CachedLogonsCount to 1.

In addition to the above, follow the below standard preventative measures:

Inventory all service account and ensure all of them follow robust password policies:
long (25+ characters), complex passwords,
ideally randomly generated
rotating on a regular basis: no less than yearly, ideally monthly or more
Follow least privilege access model and ensure privileges and permissions are limited to the strict indispensable minimum on service accounts.
Use Privilege Account Solution (PAM) to track and monitor the use of any privileged account and monitor for any usage of these account bypassing your PAM solution.

How do I detect a Pass the Hash attack?

There are several ways to detect the pass the hash attack, some of them that generate low false positives and effectively detect this attack using different event correlations are mentioned below:

Pre-requisite: Windows security events from Laptops/Workstations, servers and Domain Controllers should be collected into your SIEM platform.

Sample of Windows events collected in SIEM from 2 machines (Source and Target):

sourceIP: IP address of the source machine from where attack has been launched

sourceUserName: Account on the source machine which attacker already has access to

sourceHostName: Hostname of the source machine from where attack has been launched

targetUserName: The target account for which attacker is trying to authenticate using pass the hash

targetHostName: Hostname of the target machine

LogonProcessName: the process name related to the authentication on the host

Method 1: Detecting Overpass the Hash or Pass the Key attack

Create UC/Rule to correlate Event 1 sourceHostName field with Event 2 ComputerName field:

Event 1 (Source):

event_id: “4624”

AND

LogonType: “9”

AND

AuthenticationPackageName: “Negotiate”

AND

LogonProcessName: “seclogo”

Event 2 (Target):

event_id: “4624”

AND

LogonType: “3”

AND

AuthenticationPackageName: “NTLM”

AuthenticationPackageName: “Kerberos”

Generate Alert - Overpass the Hash or Pass the Key attack

Method 2: pass the hash from Unknown source

Create UC/Rule to correlate Event 1 targetUserName field with Event 2 subjectUserName field:

Event 1 (Target)

event_id: “4624”

AND

LogonType: “3”

AND

AuthenticationPackageName: “NTLM”

Event 2

event_id: “4672” ## privileged connection on same host

AND

if sourceHostName is not on the domain or empty

Generate Alert - pass the hash from Unknown source

Method 3: potential pass the hash from known source

Create UC/Rule to correlate Event 1 targetUserName field with Event 2 subjectUserName field:

Event 1 (Target)

event_id: “4624”

AND

LogonType: “3”

AND

AuthenticationPackageName: “NTLM”

Event 2

event_id: “4672” ## privileged connection on same host

AND

if sourceHostName is on the domain

AND

Event 3 (DC)

event_id: “4776” OR event_id: “4768” OR event_id: “4769” AND event_data.Status: "0x0” ## success only

event_id: “4624”

AND

no successful authentication before suspicious event on the target (event 1) from same sourceIP in last 2 hours

AND

LogonProcessName is not whitelisted

AND

This authentication (sourceIP, sourceHostName, targetHostName, targetUserName) not seen in last 2 months

Generate Alert - potential pass the hash from known source

Method 4: potential pass the hash using explicit credentials

Create UC/Rule to correlate Event 1 targetUserName field with Event 2 targetUserName field:

Event 1 (Target)

event_id: “4624”

AND

LogonType: “3”

AND

AuthenticationPackageName: “NTLM”

Event 2 (source)

event_id: “4648” ## explicit credentials

AND

if LogonProcessName is not whitelisted

AND

This authentication (sourceIP, sourceHostName, targetHostName, targetUserName) not seen in last 2 months

Generate Alert - potential pass the hash using explicit credentials

How do I respond to Pass the Hash attack alert?

If Pass the Hash attack is detected, there are several response actions that should be taken:

Activate the incident response process and alert the incident response team
Check all the activity performed from the compromised accounts (both accounts, one used to execute Pass the hash attack and other whose hash is utilized for logon)
Check with the account owner to confirm if the source machine is legitimate/authorized to connect to the target server
Perform forensic investigation, as well as eradication and recovery activities.
Reset the password of all the compromised accounts

Related content:

Pass the Hash: it's all a shell game

Recent Posts

Comments