Kerberos vs NTLM: The Practical Difference Every Windows Admin Should Know
Retool's new app builder is where AI-generated code ships safely
Building apps with AI is easy. Getting them to production safely is another story.
When a Windows machine authenticates to a domain resource, it uses either Kerberos or NTLM. Most administrators know that 'Kerberos is better and NTLM is bad': but without understanding why and when each one is used, you cannot accurately assess your attack surface or understand why certain attacks succeed in your environment.
This matters directly for the detections you build: pass-the-hash attacks use NTLM, Kerberoasting uses Kerberos, NTLM relay exploits NTLM. Knowing the difference tells you what is possible where.
How Kerberos Works
Kerberos authentication involves three parties: the client, the Key Distribution Center (the domain controller), and the service the client wants to access.
Step 1: Client authenticates to the KDC (AS-REQ / AS-REP). The client sends an AS-REQ (Authentication Service Request) to the domain controller's KDC. The request proves the client's identity by encrypting a timestamp with the user's password hash. The KDC decrypts the timestamp, verifies the user's identity, and returns an AS-REP containing a Ticket-Granting Ticket (TGT): a time-limited token that proves the client authenticated successfully.
The user's password hash never leaves the client machine. The KDC proves the client knows the hash by verifying the encrypted timestamp.
Step 2: Client requests a service ticket (TGS-REQ / TGS-REP). When the client wants to access a specific service (a file share, a web application, a SQL server), it presents its TGT to the KDC and requests a service ticket for that specific resource. The KDC issues a service ticket encrypted with the target service's account hash: only the service can decrypt it.
Step 3: Client presents the service ticket to the target. The client presents the service ticket to the target service. The service decrypts it, verifies the authentication, and grants access. The domain controller is not involved in this final step: after the tickets are issued, the KDC is out of the picture.
Security properties: Credentials never traverse the network. Service tickets are time-limited (default 10 hours). Tickets are service-specific: a ticket for the file server cannot be used for the SQL server.
Kerberos attack surface: Kerberoasting exploits the fact that service tickets are encrypted with the service account's hash. An attacker who requests a service ticket for an account with a SPN can attempt to crack the service account's password offline. AS-REP roasting exploits accounts configured with 'Do not require Kerberos preauthentication': these return an encrypted AS-REP without requiring the client to prove identity first, allowing the encrypted blob to be cracked offline.
How NTLM Works
NTLM is a challenge-response protocol: the server proves the client knows the correct password hash without the client sending the hash directly.
Step 1: Client sends a NEGOTIATE message. The client initiates authentication by sending an NTLM NEGOTIATE message to the target server.
Step 2: Server sends a CHALLENGE. The server generates a random 8-byte challenge and sends it to the client.
Step 3: Client sends a AUTHENTICATE response. The client computes a response by running the NTLM hash through an encryption function with the server's challenge. The result is sent as the AUTHENTICATE message. The client never sends the NTLM hash directly.
Step 4: Server verifies the response. The server passes the client's response to the domain controller (or verifies locally for local accounts). If the DC confirms the response is valid for that user's hash and that challenge, authentication succeeds.
Security properties: The password hash is not transmitted, but the challenge-response exchange can be attacked in two ways:
- Pass-the-hash: If an attacker obtains the NTLM hash (from LSASS, SAM, or ntds.dit), they can generate valid AUTHENTICATE responses without knowing the plaintext password. Authentication succeeds because the server only verifies the hash, not the password.
- NTLM relay: An attacker intercepts the NTLM challenge from a legitimate server and relays it to the client. The client computes a valid response to the relayed challenge. The attacker relays that response to the original server, completing authentication as the victim user: without ever obtaining the hash.
When Windows uses NTLM instead of Kerberos:
- Authentication to a system by IP address instead of hostname (no SPN lookup possible for bare IPs)
- Authentication to a non-domain-joined system
- Authentication to a domain-joined system where the SPN is not correctly registered
- Legacy applications configured to use NTLM explicitly
Briefings like this, every morning before 9am.
Threat intel, active CVEs, and campaign alerts, distilled for practitioners. 50,000+ subscribers. No noise.
Determining Which Protocol Is In Use
Knowing which protocol fires in a given scenario is important for attack surface assessment.
Check via Windows Security event log:
On the destination machine, Event ID 4624 (successful logon) includes the AuthenticationPackageName field:
Kerberos: Kerberos was usedNTLM: NTLM was usedNegotiate: the system negotiated between the two and typically settled on Kerberos
Force Kerberos vs NTLM to test:
:: This uses Kerberos (hostname lookup enables SPN resolution)
net use \\SERVER01\share
:: This forces NTLM (IP address, no SPN lookup)
net use \\192.168.1.10\share
Check which services are using NTLM in your environment:
# Query Windows NTLM operational log (shows inbound NTLM authentications)
Get-WinEvent -LogName "Microsoft-Windows-NTLM/Operational" |
Where-Object { $_.Id -eq 8004 } |
Select-Object -First 20 -Property TimeCreated, Message
Event ID 8004 in the NTLM operational log shows inbound NTLM authentications to the machine: useful for identifying applications and services that are still using NTLM and should be migrated to Kerberos.
Why NTLM Persists and How to Reduce It
Despite Kerberos being more secure, NTLM persists in every Windows environment because:
-
IP-address-based connections: Many applications connect to backend services by IP. NTLM is the only option when there is no hostname for SPN lookup. Fix: use hostnames instead of IPs in application configuration.
-
Missing or broken SPNs: If a service's SPN is not registered in AD, Kerberos cannot generate a service ticket for it: Windows falls back to NTLM. Fix: audit SPNs with
setspn -L ACCOUNTNAMEand register missing SPNs. -
Local account authentication: NTLM is always used for local (non-domain) account authentication. Fix: use domain accounts for services instead of local accounts.
-
Legacy application configuration: Some applications have NTLM hardcoded. Fix: check vendor documentation for Kerberos support and upgrade where possible.
Reducing NTLM without breaking things:
Do not block NTLM globally without testing: this will break things immediately. The safe approach:
- Enable the NTLM operational log and review which applications are using NTLM (Event ID 8001 for outbound, 8004 for inbound)
- Fix the root cause for each application (IP-to-hostname, missing SPN, local account replacement)
- Use Group Policy to set 'Network security: Restrict NTLM' to 'Audit all' first, which logs but does not block
- After 30 days of audit with no unresolved applications, consider moving to 'Deny all' for specific server types where NTLM should never occur (domain controllers, for example)
The bottom line
Kerberos is ticket-based: credentials never cross the network, making it resistant to credential relay attacks. NTLM is challenge-response: the hash can be relayed or replayed in pass-the-hash attacks. NTLM fires when Kerberos cannot: IP-address connections, missing SPNs, local account authentication, and legacy application configuration. Reducing NTLM requires identifying its root causes per application before any protocol restriction: audit with Event ID 8004 in the NTLM operational log, fix root causes, and restrict gradually.
Frequently asked questions
What is the difference between Kerberos and NTLM authentication?
Kerberos uses time-limited tickets issued by the domain controller: credentials never traverse the network, and tickets are service-specific. NTLM uses a challenge-response mechanism where the client proves knowledge of a password hash: the hash is not sent directly, but it can be relayed or replayed in pass-the-hash attacks. Kerberos is the default for domain-joined systems; NTLM is the fallback for IP connections, missing SPNs, and local accounts.
When does Windows use NTLM instead of Kerberos?
Windows uses NTLM when Kerberos cannot complete authentication: connecting by IP address instead of hostname (no SPN lookup), connecting to a non-domain-joined system, authenticating with a local account, when the service's SPN is not registered in Active Directory, or when an application is explicitly configured to use NTLM.
Why is NTLM authentication considered insecure?
NTLM is vulnerable to three attack classes. Pass-the-hash: attackers capture NTLM hashes from memory with tools like Mimikatz and authenticate without knowing the plaintext password. NTLM relay: attackers intercept an authentication challenge and relay it to a target server, authenticating as the victim (e.g., PetitPotam, PrintNightmare relay). Offline brute force: captured Net-NTLMv2 hashes can be cracked offline since they contain enough information to test password guesses. Kerberos avoids all three: tickets are service-specific, not replayable, and credentials never traverse the network.
How do I block NTLM authentication in Active Directory?
Use Group Policy to restrict NTLM: Computer Configuration > Windows Settings > Security Settings > Local Policies > Security Options > Network Security: Restrict NTLM. Start with Audit mode (set to 'Audit all') and review Event ID 8004 in the NTLM operational log to identify services still using NTLM before enabling Block mode. Common NTLM dependencies include legacy applications, printers, and network-attached storage devices. For modern environments, disabling NTLM across the domain requires Kerberos SPNs to be correctly registered for all services.
What is a Kerberos SPN and why does it matter for security?
A Service Principal Name (SPN) is a unique identifier for a service instance that clients use to request a Kerberos service ticket. SPNs must be registered for services that require Kerberos authentication. Missing SPNs cause Windows to fall back to NTLM, increasing attack surface. Misconfigured or duplicate SPNs cause authentication failures or Kerberoasting vulnerability (service accounts with SPNs can have their ticket-encrypted passwords cracked offline). Audit SPNs with: Get-ADUser -Filter {ServicePrincipalName -ne '$null'} -Properties ServicePrincipalName.
What is NTLM relay and how does it exploit the NTLM authentication protocol's design weaknesses?
NTLM relay exploits the fact that NTLM authentication is a three-message challenge-response protocol that authenticates a server to a client but does not cryptographically bind the authentication to the specific session or service. An attacker positioned between a client and server can intercept the NTLM negotiation (Negotiate, Challenge, Authenticate messages) and relay them to a different target server in real time. The attacker never sees the plaintext password -- they act as a transparent intermediary, forwarding messages to both parties. The attacked server believes the authentication came from the legitimate client and grants access under that user's privileges. Common attack flows: Responder captures NTLM authentication triggered by broadcast protocols (LLMNR, NBT-NS) and relays them to SMB or LDAP on servers where the victim has admin rights. Ntlmrelayx automates this, often creating new domain admin accounts or extracting NTLM hashes from SAM via the relayed authentication. Primary defenses: disable LLMNR and NBT-NS to prevent hash capture triggers, enable SMB signing on all servers (makes relay to SMB fail), enable LDAP signing and channel binding (makes relay to LDAP fail), and enable Extended Protection for Authentication (EPA) on IIS/Exchange (prevents HTTP relay). NTLM relay is substantially mitigated by a combination of these controls; Kerberos-only environments eliminate it entirely.
Sources & references
Free resources
Critical CVE Reference Card 2025–2026
25 actively exploited vulnerabilities with CVSS scores, exploit status, and patch availability. Print it, pin it, share it with your SOC team.
Ransomware Incident Response Playbook
Step-by-step 24-hour IR checklist covering detection, containment, eradication, and recovery. Built for SOC teams, IR leads, and CISOs.
Get threat intel before your inbox does.
50,000+ security professionals read Decryption Digest for early warnings on zero-days, ransomware, and nation-state campaigns. Free, daily, no spam.
Unsubscribe anytime. We never sell your data.
Founder & Cybersecurity Evangelist, Decryption Digest
Cybersecurity professional with expertise in threat intelligence, vulnerability research, and enterprise security. Covers zero-days, ransomware, and nation-state operations for 50,000+ security professionals every morning.
Win a $2,495 Black Hat pass.
Full-access to Black Hat USA 2026 in Las Vegas. Subscribe free to enter.