AD Domäne pass-the-hash Angriff NTLMv2

[Avalox]

So ein wenig bin ich schon überrascht wie allen Anschein pass the hash auch mit NTLMv2 noch gegriffen werden kann.

Wie geht ihr denn vor Clients zu härten und die Server zu schützen, vor allen den DC selbst. Welcher Ansatz wird genutzt kompromittierte Tickets zu erkennen?

[qiller]

http://blogs.technet.com/b/askds/archive/2009/10/08/ntlm-blocking-and-you-application-analysis-and-auditing-methodologies-in-windows-7.aspx

Hatte mal die Analyse bei uns angeschmissen und jede Menge Eventlogs bekommen. Wenn ich das richtig verstanden habe, ist die Alternative zum alten NTLM die Kerberos-Authentifizierung. Das Problem bei Kerberos ist, das benutzt Windows nur standardmäßig, wenn es in einem AD eingebunden ist. Falls aus irgendeinem Grund Kerberos nicht benutzt werden kann (und da soll wohl schon das Ansprechen des Hosts über eine IP-Adresse, anstatt über einen FQDN, reichen), gibt es einen Fallback auf NTLM, den man in einer Domäne per GPO verhindern kann. Benutzt man im Netzwerk allerdings Dienste, die kein Kerberos benutzen (der IIS soll da z.B. Probleme haben?), kann man sich hier nicht mehr authentifizieren und man hat ein Problem :F. Daher empfiehlt MS erst die gründliche Analyse und wie man im Artikel sieht, ist die durchaus aufwendig.

mfg Oli

[Avalox]

pass-the-hash rührt ja gerade aus grundsätzlichen Problemen von Kerberos, bzw. der Authentifizierung in der AD Domäne her.

Das Problem ist ganz grundsätzlicher Art, sodass ein Windows Rechner einer Domäne mit seinen Zugriffstickets auf Server sich prima für Eindringlinge eignet, um sich in die Domäne festzusetzen.

Windows hat einen Passwortspeicher für Anmeldedaten, dessen PW Hashs können im für den Angreifer besten Fall direkt wieder in klar lesbare Passwörter zurück übersetzt werden, wenn sich also jemals ein Admin an diesem PC mit seiner Domänen Admin Kennung angemeldet hat, wird der Angreifer diesen aus dem Hauptspeicher lesen können.
Im für den Angreifer schwierigeren Fall kommt der Angreifer nicht an das PW aber an ein gültiges Kerberos Ticket, welches er A) selbst abwandeln kann um Zugriff zu erhalten, oder sich gleich ganz ein neues Ticket erstellen kann. Das wäre dann so, als ob der Angreifer einen eigenen voll kontrollierbaren DC im System hat.

Das Problem von Pass-the-hash ist seit Jahren vorhanden und prinzipiell. Ein unglaublicher Unsicherheitsfaktor für Windows AD Domänen.

MS hatte vor Jahren probiert nachzubessern, NTLM Version 2 ist darauf hin entstanden, aber offensichtlich bringt es auch auch nicht viel.

Prinzip

http://download.microsoft.com/download/C/3/B/C3BD2D13-FC9B-4FAB-A1E7-43FC5DE5CFB2/PassTheHashAttack-DataSheet.pdf

Nun gibt es einige Mittel wie man die Systeme härten kann. Nie mehr als ein Serverdienst auf einem Server, Anmeldedatenspeicher immer löschen, Ticket Validierung eines jeden Servers bei Anmeldung mit dem DC um Silvertickets zu erkennen, Geschützte Benutzer verwenden, usw. usw.

Deshalb die Frage, was macht ihr um pth möglichst schwer zu machen.

[Avalox]

Wieder mal pass the hash


Windows alt bis 10 Zugang in Sekunden.

An einem gesperrten Windows PC wird ein USB Dongle angesteckt, welcher einen Netzwerkadapter simuliert, hinter dem Netzwerkadapter wird ein Standard Gateway, DNS und Proxy Server mit simuliert, welchen Windows dann auch gerne verwendet und diesem dann auch gleich zur Identifikation den Passwort Hash des angemeldeten Nutzers zusendet.

Sekunden später ist der Rechner entsperrt.

Oplubg5q7ao

https://room362.com/post/2016/snagging-creds-from-locked-machines/

[konkretor]

Viele Anwendungen die man ans AD anbindet, können kein Kerberos oder Ferderation


Also Hashcat ist dein Freund, damit habe ich auch schon gute Ergebnisse bekommen.
Besonders Notebooks aus der IT Abteilung sind ein guter Spender für Hashes, die nicht verschlüsselt sind. Gibt es immer noch zu hauf.

Mit der richtigen Graka biste schnell am Ziel

Da könnte ich mal schauen was man für Werte mit einer R9 Fury hin bekommt

[Jasch]

Nun muss ich mir wegen euch wieder Gedanken machen.:rolleyes:
Spaß beiseite, inter. Thread.
USB Ports sind bei uns zwar über DeviceControl gesperrt, aber noch ein Grund mehr, sich wegen einer Kerberos implementation mal Gedanken zu machen.