eladshamir/internal-monologueInternal Monologue Attack: NTLM-Hashes abrufen ohne LSASS zu berühren
Mimikatz, entwickelt von Benjamin Delpy (@gentilkiwi), ist ein weithin geschätztes Post-Exploitation-Tool, das es Angreifern ermöglicht, Klartext-Passwörter, NTLM-Hashes und Kerberos-Tickets aus dem Speicher zu extrahieren sowie Angriffe wie Pass-the-Hash, Pass-the-Ticket oder das Erstellen eines Golden Ticket durchzuführen. Man könnte sagen, der Hauptzweck von Mimikatz ist das Abrufen von Benutzeranmeldeinformationen aus dem LSASS-Prozessspeicher für die laterale Bewegung nach der Ausnutzung.
In letzter Zeit hat Microsoft Credential Guard in Windows 10 Enterprise und Windows Server 2016 eingeführt, das virtualisierungsbasierte Sicherheit zur Isolierung von Geheimnissen verwendet und sehr effektiv darin ist, Mimikatz daran zu hindern, Hashes direkt aus dem Speicher abzurufen. Außerdem ist Mimikatz ein Hauptziel der meisten Endpoint-Protection-Lösungen geworden, und diese sind sehr aggressiv in ihren Bemühungen, es zu erkennen und zu verhindern. Obwohl diese Bemühungen zum Scheitern verurteilt sind, werden sie zunehmend lästig.
NetNTLM ist das Challenge-Response-Protokoll von Windows, das hauptsächlich dort verwendet wird, wo Kerberos nicht unterstützt wird. Bei NetNTLM sendet der Server dem Client eine zufällige 8-Byte-Nonce als Challenge, und der Client berechnet eine Response, die die Challenge mit dem NTLM-Hash als Schlüssel verarbeitet, wobei es sich um den MD4-Hash des Benutzerpassworts handelt. Es gibt zwei Versionen des NetNTLM-Authentifizierungsprotokolls, und beide sind anfällig für bestimmte Angriffe. Natürlich ist Version 1 deutlich schwächer als Version 2, und daher ist ab Windows Vista/2008 NetNTLM Version 1 standardmäßig deaktiviert.
Da der NTLM-Hash der Schlüssel zur Berechnung der Response ist, muss ein Angreifer nicht unbedingt das Klartext-Passwort des Opfers erhalten, um sich zu authentifizieren. Daher ist das Abrufen des Hashes aus dem LSASS-Speicher mit Mimikatz fast gleichbedeutend mit dem Stehlen eines Klartext-Passworts. Chris Hummel hat 2009 einen Artikel veröffentlicht, der diese Technik beschreibt, und nannte sie „Pass the Hash“ [https://www.sans.org/reading-room/whitepapers/testing/crack-pass-hash-33219].
Auf der Defcon 2012 präsentierten Moxie Marlinspike und David Hulton einen „Divide and Conquer“-Angriff gegen NetNTLMv1 [https://www.youtube.com/watch?v=sIidzPntdCM]. Bei NetNTLMv1 empfängt der Client die 8-Byte-Challenge und berechnet die Response, indem er sie dreimal mit DES unter Verwendung verschiedener Teile des NTLM-Hashs als Schlüssel verschlüsselt. Die Schlüssellänge für DES beträgt effektiv 56 Bit, also 7 Byte, während der NTLM-Hash 16 Byte hat. NetNTLMv1 verschlüsselt zuerst die Challenge mit den ersten 7 Bytes des NTLM-Hashs als Schlüssel, dann die Challenge mit den nächsten 7 Bytes des NTLM-Hashs als Schlüssel und schließlich die Challenge mit den letzten 2 Bytes des NTLM-Hashs, aufgefüllt mit Null-Bytes, als Schlüssel. Das bedeutet effektiv, dass ein Angreifer, um den NTLM-Hash aus einer gegebenen NetNTLMv1-Challenge und -Response zu erhalten, zwei 56-Bit-DES-Schlüssel knacken muss, was exponentiell einfacher ist als das Knacken eines einzigen 128-Bit-Schlüssels. Moxie und Hulton entwickelten dafür kundenspezifische Hardware und waren in der Lage, den gesamten DES-Schlüsselraum in weniger als 24 Stunden zu bruteforcen, was den erfolgreichen Abruf des NTLM-Hashs innerhalb einer angemessenen Zeit garantiert. Beachten Sie, dass dieser Angriff im Gegensatz zu Wörterbuch- oder Brute-Force-Angriffen auf das Passwort, die möglicherweise nicht erfolgreich sind, den erfolgreichen Abruf des NTLM-Hashs garantiert.
Wie von ToorCon unter https://crack.sh demonstriert, ist es machbar, eine vollständige Rainbow Table für alle möglichen NetNTLMv1-Responses auf eine gewählte Challenge zu erstellen, z. B. 0x1122334455667788, was das Knacken des NTLM-Hashs für eine gegebene Response innerhalb von Minuten ermöglicht. Die Implikation ist, dass das Erfassen einer NetNTLMv1-Response für die gewählte Challenge fast sofort in den entsprechenden NTLM-Hash übersetzt werden kann, was aufgrund von Pass the Hash fast dem Erhalt des Passworts gleichkommt.
Mimikatz wird üblicherweise ausgeführt, nachdem der Angreifer erweiterten Zugriff auf den Zielhost erlangt hat. An diesem Punkt kann der Angreifer auch Registrierungsschlüssel ändern, wie z. B. LMCompatibilityLevel, der angibt, ob der Host NetNTLMv1 oder NetNTLMv2 aushandeln soll. Der Angreifer kann den Wert auf 0, 1 oder 2 ändern, was NetNTLMv1 als Client aktiviert, und dann versuchen, sich gegenüber einem schädlichen SMB-Server zu authentifizieren, der die Response des Clients erfasst, wie in Optivs Blogbeitrag beschrieben [https://www.optiv.com/blog/post-exploitation-using-netntlm-downgrade-attacks].
Zwei weitere Einstellungen können verhindern, dass das Opfer eine NetNTLMv1-Response aushandelt:
In sicheren Umgebungen, in denen Mimikatz nicht ausgeführt werden sollte, kann ein Angreifer einen Internal Monologue Attack durchführen, bei dem er einen lokalen Prozeduraufruf an das NTLM-Authentifizierungspaket (MSV1_0) von einer Benutzermodusanwendung über SSPI tätigt, um eine NetNTLM-Response im Kontext des angemeldeten Benutzers zu berechnen, nachdem ein erweiterter NetNTLM Downgrade durchgeführt wurde.
Der Ablauf des Internal Monologue Attack wird im Folgenden beschrieben:
Ich habe Internal Monologue kürzlich in Umgebungen mit aktiviertem Credential Guard erneut getestet und negative Ergebnisse erhalten. Ich bin mir nicht sicher, ob Credential Guard in meiner Testumgebung während der ersten Tests nicht richtig funktioniert hat oder ob sich seitdem etwas geändert hat. Ich habe die Implementierung aktualisiert, um ein Server-Token von AcceptSecurityContext dynamisch zu erwerben und damit zu manipulieren, um die lokale Authentifizierungsfalle zu vermeiden, sodass, falls NetNTLMv1 ohne erweiterte Sitzungssicherheit fehlschlägt, zumindest eine NetNTLMv2-Challenge-Response erfasst werden kann.
Der Internal Monologue Attack ist wohl heimlicher als das Ausführen von Mimikatz, da kein Code injiziert und kein Speicher in einen oder aus einem geschützten Prozess ausgelagert werden muss. Da die NetNTLMv1-Response durch lokale Interaktion mit NTLM SSP hervorgerufen wird, wird kein Netzwerkverkehr erzeugt und die gewählte Challenge ist nicht leicht sichtbar. Es wird kein erfolgreiches NTLM-Authentifizierungsereignis in den Protokollen aufgezeichnet. Die Registrierungsänderungen für den NetNTLM Downgrade und das Stehlen von Token/Imitieren anderer Benutzer könnten Indikatoren auslösen.
Dieses Tool ist ein Proof of Concept, das den Internal Monologue Attack in C# implementiert. Das Portieren des Codes nach PowerShell kann bestimmte Ereignisprotokolle im Audit Trail durch andere ersetzen. Der PoC-Code ist weit entfernt von Perfektion. Positive Beiträge und Verbesserungen sind willkommen.
Elad Shamir von The Missing Link Security
