Pass-the-hash (PtH) is an all too common form of credentials attack, especially since the advent of a tool called Mimikatz. Using PtH to extract from admin memory parsing is much faster than old dictionary and brute force style attacks of yester-year using tools such as ”Cain and Abel.” This blog introduces the Windows Security Account Manager (SAM) file, hashes for credentials, how PtH is easily performed using a tool called Mimikatz, and how to detect such attacks within alerts.


Creating Context – the SAM File


Windows “hash” (fixed-size mathematically generated value) values for passwords for users on a computer are stored in the Windows SAM file located at %SystemRoot%/system32/config/SAM and mounted via HKLM/SAM:




SAM file as seen in Windows 10 in the System32 config directory


If a computer is compromised by a remote actor or malicious insider they can easily view, copy, and/or exfiltrate the SAM file from a computer to then leverage in compromising credentials. Using old-school methods, one can copy the SAM file from the local system and exfiltrate it to an attacker computer for brute force password attacks against the file. This is not as easy as you think, since it is already in use and therefore not allowed by Windows. However, a trivial batch (.bat) file run as admin easily creates a copy on the local C drive:


@echo off





Once obtained, the SAM file can then be leveraged for password cracking. In a reverse direction an actor may also just upload a tool like Mimikatz to a remote compromised endpoint to then run it on the computer to then compromise credentials, which is far more efficient than using PtH tactics.


SAM File Contents and Hash Types


The SAM file contains data as shown below, when viewed in Notepad on Windows:




SAM file snippet viewed in Notepad


Windows XP and older operating systems store passwords in the SAM file.  To keep passwords secure they are ‘hashed’ using one of two formats: LAN Manager (LM) Hash or NT LAN Manager (NTLM). LM hashes are the older, easily cracked version of security, which should not be used today. LM hashes can be cracked in seconds using off-the-shelf hacking tools. When viewing hashes in a SAM file, if you see two different hash values present you know you can ‘pwn’ (own) the credentials because it must contain both LM and NTML hashes!


NTLM hashes are more robust, but produce a cryptographic value that is predictable. In other words, if you generate the hash value for “admin123” or “sunset” you get a known value that can then be used in a dictionary style attack against unknown hashes.  


PtH with Mimikatz


No matter what type of hash you use, if admin exists on an endpoint and it’s compromised and Mimikatz is used, complete pwn’ge is in your immediate future.  It’s trivial to run the tool to quickly dump all passwords on a local system as shown below:




Mimikatz dumping passwords to “Passwords.txt”




Examples of passwords dumped by Mimikatz including user kdunham and a NAS device


Once the user is compromised, whatever privileges they have across the network can then be used to log into different computers with different users and hashes. This enables an actor to quickly traverse a network laterally and/or elevate to Domain Admin in many cases. It can also enable an actor to have access to special file stores, such as the network area storage device used for backups as seen in the example above.


Mature pen testers and threat agents often automate the use of Mimikatz with a script, such as a PowerShell script. This enables them to perform several tasks quickly that are always required - such as disabling AV and running the desired command for Mimikatz to steal credentials.  Some tools, such as PowerShell Empire, contain a module such as “pth” to also automate such tasks. Even Microsoft has a PowerShell script for downloading from Github and executing Mimikatz, available at  


Mimikatz is one of the most popular but certainly not the only tool for stealing credentials.  Related tools of concern include but are not limited to MetaSploit, SMBShell, fgdump, gsecdump, PWDumpX, creddump, and WCE.


Detecting PtH in Alerts


Lateral movement of PtH attempts can be seen between workstations:


  • Microsoft Event Security Log ID 4624
    • LogonType 3 using NTLM
    • Event level information
    • Authentication is NOT a domain and NOT anonymous
    • Security ID is commonly null for PtH attacks


ID 4624 is for a successful user account login, which can be seen in the Windows event security log. Other codes, like 4740 for lockout, may help reveal a picture of attempted hacking of an account. Combining at least the three PtH components of ID 4624, 3, and NTLM into event correlation enables an analyst to quickly identify PtH attacks. In the real world of reaching through SIEM/SOC data an analyst may be viewing a triggered syslog alert such as:


alert syslog $HOME_NET any -> $EXTERNAL_NET any (msg: "[WINDOWS-AUTH] Pass-The-Hash detected!"; pcre: "/ 4624: | 4625: /"; content: "Logon Type|3a| 3 "; content: "Authentication Package|3a| NTLM "; content:!"ANONYMOUS LOGON"; meta_content:!"Domain|3a| ",$WINDOWS_DOMAINS; meta_nocase; program: Security|Security-Auditing; parse_src_ip: 1; classtype: successful-user; reference: url,; reference: url,; sid: 5002017; rev:2;)


Reading through the rule above notice the use of “!” where something like “ANONYMOUS LOGON” is NOT part of the rule. This matches the ruleset described above and is relatively fast to triage by a junior analyst as PtH.



Understanding PtH is important in 2018 because it is a very common method popularized by tools such as Mimikatz. It’s common and relatively easy to spot in terms of low hanging fruit on alerts, monitoring and response. There is a much more complicated architecture behind the scenes of any well defended network related to how identity and access management (IAM) is performed in addition to more advanced PtH detection and counter-tactics.


While this article does not focus upon preventative controls to reduce credential theft risk a few must be noted out of good conscience in addition to additional references below:


  • Ensure you don’t have admin for all users on a flat network! PtH requires administrative rights. Manage such accounts accordingly.
  • Do not allow remote interactive sessions on any high value asset account or device.
  • Ensure proper termination of Remote Desktop Protocol (RDP). This varies based upon your specific version of Windows but results, in general, in an increase around admin privileges and protection to use RDP.
  • Audit the use of scripts, especially PowerShell, on Windows endpoints.  Also audit anti-virus logs and other data for possible Mimikatz or PtH abuse and/or disabling of anti-virus.


More Information


For more information on PtH read the SANS paper at  


Extensive mitigation advice from MS against PtH at and


Binary Defense dives into how to detect PtH at…;


A Blackhat talk on why you need to detect more than PtH, because this is a complex subject, available at  


A more technical video on how authentication takes place related to PtH:

Ken Dunham
Senior Director, Technical Cyber Threat Intelligence
Ken Dunham has spent 30 years in cybersecurity, consulting in adversarial counterintelligence, forensics, Darknet Special Ops, phishing and hacking schemes, AI/BI, machine learning and threat identification.