When you set a Windows password, you probably picture it being stored somewhere in a vault, encrypted and safe. The reality is a bit different. Windows doesn't encrypt your password in a reversible way. It hashes it. And the hash format it uses is called NTLM.
Understanding how NTLM hashes work is essential for anyone interested in Windows security, whether you're a system administrator, a security researcher, or just curious about what happens under the hood when you log in. Let's break it down.
What Is an NTLM Hash?
An NTLM hash is a cryptographic fingerprint of your password. Windows computes it using a specific process and then stores that fingerprint instead of your actual password. When you log in, Windows hashes the password you type and compares it to the stored hash. If they match, you're in.
The name "NTLM" comes from NT LAN Manager, Microsoft's authentication protocol family introduced with Windows NT. The hash itself is sometimes called the "NT hash" to distinguish it from the older, broken LM hash (more on that later).
Here's the key thing to understand: the NTLM hash is not encryption. It's a one-way hash function. You can't "decrypt" an NTLM hash back to the original password. But as we'll see, that doesn't mean it's secure.
How the NTLM Hash Is Computed
The computation is remarkably simple, which is part of the problem. Here's the exact process:
1. Take the user's password as a UTF-16LE (Little Endian) encoded string. 2. Run it through the MD4 hash algorithm. 3. The output is a 16-byte (128-bit) hash, typically represented as a 32-character hexadecimal string.
That's it. No salt, no iterations, no key stretching. Just UTF-16LE encoding followed by MD4.
For example, if your password is "Password123", Windows encodes it as UTF-16LE, feeds those bytes into MD4, and produces the hash. You can try this yourself with our NTLM Hash Generator to see exactly what hash a given password produces.
The simplicity of this process is a double-edged sword. It makes authentication fast and straightforward, but it also means that once an attacker obtains a hash, they can attempt to crack it at enormous speed.
Why Windows Still Uses NTLM Hashes
You might wonder: if MD4 is broken and the process is so simple, why does Windows still use it? The answer is backward compatibility.
Windows NT introduced NTLM in the 1990s. Over the decades, Microsoft has built newer, more secure authentication systems like Kerberos. But the NTLM hash format remains embedded in the core of Windows authentication because removing it would break compatibility with countless applications, services, and legacy systems.
The hash stored in the SAM database and in Active Directory's NTDS.dit file is still the MD4-based NTLM hash. Modern Windows versions have strengthened the protocols that use this hash (NTLMv2, for example), but the underlying hash format hasn't changed.
Microsoft has been gradually deprecating NTLM authentication and pushing organizations toward Kerberos, but the hash format persists because it's the foundation that newer protocols build on. You can learn more about the protocol differences in our article on NTLM vs NTLMv2.
Where NTLM Hashes Are Stored
Windows stores NTLM hashes in two primary locations:
**The SAM Database (Local Accounts):** The Security Account Manager (SAM) is a registry hive on local Windows machines. It stores user account information, including NTLM hashes, for local accounts. The SAM file is located at C:\Windows\System32\config\SAM and is protected by Windows file permissions and encryption. You can't just copy it while Windows is running.
**NTDS.dit (Domain Accounts):** On Active Directory domain controllers, domain user account hashes are stored in the NTDS.dit database file. This is the central repository for all domain credentials. Like the SAM, it's protected, but it can be extracted if an attacker gains sufficient privileges.
**LSASS Memory:** At runtime, Windows loads credential information into the Local Security Authority Subsystem Service (LSASS) process memory. Tools like Mimikatz can dump these hashes from memory, which is why protecting LSASS is a critical security measure.
The Security Implications
The NTLM hash format has several well-known security weaknesses:
**No Salt:** Each password produces the same NTLM hash regardless of the user or system. "Password123" always produces the same hash. This means attackers can use pre-computed rainbow tables to look up hashes instantly.
**MD4 Is Fast:** MD4 was designed for speed, and modern GPUs can compute billions of MD4 hashes per second. This makes brute-force and dictionary attacks extremely efficient against NTLM hashes.
**Pass-the-Hash:** Because Windows accepts the NTLM hash for authentication in certain contexts, attackers who steal hashes don't even need to crack them. They can use the hash directly to authenticate as the user, a technique known as pass-the-hash.
**No Key Stretching:** Unlike modern password hashing schemes like bcrypt or Argon2, NTLM applies no iterations. A single MD4 operation per guess means cracking speeds are limited only by hardware.
How to Generate an NTLM Hash
If you want to understand how this works hands-on, you can generate NTLM hashes yourself. The process is straightforward:
- Take any password string - Encode it as UTF-16LE - Compute the MD4 hash of those bytes
You can do this programmatically in Python, PowerShell, or other languages. Or you can use our NTLM Hash Generator tool which does the computation right in your browser. Try generating a hash for a simple password like "test" and compare it to known values to verify your understanding.
What This Means for Windows Security
The persistence of NTLM hashes in Windows is a reminder that security is often constrained by legacy decisions. The format was designed in an era when computational power was limited and the threat landscape was different. Today, the speed of MD4 and the lack of salting make NTLM hashes vulnerable to rapid cracking.
Organizations can mitigate these risks by: - Enforcing strong, long passwords that resist brute-force attacks - Disabling NTLM authentication where possible in favor of Kerberos - Protecting LSASS from credential dumping - Using tools like LAPS to manage local administrator passwords - Monitoring for pass-the-hash attack indicators
Understanding the NTLM hash format is the first step toward securing Windows environments. Once you know how hashes are computed and stored, you can make informed decisions about password policies, authentication configuration, and incident response.
For a deeper dive into the protocol that uses these hashes, read our comparison of NTLM vs NTLMv2. And to understand the broader authentication landscape, check out our guide on Windows authentication with Kerberos and NTLM.
