Der Angriff muss aus dem lokalen Netzwerk aus erfolgen. Das ist bei euch ausgeschlossen? Ehrlich?? ASUME BREACH – geht davon aus, dass es durchaus Wege in die interne Infrastruktur gibt:

• nicht verschlossene, leere Büros (da gibt es ganz tolle Videos im Netz)
• ein bereits von außen übernommener Client
• ein unbedarfter Benutzer (Frechheit siegt)
• …

In meinem Fall hat es der Angreifer geschafft, sein KALI im Netzwerk zu plazieren. Dank DHCP hat er auch schon eine IPv4-Konfiguration:

Nun muss er geeignete Kandidaten für diesen Angriff ausspähen. Dafür braucht er Werkzeuge…

Ich verwende in meiner Simulation die Tools von Responder. Diese waren in meiner KALI-Version schon dabei:

Responder

Dieses Tool nutzt Broadcasts und Multicasts für Namensauflösungsanfragen im lokalen Netzwerksegment aus, um immer mit der IP-Adresse des Angreifers (oder einer anderen) zu antworten:

• Client: „ich suche ‚Webserver‘. Ist hier ein ‚Webserver‘?“
• Responder: „Ich bin ‚Webserver‘. Das ist meine IP: ###.###.###.###“
• Und dann wird der Client den Verbindungsaufbau zum Angreifer einleiten…
• Natürlich wird dieser Effekt nicht immer zum Erfolg führen. Dazu aber später mehr.

MultiRelay.py

Hat es der Responder geschafft, einen Computer, der einen SMB-Server sucht auf seine eigene IP-Adresse zu verweisen, dann könnte er selbst versuchen einen NTLM-Challenge aufzuzeichnen, mit dem der Computer die Anmeldung des angemeldeten Benutzers zum „FileServer“ übertragen möchte. Diese Challenges sind aber durchaus schwer zu knacken. Und Klartextkennwörter werden selten über die Leitung gesendet…

Einfacher ist es, wenn man die Anmeldung auf einen anderen Computer im Netzwerk umlenkt, der mit den Anmeldeinformationen auch noch was anfangen kann. Dann wird dieser Rechner zugänglich – ohne dass der Angreifer irgendeinen Hash knacken muss – also in Echtzeit! Und das bietet MultiRelay… Das funktioniert aber auch nur unter bestimmten Voraussetzungen. Eine davon: der Ziel-Computer darf selbst keine SMB-Signing-Ansprüche haben, denn sonst würde er erkennen, dass die Anfrage nicht vom originalen Server stammt, sondern ein Man-In-The-Middle dazwischenfunkt.

RunFinger.py

Und genau solche Computer ohne SMB-Signing-Ansprüche findet RunFinger…

Dann bringen wir einmal die Tools in Stellung. Beginnen wir mit einem kleinen Scan, um Clients ohne SMB-Signing zu finden:

Und da ist auch schon ein Kandidat! LON-SVR1 – ein DomainMember mit Windows Server 2016. Er hat die IPv4 172.16.0.11

OK, dann kann nun MultiRelay in Stellung gebracht werden. Dieses Script benötigt die IPv4 des Zieles und die Informationen, welche Benutzer „umgeleitet“ werden sollen. Mit ALL werden alle Benutzer umgelenkt:

Und zu guter Letzt kommt nun der Responder zum Einsatz dazu. Der Responder darf aber keine Überschneidung der zu öffnenden Ports mit dem MultiRelay eingehen. Daher sollten vorab in seiner Conf-Datei diese Anpassung vorgenommen werden:

Und dann kann der Responder starten. Er benötigt das Interface und einige Optionen. MultiRelay empfiehlt in diesem Fall die Optionen -rv für einen optimalen (und leisen) Angriff:

Nun muss man Geduld haben. Andere Computer im gleichen Netzwerksegment stellen Namensauflösungsanfragen normalerweise über DNS-Lookups direkt an den (oder die) konfigurierten DNS-Server. Da diese Verbindungen auf Unicast basieren wird der Responder davon nichts mitbekommen. Dennoch kommen auch immer wieder NBNS oder LLMNR-Abfragen im Netzwerk vor – gerade, wenn ein Benutzer mit Single-Names statt FQDN arbeitet und DNS diese nicht auflösen kann.

Vielleicht hat sich der Benutzer ja vertippt? Das würde dann auf LON-SVR2 für den dort angemeldeten adatum\administrator so aussehen:

Klar, der Benutzer wird nach diesem Typo keinen Ressourcenzugriff erhalten und es mit dem richtigen Namen erneut versuchen. Aber was hat der Angreifer nun erreicht?

Da er DNS-Server auf LON-DC1 keine Antwort auf die Frage „Welche IP hat der FileSerfer“ geben konnte, hat es der Computer mit NBNS (NetBIOS via Broadcast) und LLMNR probiert – der Link Local Multicast Name Resolution von IPv6 als Multicast. Und der fleißige Responder hat ihm mit der geantwortet: „FileSerfer hat die IP 172.16.0.160“ …

Nur hinter dieser IP und dem Port 445 (SMB für FileServices) wartet das MultiRelay:

… und dieser lenkt die Anmeldung an den Zielserver um – und der Angreifer ist online!!! Es ist kein Passwort-Cracking oder Ähnliches erforderlich: nur ein Admin, der sich im Windows Explorer vertippt! Und das Beste: Der Admin bekommt nichts davon mit!!!

OK, was sind denn nun die Optionen des Angreifers? Welche Rechte hat er?

Aha, das sollte für weitere PostExploits genügen. Wie wäre es mit einer Mimikatz-Variante – BuiltIn?

Volltreffer! der ungeschützte NTLM-Hash des DomainAdmins! Ein Pass-The-Hash später gehört ihm der DomainController!

Aber auch andere nachgelagerte Attacken sind denkbar… Sehr unschön auf einem modernen Windows Server 2016, oder?

Der Schuldige ist die Namensauflösungsstrategie des Windows Systems. Der Admin hat den SingleName (!) „FileSerfer“ in den Windows Explorer eingegeben. Zunächst versucht der Server einen DNS-Lookup, indem er den Namen der Domain an den SingleName anfügt:

Klar, ein Typo wird (hoffentlich) nicht aufgelöst. Nur dann versucht der Computer die anderen Namensauflösungsmechanismen. Für IPv4 ist das NBNS (NetBios über Broadcasts) und für IPv6 ist es LLMNR (Link Local Multicast Name Resolution über Multicasts):

Und auf diese „Rundrufe“ kann jeder im gleichen Netzwerksegment antworten. Genau das ist die Aufgabe vom Responder! In Zeile 136 wird die NBNS-Anfrage beantwortet und in Zeile 137 wird das Multicast von IPv6 erwidert: Als IPv4-Adresse kommt in beiden Antworten die 172.16.0.160 zurück – die IP des Angreifers!!!

Und so ist der Verbindungsaufbau vom Opfer-Computer zum Angreifer zu erklären.

Dafür muss man verstehen, wie eine „normale“ Anmeldung an einer Ressource funktioniert. Der Benutzer muss sich zunächst authentisieren, bevor er für den Ressourcenzugriff autorisiert wird. Doch da der Benutzer bereits an LON-SVR2 authentifiziert wurde kennt dieser Computer dessen Kennwort. Natürlich (und hoffentlich) liegt es nicht im Klartext vor, sondern als NTLM-Hash. Dennoch kann dieser für Pass-The-Hash-Attacken wie ein Kennwort verwendet werden. Der Computer kann den NTLM-Hash also nicht direkt über das Netzwerk an den Ziel-Computer übertragen. Stattdessen wird eine NTLMv2-Challenge ausgeführt. Und das sieht so aus:

Im Wireshark sind dabei diese Pakete zu beobachten:

Paket 30 Client -> Server: Der Client nennt seine Optionen für den Verbindungsaufbau:

Paket 31 Server -> Client: Der Server antwortet auf das Paket. Es werden so die Parameter der Authentifizierung ausgehandelt. Neben den Optionen (Capabilities) und einigen anderen interessanten Werten (Boottime ) nennt der Zielserver auch seine Authentifizierungsmethoden. Kerberos steht dabei über NTLMSSP:

Paket 34 Client -> Server: Nach einer kurzen Aushandlung (Paket 32 und 33) bietet der Client nun NTLMSSP als Authentifizierung im Request-Paket 34 an:

Auch der Client ist etwas gesprächig: er nennt seine Versionsnummer (Win 10 14393), nur seinen Namen teilt er nicht mit. Er nennt außerdem nur noch den MechType NTLMSSP, Kerberos funktioniert also nicht (kein DC?, kein Trust?, kein AD-Benutzer?).

Paket 35 Server -> Client: Der Server antwortet auf diesen Request mit einer NTLM-Challenge. Das ist ein Zufallswert, der im Idealfall nie wieder verwendet wird…

Paket 36 Client -> Server: Auf diese Challenge berechnet der Client mit dem NTLM-Hash des Benutzerkennwortes die Response und sendet diese an den Server. Aus dem Wissen der Challenge und des Responses kann der NTLM-Hash nicht wieder berechnet werden. So kann alles „im Klartext“ über die Leitung transportiert werden:

Ebenso trägt der Client hier die fehlenden Werte (Benutzername und Domain) mit ein.

Paket 38 Server -> Client: Der Server berechnet nun mit seinem gespeicherten NTLM-Hash des Benutzers den gleichen Response auf seine zuvor gewählte Challenge und bestätigt im letzten Paket die erfolgreiche Anmeldung:

Soweit alles klar?

Das MultiRelay kennt den NTLM-Hash des Benutzers nicht. Sonst würde der Angreifer gleich einen Pass-The-Hash fahren. Und das Script kann den NTLM-Hash aus dem Response einer Challenge nicht zurückrechnen, da die genutzten Funktionen praktisch unumkehrbar sind. Aber das Script nutzt einfach die Verbindung zu beiden Systeme aus um die NTLM-Challenge des Zieles an den Client zur Bearbeitung zu senden. Danach nimmt es die Antwort des Clients und sendet diese „stellvertretend“ an den Server…

Das sieht dann so aus:

Wie genial ist das denn bitte?

Im Detail sehen dann so die Datenströme im WireShark aus. Den Dialog habe ich der Übersicht halber mal in die zeitliche Relation gebracht und die Konversation zwischen Quelle und dem Angreifer Orange und die Kommunikation zwischen dem Angreifer und dem Zielserver blau dargestellt. Grün ist die Namensauflösung:

Und das hier sind die Details:

Paket 216 Client -> Angreifer: Der Client sendet das Aushandlungspaket an den Angreifer. Dieser startet daraufhin einen Verbindungsaufbau zu seinem Ziel (TCP-Handshake).

Paket 221 Angreifer -> Client: Dann beantwortet der Angreifer den Request des Clients.

Paket 229 Client -> Angreifer: Der Client wünscht nun eine Anmeldung und fragt diese als NTLMSSP an:

Paket 232 Angreifer -> Zielserver: Doch der Angreifer kopiert diese Informationen und erstellt daraus einen eigenen Request an seinen Zielserver:

Paket 236 Zielserver -> Angreifer: Der Zielserver generiert nun seine NTLM-Challenge uns sendet diese zusammen mit einigen Informationen über sich an den Angreifer:

Paket 237 Angreifer -> Client: Und daraus erstellt der Angreifer eine identische Challenge für den Client. Dabei übernimmt er sogar die Detailinformationen:

Paket 238 Client -> Angreifer: Der Client kennt den NTLM-Hash des Benutzers und kann zusammen mit der NTLM-Challenge den NTLM-Response berechnen. Diese soll beweisen, dass es sich auch wirklich um den angegebenen Benutzer handelt:

Paket 247 Angreifer -> Zielserver: Und nun hat der Angreifer einen korrekt berechneten Response auf die Challenge des Zielservers. Eine kurze Paketmodifikation später sendet er „seine“ Antwort zum Ziel:

… und wird angemeldet!

Das war es – der Angreifer hat eine Verbindung zum Ziel.

Nun testet das MultiRelay-Script, ob der Benutzer administrative Rechte auf dem Zielsystem hat:

Dazu wird einfach die Verbindung zur administrativen Freigabe C$ angefragt:

Der Zielserver bestätigt das einwandfrei:

Danach läd es einfach exe-Dateien in das Verzeichnis c:\Windows\Temp und erstellt darauf Windows Services mit dem Account NT-Authority\System. Das ist dann gleichzeitig auch eine Privilege Escalation. Hier kommt die Datei…

… und hier der Service:

Jeder Befehl in der Angreifer-Console wird eine neue *.exe-Datei. Diese erzeugt einfach einen Output als Datei, nachdem die Aktion abgeschlossen ist. Diese Datei (TXT) holt MultiRelay zurück zum Angreifer und die Darstellung in der Console wird gerendert.

Bis hier alles klar? Wer jetzt davon ausgeht, dass ein Virenscanner euch schützen wird – da muss ich leider enttäuschen. Es sind immer live erzeugte Dateien. Eine signaturbasierte Prüfung wird da nur schwer mitkommen. Und denkbar wäre auch ein PowerShell-Code. Wie will ein AV so etwas erkennen?

Diese Option ist so simpel wie effizient! Warum soll denn ein Client heute noch broadcasten oder multicasten, wenn er Namen auflösen möchte? Für diese Aufgaben gibt es DNS! Jaja, es gibt ja noch alte Anwendungen, die des brauchen… dann nehmt WINS oder GlobalNameZones. Dann ist der Traffic wieder Unicast!

Wenn ihr dagegen diese alten Protokolle abschalten wollt, dann geht das

1. lokal auf allen Clients und Servern – manuell ☹
2. mit einer kleinen GPO 🙂

Für das modernere LLMNR gibt es in den aktuellen Administrative Templates für GPOs sogar einen eigenen Schalter:

Bei der Deaktivierung von NetBIOS (NBNS) hingegen wird es komplizierter, da ein Computer durchaus mehrere Netzwerkkarten verwenden kann und diese Funktion je Adapter deaktiviert werden muss. Im Internet kursieren verschiedene Scriptlösungen – alle nicht wirklich elegant.

Dennoch habe ich eine einfache Lösung OHNE Script gefunden: ein einfacher Registry-Key genügt für alle Interfaces:

Beides zusammen in einer GPO und der Client interessiert sich nicht mehr für den Responder. Das hier ist ein lokaler Mitschnitt einer Namensauflösung. Man erkennt deutlich die reinen DNS-Versuche, bevor es zur Fehlermeldung kommt (und diese erscheint auch deutlich schneller!):

Und der Responder? Der kann lange auf Arbeit warten:

Ein netter Nebeneffekt: in öffentlichen Netzen sind eure Systeme dann auch nicht mehr so „freizügig“ mit Infos!

Ebenso einfach ist die Aktivierung des SMB-Signings. Damit müssten die Pakete zum SMB-Verbindungsaufbau digital vom Absender signiert werden. Man-In-The-Middle wird so ordentlich erschwert. Und das MultiRelay möchte so nicht arbeiten.

ABER: SMB-Signing betrifft nicht nur den Verbindungsaufbau. Vielmehr wird JEDES SMB-Paket digital signiert. Die dafür erforderliche Rechenleistung kann die Gesamtleistung der Datenübertragung beeinflussen. Hier mal ein kleines Beispiel. Ich kopiere die gleiche Datenmenge einmal ohne und dann mit SMB-Signing. Das hier sind die Ergebnisse ohne Signing:

Nach dem Aktivieren des SMB-Signings und einem Neustart der beteiligten Maschinen (so ist auch der Cache leer) habe ich dann diese Ergebnisse gemessen:

Das Delta an Dateivolumen von etwa 50MB kann durchaus vernachlässigt werden – aber 8 Sekunden mehr Zeitbedarf durch das Signing und die Validierung ist nicht schönzureden… Sicherheit kostet eben – in diesem Fall Leistung!

Die gute Nachricht: auch das Signing wird über GPO aktiviert:

RunFinger.py zeigt nun keine Ziele ohne SMB-Signing mehr an:

Selbst wenn ein Angreifer loslegt – das hier meldet das MultiRelay:

Es kann so einfach sein!

einfach keinen Admin-Account benutzen

Warum braucht man denn immer administrative Berechtigungen? Würde der Benutzer auf dem Client einen Account ohne Admin-Rechte verwenden, dann würde MultiRelay auch nicht mit C$ eine Verbindung aufbauen können. Hier ein Beispiel, in der sich die Benutzerin Abbi im Windows Explorer vertippt hat:

MultiRelay (und viele andere Tools) kommen so nicht wirklich weiter.

Protected Users

Das Verwenden der Admin-Accounts lässt sich aber leider nicht immer vermeiden. Dennoch gibt es für genau diese sensiblen Konten die Gruppe „Privileged Users“ im Active Directory:

Diese Gruppenmitgliedschaft wird auf Betriebssystemen ab Windows Server 2012 R2 und Windows 8.1 angewendet und bewirkt Folgendes:

• CredSSP (Default Credential Delegation) speichert keine Klartext-Kennwörter und kann damit nicht verwendet werden
• WDigest ist für diesen Benutzer deaktiviert und kann keine Klartextkennworte speichern
• Zwischengespeicherte Anmeldungen sind nicht möglich: für jede Anmeldung wird der Kontakt zum DC erforderlich!

Wenn die Domänenfunktionsebene zusätzlich 2012R2 oder höher ist, dann:

• ist keine Constrained oder UnConstrained Delegation erlaubt
• ist keine NTLM-Authentication mehr erlaubt!

Und genau diese NTLM-Authentication ist ja eine Voraussetzung für MultiRelay… Wenn wir nun den Administrator-Account in diese Gruppe aufnehmen und dieser sich im Windows Explorer „vertippt“, dann versucht MultiRelay wie bisher die Anmeldung auf das Ziel umzuleiten:

Der Client muss aber wegen dem Benutzer und seiner Gruppenmitgliedschaft in „Protected Users“ eine Kerberos-Authentication versuchen (denn meine Funktionsebene ist Windows Server 2016). Das ist hier gut sichtbar:

Nur sagt der DC, dass es diesen Zielcomputer (den „vertippten“ im Windows Explorer) im AD nicht gibt. Also kann auch kein Session Ticket vom TGS (Ticket Granting Server – ein Service des Key Distribution Centers im Active Directory) ausgestellt werden. Nun bleibt dem Client nur noch eine Null-Anmeldung ohne Kennwort auf Gut-Glück. Er antwortet also mit einem ungültigen NTLM-Response. Das MultiRelay kann dies nicht prüfen und sendet den ungültigen Wert in Zeile 172 weiter an das Ziel. Nur das Ziel weiß, dass es für diesen Benutzer keine NTLM-Berechnungen ausführen kann (weil keine Werte gespeichert sind). Also antwortet das Ziel mit einem „Account Status Restriction“ in Zeile 198.

Nebenbei erkennt man in den roten Zeilen, dass auch das Ziel Probleme mit NTLM hat, so wird in Zeile 194+195 ein Netlogon vom DC verweigert…

Das MultiRelay kann mit der Antwort des Zielservers nicht viel anfangen und wartet einfach ab:

Der Client erhält dann später eine Meldung, dass er nicht auf das Ziel „FileSerFer“ zugreifen kann. Und im Zielserver wird der fehlgeschlagene Anmeldeversuch im Eventlog sichtbar:

Auch in diesem Beispiel konnte der Angriff abgewendet werden. Dennoch müsst ihr genau prüfen, unter welchen Voraussetzungen in euren Infrastrukturen die Gruppenmitgliedschaft in „Protected Users“ nachteilig ist.

Für die ganz Harten unter uns: wenn es die Umgebung erlaubt, kann NTLM auch ganz abgeschaltet werden. Dafür müssen aber alle (!!!) Beteiligten kompatibel sein: alle Clients, alle Server und alle Anwendungen! (Es ist natürlich möglich, Ausnahmen zu definieren, aber da steckt einiges an Aufwand dahinter!)

Vorbereitung – Der Audit-Mode

Diese Umstellung bedarf also etwas Vorbereitung. Zunächst sollte das Protokollieren der NTLM-Nutzung auf den DCs aktiviert werden. Danach sollte man einige Zeit warten und regelmäßig die Logfiles kontrollieren. Denkt bitte an die vorhandene Umlaufprotokollierung der Eventlogs: ist das Logfile voll, dann werden einfach die ältesten Records durch die Neusten überschrieben. Es nützt also kein Audit-Zeitraum von 4 Wochen, wenn eure Logfiles nur 1MB größ werden…

Auch wichtig: JEDER DC schreibt seine eigenen Logfiles. Für ein vollständiges Bild müsst ihr also alle DCs auswerten. Vielleicht hilft euch ja mein Powershell-Code weiter. Dieser sucht auf allen DCs der Domain nach dem Logfile und filtert euch die relevanten Infos heraus:

Invoke-Command -ComputerName (Get-ADDomain).ReplicaDirectoryServers -ScriptBlock {
Get-WinEvent -Path C:\Windows\System32\Winevt\Logs\Microsoft-Windows-NTLM%4Operational.evtx |
   Select-Object -Property @{ n='DC' ; e={ $env:COMPUTERNAME } },
         @{ n='Datetime' ; e={ (Get-Date -Date $_.TimeCreated -Format u) -replace 'z' } },
         @{ n='Client' ; e={ (($_.Message -split "`n" | select-string 'Workstation') -split ':')[1].trim() } },
         @{ n='Server' ; e={ (($_.Message -split "`n" | select-string 'Secure Channel name') -split ':')[1].trim() } },
         @{ n='Domain' ; e={ (($_.Message -split "`n" | select-string 'Domain name') -split ':')[1].trim() } },
         @{ n='User' ; e={ (($_.Message -split "`n" | select-string 'User name') -split ':')[1].trim() } }
} | Format-Table -Property DC,Datetime,Client,Server,Domain,User

Damit könnt ihr einfach CSV-Dateien erstellen und diese auswerten.

So könnte die GPO aussehen:

Und das sind die Logfiles in den DomainControllern:

NTLM lässt sich einfach testen, indem man eine SMB-Verbindung mit der IP-Adresse des Zieles aufbaut. Da kann/darf kein Kerberos verwendet werden… Probiert es aus!

Scharfschalten der NTLM-Restriktion

Nachdem ihr ausgiebig getestet habt könnt ihr nun die GPO mit der Restriktion und ggf. den Ausnahmen aufsetzen. Ich lasse hier keine Ausnahmen zu:

Habt ihr bei der Vorbereitung aufgepasst? Man kann des mit IP-Adressen „testen“ – eben weil diese Aufrufe nach dem Scharfschalten nicht mehr funktionieren:

Passt also bitte u.A. folgendes an:

• Scripte mit UNC-Pfaden auf IP-Adressen
• gemappte Laufwerke und Drucker
• ODBC-Verbindungen
• …

Sonst findet ihr solche Einträge im Eventlog:

Und der Angriff?

Nachdem nun NTLM abgeschaltet ist können wir die Funktion vom Responder und dem MultiRelay prüfen. Der Angriff folgt wieder dem gleichen Muster. Der Client-Admin ruft die falsche URL im Windows Explorer auf, der Responder lenkt ihn auf das MultiRelay und dieses versucht die Clientanmeldung an den Zielserver durchzureichen:

Nur bekommt das MultiRelay keine, da dieser Traffic nicht mehr erlaubt ist. Dafür findet man nun im DC dieses Eventlog:

Im WireShark sieht die Kommunikation zwischen den 4 Beteiligten (der DC gehört dazu) so aus:

Hier findet ihr die Erläuterungen zu den relevanten Paketen:

Paket 64 Client -> DC: Der Client fordert für die Authentisierung am Service CIFS (Filesystem) am Server „FileSerfer“ ein TGS (Ticket Granting Service) an:

Paket 66 DC -> Client: Der DC antwortet dem Client, dass er diesen Server nicht finden kann:

Paket 74 Zielserver -> Angreifer: Hier bekommt der Angreifer vom Zielserver die NTLM-Challenge:

Paket 76 Angreifer -> Client: Hier reicht der Angreifer die zuvor bekommene NTLM-Challenge vom Zielserver an den Client weiter:

Paket 77 Client -> Angreifer: Der Client antwortet auf die Challenge, verwendet aber nicht den NTLM-Hash, da er diesen nicht besitzt:

Paket 95 Angreifer -> Zielserver: Der Angreifer klont das Paket und sendet die Response des Clients als seine eigene zum Zielserver – unwissend, dass diese falsch ist:

Paket 119 Zielserver -> Angreifer: Der Zielserver kann dies dennoch genau herausfinden und dem Angreifer die Authentifizierung verweigern:

Damit ist auch dieser Angriff abgewehrt.