NTLM: Der Zombie im Windows-Netzwerk – wie du ihn jagst und endgültig tötest

Bevor ich auf die aktuelle Situation rund um NTLMv1 eingehe, möchte ich einen Schritt zurückgehen: zurück in die frühen 90er, als dieses Authentifizierungsprotokoll entstand und tatsächlich als ausreichend sicher galt. In meinem Blogpost zeige ich, warum NTLMv1 damals sinnvoll war – und warum genau diese historischen Wurzeln heute ein gewaltiges Sicherheitsrisiko darstellen.

Ich erkläre verständlich, wie NTLM funktioniert, warum es trotz massiver Schwächen noch immer in vielen Netzwerken aktiv ist und welche realen Angriffsvektoren dabei eine Rolle spielen. Gleichzeitig skizziere ich Microsofts klaren Fahrplan, NTLM aus Windows herauszulösen, und beschreibe, welche Schritte ich Organisationen empfehle, um Altlasten aufzuspüren, Risiken zu minimieren und Compliance‑Problemen vorzubeugen.

Kurz gesagt: NTLMv1 ist ein Relikt aus einer längst vergangenen IT‑Ära – und wer es heute noch einsetzt, geht ein unnötiges Risiko ein. In diesem Beitrag zeige ich, warum ich das so deutlich sage und was konkret zu tun ist.

📋Agenda

Bevor wir auf die aktuelle Situation schauen – lasst uns zuerst einen Blick auf die Ursprünge von NTLMv1 machen:

🔙 Ein kurzer Blick zurück: Die 1990er und der Beginn von Windows‑Netzwerken

NTLMv1 steht für NT LAN Manager Version 1 und wurde 1993 eingeführt, als Microsoft Windows NT 3.1 auf den Markt brachte. Damals war das Internet noch jung, Cyberangriffe selten und Rechenleistung begrenzt. Sicherheitsstandards (und -Anforderungen) waren schlicht andere als heute.

NTLM gehört zu einer ganzen Familie von Microsoft‑Authentifizierungsprotokollen, die zu dieser Zeit dafür entwickelt wurden, Benutzer sicher in einem Windows‑Netzwerk anzumelden. Und zur Einordnung: In diese Zeit gab es noch kein Active Directory! 😮Das wurde nämlich erst mit Windows 2000 eingeführt!

Damals (viele von meinen Lesern waren noch gar nicht auf der Welt! 😁) funktionierte NTLMv1 zuverlässig, war schnell und – für die damalige Zeit – „ausreichend sicher“. Es passte perfekt zur PC‑Welt der frühen 90er: einfache Netzwerke, einfache Angriffe, einfache Passwörter.

NTLM overview in Windows Server | Microsoft Learn

🔐 Wie NTLMv1 funktioniert – ganz einfach erklärt

NTLMv1 ist eine Art Ausweisprüfung zwischen deinem Computer und dem Server:

  1. Du willst irgendwo rein (z. B. auf eine Datei oder einen Server).
  2. Der Server fragt: „Bist du wirklich du?“ und schickt dir eine Art Geheimzahl.
  3. Dein Computer antwortet mit einer Berechnung, die auf deinem Passwort basiert (=> NTLM Hash).
  4. Der Server vergleicht, ob das Ergebnis stimmt.

=> So erkennt der Server: Wer das richtige Passwort besitzt, darf rein.

Die wesentliche Herausforderung heute ist: die Algorithmen/Berechnungen zur Erzeugung der Hashes stammen (siehe oben) aus den 90ern! 😱
Lasst uns kurz drüber nachdenken, was sich seitdem technisch getan hat… kommt ihr selber drauf, dass das nicht zwingend heute noch eine gute Idee ist, oder?

Wenn wir mal die typischen, bekannten Angriffsvektoren gegen eine NTLMv1 Authentication betrachten:

AngriffsvektorWarum möglich?Quellen
Brute ForceDES‑basierte, ungesalzene Hashes[technewskills.com], [en.wikipedia.org]
Rainbow TablesUngesalzene Hashes, bekanntes Verfahren[technewskills.com]
Pass‑the‑HashHash = Passwort‑Äquivalent, einfach kopierbar[thievi.sh]
NTLM RelayKeine gegenseitige Authentifizierung[thievi.sh], [technewskills.com]
Credential Capture / Offline‑CrackingSchwacher Challenge‑Response[technewskills.com], [en.wikipedia.org]
Man‑in‑the‑MiddleClient prüft Server nicht[thievi.sh]
Downgrade / FallbackLegacy‑Systeme und Abwärtskompatibilität[woshub.com]

Oder kurz zusammengefasst: sicher ist anders!

🧭 Warum wird NTLM überhaupt noch verwendet?

Das liegt an Kompatibilität und Altlasten:

  • Viele alte Geräte (z. B. ältere NAS‑Systeme) sprechen nur NTLM.
  • Manche (viel zu viele) ältere Anwendungen wurden nie modernisiert und verwenden weiter NTLM.
    Ihr kennt das:
    • Der Hersteller ist nicht mehr am Markt
    • Der Hersteller hat sich auf eine andere Applikation fokussiert
    • Der Software Engineer der selbstentwickelten Applikation ist nicht mehr im Unternehmen (Rente? Praktikum zu Ende?)
  • In Windows ist NTLM bis heute Teil der Authentifizierung, vor allem bei „Notfällen“, wenn Kerberos nicht funktioniert.
    Allerdings seit 2024 als „deprecated“ markiert und schon deutlich länger wird empfohlen auf moderne Authentications umzusteigen, am Besten Cloud Based und mit phishing resistant MFA!

Kurz: NTLM verschwindet nicht automatisch – man muss es aktiv entfernen.

Und dieses „aktiv entfernen“ kostet Zeit, Geld und Nerven! Hat doch früher funktioniert, warum sollte ich es angehen, „never touch a running system“ (was aus Security Sicht schon immer falsch war und immer falsch sein wird! 😉=> „always change a running system“ oder „Stillstand ist der Tod“)

🛣️ Fahrplan zur Entfernung von NTLM aus Windows

Microsoft hat eine klare dreiphasige Strategie veröffentlicht, um das veraltete NTLM-Protokoll durch modernere Alternativen wie Kerberos zu ersetzen:

🔍 Phase 1 – Sichtbarkeit schaffen (ab Windows 11 24H2 & Server 2025)

  • Einführung ausgeweiteter NTLM-Auditing-Logs in Event Viewer → Microsoft → Windows → NTLM → Operational, inklusive Informationen zu:
    • wer NTLM nutzt,
    • welcher Prozess und welches Gerät beteiligt ist,
    • ob es sich um NTLMv1 handelt und
    • warum NTLM statt Kerberos genutzt wurde.
  • Standardmäßig im Audit Mode: NTLM-Nutzung wird protokolliert, aber nicht blockiert.
  • Einführung des neuen Registry-Keys BlockNtlmv1SSO, um zwischen Audit- und Enforce-Modus zu wechseln.

🛡️ Phase 2 – Kerberos-Alternativen & Reduktion (zweite Jahreshälfte 2026)

  • Erweiterung der Kerberos-Funktionalität durch:
    • IAKerb (Initial Authentication using Kerberos)
    • Lokaler KDC für Kerberos, auch ohne direkte Domänenanbindung
  • Windows-Dienste werden so angepasst, dass sie standardmäßig Kerberos statt NTLM priorisieren.

🚫 Phase 3 – NTLM-Blockierung als Default (Nächste Hauptversion)

  • In der kommenden Hauptversion von Windows wird NTLM standardmäßig deaktiviert:
    • Netzwerk-Authentifizierungen mit NTLM sind ohne explizite Policy deaktiviert
    • Administratoren können NTLM bei Bedarf per Gruppenrichtlinie wieder aktivieren
    • Das Protokoll bleibt zwar im System, wird aber nur noch über bewusste Konfigurationen genutzt.

🔧Und da stehen wir jetzt mit der Frage: was tun wir proaktiv?

Einfache Antwort: Applikation rausschmeißen und durch eine moderne Anwendung ersetzen. Hat übrigens meist noch weitere Vorteile, aber das soll nicht Teil dieses Posts sein.

Jetzt werden alle sagen: „Na klar!“, oder?
Ok, nicht realistisch. Aber was dann?

Zuallererst sollte gewusst werden:

🔍Wo findet eigentlich im eigenen Netzwerk noch NTLM Authentifizierung statt?

  1. Händisch über AD Logs, insb. wenn die GPO GPS: NTLM Enhanced Logging genutzt wird.
    Audit use of NTLMv1 on a domain controller – Windows Server | Microsoft Learn
  2. Automatisiert über Microsoft Sentinel + Microsoft XDR incl. Microsoft Defender for Identity
    NTLM Under Attack: How We’re Hardening Authentication with Microsoft Sentinel + Microsoft XDR | LinkedIn
  3. Auf die harte Tour: wir disablen per GPO NTLM und schauen, wer sich beim Support meldet! 😁
    GPS: Block NTLM (LM, NTLM, NTLMv2), ggf. über eine AllowList abzuschwächen: GPS: Block NTLM Server Exception List

⚡Also, was tun (sprach Zeus)?

Klare Empfehlung ist: es sollte mindestens Microsoft Defender for Identity (MDI, Teil der Defender Suite [for Business Premium] oder Microsoft 365 E5) verwendet werden – auch, wenn kein Sentinel oder Copilot for Security zur Verfügung steht, um sowohl festzustellen welche Dienste noch NTLM verwenden und vor allem um Angriffe gegen diese Dienste zu erkennen und (automatisiert) zu unterbinden!

Insb. und grade auch das Thema „Pass-the-Hash„!

Das heißt, mit Hilfe von MDI lassen sich nicht nur die veralteten Authentications aufspüren, sondern auch Angriffe gegen diese detektieren und verhindern. Und nicht nur gegen NTLM, sondern auch gegen Kerberos und klassische andere Themen wie Pass-the-ticket, Golden Ticket, etc.

Eine weitere Variante habe ich im Grundsatz in Wie Cybersecurity dazu beitragen kann, die digitale Transformation voranzutreiben beschrieben: Die Applikation, die nach wie vor unsicher und angreifbar ist zu kapseln, mittels z.B. What is Global Secure Access? – Global Secure Access | Microsoft Learn zugreifbar machen und langsam ausphasen.
Oder aber mittels einer Kapselung über Active Directory Domain Services overview | Microsoft Learn in die eigene Sandbox zu bringen und mit modernen Authentication Mechanismen über Microsoft Entra ID abzusichern.

Die hier beschriebenen Maßnahmen sollten maximal dazu verwendet werden, um sich Zeit zu verschaffen, dass eine langfristige Lösung, nämlich die Ablösung oder Weiterentwicklung der verwendeten Applikationen zu ermöglichen. Dies stellt in keinem Fall eine permanente Lösung dar! Das Konstrukt mit NTLM und nicht gewarteten Applikationen stellt IMMER ein IMMENSES Sicherheitsrisiko dar.

Um das auch klar zu sagen: NTLM ist lange (eigentlich seit Jahrzehnten) nicht mehr State-of-the-Art (SOTA), sondern entspricht nicht mal mehr im Ansatz dem „aktuellen Stand der Technik“.
Und wer mich kennt, der weiß, dass ich damit vor allem auf das Thema DSGVO und NIS2 schaue! Und auch, wenn ich keine Rechtsberatung machen kann/darf – ich glaube für mich persönlich nicht, dass ein System, was noch NTLM (und streng genommen auch Kerberos) verwendet und dort Business Kritische und Personen bezogene/beziehbare Informationen verarbeitet, auch nur ansatzweise compliant zu den o.g. Regularien sein kann!
Und jetzt, da ihr diese Einschätzung von mir kennt – müsst ihr handeln!
Und am besten ihr erzählt es weiter, denn es ist immens wichtig, dass alle daran mitarbeiten, diese unsicheren Mechaniken auszumerzen!


Beitrag veröffentlicht

in

, , ,

von