Wenn Sie dabei sind, die Microsoft-Technologien in Ihrer Umgebung zu härten, steht das Abschalten von NTLM vermutlich ziemlich weit oben auf Ihrer To-Do-Liste. Nur ist es, im Gegensatz zu vielen anderen notwendigen und üblichen Härtungsmaßnahmen, bei diesem Punkt nicht immer ganz klar, welchen Zustand der Umgebung die Härtung anstreben sollte und welche Kompromisse noch akzeptabel wären, sollte das Maximalprogramm nicht umsetzbar sein. Oft wird deswegen das Projekt "Zero NTLM" zunächst einmal aufgeschoben. Dabei ist die Sache mehr als brisant.

NTLM öffnet Tür und Tor für eine Vielzahl von Angriffen. Um das Maß der Gefährdung richtig einschätzen zu können, ist es wichtig zu verstehen, wie NTLM funktioniert. Das Prinzip ist einfach: Bevor der Zugriff auf eine Ressource, beispielsweise eine Dateifreigabe, gestattet wird, sendet der Server dem Client eine zufällig generierte Zeichenfolge (die "Nonce"). Der Client antwortet mit einem Authentifizierungstoken, der den Benutzernamen und die Nonce, verschlüsselt mit dem NTLM-Hash des Kennworts, enthält. Bei einem lokalen Account auf dem Server selbst ist dieser Hash in der Registry des Servers gespeichert und kann dort direkt überprüft werden.

Im Fall eines Domänen-Accounts schickt der Server den Token zu einem Domain Controller. Letzterer hat den NTLM-Hash in der Active-Directory-Datenbank gespeichert und damit die Möglichkeit, die Richtigkeit des Kennworts zu prüfen. Anschließend sendet der Domain Controller eine Antwort an den Server, die neben der Bestätigung der erfolgreichen Authentifizierung die Liste der Sicherheitsgruppen enthält, in denen das angefragte Konto Mitglied ist. Um den Authentifizierungstoken zu erhalten, fragt der Client den User nach seinem Namen und Kennwort – entweder bereits bei der Windows-Anmeldung oder durch ein gesondertes Anmeldefenster beim Zugriff auf die Ressource. Das eingegebene Kennwort wird in einen NTLM-Hash umgerechnet und in das Authentifizierungsticket eingesetzt, wenn dieses für den Zugriff auf Ressourcen benötigt wird.

Ob das Kennwort dabei bereits am Client überprüft wird, hängt von der konkreten Situation ab. Der Server wird jedes Ticket erst einmal annehmen und dem Domain Controller zur Überprüfung vorlegen. Hier offenbaren sich bereits die Schwächen von NTLM:

- Der Server hat keine Kenntnis darüber, wie der Client zu seinem Authentifizierungstoken gekommen ist. Entspricht der NTLM-Hash dem im Active Directory oder in der lokalen Kontendatenbank des Servers gespeicherten Wert, ist der Token gültig. NTLMv2 verhindert zumindest einfache Replay-Angriffe, womit sich eine im Netzwerk abgefangene Kommunikation nicht dazu verwenden lässt, um sich gegenüber Serverressourcen zu authentifizieren. In NTLMv1 ist dieser Angriff noch problemlos möglich.

- Mit der Kenntnis des NTLM-Hashs eines Kennworts ist die Authentifizierung uneingeschränkt möglich. Sicherheitsexperten sprechen vom NTLM-Hash als "Kennwort-Äquivalent". Das direkte Verwenden des Hashs für die Authentifizierung wird auch als "Pass-the-Hash"-Angriff bezeichnet.

- Erschwerend kommt hinzu, dass die NTLM-Hashfunktion relativ schwach ausfällt angesichts der heute verfügbaren Rechenkapazitäten. Viele Kennwörter können daher aus einem erbeuteten NTLM-Hash mittels Brute Force zurückgerechnet werden, falls tatsächlich das Klartext-Kennwort benötigt wird. Für den Angreifer kann das Kennwort auch dann wertvoll sein, wenn die angegriffenen Systeme es eigentlich nicht benötigen. Enthält das Passwort nämlich ein klar erkennbares Muster ("Sommer2022!"), lässt sich mit hoher Wahrscheinlichkeit das nächste Kennwort erraten, sollte der erbeutete Hash einmal durch den Kennwortwechsel seine Gültigkeit verlieren.

Das Erbeuten eines NTLM-Hashes ist für versierte Angreifer eine Standardaufgabe, und unglücklicherweise speichert Win­dows diese Information an sehr vielen Stellen ab, was diese Aufgabe deutlich erleichtert. Für die Extraktion gültiger NTLM-Hashes aus verschiedenen Win­dows-Subsystemen ist das Programm "Mimikatz" bekannt. Dessen Autor Benjamin Delpy hat es sich zur Aufgabe gemacht, NTLM-Hashes und Klartext-Kennwörter in Windows aufzuspüren – und das mit großem Erfolg.

In einer klassischen Active-Directory-Umgebung bedeutet das Abschaffen von NTLM eine komplette Umstellung aller Authentifizierungsvorgänge auf Kerberos. Doch eröffnet ein erbeuteter NTLM-Hash unter Umständen auch Wege, um in Kerberos einzubrechen. Der Grund dafür ist fast immer die Abwärtskompatibilität. In jeder Active-Directory-Domäne ist beispielsweise per Default das RC4-Verschlüsselungsverfahren aktiv, wenn es nicht mittels Gruppenrichtlinien deaktiviert wurde.

Die RC4-Hashfunktion ist allerdings identisch mit der NTLM-Hashfunktion. Diese Designfestlegung findet in einer AD-Domäne statt, wenn der erste Domain Controller initialisiert wird und die Domäne entsteht. Die auf dem zukünftigen Domain Controller vorhandenen lokalen Konten werden in Domänen-Accounts konvertiert und ihre Kennwörter sollen dabei natürlich gültig bleiben. Da von den Kennwörtern lediglich der NTLM-Hash bekannt ist, bildet er nun die Basis der RC4-Kerberos-Authentifizierung. Daraus folgen zwei Erkenntnisse:

- Wenn der Angreifer einen Domain Controller dazu zwingen kann, RC4 für Kerberos zu verwenden, kann er mithilfe eines erbeuteten NTLM-Hashs valide Kerberos-Tickets beantragen.

- Aus lokalen Accounts konvertierte Domänenkonten können sich nicht unter Verwendung von AES per Kerberos authentifizieren, bis sie ihr Kennwort ändern. Sie haben lediglich einen RC4-Hash in der AD-Datenbank gespeichert. Dasselbe gilt für Accounts in einer Domäne, die von Windows Server 2000 bis 2008 auf 2008 R2 oder höher aktualisiert wurde. Bis das Kennwort geändert und damit die AES-Hashes generiert sind, ist für diese Accounts lediglich RC4-Authentifizierung möglich.

Und sogar eine passwortlose und hochsichere Smartcard-Authentifizierung ist nicht ganz frei von NTLM-Artefakten, die für einen Angriff verwendet werden können. Um eine Abwärtskompatibilität zu Systemen zu gewährleisten, die ausschließlich die NTLM-Authentifizierung unterstützen, generiert Windows für Konten mit erzwungener Smartcard-Authentifizierung ein langes und komplexes Kennwort, sodass auch eine Smartcard-Anmeldung mit einem NTLM-Hash aufwarten kann. Dieses Kennwort ist zwar schwer zu erraten, es ist aber auch nicht für eine Klartextnutzung gedacht. Und ein NTLM-Hash lässt sich bekanntlich gegenüber Anwendungen, die NTLM-Authentifizierung unterstützen, direkt verwenden.

Nicht gerade hilfreich in diesem Zusammenhang ist das Änderungsverhalten dieses Hash-Werts. Bis inklusive Windows Server 2012 R2 entsteht dieser, wenn für ein Konto das Merkmal "Smartcard Anmeldung erforderlich" gesetzt wird – und bleibt danach unverändert [1]. Der einzige Weg, diesen Hash zu ändern, besteht darin, das Merkmal zu entfernen und wieder zu aktivieren. Win­dows Server 2016 und höher weisen ein anderes Verhalten auf. Hier folgt die automatische Generierung des NTLM-Hashs der für das jeweilige Konto geltenden Kennwortrichtlinie.

Haben Sie die Domäne jedoch mit Server 2012 R2 oder älter instantiiert, müssen Sie nach dem Upgrade der Domain Controller auf Windows Server 2016 oder höher noch das Attribut "ms-DS-Expire-Passwords-On-Smart-Card-Only-Accounts" des Domänen-Objektes auf "TRUE" setzen, um das neue Verhalten zu aktivieren. Dies erledigen Sie entweder per ADSIEdit oder im "Active Directory-Verwaltungs-center" (rechter Mausklick auf die Domain und anschließend "Eigenschaften").

Es ist derzeit technisch nicht möglich, eine auf Windows und Active Directory basierende IT-Umgebung gänzlich von NTLM zu befreien. Bei der interaktiven Anmeldung an Windows mit Benutzernamen und Kennwort wird immer der NTLM-Hash generiert, sofern das angemeldete Konto nicht Mitglied in der Gruppe "Protected Users" ist. Per Default akzeptieren alle Microsoft-Anwendungen das alte Protokoll. Und bei der Kommunikation zu Workgroup-Systemen ist NTLM auch das einzige Verfahren, das zur Verfügung steht. Die Härtung muss also folgende Ziele verfolgen:

- Das Abgreifen lokal erzeugter NTLM-Hashes verhindern,

- Das Abfischen von NTLM-Hashes im Netzwerk unterbinden,

- Server und Dienste so konfigurieren, dass sie NTLM nicht akzeptieren und damit Pass-the-Hash mit einem erbeuteten NTLM-Hash unmöglich wird.

Um die lokal generierten Hashes zu schützen, stehen Ihnen zwei wirkungsvolle Mechanismen zur Verfügung. Für hochprivilegierte Accounts, die sich lokal anmelden müssen, verhindert die Mitgliedschaft in der Gruppe "Protected Users" die Generierung des NTLM-Hashs bei der Anmeldung. Gleichzeitig wird bei der Kerberos-Authentifizierung solcher Accounts das mit NTLM verwandte RC4-Protokoll nicht verwendet. Allerdings hat dieser Schutz seinen Preis: Die Lebenszeit des Kerberos-Tickets ist fest auf vier Stunden begrenzt, ohne Verlängerungsmöglichkeit. Computer- und Service-Accounts können daher nicht Mitglied in "Protected Users" sein.

Moderne Windows-Versionen verfügen über einen weiteren Schutzmechanismus für lokal angemeldete Credentials, der ihre Funktion nicht einschränkt und sich daher auch für normale Benutzersitzungen eignet: Windows Defender Credential Guard [2]. Dieses auf Virtualisierung basierte Schutzverfahren ist sehr effektiv gegen herkömmliche Angriffsmethoden. Allerdings konnte es in der Vergangenheit durch Memory-Patching-Techniken ausgehebelt werden, und Mimikatz bietet in den modernen Versionen sogar ein fertiges Szenario für diesen Angriff. Daher ist es ratsam, zusätzlich zu Credential Guard auch den Zusatzschutz des LSA-Prozesses zu aktivieren [3]. Diese Maßnahmen dürfen Sie allerdings nicht auf Domain Controller anwenden.

Das Verhalten von Windows-Systemen in einer AD-Domäne in Bezug auf den Umgang mit NTLM wird durch zehn Gruppenrichtlinieneinstellungen gesteuert, die im Bereich "Sicherheitseinstellungen / Lokale Richtlinien / Sicherheitsoptionen" zu finden sind. Die letzten zwei (in der deutschen Sortierung) sind selbst dann sehr wichtig, wenn Sie noch nicht bereit sind, mit der Eliminierung von NTLM in Ihrer Umgebung zu beginnen:

- "Keine LAN Manager-Hashwerte für nächste Kennwortänderung speichern" verhindert, dass die längst veraltete und extrem unsichere LM-Hashfunktion (Vorgänger von NTLM) verwendet wird. Ab Windows Vista entspricht das Aktivieren dieser Policy dem Default-Verhalten des Betriebssystems. Sie sollten diese Einstellung dennoch in Ihrer Domäne vornehmen. Falls Sie Systeme im Einsatz haben, die wirklich noch LAN Manager-Authentifizierung benötigen, müssen Sie sich erst einmal damit beschäftigen, diese zu isolieren – in ein separates VLAN und eine separate AD-Umgebung.

- "LAN Manager-Authentifizierungsebene" erlaubt das Deaktivieren veralteter LM-/NTLM-Dialekte. Die einzige aus heutiger Sicht akzeptable Einstellung finden Sie am Ende der Dropdown-Liste: "Nur NTLMv2-Antworten senden. LM und NTLM verweigern". Falls Sie noch Systeme haben, die NTLMv1 zwingend benötigen, müssen Sie sich mit diesen Anwendungen als Erstes beschäftigen, denn NTLMv1 erlaubt vielfältige Angriffsvektoren, die mit NTLMv2 zumindest stark erschwert sind.

Diese beiden Einstellungen sollten Sie domänenweit anwenden – sowohl auf Domain Controller als auch auf Server und Clients. Falls Sie noch nicht wissen, welche Systeme durch die Aktivierung dieser Richtlinien eventuell beeinträchtigt werden, müssen Sie die Anmeldeprotokolle der Domain Controller untersuchen. Das Event 4624 beinhaltet Informationen zu dem für die Anmeldung verwendeten NTLM-Dialekt.

Mittels der Einstellung "Für Kerberos zulässige Verschlüsselungstypen konfigurieren" können Sie das Verwenden von RC4 in Kerberos generell deaktivieren und damit den Missbrauch erbeuteter NTLM-Hashes für Angriffe auf Kerberos verhindern. Falls Sie in Ihrem Active Directory noch Systeme haben, die älter als Windows 7 sind, dürfen Sie diese Einstellung allerdings nicht auf Domain Controller anwenden, denn die älteren Systeme beherrschen noch keine stärkeren Verschlüsselungstypen als RC4. Doch auch andere, nicht auf Win­dows basierende Geräte wie Drucker oder Produktionsmaschinen unterstützen möglicherweise keine AES-Verschlüsselung in Kerberos. Sind solche Systeme bekannt, müssen Sie die Kerberos-Verschlüsselung granularer regeln. Leider bleibt die generell von RC4 ausgehende Gefährdung bestehen, solange Domain Controller noch auf RC4-Verschlüsselung basierende Kerberos-Tickets ausstellen.

Schließlich können Sie mit Hilfe der Einstellungen "Eingehender NTLM-Datenverkehr", "NTLM-Authentifizierung in dieser Domäne" sowie "Ausgehender NTLM-Datenverkehr zu Remoteservern" steuern, ob Ihre Systeme NTLM-Authentifizierungsanfragen beantworten oder selber versenden:

- "NTLM-Authentifizierung in dieser Domäne" muss auf Domain Controller angewendet werden. Wenn Sie diese Einstellung auf "Alle verweigern" setzen können, findet innerhalb Ihrer Domäne keine NTLM-Authentifizierung mehr statt. Allerdings werden Ihre Clients weiterhin NTLM-Authentifizierungstokens an andere Systeme versenden. Handelt es sich beim Authentifizierungsziel um ein kompromittiertes System, können Anmeldeinformationen abgefischt werden. Dagegen hilft die nächste Einstellung.

- "Ausgehender NTLM-Verkehr zu Re-moteservern" wird auf alle Maschinen angewendet, die eine interaktive Anmeldung zulassen, und steuert, ob NTLM-Authentifizierungstokens an Systeme außerhalb der Domäne geschickt werden. Ist hier "Alle verweigern" ausgewählt, sind Ihre Clients vor dem Abfischen von NTLM-Datenverkehr durch externe Systeme sicher. Allerdings funktionieren unter Umständen Anwendungen, die eine Pass-Through-Authentifizierung im Browser verwenden, nicht mehr.

- Um NTLM-Angriffe auf lokale Konten von Domänen-Mitgliedern zu unterbinden, verwenden Sie die Einstellung "Eingehender NTLM-Datenverkehr". Dies ist sozusagen die Vorstufe der ersten Einstellung und bewirkt, wenn sie aktiviert und auf "Domänenkonten verweigern" oder "Alle Konten verweigern" gestellt wird, dass NTLM-Authentifizierungsanfragen überhaupt erst an Domain Controller geschickt werden.

- Sie können Ausnahmelisten definieren, die die Verweigerung der NTLM-Authentifizierung für bestimmte Domänen- und Remoteserver aufheben. Diese Listen sollten Sie möglichst in einer Gruppenrichtlinie führen, damit Sie stets genau wissen, wo diese Ausnahmen zu suchen sind.

Wenn Ihre Windows-Umgebung überschaubar ist und Ihre User mit eventuellen Störungen an der IT gut umzugehen wissen, können Sie es versuchen und NTLM wie oben beschrieben komplett deaktivieren. Falls Sie lieber die Disruption minimieren und planvoll vorgehen möchten, wird die Abschaffung von NTLM etwas länger dauern.

Um Systeme zu identifizieren und gezielt zu behandeln, die auf NTLM angewiesen sind, müssen Sie große Mengen an Ereignisprotokollen durchforsten. Daher sollte es Ihr erster Schritt sein, alle Konfigurationen zu beseitigen, die dazu führen, dass Systeme, die eigentlich Kerberos-Authentifizierung beherrschen, dennoch auf NTLM zurückfallen. Einige einfache Maßnahmen helfen, den Umfang der NTLM-Authentifizierung in einer typischen Active-Directory-Umgebung deutlich zu reduzieren. Sie müssen

- überall, wo AD-Benutzerkonten für den Zugriff auf Systeme und Dienste verwendet werden, diese als UPN und nicht als SAMAccountName eintragen.

- überall, wo auf Serverdienste zugegriffen wird, ihre Namen als FQDN und nicht als NetBIOS-Hostnamen oder gar IP-Adressen eintragen. Das betrifft beispielsweise auch Ordnerziele in DFS-Namespaces. Hier trägt der Assistent für das Hinzufügen eines Ordnerziels die tatsächlichen Fileserver standardmäßig nur als Hostnamen ein, sofern es sich dabei um Windows-Fileserver handelt.

- SPNs bei Computer- und Service-Accounts kontrollieren und fehlende SPNs nacherfassen, falls DNS-Aliase oder Clusternamen für den Zugriff verwendet werden. Denken Sie daran: Computerkonten und Group Managed Service Accounts (gMSA) besitzen per Default das Recht, ihr eigenes servicePrincipalName-Attribut zu beschreiben, klassische Service-Accounts (Benutzer mit nicht ablaufendem Kennwort) hingegen nicht.

- Manche Systeme wie beispielsweise Exchange Server mit Loadbalancing erfordern eine besondere Behandlung, damit sie Kerberos unterstützen.

Konten, die explizit eingetragene SPNs besitzen, sind anfällig für "Kerberoasting"-Attacken und sollten daher nur so viele Berechtigungen haben, wie sie unbedingt benötigen. Es ist außerdem eine gute Idee, auch die Kennwörter von Service-Accounts regelmäßig zu ändern.

Haben Sie alles Notwendige unternommen, damit die bekannten Systeme in Ihrer Umgebung Kerberos "sprechen", können Sie nun die Jagd nach weiteren NTLM-Authentifizierungsvorgängen beginnen. Aktivieren Sie dafür auf Ihren Domain Controllern die Gruppenrichtlinie "NTLM-Authentifizierung in dieser Domäne überwachen" im Modus "Alle aktivieren" und auf allen Domänen-Rechnern die Gruppenrichtlinien "Eingehenden NTLM-Datenverkehr überwachen" sowie "NTLM-Datenverkehr zu Remoteservern".

Daraufhin werden im Ereignisprotokoll "Microsoft\Windows\NTLM" Ereignisse protokolliert, die Ihnen verraten, welche Systeme gegenüber welchen anderen Systemen und mit welchen Benutzer-Accounts NTLM-Authentifizierung verwenden. Die einzelnen Events mit den IDs 8001 bis 8005 und der Zusammenhang zwischen ihnen sind in [4] beschrieben. Event 8001 wird auf Clients, 8002 und 8003 werden auf Servern und 8004 und 8005 auf Domain Controllern protokolliert.

Das NTLM-Ereignisprotokoll ist standardmäßig auf die maximale Größe von 1 MByte eingestellt und kann daher nur rund 2000 Events aufnehmen. Sie sollten die Größe unbedingt erhöhen, um möglichst alle relevanten Ereignisse einzufangen. Das erledigen Sie beispielsweise mit der PowerShell:

Erfahrungsgemäß entdecken Sie bei einem Teil der protokollierten Kommunikationsbeziehungen Systeme, die Sie im ersten Schritt übersehen haben und die sich erfolgreich für die Benutzung von Kerberos umkonfigurieren lassen. Die übrigen Systeme jedoch, die Sie aus den Protokollen eruieren dürften, benötigen NTLM wirklich.

Wenn Sie ein System in Ihrer Umgebung identifizieren, das NTLM zwingend zum Funktionieren braucht, bedeutet dies noch lange nicht, dass alle vorherigen Bemühungen vergebens waren. Mit den zuvor beschriebenen Gruppenrichtlinien definieren Sie die Kommunikationsbeziehungen präzise, für Sie die NTLM zulassen möchten. Benötigt beispielsweise ein Server NTLM zu einem externen System, können Sie eine entsprechende Ausnahmeliste für externe Kommunikation in einer Gruppenrichtlinie festlegen, die auf diesen Server wirkt. Beachten Sie allerdings, dass die NTLM-Ausnahmenlisten aus verschiedenen GPOs nicht additiv verarbeitet werden; die Liste aus der "gewinnenden" Policy gilt für die jeweilige Maschine. Alternativ können Sie die Ausnahmenliste direkt in der Registry Ihrer Computer pflegen. Doch auch in diesem Fall müssen Sie das Zusammenfügen von Listen selbst umsetzen.

Die Abschaltung von NTLM in einer komplexen und historisch gewachsenen Umgebung ist ein längerer Prozess. Sie sollten diesen daher möglichst früh beginnen – am besten heute. Machen Sie sich mit der Funktionsweise von Kerberos vertraut und stellen Sie alle bekannten Anwendungen auf Kerberos um, bevor Sie mit dem Sammeln von Ereignisprotokollen anfangen, um die verbleibenden Systeme zu identifizieren. Pflegen Sie die Ausnahmen aus der NTLM-Einschränkung möglichst an wenigen Stellen und löschen Sie Maschinen von der Ausnahmeliste, wenn sie kein NTLM mehr benötigen.