AD Authentication
Last updated
Was this helpful?
Last updated
Was this helpful?
NTLM (NT LAN Manager) is a legacy authentication protocol that still appears in modern AD environments, particularly in fallback situations—such as when connecting to resources via IP address rather than hostname, or when a service isn’t properly registered in AD DNS. Some third-party applications also continue to prefer NTLM over Kerberos due to compatibility reasons.
The client creates an NTLM hash from the user’s password (Step 1) and sends the username to the server (Step 2).
The server replies with a randomly generated nonce, aka challenge (Step 3).
The client sends the response (the NTML-encypted nonce) back the server (Step 4).
The server forwards the username, nonce, and response to the DC (Domain Controller) (Step 5).
The DC uses the stored NTLM hash for that user to encrypt the nonce (Step 6) and if the result matches the response, authentication succeeds (Step 7).
NTML stores unsalted hashed passwords in SAM database (c:\windows\system32\config\sam) which cannot be copied while the Windows OS is running. Local Security Authority System (LSASS) runs with SYSTEM privileges and caches NTLM hashes.
Although NTLM hashes are non-reversible, the algorithm is very fast, making brute-force attacks relatively easy. Despite its weaknesses, NTLM remains in use primarily for compatibility with legacy systems and fallback scenarios.
Kerberos is the default authentication protocol in modern AD environments, having replaced NTLM since Windows Server 2003. It is based on Kerberos version 5 (originally developed by MIT) and relies on a ticket-based model involving a central authority called the Key Distribution Center (KDC). In AD, every Domain Controller functions as a KDC.
The key differences between the NTML and Kerberos protocols are that:
Challenge-response (NTML) vs. ticket-based (Kerberos) system.
The client initiates authentication directly with the application server (NTML) vs. authentication begins with the KDC (Kerberos).
The Kerberos authentication process works as follows:
User Login (AS-REQ) When a user logs in, their machine sends an Authentication Service Request (AS-REQ) to the DC (KDC). This request includes a timestamp encrypted using a key derived from the user's password.
KDC Response (AS-REP)
The KDC retrieves the user’s password hash from ntds.dit and attempts to decrypt the timestamp. If successful and the timestamp is valid (a duplicate timestamp may indicate a replay attack), the KDC replies with an Authentication Service Reply (AS-REP). This contains a session key (encrypted with the user’s password hash) and a Ticket Granting Ticket (TGT), which is encrypted with the krbtgt account’s hash (this is known only to the KDC). The client can decrypt the session key and stores the TGT, which is typically valid for 10 hours and renewable.
Service Request (TGS-REQ) When the user tries to access a service, the client sends a Ticket Granting Service Request (TGS-REQ) to the KDC. It includes the username, the encrypted TGT, a timestamp encrypted with the session key, and the name of the requested service.
KDC Issues Service Ticket (TGS-REP) The KDC validates the TGT, checks the timestamp, and ensures the username and IP address match. If everything checks out, it sends a Ticket Granting Service Reply (TGS-REP), which includes a new session key (shared between client and service) and a service ticket encrypted with the service account’s password hash.
Client to Service (AP-REQ) The client sends an Application Request (AP-REQ) to the service, containing the service ticket, the client’s username, and a timestamp encrypted with the new session key.
Service Validates and Grants Access The service decrypts the ticket using its own password hash, extracts the session key and username, and verifies the timestamp. If valid, it checks group membership information from the ticket and grants access accordingly.
To support Single Sign-On (SSO) and reduce the need for repeated authentication, Windows stores user credentials in memory. These cached credentials include NTLM or SHA1 password hashes and Kerberos tickets (TGTs and TGSs). They are held within the memory space of a critical Windows process called Local Security Authority Subsystem Service (LSASS).
Accessing LSASS memory requires SYSTEM or administrative privileges. The contents of LSASS are encrypted and undocumented, but attackers can still extract them with sufficient permissions. If they gain access, they can dump password hashes, cleartext passwords (if older protocols like WDigest are enabled), and even Kerberos tickets—allowing them to impersonate users or escalate privileges.
While inspecting LSASS or dumping credential materials, we may encounter various hash formats such as:
NTLM
Default for older AD (2003 level)
SHA1
Often used with AES in newer domains
DPAPI
Protects local secrets
Cleartext
If WDigest is enabled
Some defensive measures can reduce the risk of credential theft:
LSA Protection (also known as Credential Guard) restricts access to LSASS memory, even from administrative accounts. This can be enabled via registry configuration.
Disable WDigest to prevent storage of cleartext passwords in memory.
Use Endpoint Detection and Response (EDR) tools that can detect and alert on tools like Mimikatz or suspicious memory access patterns.
We can dump LSASS credentials or extract Kerberos tickets (TGS, TGT) using . However, running mimikatz directly on a machine is easily detected by antivirus and endpoint detection systems. To evade detection, attackers often inject it into memory via PowerShell or download LSASS memory for offline analysis using built-in tools like Task Manager or comsvcs.dll.
