8.3 Windows Authentication: NTLM, Kerberos & Password Security

8.3 Windows Authentication: NTLM, Kerberos & Password Security

Authentication in Microsoft Windows environments relies on two distinct protocol families: the legacy NT LAN Manager (NTLM) challenge-response suite and the modern Kerberos network authentication protocol. For a CREST-certified penetration tester, understanding how credentials are stored in memory and on disk, how cryptographic tokens are exchanged across the wire, and how protocol design weaknesses can be weaponized is fundamental to assessing Windows security.

---

Windows Credential Storage: SAM vs NTDS.dit

Windows stores credentials in two distinct databases depending on whether the system operates as a standalone/workgroup host or an Active Directory Domain Controller.

+-----------------------------------------------------------------------------+
|                         WINDOWS CREDENTIAL STORAGE                          |
+-----------------------------------------------------------------------------+
| 1. Local Workstations & Member Servers:                                     |
|    [SAM Registry Hive: %SystemRoot%\System32\config\SAM]                    |
|    Protected by Boot Key (SYSKEY) stored in SYSTEM registry hive.          |
|    Holds local user accounts and NTLM password hashes.                     |
|                                                                             |
| 2. Active Directory Domain Controllers:                                     |
|    [NTDS Database: %SystemRoot%\NTDS\NTDS.dit]                              |
|    Extensible Storage Engine (ESE/Jet) database file.                       |
|    Encrypted using Password Encryption Key (PEK) derived from SYSTEM hive.  |
|    Holds all domain user, computer, and service account hashes.             |
+-----------------------------------------------------------------------------+

1. The Security Account Manager (SAM)

On standalone systems and domain member servers, local accounts are stored in the Security Account Manager (SAM) registry hive (%SystemRoot%\System32\config\SAM).

• The operating system locks the SAM file during runtime to prevent direct file access.
• Password hashes within the SAM hive are encrypted using the SYSKEY (or Boot Key), which is stored in the SYSTEM registry hive (%SystemRoot%\System32\config\SYSTEM).
• Extracting local hashes requires offline access or administrative privileges to create hive copies:

  reg save HKLM\SAM C:\temp\sam.save
  reg save HKLM\SYSTEM C:\temp\system.save
  

2. The Active Directory Database (NTDS.dit)

On Domain Controllers, domain accounts are not stored in the SAM hive; they are maintained within the NTDS.dit database file (%SystemRoot%\NTDS\NTDS.dit).

• NTDS.dit is an Extensible Storage Engine (ESE / Jet) database containing all domain objects, schema definitions, group memberships, Kerberos master keys, and password hashes.
• The database is locked by the Active Directory Domain Services engine (ntds.exe). Extracting NTDS.dit requires leveraging the Volume Shadow Copy Service (VSS), invoking the built-in ntdsutil utility, or using remote replication protocols:

  # Extracting via Volume Shadow Copy
  vssadmin create shadow /for=C:
  copy \\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy1\Windows\NTDS\NTDS.dit C:\temp\ntds.dit
  copy \\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy1\Windows\System32\config\SYSTEM C:\temp\system.dit
  

• Decrypting NTDS.dit hashes requires the Password Encryption Key (PEK) stored inside the Domain Controller's SYSTEM registry hive.

3. Password Hash Algorithms: LM vs NTLM

                LAN MANAGER (LM) HASH ALGORITHM (COMPLETELY BROKEN)
Password: "Password123" 
   |--> Uppercase: "PASSWORD123"
   |--> Split into two 7-byte halves: ["PASSWOR"] and ["D123\0\0\0"]
   |--> DES Encrypt constant "KGS!@#$%" with Half 1 ===> Hash Half 1
   |--> DES Encrypt constant "KGS!@#$%" with Half 2 ===> Hash Half 2
   |--> Concatenate halves ===> 16-byte LM Hash (Easily cracked via tables!)

                NT LAN MANAGER (NTLM) HASH ALGORITHM (UNSALTED)
Password: "Password123"
   |--> UTF-16 Little Endian Encoding: 50 00 61 00 73 00 73 00 77 00 ...
   |--> MD4 Hash Digest ===> 32-character Hex String (Unsalted!)

A. LAN Manager (LM) Hash (Obsolete & Insecure)

• Length Limitation: Truncates passwords at 14 characters.
• Case Insensitivity: Converts all characters to uppercase before hashing, eliminating case complexity.
• Split Halves: Splits the 14-byte string into two 7-byte chunks and pads shorter halves with null bytes. Each 7-byte chunk is used as a 56-bit DES key to encrypt the fixed ASCII string "KGS!@#$%" (0x4B47532140232425).
• Empty Half Vulnerability: If a password is 7 characters or fewer, the second half always results in the well-known constant AAD3B435B51404EE. Attackers can crack both halves independently in seconds.
• Disabled by default since Windows Vista and Windows Server 2008.

B. NT LAN Manager (NTLM) Hash

• Formula: MD4(UTF-16LE(password))
• Mechanics: The plaintext password is encoded as a UTF-16 Little Endian byte array and processed through the MD4 message digest algorithm. The result is a 16-byte (32-character hex) digest.
• Critical Flaw: Zero Salting: The NTLM hash incorporates no cryptographic salt. Two identical passwords yield identical NTLM hashes across different accounts, computers, and domains. This makes NTLM hashes highly susceptible to precomputed rainbow tables and lookup dictionaries.

---

NTLM Authentication Protocols & Attacks

The NTLM Challenge-Response Handshake

When authenticating across the network using NTLM (over SMB, HTTP, or MSRPC), the client never transmits its stored NTLM hash over the wire. Instead, it executes a three-way challenge-response handshake:

Client                                                Server
   |                                                     |
   |----- 1. Type 1: NEGOTIATE_MESSAGE ----------------->| (Supported capabilities)
   |                                                     |
   |<---- 2. Type 2: CHALLENGE_MESSAGE ------------------| (Server Nonce / 8-byte Challenge)
   |                                                     |
   | [Computes NetNTLM response using NTLM hash & Nonce] |
   |                                                     |
   |----- 3. Type 3: AUTHENTICATE_MESSAGE --------------->| (NetNTLM response, User, Domain)
   |                                                     |
   |<---- Access Granted / Denied -----------------------|

NTLMv1 vs NTLMv2

• NetNTLMv1: The server provides an 8-byte challenge. The client splits its 16-byte NTLM hash into three 7-byte keys and encrypts the challenge using DES. NetNTLMv1 can be converted into DES keys and cracked in under 24 hours using precomputed tables.
• NetNTLMv2: Employs HMAC-MD5. The client creates an NTLMv2_Hash = HMAC-MD5(NTLM_Hash, UPPERCASE(User) + Domain). The client generates a random client challenge (client nonce) and timestamp (the Client Blob). The response is calculated as: HMAC-MD5(NTLMv2_Hash, Server_Challenge + Client_Blob). NetNTLMv2 is resilient against precomputed tables but remains vulnerable to dictionary attacks and relaying.

Stored NTLM Hash vs NetNTLM Network Hash

A critical distinction frequently tested on CREST examinations is the difference between a stored NTLM hash and a NetNTLM challenge-response hash:

• Stored NTLM Hash: Resides in the SAM hive or NTDS.dit. It is the raw MD4 digest. It can be used directly in Pass-the-Hash (PtH) attacks.
• NetNTLMv1 / NetNTLMv2 Hash: The network capture format (captured via Wireshark or Responder). It CANNOT be used in Pass-the-Hash attacks. An analyst must either crack the NetNTLM hash offline using Hashcat (Mode 5600 for NetNTLMv2) to recover the plaintext password, or relay the authentication token live to another server.

Pass-the-Hash (PtH)

Because the NTLM challenge-response protocol uses the stored NTLM hash as the encryption key to calculate responses, an attacker possessing the stored NTLM hash does not need to crack the plaintext password. The attacker passes the 32-character hash directly to client software (e.g., Impacket's psexec.py, wmiexec.py, or mimikatz) to authenticate to target services across SMB, RPC, and WMI.

# Pass-the-Hash execution using Impacket wmiexec
wmiexec.py -hashes aad3b435b51404eeaad3b435b51404ee:fc525c9680e4766f63f01103282453a1 Administrator@192.168.1.50

NTLM Relay Attacks

In an NTLM Relay attack, an attacker positions themselves between a victim client and a target server (e.g., via LLMNR/NBT-NS spoofing with Responder). When the victim attempts to authenticate to the attacker's machine, the attacker relays the Type 1, Type 2, and Type 3 messages in real-time to an enterprise target server. If the victim has administrative privileges on that target, the attacker gains full administrative access.

Key Mitigations for NTLM Relay:

1. Enforce SMB Signing (RequireSecuritySignature = 1): Cryptographically signs each SMB packet with a session key. The relaying attacker cannot forge valid signatures, terminating the session.
2. Enforce LDAP Signing & Channel Binding: Protects Domain Controllers from relayed NTLM authentication over LDAP/LDAPS.
3. Disable NTLM: Enforce Kerberos-only authentication enterprise-wide.

---

Kerberos Authentication in Depth

Kerberos is a ticket-based, third-party authentication protocol (RFC 4120) that uses symmetric cryptography to authenticate clients to network services without transmitting passwords or password hashes across the network.

+-----------------------------------------------------------------------------+
|                        THE KERBEROS 3-STEP EXCHANGE                         |
+-----------------------------------------------------------------------------+
|                                                                             |
|   Client                         Domain Controller (KDC)   Application      |
|     |                                [AS]     [TGS]          Server         |
|     |--- 1. AS-REQ (Encrypted Timestamp) ->|     |              |            |
|     |<-- 2. AS-REP (TGT + Session Key) ---|     |              |            |
|     |                                            |              |            |
|     |--- 3. TGS-REQ (Presents TGT + SPN) ------->|              |            |
|     |<-- 4. TGS-REP (Service Ticket) ------------|              |            |
|     |                                                           |            |
|     |--- 5. AP-REQ (Presents Service Ticket) ------------------>|            |
|     |<-- 6. AP-REP (Mutual Authentication / Established) -------|            |
+-----------------------------------------------------------------------------+

Core Kerberos Components

• Key Distribution Center (KDC): Runs on Domain Controllers; divided into the Authentication Service (AS) and the Ticket Granting Service (TGS).
• Ticket Granting Ticket (TGT): Issued by the AS. Proves the user's identity to the KDC. Encrypted with the secret key of the domain's krbtgt account.
• Service Principal Name (SPN): A unique identifier for a service instance (e.g., MSSQLSvc/sql01.corp.internal:1433).
• Service Ticket (TGS Ticket): Issued by the TGS. Authorizes access to a specific service. Encrypted with the password hash of the service account running that service.

The 3-Step Handshake

1. Authentication Service Exchange:
   • AS-REQ: The client encrypts the current timestamp using its own password hash (Pre-Authentication, PA-ENC-TIMESTAMP) and sends it to the KDC's AS to prevent replay attacks.
   • AS-REP: The AS validates the timestamp using the user's stored hash. It returns a TGT (encrypted with the krbtgt key) and a Client/TGS Session Key (encrypted with the user's password hash).
2. Ticket-Granting Service Exchange:
   • TGS-REQ: The client presents the TGT and an Authenticator to the TGS, requesting access to a specific Service Principal Name (SPN).
   • TGS-REP: The TGS decrypts the TGT using the krbtgt key and verifies the user's PAC. It issues a Service Ticket (encrypted with the target service account's password hash) and a Client/Server Session Key.
3. Application Exchange:
   • AP-REQ: The client delivers the Service Ticket and an Authenticator directly to the target application server.
   • AP-REP: The application server decrypts the Service Ticket using its own password hash, validates the user's identity, and grants access.

---

Kerberos Attack Vectors

1. Kerberoasting

• Mechanics: Any authenticated domain user (even a low-privileged contractor) can request a TGS Service Ticket for any service account that has an SPN registered in Active Directory.
• Because the KDC issues the Service Ticket encrypted with the target service account's password hash, the attacker extracts the encrypted ticket from memory or packet captures.
• The attacker takes the ticket offline and performs brute-force dictionary cracking against the service account's password hash using Hashcat (Mode 13100).
• Operational Advantage: Kerberoasting generates zero failed logon events on the Domain Controller, because requesting a service ticket is a standard, legitimate operation.

# Requesting Kerberoastable tickets using Impacket GetUserSPNs
GetUserSPNs.py corp.internal/jdoe:Password123 -dc-ip 192.168.10.10 -request

# Cracking Kerberoast tickets offline with Hashcat
hashcat -m 13100 kerb_tickets.txt /usr/share/wordlists/rockyou.txt

2. AS-REP Roasting

• Mechanics: Targets user accounts that have the DONT_REQ_PREAUTH flag (UAC bit 0x400000) enabled in Active Directory.
• For these accounts, Kerberos pre-authentication is disabled. An attacker can transmit an AS-REQ for the target username without supplying an encrypted timestamp.
• The KDC immediately replies with an AS-REP containing session data encrypted with that user's password hash.
• The attacker captures the AS-REP message and cracks it offline using Hashcat (Mode 18200).
• Assessment Implication: If unauthenticated network access to a DC is available, AS-REP Roasting can be executed without any initial domain credentials.

# Extracting AS-REP roastable hashes using GetNPUsers
GetNPUsers.py corp.internal/ -usersfile userlist.txt -dc-ip 192.168.10.10 -no-pass

# Cracking AS-REP hashes offline with Hashcat
hashcat -m 18200 asrep_hashes.txt /usr/share/wordlists/rockyou.txt

3. Golden Tickets vs Silver Tickets

• Golden Ticket: Created after an attacker achieves full domain compromise and extracts the krbtgt hash. The attacker forges a TGT with arbitrary user identifiers (e.g., Administrator), arbitrary group SIDs (Domain Admins 512, Enterprise Admins 519), and an extended validity period (e.g., 10 years). Grants persistent, undetected forest-wide administrative access.
• Silver Ticket: Created when an attacker obtains the password hash of a specific service account. The attacker forges a Service Ticket directly for that service, bypassing the KDC completely. This makes Silver Tickets stealthier than Golden Tickets because no traffic touches the Domain Controller.

---

Credential Harvesting from Memory: LSASS & Mimikatz

The Local Security Authority Subsystem Service (lsass.exe) is the core Windows security process responsible for enforcing security policies, handling interactive user logons, and caching active credentials.

Credentials Maintained in LSASS Memory

Depending on installed Security Support Providers (SSPs) and Windows versions, LSASS caches:

• Stored NTLM hashes of logged-on users.
• Kerberos tickets (TGTs and TGS tickets) and session keys.
• Plaintext passwords (in legacy systems supporting WDigest, SSP, or CredSSP).

Harvesting Mechanics

Security assessment tools like Mimikatz interact with LSASS to extract active credentials:

• sekurlsa::logonpasswords: Interrogates LSASS memory tables to extract plaintext passwords, NTLM hashes, and Kerberos keys.
• sekurlsa::tickets /export: Extracts all Kerberos .kirbi ticket files from memory for use in Pass-the-Ticket (kerberos::ptt) attacks.

# Dumping LSASS memory offline using Sysinternals procdump
procdump.exe -ma lsass.exe C:\temp\lsass.dmp

# Extracting credentials offline in Mimikatz
mimikatz.exe
sekurlsa::minidump C:\temp\lsass.dmp
sekurlsa::logonpasswords

Enterprise Mitigations Against LSASS Dumping

1. Credential Guard: Uses Virtualization-Based Security (VBS) to isolate the LSA process inside an isolated hardware virtual container (Virtual Secure Mode / VSM). The host OS kernel cannot access LSA secrets, preventing Mimikatz and memory-dumping utilities from extracting hashes.
2. LSA Protection (RunAsPPL): Configures LSASS to run as a Protected Process Light (RunAsPPL = 1 in HKLM\SYSTEM\CurrentControlSet\Control\Lsa). Blocks non-protected processes from opening lsass.exe with PROCESS_VM_READ rights.
3. Disable WDigest Plaintext Caching: Ensure UseLogonCredential is set to 0 under HKLM\System\CurrentControlSet\Control\SecurityProviders\WDigest.