NTLM - NT LAN Manager Authentication

NTLM sollte laut Microsoft schon lange abgelöst sein - aber in der Praxis ist NTLM in nahezu jedem Active-Directory-Unternehmen noch aktiv. Und solange NTLM aktiv ist, sind Pass-the-Hash, NTLM-Relay und Responder-Angriffe möglich. Ein einziger kompromittierter NT-Hash reicht für Lateral Movement - kein Plaintext-Passwort nötig.

NTLM-Protokoll

Challenge-Response-Flow

1. Client → Server: NEGOTIATE (Capabilities)
2. Server → Client: CHALLENGE (8-Byte-Zufallswert)
3. Client → Server: AUTHENTICATE (NT-Hash über Challenge)
   • NTLM-Response = HMAC-MD5(NT-Hash, Challenge)

Schwachstelle des Designs

• Der NT-Hash ist der geheime Schlüssel - nicht das Klartextpasswort
• Wer den NT-Hash kennt, kann sich authentifizieren (Pass-the-Hash)
• Der Hash wird beim Challenge-Response nie im Netzwerk übertragen - aber Hash + Challenge-Response kann offline gecrackt werden

NT-Hash Berechnung:

NT-Hash = MD4(Unicode(password))

MD4 ist kryptographisch gebrochen; Rainbow Tables für NT-Hashes sind verfügbar.

Wo NTLM noch aktiv ist

• Lokale Windows-Anmeldungen (kein Kerberos)
• Workgroup-Authentifizierung
• SMB-Verbindungen zu alten Systemen
• IIS-Authentifizierung (NTLM HTTP)
• Fallback wenn Kerberos scheitert (häufig)

NTLM-Angriffe

1. Pass-the-Hash (PtH)

Der Angreifer stiehlt den NT-Hash (aus LSASS, SAM oder Domain) und nutzt ihn direkt zur Authentifizierung - kein Passwort nötig. Funktioniert für: SMB, RDP (Restricted Admin), WMI.

Hash-Quellen:

• LSASS-Dump (Mimikatz, Task Manager, ProcDump)
• SAM-Datei (lokale Hashes, wenn Admin): reg save HKLM\SAM
• ntds.dit-Dump (alle Domain-Hashes via DCSync)
• Credential Cache

# PtH mit Impacket:
psexec.py -hashes :NTLM_HASH_HERE domain.local/Administrator@TARGETIP
smbclient.py -hashes :NTLM_HASH_HERE domain.local/Administrator@TARGETIP
wmiexec.py -hashes :NTLM_HASH_HERE domain.local/Administrator@TARGETIP

# PtH mit CrackMapExec (CME):
cme smb 192.168.1.0/24 -u Administrator -H NTLM_HASH --shares
cme smb TARGET -u Administrator -H NTLM_HASH -x "whoami"

Einschränkungen:

• Nur NTLM (Kerberos benötigt ein Ticket, nicht den Hash)
• Windows „Protected Users” Security Group blockiert PtH
• LocalAccountTokenFilterPolicy: Remote-Admin via PtH einschränkbar

2. NTLM-Hash-Capturing (Responder)

Im lokalen Netz beantwortet der Angreifer Broadcast-Anfragen via LLMNR (Link-Local Multicast Name Resolution) und NBT-NS. Ein Client sucht z. B. nach „FILESERV” (Tippfehler) per Broadcast. Der Angreifer antwortet: „Ich bin FILESERV!” Der Client sendet daraufhin den NTLM-Authentifizierungsflow und der Angreifer fängt den Hash ab.

# Responder (für autorisierte Tests):
responder -I eth0 -w -r -f
# → Fängt NTLM-Hashes im Netzwerk ab
# → Speichert in Responder/logs/

# Hash-Cracking:
hashcat -m 5600 captured-hashes.txt wordlist.txt
# -m 5600 = NetNTLMv2

Schutz gegen Responder:

• LLMNR deaktivieren (GPO: Computer Config → Admin Templates → DNS Client)
• NBT-NS deaktivieren (Netzwerkeinstellungen → WINS → NetBIOS deaktivieren)
• mDNS deaktivieren
• Firewall: UDP 5355 (LLMNR) und UDP 137 (NBT-NS) intern blockieren

3. NTLM-Relay-Angriff

Der Angreifer fängt einen NTLM-Handshake ab und leitet ihn an einen anderen Server weiter. Der Client authentifiziert sich beim Angreifer, der Angreifer relayed zum Zielserver. Kein Passwort-Cracking nötig.

# ntlmrelayx (Impacket, für autorisierte Tests):
ntlmrelayx.py -tf targets.txt -smb2support
# + Responder (ohne SMB-Listener) im selben Netz
# → Captured NTLM → automatisch relayed zu allen Targets!

# Prüfen welche Hosts SMB-Signing deaktiviert haben:
cme smb 192.168.1.0/24 --gen-relay-list targets.txt

Multi-Relay-Szenarien:

• NTLM → SMB: Code-Execution via smbexec/psexec
• NTLM → LDAP: DCSync-Rechte erteilen
• NTLM → HTTP/ADCS: ESC8 (Certificate-Enrollment)
• NTLM → Exchange: Postfach-Zugriff

SMB-Signing: Ohne Signing ist NTLM-Relay auf SMB möglich. SMB-Signing schreibt einen MAC über den SMB-Traffic und verhindert dadurch Relay-Angriffe.

4. NTLMv1 Downgrade

NTLMv1 ist schwächer als NTLMv2 und kann durch Challenge-Manipulation erzwungen werden. NTLMv1 ist mit spezialisierten Rainbow Tables crackbar (crack.sh).

# Schutz via GPO:
Network security: LAN Manager authentication level →
"Send NTLMv2 response only. Refuse LM & NTLM"

NTLM deaktivieren

Schritt 1 - NTLM-Nutzung ermitteln

// Windows Event Log: Event ID 4776 (NTLM-Authentifizierung)
// Sentinel KQL:
SecurityEvent
| where EventID == 4776  // NTLM Credential Validation
| summarize count() by Account, WorkstationName, Computer
| order by count_ desc

Problematische NTLM-Quellen identifizieren: Drucker, Scanner (oft nur NTLM), ältere Anwendungen mit hardcoded NTLM, NAS-Geräte.

Schritt 2 - Audit-Modus

GPO: Computer Config → Security Settings → Local Policies → Security Options
"Network security: Restrict NTLM: Audit Incoming NTLM Traffic" → Enable
"Network security: Restrict NTLM: Audit NTLM authentication in this domain" → Enable
→ 7+ Tage Audit → Logs auswerten

Schritt 3 - Schrittweise Deaktivierung

Zuerst eine Audit-Phase von 4 Wochen, dann Block für Client (nicht Server) als Baseline:

GPO: "Network security: Restrict NTLM: Outgoing NTLM traffic to remote servers"
  → Deny all (für nicht-kritische OUs zuerst!)

Schritt 4 - Domain-weite Deaktivierung

GPO: "Network security: Restrict NTLM: NTLM authentication in this domain"
  → Deny all
"Network security: LAN Manager authentication level" →
  "Send NTLMv2 response only. Refuse LM & NTLM"

Schritt 5 - SMB-Signing erzwingen

# GPO:
# Microsoft network server → Digitally sign communications (always) → Enabled
# Microsoft network client → Digitally sign communications (always) → Enabled

Set-SmbServerConfiguration -RequireSecuritySignature $True
# → Verhindert NTLM-Relay-Angriffe!

Quick-Win: Protected Users Security Group

Alle privilegierten Accounts (Admins) in die Protected Users Gruppe aufnehmen. Mitglieder können sich nicht per NTLM authentifizieren, keine Kerberos-Delegation ist möglich und Credential-Caching wird verhindert - sofortige Wirkung ohne NTLM komplett zu deaktivieren.