Altlasten abschalten: NTLM, SMBv1 & Co.
Viele Active-Directory-Umgebungen laufen heute noch mit Authentifizierungs- und Dateifreigabeprotokollen, die längst als unsicher gelten.
Zwei Klassiker: NTLM (NT LAN Manager) und SMBv1 (Server Message Block v1).
Beide stammen aus einer Zeit, als „Pass-the-Hash“, „Relay“ oder „EternalBlue“ noch nicht in jedem Security-Report auftauchten.
Das Problem: Selbst in modernen Windows-Server-2022- oder 2025-Umgebungen sind diese Altlasten oft noch aktiv, weil niemand sie jemals konsequent deaktiviert hat.
Warum das ein Problem ist
NTLM:
- Schwache Hash-basierte Authentifizierung (anfällig für Pass-the-Hash & Relay-Angriffe)
- Kein Kerberos-Feature-Set (kein Mutual Authentication, keine Tickets mit Zusatzinformationen)
- In vielen Penetrationstests ein Hauptangriffsvektor
SMBv1:
- Unsichere Kommunikation (keine Signierung, keine Verschlüsselung)
- Verwundbar für WannaCry- und NotPetya-artige Attacken (EternalBlue)
- Keine Unterstützung moderner Dateifreigabe-Features
Ab wann Microsoft Änderungen eingeführt hat
Windows-Version / Jahr | NTLM-Status | SMBv1-Status |
---|---|---|
Windows Server 2003/2008 | NTLM standardmäßig aktiv | SMBv1 aktiv, SMBv2 optional |
Windows Server 2012 R2 | NTLM noch Standard, erste GPO-Restriktionen | SMBv2/3 empfohlen, SMBv1 noch dabei |
Windows Server 2016 | Neue GPOs zur NTLM-Reduzierung, Kerberos-Verbesserungen | SMBv1 optional, wird aber nicht mehr benötigt |
Windows Server 2019 | NTLM standardmäßig aktiv, Warnungen in Doku | SMBv1 standardmäßig deaktiviert, aber nachinstallierbar |
Windows Server 2022 | NTLM nur noch für Kompatibilität, Audit-Modus empfohlen | SMBv1 nicht mehr vorinstalliert |
Windows Server 2025 | Neue NTLM-Audit-Ereignisse & Channel Binding Logging | SMBv1 komplett veraltet, Microsoft empfiehlt Entfernung aus AD |
Schritt 1: Prüfen, ob NTLM oder SMBv1 noch aktiv sind
NTLM-Events auswerten
# NTLM-Anmeldungen der letzten Tage Get-WinEvent -FilterHashtable @{LogName='Security';ID=4624} | Where-Object { $_.Message -match 'NTLM' } | Select TimeCreated, Id, Message
SMBv1-Status prüfen
Get-WindowsFeature FS-SMB1
Ergebnis:
– Installed → SMBv1 ist aktiv
– Removed → SMBv1 ist nicht installiert
Schritt 2: Protokolle abschalten
SMBv1 deinstallieren
Disable-WindowsOptionalFeature -Online -FeatureName SMB1Protocol -NoRestart
NTLM reduzieren / blockieren
Per Gruppenrichtlinie:
Computerkonfiguration → Windows-Einstellungen → Sicherheitseinstellungen → Lokale Richtlinien → Sicherheitsoptionen → Network security: Restrict NTLM: Incoming NTLM traffic → Deny all accounts
Per PowerShell-Audit (erst prüfen, dann blockieren):
# NTLM-Audit aktivieren Set-ItemProperty -Path HKLM:\SYSTEM\CurrentControlSet\Control\Lsa\MSV1_0 ` -Name RestrictReceivingNTLMTraffic -Value 1
Best Practices
1. Audit-Phase einplanen
Vor der kompletten Abschaltung mindestens 2–4 Wochen nur auditieren, um Altsysteme zu identifizieren.
2. Kerberos-only Authentication umsetzen
Dienste und Anwendungen auf Kerberos umstellen.
3. SMB-Signing aktivieren
Schutz gegen Manipulation auf SMB-Ebene.
4. Ältere Systeme migrieren
Alte Geräte oder Anwendungen, die nur NTLM oder SMBv1 können, ersetzen.
Extra-Tipp (Windows Server 2025)
Mit Server 2025 kann man über neue NTLM-Audit-Ereignisse direkt erkennen, welche Systeme noch NTLM nutzen – inklusive Channel Binding Details.
Das erleichtert die Umstellung enorm, weil man betroffene Clients gezielt anpassen kann, statt blind abzuschalten.
Fazit
NTLM und SMBv1 gehören zu den größten Altlasten in Active-Directory-Umgebungen.
Wer sie heute noch aktiviert lässt, schenkt Angreifern einen direkten Weg ins Herz der IT.
Der Umstieg auf Kerberos-only und moderne SMB-Versionen bringt sofort mehr Sicherheit – und reduziert Risiken für Ransomware & Credential Theft dramatisch.