NTLM vs Kerberos: Fundamental Differences in DFIR Investigations

Protocol Investigation Axiom

• Kerberos is a trusted third-party ticketing protocol: Initial logon creates a TGT (Event 4768) on the KDC, each service access generates a TGS (Event 4769), and the target host records an Event 4624.
• NTLM is a point-to-point challenge-response protocol: The domain controller only observes authentication if the target server delegates validation via Netlogon (Event 4776 / 8004). If the accessed account is local, the DC is completely blind.

Concept

In contemporary Active Directory environments, two core authentication protocols coexist:

1. Kerberos v5 (Default and Preferred Protocol): Employs symmetric shared-key cryptography orchestrated by a centralized trusted third party (the Key Distribution Center - KDC, hosted on every DC). The user never transmits their plaintext password or NTLM hash to resource servers.
2. NTLM (NT LAN Manager - Legacy Protocol): Uses a three-way challenge-response handshake (Negotiate, Challenge, Authenticate). The client proves password knowledge by computing a cryptographic response over a server-issued challenge using its NTLM hash.

---

Why It Matters in DFIR

Determining whether an action was performed over NTLM or Kerberos fundamentally directs triage:

• Telemetry Dispersal: Kerberos transactions generate immediate, high-fidelity DC telemetry (Events 4768 and 4769 specifying the principal, client IP, and target SPN). NTLM authentications targeting local hosts or local accounts generate zero DC events.
• Exploitation Susceptibility:
  • NTLM is vulnerable to credential relaying (NTLM Relay) and direct hash reuse (Pass-the-Hash).
  • Kerberos is immune to raw Pass-the-Hash (requiring ticket structure construction), but susceptible to ticket harvesting (Pass-the-Ticket, Golden/Silver Tickets) and offline cracking (Kerberoasting, AS-REP Roasting).
• Protocol Downgrade Anomaly Detection: When adversaries execute automated tools (NetExec, Impacket) by targeting raw IP addresses rather than FQDNs, Windows automatically falls back to NTLM. This unexpected protocol switch is a key indicator of compromise.

---

How It Works

Forensic Protocol Comparison Matrix

Investigative Criterion	Kerberos v5	NTLMv2
Central Authority	KDC (port 88 TCP/UDP)	None (Point-to-point or Netlogon RPC)
Authentication Proof	Encrypted tickets (TGT, TGS with PAC)	Encrypted challenge-response (HMAC-MD5)
DC Telemetry on Logon	Event 4768 (TGT) + Event 4769 (TGS)	Event 4776 (Netlogon validation)
Target Host Telemetry	Event 4624 (LogonProcessName: Kerberos)	Event 4624 (LogonProcessName: NtLmSsp)
Encryption Standard	AES-256 (0x12), AES-128 (0x11), RC4 (0x17)	DES / HMAC-MD5 / RC4
Delegation Support	Yes (Unconstrained, Constrained, RBCD)	No (unless transitioned via Kerberos S4U)
IP-Based Targeting	Fails (requires registered SPN mapping)	Succeeds seamlessly

---

What Is Possible

• Differentiating Protocol Usage per Session: Inspecting LogonProcessName in Event ID 4624 reveals whether Kerberos or NtLmSsp was utilized.
• Auditing Kerberos Encryption Standards: Event ID 4769 records TicketEncryptionType (0x12 = AES-256; 0x17 = RC4, frequently indicative of ticket forgery or Kerberoasting).
• Identifying Source Hostnames in NTLM: Event ID 4624 captures the client-supplied Workstation Name during NTLM handshakes.

---

What Is Not Possible

• Acquiring a Kerberos Ticket via Raw IP Address: Kerberos strictly requires resolving an SPN tied to an Active Directory object. Commands targeting \\192.168.1.10\c$ automatically trigger NTLM fallback.
• Relaying Kerberos Tickets Like NTLM Hashes: Kerberos tickets are cryptographically bound to specific session keys and service identities; they cannot be arbitrarily relayed to third-party endpoints.
• Locating Kerberos Events for an NTLM Session: If an adversary operated via NTLM, DC Event 4768/4769 logs will remain completely void of that transaction.

---

Common DFIR Confusions

Frequent Confusion	Verifiable Forensic Reality
”We observed Event 4624 on the file server, confirming the DC authenticated the user.”	If LogonProcessName is NtLmSsp and the account is local, the DC was never contacted.
”Pass-the-Hash works directly against Kerberos.”	False. Pass-the-Hash strictly injects an NT hash into NTLM. Kerberos requires Overpass-the-Hash / Pass-the-Key to negotiate a TGT.
”Event 4776 proves the user successfully accessed the remote workload.”	Event 4776 merely proves the DC verified the NTLM hash. Workload access may still have been blocked by local DACLs.

---

Concrete Forensic Example

During a targeted intrusion, an investigator analyzes two simultaneous network logons targeting financial server SRV-FINANCE:

1. First Connection:
   • Event 4624: TargetUserName: admin_local, LogonProcessName: NtLmSsp, Workstation Name: LAPTOP-DEV.
   • DC logs: Zero events for 4768, 4769, or 4776.
   • Finding: Local Pass-the-Hash utilizing a local administrative account, completely evading DC logging.
2. Second Connection:
   • Event 4624: TargetUserName: DA_Bob, LogonProcessName: Kerberos, Workstation Name: -.
   • DC logs: Event 4768 at 02:14 UTC, followed by Event 4769 for cifs/SRV-FINANCE.corp.local with TicketEncryptionType: 0x17 (RC4).
   • Finding: Kerberos lateral movement utilizing legacy RC4 encryption, indicating a forged ticket or coerced downgrade.

---

Key Forensic Artefacts

1. Domain Controller Event Logs:
   • Event ID 4768 (TGT Request): Initial authentication telemetry (PreAuthType: 2 = standard password, PreAuthType: 0 = AS-REP Roasting candidate).
   • Event ID 4769 (TGS Request): Service access request (ServiceName, client IP, encryption type).
   • Event ID 4776 (Netlogon Credential Validation): Validation of NTLM credentials by a DC.
2. Target Server Event Logs:
   • Event ID 4624 (Logon): Examine LogonType: 3, AuthenticationPackageName, LogonProcessName (Kerberos vs NtLmSsp), ElevatedToken.
   • Event ID 4625 (Logon Failure): Inspect failure codes (0xC000006A = bad NTLM password, 0xC00002F5 = Kerberos pre-auth failed).

---

Investigation Methods

1. Isolate Protocol Usage via Event 4624: Filter LogonProcessName to partition investigations into Kerberos and NTLM trajectories.
2. Correlate Kerberos Sessions Back to KDC Events: Search DC Event ID 4769 for timestamps and client IPs matching workload Event 4624 logons.
3. Trace NTLM Sessions via Netlogon Logs: Check DC Event ID 4776 matching user and timestamp to confirm whether the account was a domain or local principal.

---

Investigative Tooling

• PowerShell / Get-WinEvent:

  # Hunt for NTLM network logons
  Get-WinEvent -FilterHashtable @{LogName='Security'; ID=4624} |
    Where-Object { $_.Properties[8].Value -eq 'NtLmSsp' -and $_.Properties[7].Value -eq 3 } |
    Select-Object TimeCreated, @{N='User';E={$_.Properties[5].Value}}, @{N='Workstation';E={$_.Properties[11].Value}}, @{N='IP';E={$_.Properties[18].Value}}

• Klist:

  klist sessions
  klist tickets

---

Key Takeaways

• Kerberos relies on central KDCs (Events 4768, 4769); NTLM relies on Netlogon (Event 4776) or the local SAM.
• Targeting IP addresses consistently forces NTLM fallback over Kerberos.
• Classic Pass-the-Hash is exclusively an NTLM technique.
• RC4 encryption (0x17) in modern Kerberos environments warrants immediate investigation for ticket forgery.

---

References & Further Reading

• Microsoft Learn: Kerberos Survival Guide
• Card 05 — Authentication vs Authorization: The Decisive Boundary in DFIR
• Card 16 — Cross-Domain Authentication: Kerberos Referral and NTLM Pass-Through
• Card 22 — The Kerberos PAC: Structure, Validation, and Forgery
• Card 27 — Golden Ticket vs Silver Ticket: Creation, Scope, and Detection