Windows Authentication with NTLM

Windows authentication is based on many security best practices although it has several weaknesses especially when it comes to legacy authentication in the form of New Technology LAN Manager (NTLM), which first debuted with Windows NT in the mid 1990’s.

Modern Windows versions continue to support NTLM authentication for local and client/server authentication. Professional environments with central authentication servers almost exclusively use Microsoft Active Directory which primarily uses Kerberos authentication but uses NTLM for certain tasks and legacy support. Older consumer-focused Windows versions like Windows 98 used an authentication mechanism called Local Area Network Manager (LANMAN or LM) which is still supported on modern Windows, but is generally disabled by policy due to cryptographic weaknesses.

With local log in, the password you type in is hashed and compared against the stored version. If they match, then you have authenticated as the given user.

In client-server remote authentication, NTLM is used as a challenge-response authentication method where the client authenticates itself by performing a calculation using their password hash on a random value sent from the server. If the server calculates the same value from its local copy of the password hash, then the user is authenticated. This challenge-response provides secrecy from network eavesdropping but since the hash is not salted, it effectively is the user’s network authentication (password equivalent). This enables attacks called ‘Pass-the-Hash’ where an attacker doesn’t know an account’s password, but does have its hash and is able to impersonate them.

The formula to calculate a response is NTLM(NTLM(password) + challenge).

  • NLTM(value) means take the NTLM hash of the given value.
  • + means append or concatenate.


The default local Windows password storage method is NTLM which is a cryptographic hash function that produces a 128 bit digest. The hashes are stored on disk in a special registry file C:\windows\system32\config\SAM (Security Account Manager) as well as the lsass.exe (local security authority sub service) process at runtime.

Basic usage

One way to use remote NTLM authentication is using the PsExec command line tool. This is found in the Windows System Internals suite that extends some existing Windows features for system administrators and power users. It can be used to launch arbitrary commands on a remote system with the PsExec service using an account with administrator privileges.

Example of PsExec usage:

PsExec.exe \\<server> -u <user> -p <password> <command>


Stored NTLM hashes can be retrieved from both the lsass.exe process and the SAM on disk but both methods require privileged access since they are of high value to attackers and may give access to additional user credentials. The SAM file can be accessed with tools like pwdump or samdump and can even be accessed from offline images of a Windows system.

However to read the NTLM hashes from a running system, the easiest way is with Mimikatz, a very powerful and convenient tool written by a security researcher. It is able to interact with the Windows LSA and extract useful information from it assuming it has sufficient privileges.

An example of dumping the local user and machine account hashes:

privilege::debug # Elevate privileges to interact with the LSA.
sekurlsa::logonpasswords # Dumps the current credential store.

Mimikatz can also be used to conduct Pass-the-Hash attacks. This requires two steps, first you must open a local command prompt with the remote authentication already set up and then execute the remote command.

Example of the Mimikatz command to open a new command line with the hash in memory:

sekurlsa::pth /user:<account> /domain:<domain> /ntlm:<ntlm-hash>

This will open a new command prompt which now has these credentials loaded, so issuing commands with PsExec in that shell does not require you to add a username and password anymore.

Example command in spawned shell:

PsExec.exe \\<domain-controller> whoami.exe

This will produce the same output as if you had separately run PsExec with the user and password of the given account.


Directly mitigating Pass-the-Hash is difficult as it relies on exploiting core functionality of NTLM. The best mitigation is minimizing the use of legacy authentication protocols and using ones like Kerberos which include cryptographic protections for this kind of attack. Additionally, monitor for suspicious user access, which covers compromised accounts no matter how they occurred. The best way to detect Pass-the-Hash directly is by monitoring client access logs (e.g. workstations) and investigating Event ID 4624 with Logon Type 9 as this is almost exclusively found with Pass-the-Hash scenarios.

If an account has been found compromised, then you need to reset the user’s password and contact the user immediately to try and understand what happened.


NTLM is a solid authentication method, but should not be relied solely to protect user identities. As with most aspects of security, layers of controls are key to building strong security and making it difficult for cyber adversaries to win.

Ben Langrill