ExamFinch.com My Study

Study guide

8.3 Windows Authentication: NTLM, Kerberos & Password Security

Practice this exam

CREST Practitioner Security Analyst CPSA

Track your progress as you read

Finished sections get a check mark.

1 Chapter 1: Soft Skills, Legal Framework & Assessment Management

1.1 The Penetration Testing Engagement Lifecycle & Scoping 1.2 Legal Framework: Computer Misuse Act & Compliance 1.3 Understanding, Explaining & Managing Technical Risk 1.4 Record Keeping, Interim Escalation & Reporting Standards

2 Chapter 2: Core Networking: IP Protocols & Network Architectures

2.1 IPv4 and IPv6 Addressing, Subnetting & Header Architecture 2.2 TCP and UDP Transport Protocols & Handshake Mechanics 2.3 ICMP Protocol, Network Diagnostics & Error Messages 2.4 Network Topologies, Switched Media & VLAN Segmentation 2.5 Network Media, Ethernet Standards & Physical Topologies

3 Chapter 3: Cryptography & Secure Communication Protocols

3.1 Symmetric & Asymmetric Cryptographic Algorithms 3.2 Cryptographic Hash Functions, MACs & Digital Signatures 3.3 Secure Protocols: SSL/TLS, IPsec & SSH

4 Chapter 4: Background Information Gathering & OSINT Reconnaissance

4.1 WHOIS Records, Domain Registrars & Autonomous Systems 4.2 DNS Infrastructure, Record Types & Zone Transfers 4.3 Search Engine Reconnaissance, Google Dorking & Information Leakage 4.4 Newsgroups, Mailing Lists & Public Archive Reconnaissance

5 Chapter 5: Networking Equipment & Infrastructure Protocols

5.1 Router & Switch Management: SNMP, SSH & Authentication 5.2 Layer 2 Protocols: ARP, CDP, STP, VTP & Redundancy 5.3 Core Network Services: DHCP, NTP & TFTP 5.4 Wireless Security (802.11) & VoIP Assessment 5.5 Out-of-Band Management, Console Access & Cisco Reverse Telnet

6 Chapter 6: Network Mapping, Nmap Techniques & Target Identification

6.1 Host Discovery Techniques & Ping Sweep Methodologies 6.2 Port Scanning Mechanics: TCP, UDP & Stealth Scans 6.3 OS Fingerprinting, Service Detection & Timing Templates 6.4 Firewall and IDS/IPS Evasion Techniques 6.5 Passive OS & Service Fingerprinting 6.6 Network Access Control Analysis & Firewall Rule Base Review

7 Chapter 7: Vulnerability Identification & Tool Output Analysis

7.1 Vulnerability Scanning Principles & Methodology 7.2 CVE Referencing, CVSS Scoring & Risk Prioritisation 7.3 Banner Grabbing, Service Verification & Manual Triage 7.4 Host Audit Techniques: Processes, Sockets, Patch Levels & Interesting Files

8 Chapter 8: Microsoft Windows Security Assessment & Active Directory

8.1 Active Directory Architecture & Domain Reconnaissance 8.2 Windows User & Group Enumeration via SMB & RPC 8.3 Windows Authentication: NTLM, Kerberos & Password Security 8.4 Windows Patch Management, Local Security & Common Services 8.5 Windows File System, Share & Registry Permissions 8.6 Desktop Lockdown, Citrix Breakout & Common Windows Applications

9 Chapter 9: Unix & Linux Security Assessment & Legacy Services

9.1 Linux/Unix Security Architecture, Permissions & Filesystem 9.2 Unix User Enumeration & Service Discovery 9.3 Network File System (NFS) & RPC Services Assessment 9.4 Legacy Unix Services: R-Services, X11, FTP & Modern SSH 9.5 Unix Remote Information Services: rusers, rwho, finger & systat 9.6 Unix Vulnerability Exploitation & Post-Exploitation Workflow

10 Chapter 10: Web Architectures, Technologies & Testing Methodologies

10.1 Web Server Architecture & the HTTP/HTTPS Protocol 10.2 Web Application Components, Frameworks & State Management 10.3 Web Reconnaissance, Content Discovery & Threat Modelling 10.4 Testing Authentication, Authorization & Session Management 10.5 Web Service Protocols: SOAP, REST & XML Messaging 10.6 Web APIs, Server Extensions & Client-Side Sub-Components

11 Chapter 11: Web Testing Techniques & OWASP Top Vulnerabilities

11.1 Input Validation Vulnerabilities & Parameter Manipulation 11.2 Cross-Site Scripting (XSS): Types, Impact & Defenses 11.3 Cross-Site Request Forgery (CSRF) & Client-Side Attacks 11.4 Command Injection, File Upload Vulnerabilities & API Flaws 11.5 Information Disclosure: Error Messages & Mark-up Leakage 11.6 Injection Beyond SQL: LDAP, XPath, Code & Template Injection 11.7 Source Code Review & Encoded/Cryptographic Value Analysis

12 Chapter 12: Database Security Assessment & SQL Injection

12.1 Database Architectures, Default Ports & Authentication 12.2 SQL Injection (SQLi) Foundations & In-Band Techniques 12.3 Blind SQL Injection & Database Enumeration 12.4 Database Attack Vectors, Stored Procedures & Hardening

8.3 Windows Authentication: NTLM, Kerberos & Password Security

Key Takeaways Explain This Topic AI

Local Windows accounts are stored in the SAM registry hive protected by the SYSKEY, whereas domain accounts reside in Active Directory's NTDS.dit database; NTLM password hashes are unsalted MD4 digests of the UTF-16LE password string.

The NTLM challenge-response protocol uses a three-way handshake (Negotiate, Challenge, Authenticate) resulting in NetNTLMv1/v2 challenge hashes that cannot be passed directly but can be cracked offline or relayed if SMB/LDAP signing is unenforced.

Pass-the-Hash (PtH) enables an attacker with a stored NTLM hash to authenticate across network services (SMB, RPC, WMI) without cracking the plaintext password, because the NTLM hash serves directly as the cryptographic secret.

Kerberos operates via a three-phase ticket system (AS-REQ/AS-REP, TGS-REQ/TGS-REP, AP-REQ); key attacks include Kerberoasting (cracking service tickets for SPN accounts), AS-REP Roasting (cracking accounts with pre-auth disabled), and Golden/Silver ticket forgery.

Last updated: September 2026

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:

Enforce SMB Signing ( RequireSecuritySignature = 1 ): Cryptographically signs each SMB packet with a session key. The relaying attacker cannot forge valid signatures, terminating the session.

Enforce LDAP Signing & Channel Binding: Protects Domain Controllers from relayed NTLM authentication over LDAP/LDAPS.

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

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).

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.

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
  • Feature Golden Ticket Silver Ticket
  • Ticket Type Forged Ticket Granting Ticket (TGT) Forged Service Ticket (TGS Ticket)
  • Encryption Key krbtgt account NTLM or AES-256 hash Target Service account NTLM or AES-256 hash
  • Scope of Impact Entire Forest / Domain (Enterprise persistence) Single Service (e.g., CIFS, HTTP, MSSQL)

KDC Interaction Interacts with KDC to request subsequent TGS tickets Zero KDC interaction (Presented directly to service)

Detection Profile Appears in KDC event logs (Event ID 4769) Bypasses Domain Controller logging entirely

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

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.

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.

Disable WDigest Plaintext Caching: Ensure UseLogonCredential is set to 0 under HKLM\System\CurrentControlSet\Control\SecurityProviders\WDigest .