Learning About Pass the Hash Attacks
Simplified NTLM authentication flow:
This English translation example is relatively easy to understand.
- Client -> Server: “Hi, I want to access your resource.”
- Server -> Client: “Oh? Then prove who you are. Here is a random string (Challenge); encrypt it with your password and send it back to me.”
- Client: The client encrypts this Challenge using the user’s NTLM hash (not the plaintext password), generating a “response” (Response).
- Client -> Server: “Here is the encrypted Response.”
- Server: The server passes the Response to the domain controller (DC). The DC has all users’ NTLM hashes and performs the same encryption calculation using the stored hash. If the result matches the Response sent by the client, it proves that the client has the correct credentials, and authentication succeeds.
Common extraction locations
From this process, we can see that authentication depends on the NTLM hash, not the plaintext password.
NTLM hashes are generally stored in the following two locations:
- SAM file: For local accounts, hashes are stored in the
C:\Windows\System32\config\SAMfile. This file is locked while the system is running.
# mimikatz
lsadump::sam
- LSASS process memory: After a user logs in (whether locally, through Remote Desktop, or by running a service), the system caches that user’s credentials (including the NTLM hash) in the memory of a process named
lsass.exe(Local Security Authority Subsystem Service) to facilitate subsequent authentication. This is the primary hash source for PtH attacks.
#mimikatz
privilege::debug sekurlsa::logonpasswords
- DCSync
Simulates a domain controller replication request to retrieve user hashes from a DC.
mimikatz
lsadump::dcsync /user:DOMAIN\Administrator
Typical attack process
A typical PTH attack in a domain environment generally proceeds as follows:
- Gain access to a host in the domain (possibly with low privileges).
- Extract hashes from LSASS or SAM.
- Use a PTH tool to establish a session:
- Built into Windows:
runas /netonly /user:DOMAIN\Administrator cmd
- Impacket:
python3 psexec.py DOMAIN/Administrator@TARGET -hashes <LMhash>:<NThash>
- Continue lateral movement.
Defensive measures
- Disable NTLM or restrict its use (replace it with Kerberos).
- Enable LSASS protection (RunAsPPL):
reg add HKLM\SYSTEM\CurrentControlSet\Control\Lsa /v RunAsPPL /t REG_DWORD /d 1 /f
…
NTLM and Kerberos
Summarized by GPT-5
NTLM (NT LAN Manager)
Core characteristics
- A Challenge-Response protocol.
- It does not transmit plaintext passwords directly; instead, an NTLM hash participates in the encryption calculation.
- Mainly used in:
- Scenarios where Kerberos cannot be used (such as non-domain environments, cross-domain situations, and interactions with legacy systems).
- Some legacy applications and protocols (SMBv1/2, RPC, RDP, etc.).
Simplified authentication flow
- The client initiates a request.
- The server sends a random Challenge (8 bytes).
- The client calculates a Response using the NTLM hash + Challenge.
- The server passes the Response to the domain controller (or local SAM database) for verification.
Weaknesses
- The hash is the credential → anyone who obtains the hash can authenticate (the core of PTH attacks).
- It cannot resist replay attacks (unless the Challenge is single-use and valid only for a short time).
- It has no strongly encrypted session ticket, so it is less secure than Kerberos.
Kerberos
Kerberos is a widely used network authentication protocol. It provides secure authentication between clients and servers in an untrusted network environment. Its central idea is to use a trusted third party to verify the identities of both communicating parties.
Core characteristics
- A ticket-based authentication protocol.
- Uses symmetric encryption (AES, RC4, etc.) and timestamps to prevent replay attacks.
- Used by default in Windows domain environments; NTLM is the fallback.
- Designed for single sign-on (SSO): log in once to access multiple machines in the domain.
Participants
- Client (User/Machine)
- Service (Server)
- KDC (Key Distribution Center) → typically hosted on a domain controller and includes:
- AS (Authentication Service): initial authentication
- TGS (Ticket Granting Service): issues service tickets
Simplified authentication flow
- Initial authentication (AS exchange)
- The client requests a TGT (Ticket Granting Ticket) from the KDC.
- The KDC encrypts the TGT using the user’s password hash → successful decryption by the client proves its identity.
- Requesting a service ticket (TGS exchange)
- The client uses its TGT to request a ticket for a service from the KDC.
- The KDC generates a service ticket and encrypts it with the service’s key.
- Accessing the service (AP exchange)
- The client presents the service ticket to the target service → the service decrypts and verifies it → a session is established.
Advantages
- Does not rely on the hash for direct login (unlike NTLM, the hash does not directly participate in the Challenge).
- Effectively prevents replay attacks (tickets have timestamps and lifetimes).
- Supports mutual authentication (the client and server verify each other).
Weaknesses
- If an attacker obtains a TGT or TGS ticket, they can still forge a session (Pass-the-Ticket attack).
- If the KDC/domain controller is compromised, the entire domain is compromised (Golden Ticket/Silver Ticket attacks).
Impacket suite
Impacket is an “aircraft carrier” of command-line tools for internal network penetration testing: it wraps complex Windows network-protocol attacks in easy-to-use scripts.
Simply put, Impacket is a collection of Python libraries for working with network protocols.
Mimikatz (“Kiwi”)
Common operations
Elevate privileges
privilege::debug
Export system credentials:
sekurlsa::logonpasswords
Export the SAM database:
lsadump::sam
Export cached domain credentials:
lsadump::cache
Kerberos ticket operations:
sekurlsa::tickets
kerberos::list
Export NTDS.dit (domain controller):
lsadump::dcsync /user:Administrator