Learn what Mimikatz is, how it works, and how to detect and defend against its attacks. Protect your network from credential theft and lateral movement.
For IT professionals and security-conscious organizations, understanding this aging protocol, how it works, and why it’s still lurking on your network is more crucial than you might think. This blog is all about shining a light on NTLM’s inner workings, recognizing its risks and benefits, and offering practical advice for safeguarding your environment.
Read on as we strip away the jargon to explain what NTLM is, how it authenticates users, how it compares to Kerberos, and why it continues to matter—even as modern threats grow more sophisticated.
What is NTLM?
NTLM stands for New Technology LAN Manager. Developed by Microsoft, NTLM is a suite of security protocols designed to authenticate users on networks running Windows operating systems. At its core, NTLM provides a means to confirm someone’s identity without constantly demanding their password, making it an early player in the realm of single sign-on (SSO).
NTLM was the standard protocol for Windows domains up until Windows 2000, when Kerberos took over by default. Yet NTLM is still part of today’s Windows systems, mainly for legacy compatibility reasons. That means if your network has old applications or clients, odds are NTLM is still somewhere in the authentication chain.
Quick facts about NTLM
-
Developed for Microsoft Windows environments
-
Relies on a challenge-response mechanism
-
Still present in many networks to support older systems
-
Replaced by Kerberos in newer Active Directory domains, but not fully retired
Understanding NTLM’s challenge-response process
Authentication protocols can seem like a maze, but NTLM’s process breaks down into a straightforward three-step handshake between client and server. The main goal? Prove user identity without sending passwords over the network.
Step-by-step NTLM authentication
Here’s what happens when you attempt to log in using NTLM:
Negotiation
The client (your computer) starts a conversation with the server, listing NTLM as an authentication option.
Challenge
The server responds with a random “challenge”—a unique 16-byte number.
Response
The client, using the user’s password (or rather, a hash of it), encrypts the challenge and sends this “response” back to the server.
Verification
The server forwards the username, challenge, and response to the domain controller.
The domain controller retrieves the user’s stored password hash, uses it to encrypt the challenge again, and compares its result to the client’s response.
Access Granted (or Denied)
If the encrypted responses match, authentication is a success. If not, access is blocked.
Key points
The real password never travels the network in plain text.
Rather, password hashes are used to encrypt proof that the user knows the password.
This prevents eavesdropping but, as we’ll see, is far from bulletproof.
What is NTLM used for?
Despite its age, NTLM’s roots are still embedded in the fabric of many corporate networks. You’ll find NTLM used in situations such as:
Authenticating devices running old versions of Windows (Windows 95/98/NT)
Allowing modern servers to talk to outdated clients or applications that don’t support Kerberos
Handling local logons on standalone systems or non-domain-joined machines
Acting as a fallback method when Kerberos fails
Nobody sets out to rely on an old authentication protocol, but supporting legacy systems and complex networks can make a total phase-out difficult. Think of NTLM as the stubborn relative at a family reunion; it might not be the life of the party, but you can’t just show it the door.
Breaking down the NTLM authentication process
NTLM’s core mechanism is the challenge-response handshake, as mentioned earlier, but there are nuances worth understanding.
Inside the NTLM handshake
-
Credentials gathering
Users enter their username, password, and domain into their device.
-
Hashing
The client creates a hash of the password (not the plaintext) and immediately gets rid of the actual password.
-
Initiation
The client sends just the username to the server.
-
Random challenge
The server throws down a 16-byte random number, daring the client to prove their identity.
-
Encrypted response
The client encrypts this challenge using the password hash, then sends the result as a response.
-
Third-party verification
The server checks with the domain controller, which encrypts the challenge with its own copy of the user’s hash.
-
Match and approve
If the hashes line up, access is allowed.
On the surface, NTLM keeps passwords off the network, favoring hashed comparisons. However, this method has aged poorly, making it a tempting target for modern attackers.
NTLM vs Kerberos: What’s the real difference?
If NTLM is the defender stuck in the past, Kerberos is the fast, modern alternative Microsoft now trusts by default.
The approach
NTLM
-
Uses a challenge-response (three-message) exchange, validating identity each time for each resource.
Kerberos
-
Implements a “ticketing” system managed by a Key Distribution Center (KDC). After initial login, users get a ticket (session key) granting access for a defined period, reducing repeated password usage.
Encryption
NTLM
-
Relies on password hashing, which, if stolen, can be abused by attackers in “pass-the-hash” techniques.
Kerberos
-
Uses strong encryption. Both tickets and authenticators are encrypted, making credential theft much less exploitable.
Security
NTLM
-
No support for multifactor authentication
-
Vulnerable to brute-force and pass-the-hash attacks
-
Lacks salting on password hashes
Kerberos
-
Built around encrypted ticket-granting services
-
The default for Active Directory domains
-
Modern, flexible, and more resilient to most types of credential attacks
NTLM’s main flaw lies in how it handles password hashes and authentication. Without “salting” (adding random data to hashes), attackers with access to password hashes can impersonate users, with no need for the real password. This makes brute-force cracking and pass-the-hash attacks dangerously effective.
Add to that the static, simplistic cryptography of NTLM and lack of multifactor authentication options, and you have a recipe for compromise that modern threat actors love to exploit.
Kerberos, by contrast, brings session tickets, encrypted communications, and strong cryptographic routines. It adds layers of defense that NTLM simply can’t match.
Benefits of NTLM and why do some still use it
Despite its faults, NTLM does offer a few genuine advantages, especially when looking through the lens of legacy support:
- Compatibility: Keeps older software and operating systems functional in mixed environments
- Simplicity: Straightforward, low overhead compared to more complex protocols
- Password protection (to an extent): Ensures the user’s plaintext password is never sent over the wire
But for every advantage, there’s a corresponding risk. Compatibility is what keeps NTLM on life support; it’s also what makes it so dangerous in a modern context.
Disadvantages and security concerns of NTLM
NTLM’s disadvantages have become increasingly critical as attackers grow bolder and more sophisticated.
Vulnerable to attack
Lack of password salting allows attackers to impersonate users using hashed credentials
Susceptible to brute-force and pass-the-hash exploits
No support for contemporary security standards
No multifactor authentication
Can’t harness the latest encryption algorithms
Obsolete but hard to terminate
Legacy systems require it, so it continues to have a presence
Think of NTLM as a ramshackle lock on a door. It works, but any determined burglar knows exactly how to force it open.
Frequently asked questions
Yes, but only for backward compatibility. Kerberos remains the default for new Active Directory domains.
It can be, but only if all systems and applications in your network support Kerberos or another secure alternative.
NTLM relies on outdated cryptography, is vulnerable to pass-the-hash attacks, and lacks multifactor authentication support.
Many older Windows systems and some applications require NTLM for network authentication, which is why it persists.
Network audits, monitoring tools, and reviewing system logs can reveal where NTLM authentication attempts occur.
Strengthen your defenses
If NTLM still lurks in your organization, treat it the way you’d treat an unsecured backdoor. Don’t rely on hope. Make auditing, patching, and ultimately moving away from NTLM a clear security objective. It’s also worth considering investing in security solutions and identity protection strategies tailored for modern threats.
Related Resources
Protect What Matters
Secure endpoints, email, and employees with the power of our 24/7 SOC. Try Huntress for free and deploy in minutes to start fighting threats.
Try Huntress for Free
