LLMNR und NBT-NS sind veraltete Protokolle, die bei aktuellen Windows-Betriebssystemen allerdings noch immer im Standard aktiviert sind. Die Schwachstelle in den beiden Protokollen sorgt dafür, dass Angreifer wertvolle Passwort-Hashes abfangen oder sich ohne die Kenntnis von Anmeldeinformationen an Servern oder Clients authentifizieren können. Leider ist diese gravierende Schwachstelle bei vielen Systemadministratoren nicht bekannt und in vielen Unternehmensnetzwerken klafft daher diese gravierende Sicherheitslücke.
Inhaltsverzeichnis
Was ist LLMNR und NBT-NS?
LLMNR (Link-Local Multicast Name Resolution) und NBT-NS (NetBIOS-Nameservice) sind alte Protokolle für die Namensauflösung. Kurz gesagt kommen diese Protokolle zum Einsatz, wenn der DNS-Server im Netzwerk keine passende Antwort liefert. Beispiel: Ein Host im Netzwerk fragt den DNS-Namen "gibtesnicht" an. Der DNS-Server liefert allerdings keine passende IP-Adresse, weil er den Namen nicht kennt. Der Host macht sich daher selbst auf die Suche und schickt mit den Protokollen LLMNR, oder wenn LLMNR deaktiviert ist mit NBT-NS, einen Broadcast ins Netzwerk und hofft, dass sich ein Teilnehmer des Netzwerks auf "gibtesnicht" angesprochen fühlt und antwortet.
Net-NTLM, NTLMv1/2 und NTLM
Da die hier gezeigten Angriffe viel mit Passwort-Hashes zu tun haben, hier einmal etwas einleitende Theorie zu den verschiedenen Hashes. Wem das nicht sonderlich interessiert, kann direkt zum nächsten Abschnitt springen, in dem es um den eigentlichen Angriff geht.
Es gibt verschiedene relevante Passwort-Hashes in Windows. In diesem Artikel beschäftigen wir uns mit Net-NTLM, NTLMv1/2 und NTLM. Wenn man von NTLMv1/2 spricht, spricht man eigentlich von Net-NTLM(v1/2). Diese Hashes werden für Netzwerkauthentifizierungen verwendet und können durch einen Name Resolution Response-Angriff abgefangen oder für einen Relaying-Angriff, nicht aber für einen Pass-the-Hash-Angriff, verwendet werden. Den nachgelagerten Relaying-Angriff schauen wir uns später in diesem Artikel an. Für einen Pass-the-Hash-Angriff benötigt der Angreifer einen NTLM-Hash (also nicht Net-NTLM bzw. NTLMv1/NTLMv2, sondern einen LM- oder NT-Hash). LM- oder NT-Hashes sind in der SAM-Datenbank (Security Account Manager Datenbank) von Windows oder in der Ntds.dit Datenbank auf dem Domänencontroller gespeichert. Ein solcher Hash sieht wie folgt aus:
aad3b435b51404eeaad3b435b51404ee:31d6cfe0d16ae931b73c59d7e0c089c0
Vor dem Doppelpunkt ist das Passwort als (schwacher) LM-Hash gespeichert und nach dem Doppelpunkt als NT-Hash. Wenn man von NTLM spricht, meint man in der Regel aber den NT-Hash. Das Speichern des LM-Hashes kann man mit einer GPO deaktivieren. Außerdem empfiehlt es sich in diesem Zusammenhang die GPO "Netzwerksicherheit: LAN-Manager-Authentifizierungsebene" auf "Nur NTLMv2-Antworten senden. LM & NTLM verweigern" zu setzen.
Die verschiedenen Hashes ermöglichen verschiede Angriffsszenarien und es ist schwer den Überblick über die verschiedenen Hashtypen zu behalten. Zusammenfassend könnte man folgendes festhalten: (Net-)NTLMv1/2-Hashes ermöglichen einen Relaying-Angriff und LM- oder NT-Hashes ermöglichen einen Pass-the-Hash-Angriff.
Zwei empfehlenswerte Seiten, die die verschiedenen Hashes noch ganz gut erklären, habe ich hier einmal verlinkt:
https://byt3bl33d3r.github.io/practical-guide-to-ntlm-relaying-in-2017-aka-getting-a-foothold-in-under-5-minutes.html
https://medium.com/@petergombos/lm-ntlm-net-ntlmv2-oh-my-a9b235c58ed4
Der Name Resolution Response-Angriff
Mit dem Wissen was LLMNR und NBT-NS ist, kann sich ein Angreifer jetzt als "gibtesnicht" ausgeben und dem Opfer vortäuschen, dass er "gibtesnicht" sei. Wenn das Opfer jetzt beispielsweise versucht einen falschgeschriebenen Netzwerkshare "gibtesnicht" aufzurufen und ein Angreifer sich als Zielserver "gibtesnicht" meldet, wird das Opfer sogar seinen Passwort-Hash (Net-NTLM Hash) an den Angreifer senden.
Voraussetzungen für diesen Angriff:
- Opfer und Angreifer müssen in der selben Broadcast-Domäne sein.
- LLMNR und/oder NBT-NS muss bei dem Opfer aktiviert sein.
Der Angreifer kann jetzt beispielsweise versuchen diesen Hash mit einem Dictionary- oder Brute-Force-Angriff (offline) zu knacken.
Die Laborumgebung
Für die durchgeführten Tests in diesem Artikel habe ich in meiner Testumgebung folgende Systeme aufgesetzt, die bis auf dem Angreifer, alle Teil der Domäne lab.local sind:
Domänencontroller / DNS-Server
Windows Server 2019
Hostname: LABDC01.lab.local
IP-Adresse: 192.168.0.2
Opfer
Windows 10 20H2
Hostname: LABCLIENT01.lab.local
IP-Adresse: 192.168.0.200 (DHCP)
Benutzer: LAB\peter
Angreifer
Ubuntu 20.04 LTS
Hostname: HACKERPC
IP-Adresse: 192.168.0.205 (DHCP)
Der Name Resolution Response-Angriff in der Praxis
Bevor wir den eigentlichen Angriff starten, schauen wir uns in Wireshark die Auswirkung von LLMNR bzw. NBT-NS an. Dazu installiere ich auf dem Angreifer-PC Wireshark und starte es:
sudo apt install wireshark
sudo wireshark
Wenn das entsprechende Netzwerkinterface in Wireshark ausgewählt wurde, beginnt auch schon der Mitschnitt sämtlicher Pakete. Mit dem Anzeigefilter udp.port == 5355 || nbns lässt sich die Anzeige schließlich auf das Wesentliche reduzieren. Wenn wir auf einem Host im Netzwerkt ping gibtesnicht ausführen, zeichnet Wireshark auf dem Angreifer-PC diverse LLMNR- und NBT-NS-Pakete auf:
An dieser Stelle passiert jetzt noch nicht viel. Aber das ändert sich ganz schnell, wenn der Angreifer-PC auf die Anfrage antwortet und sich als "gibtesnicht" ausgibt. Genau das werden wir jetzt tun. Es gibt bereits diverse freie Tools, die auf eine solche Anfrage antworten können. Ich nutze für diesen Artikel Responder. Das Tool setzt Python voraus. Die Installation ist denkbar einfach:
cd /home/hacker/Downloads/
wget https://github.com/lgandx/Responder/archive/master.zip
unzip master
cd Responder-master/
sudo python3 Responder.py -I enp0s3
Der Responder läuft jetzt und wartet auf Anfragen:
Jetzt mache ich den gleichen Test wie vorhin und pinge von unserem Opfer-PC "gibtesnicht" an:
Als wäre der Angriff bis jetzt nicht genug, kann der Angreifer mit etwas Glück und Geduld auch den Passwort-Hash des Opfers abfangen. Der einfachste Weg für dieses Szenario ist, dass ein Benutzer schließlich versucht eine nicht existierende Webadresse (z.B. http://gibtesnicht oder https://gibtesnicht) oder Netzwerkshare (\\gibtesnicht) aufzurufen:
Jetzt hat der Angreifer mehrere Möglichkeiten, wie er weiter vorgehen kann. Er könnte einen Relaying-Angriff versuchen (dazu später mehr) oder er versucht den NTLMv2-Hash mit einem Tool wie z.B. hashcat zu cracken und so zum Klartextpasswort zu kommen.
Hash mit hashcat cracken
Mit hashcat kann nun versucht werden das Klartextpasswort für den Hash herauszufinden. Dafür eignen sich beispielsweise der Dictionary- oder der Brute-Force-Angriff. Installiert werden kann hashcat mit folgendem Befehl:
sudo apt install hashcat
Dictionary-Angriff
Dieser Angriff versucht eine Liste von bekannten Passwörtern auszuprobieren, bis das richtige Passwort gefunden ist. Dafür werden meist große Passwortlisten oder Passwörter aus bekannten Leaks verwendet. Bekannte Passwortlisten sind beispielsweise CrackStation's Password Cracking Dictionary oder rockyou.txt.
Ein Angriff sähe beispielsweise wie folgt aus:
hashcat -a 0 -m 5600 hashes.txt rockyou.txt -o passwords.txt
Der Parameter "a" gibt den Angriffstyp an. 0 steht dabei für den Dictionary-Angriff. Mit "m" wird der Hashtyp angegeben. 5600 steht dabei für NTLMv2 bzw. Net-NTLMv2 (NTLMv2 und Net-NTLMv2 sind Synonyme). Als nächstes wird die Textdatei mit den Hashes angegeben. Die Hashes die der Responder ausgegeben hat, können dort einfach Ziele für Zeile eingefügt werden. Schließlich kann noch mit "o" eine Ausgabedatei angegeben werden.
Weil der Benutzer Peter in diesem Beispiel ein sehr schwaches Kennwort gewählt hat, war der Dictionary-Angriff bereits nach kurzer Zeit erfolgreich:
Brute-Force-Angriff
Ist der Dictionary-Angriff nicht erfolgreich, kann noch durch rohe Gewalt versucht werden, das Kennwort zu knacken. Das kann wie folgt gelingen:
hashcat -a 3 -m 5600 hashes.txt -1 ?l?u?d?s ?1?1?1?1?1?1?1 -o password.txt
Die 3 bei "a" steht hier für einen Brute-Force-Angriff. Mit "-1" kann noch angegeben werden, welche Zeichen das Passwort enthalten könnte:
- ?l steht für Kleinbuchstaben.
- ?u steht für Großbuchstaben.
- ?d steht für Zahlen.
- ?s steht für Sonderzeichen.
"?1?1?1?1?1?1?1" bedeutet, dass das gesuchte Passwort aus sieben Zeichen besteht. Wenn ein Angreifer nicht weiß, wie lang das Kennwort ist, wird es viel aufwändiger. Er kann dann eine Mindest- oder Maximallänge angeben:
-i --increment-min 8 --increment-max 12
Mehr Informationen zu den möglichen Parametern sind in der offiziellen Dokumentation zu finden. Weitere Erklärungen zu den Passwortmasken sind ebenfalls in der offiziellen Dokumentation zu finden.
Wenn der Angreifer die Passwortrichtlinien oder weitere Informationen über ein Passwort kennt, lässt sich ein Brute-Force-Angriff effizienter gestalten, da er beispielsweise die Mindestlänge oder erlaubte Passwortzeichen weiß. Hat ein Angreifer bereits Zugriff auf einen Domänenrechner (beispielsweise durch einen Relaying-Angriff), kann er die gültigen Passwortrichtlinien einfach einsehen.
Hier zeigt sich jetzt, dass ein möglichst komplexes Passwort sehr wichtig ist, um den Angreifer das Knacken zu erschweren, sollte er bereits an den Hash gekommen sein.
Der Relaying-Angriff
Wenn der Name Resolution Response-Angriff erfolgreich war, das Passwort sich aber nicht so einfach cracken lässt, beispielsweise weil es sehr komplex ist, kann der Angreifer auch versuchen sich mit Hilfe eines Relaying-Angriffs, also Weitereichen des Passwort-Hashes, an seinem eigentlichen Ziel zu authentifizieren. Beispiel: Der Benutzer "Peter" arbeitet immer auf seiner Workstation "LABCLIENT01" und hat zusätzlich administrative Berechtigungen auf die Workstation "LABCLIENT02" und dem Server "LABSRV2012R2". Peter wollte auf einem Netzwerkshare zugreifen und hat durch Vertippen einen nicht existierenden DNS-Namen angefragt. Der Angreifer konnte durch den Name Resolution Response-Angriff zwar den Passwort-Hash von Peter abfangen, diesen jedoch nicht cracken, weil das Passwort zu stark ist. Der Angreifer kann jetzt durch einen Relaying-Angriff den Hash einfach an sein eigentliches Ziel "LABCLIENT02" oder "LABSRV2012R2" weiterreichen und sich dort authentifizieren. Er muss das Passwort für diesen nachgelagerten Angriff also gar nicht kennen.
Voraussetzungen für diesen Angriff:
- Opfer, Angreifer und das Angriffsziel müssen in der selben Broadcast-Domäne sein.
- LLMNR und/oder NBT-NS muss bei dem Opfer aktiviert sein.
- SMB-Signierung auf dem Zielsystem darf nicht erzwungen sein.
- Firewall auf dem Zielsystem darf die SMB-Anfrage vom Angreifer nicht blockieren.
- Der abgefangene Passwort-Hash muss zu einem Benutzer mit ausreichenden Rechten auf dem Zielsystem gehören.
Erweiterung der Laborumgebung
Die Laborumgebung aus dem ersten Angriff habe ich für diesen nachgelagerten Angriff etwas erweitert. Hinzugekommen sind zwei Angriffsziele, auf die wir einen Relaying-Angriff starten möchten.
Domänencontroller / DNS-Server
Windows Server 2019
Hostname: LABDC01.lab.local
IP-Adresse: 192.168.0.2
Opfer
Windows 10 20H2
Hostname: LABCLIENT01.lab.local
IP-Adresse: 192.168.0.200 (DHCP)
Benutzer: LAB\peter
Angriffsziel 1 (Ziel für Relaying-Angriff)
Windows 10 20H2
Hostname: LABCLIENT02.lab.local
IP-Adresse: 192.168.0.202 (DHCP)
Lokaler Administrator: LAB\peter
Windows Firewall: deaktiviert
Angriffsziel 2 (Ziel für Relaying-Angriff)
Windows Server 2012 R2
Hostname: LABSRV2012R2.lab.local
IP-Adresse: 192.168.0.204 (DHCP)
Lokaler Administrator: LAB\peter
Windows Firewall: deaktiviert
Angreifer
Ubuntu 20.04 LTS
Hostname: HACKERPC
IP-Adresse: 192.168.0.205 (DHCP)
In dieser Laborumgebung habe ich die Windows Firewall der beiden Angriffsziele deaktiviert, um den Test einfacher zu gestalten. Es hätte aber auch genügt eingehenden SMB-Traffic zu erlauben.
Der Relaying-Angriff in der Praxis
Wir wissen jetzt wie der Name Resolution Response-Angriff funktioniert. Diesen wandeln wir etwas ab. Jetzt wollen wir nicht bloß den Passwort-Hash abfangen, sondern diesen an einen weiteren Host (Angriffsziel 1 und 2) weiterleiten, um uns dort ohne Passwort zu authentifizieren.
Für diesen Angriff kann der Angreifer nach wie vor den Responder nutzen. Allerdings wird für diesen Angriff noch ein weiteres Tool ntlmrelayx.py, welches Bestandteil von impacket ist, benötigt. Da das neue Tool ntlmrelayx.py auf HTTP- und SMB-Anfragen lauscht, müssen diese Protokolle zuvor im Responder deaktiviert werden. Das gelingt wie folgt:
cd /home/hacker/Downloads/Responder-master/
nano Responder.conf
Als nächstes kann schließlich ntlmrelayx.py installiert werden. Die Installation auf dem Angreifer-PC gelingt wie folgt:
sudo apt install python3-pip
cd /home/hacker/Downloads/
wget https://github.com/SecureAuthCorp/impacket/archive/master.zip
unzip master.zip
cd impacket-master/
pip3 install -r requirements.txt
sudo python3 setup.py install
Ab jetzt kann in jedem Verzeichnis das Skript ntlmrelayx.py ausgeführt werden.
Der Responder kann jetzt wie folgt gestartet werden:
cd /home/hacker/Downloads/Responder-master/
sudo python3 Responder.py -I enp0s3 -rdw
Das Skript ntlmrelayx.py wird wie folgt gestartet:
sudo ntlmrelayx.py -t 192.168.0.202 -smb2support
Wenn jetzt ein Teilnehmer im Netzwerk, z.B. Peter auf seiner Workstation LABCLIENT01 (192.168.0.200) einen nicht (mehr) existierenden DNS-Namen versucht aufzulösen, startet der Angriff. Peter versucht jetzt sich auf seiner Workstation mit einer Netzwerkfreigabe "\\gibtesnicht" zu verbinden.
Der Relaying-Angriff war erfolgreich. Das sehen wir z.B. in der oberen Hälfte des Bildes an der Zeile "[*] Authenticating against smb://192.168.0.202 as LAB/PETER SUCCEED" oder an den Passwort-Hashes der SAM-Datenbank (rote Markierung im Bild) des Angriffsziels. Der Angreifer hat an dieser Stelle jetzt die LM- und/oder NT-Hashes sämtlicher lokaler Benutzer auf LABCLIENT02. Diese Hashes kann er jetzt versuchen zu cracken. Außerdem sind diese Hashes ausreichend für einen späteren Pass-the-Hash-Angriff, falls der Angreifer die Passwörter nicht cracken kann.
Schauen wir uns unser Angriffsziel "LABCLIENT02" etwas genauer an, sehen wir ebenfalls, dass es einen erfolgreichen Login gab:
Bis hierhin haben wir es schon mit einer schwerwiegenden Sicherheitslücke zu tun. Aber es geht noch schlimmer. Denn das Tool ntlmrelayx.py kann auch direkt versuchen einen Befehl auf dem Zielhost auszuführen:
sudo ntlmrelayx.py -t 192.168.0.202 -smb2support -c "mkdir C:\Temp"
Auf dem Angreifer-PC sehen wir jetzt, dass die Authentifizierung zwar erfolgreich war, der Befehl "mkdir C:\Temp" aber nicht ausgeführt wurde:
Wenn wir das auf LABCLIENT02 (192.168.0.202) überprüfen, lässt sich auch verifizieren, dass der Login erfolgreich war (Windows Ereignisanzeige), und dass der Ordner C:\Temp nicht angelegt wurde.
Der Angreifer überlegt mit jeder Information, die er hat "Was kann ich hiermit anfangen?". Er hat bis jetzt diverse Passwort-Hashes, die er versuchen kann zu cracken oder für Pass-the-Hash-Angriffe verwenden kann. Er kann an dieser Stelle auch noch mehr Energie aufbringen, in der Hoffnung, dass sein gewünschter Befehl "mkdir C:\Temp" doch noch erfolgreich ausgeführt wird. Aber der Angreifer könnte sich auch neue Angriffsziele im Netzwerk suchen. Wir versuchen den gleichen Angriff also jetzt auf unser Angriffsziel 2 "LABSRV2012R2" (192.168.0.204). Da es langweilig ist einen Ordner zu erstellen, verändern wir unseren Befehl etwas:
sudo ntlmrelayx.py -t 192.168.0.204 -smb2support -c "powershell.exe (net user hacker Test123 /add),(net localgroup Administratoren hacker /add)"
Unser Peter auf LABCLIENT01 versucht jetzt wieder einen Netzwerkshare zu erreichen, den es nicht gibt, beispielsweise \\gibtesnicht und triggert dadurch eine LLMNR- und/oder NBT-NS-Anfrage und ermöglicht den Angriff:
Ich denke, dass man an dieser Stelle ganz gut sieht, wie mächtig dieser Relaying-Angriff ist. Ohne Zugangsdaten zu wissen, konnte sich der Angreifer durch die Weitergabe des Passwort-Hashes an einem weiteren Host authentifizieren und dort Befehle ausführen, beispielsweise um einen administrativen Benutzer zu erstellen, den der Angreifer fortan verwenden kann. Was wäre nun, wenn der Angreifer den Passwort-Hash von einem Domänenadministrator statt von Peter abgefangen hätte? Selbst in der aktuellen Situation ist der Angreifer dem Domänenadministrator schon ein ganzes Stück näher. Auf diesem Host findet er vielleicht weitere Informationen oder Passwort-Hashes zu Domänenbenutzern. Falls sich in der Vergangenheit ein Domänenadministrator auf diesem Host angemeldet hat, vielleicht sogar den Passwort-Hash des Domänenadministrators...
Schutz vor Name Resolution Response- und Relaying-Angriff
Wir haben eindrucksvoll gesehen, wie mächtig diese beiden Angriffe sind. Ich denke, dass jedem einleuchtet, dass diese unter allen Umständen unterbunden werden sollten. Einige wichtige Erkenntnisse sollten sein:
- Windows Firewall aktivieren und möglichst sicher konfigurieren, dann hätte der Relaying-Angriff eventuell nicht geklappt.
- Mit der Vergabe von Berechtigungen geizig sein, damit es einen Angreifer erschwert wird sich im Netzwerk auszubreiten.
- Sicherheitsupdates alleine reichen nicht aus. Windows Server 2012 R2 bekommt immer noch Sicherheitsupdates und alle Sicherheitsupdates waren für meinen Versuch installiert, der Relaying-Angriff hat aber auf Anhieb funktioniert. Auf dem Windows 10 20H2 Client hat er hingegen nicht vollständig funktioniert. Eventuell hätte der Angreifer es durch Ausprobieren und mit viel Geduld aber noch hinbekommen.
- Sich niemals mit hochprivilegierten Accounts wie einem Domänenadministrator auf Clients anmelden. Denn wenn ein Angreifer Zugriff auf einen solchen Client hat, kann er gegebenenfalls den Passwort-Hash des Domänenadministrators erlangen.
- Möglichst starke Passwörter verwenden, damit das Cracken des Passwort-Hashes erschwert oder gar unmöglich wird.
Abgesehen von den eben genannten grundsätzlichen Tipps kann man sich vor den beiden vorgestellten Angriffen durch relativ einfache technische Maßnahmen schützen:
- Netzwerkweites Deaktivieren von LLMNR und NBT-NS (Schutz vor Name Resolution Response- und Relaying-Angriff)
- Netzwerkweites Erzwingen von SMB-Signing (Schutz vor Relaying-Angriff)
SMB-Signing per GPO erzwingen
Die SMB-Signierung kann relativ einfach per GPO auf Server und Clients erzwungen werden. Der Angreifer kann ziemlich einfach herausfinden, ob sein eigentliches Ziel SMB-Signing erzwungen hat oder nicht:
sudo apt install nmap
nmap -p 445 --script smb2-security-mode 192.168.0.204/32
Wenn das SMB-Signing zwar aktiviert, aber nicht erzwungen ist, kann ein Angreifer das SMB-Protokoll für seinen Relaying-Angriff ausnutzen. Denn wenn das Signing nicht erzwungen ist, reicht es wenn ein Kommunikationspartner SMB-Signing nicht unterstützt, damit auf SMB-Signing verzichtet wird.
Die entsprechende GPO für das SMB-Signing ist in folgendem Pfad zu finden: Computerkonfiguration -> Richtlinien -> Windows-Einstellungen -> Sicherheitseinstellungen -> Lokale Richtlinien -> Sicherheitsoptionen.
Dort sind die beiden Richtlinien "Microsoft-Netzwerk (Client): Kommunikation digital signieren (immer)" und "Microsoft-Netzwerk (Server): Kommunikation digital signieren (immer)" zu aktivieren:
Prüfen, dass die neue GPO erfolgreich verteilt wurde und funktioniert, lässt sich wie folgt:
LLMNR per GPO deaktivieren
LLMNR lässt sich relativ einfach per GPO deaktivieren. Die entsprechende GPO ist in folgendem Pfad zu finden: Computerkonfiguration > Richtlinien > Administrative Vorlagen > Netzwerk > DNS-Client. Die Richtlinie heißt "Multicastnamensauflösung deaktivieren" und ist entsprechend zu aktivieren:
Dass die GPO angewendet wurde, lässt sich in der Registry feststellen. Der DWORD-Wert "EnableMulticast" unter "HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows NT\DNSClient" sollte jetzt auf "0" stehen.
Die eigentliche Sicherheitslücke ist allerdings noch nicht geschlossen. Auf dem Angreifer-PC sehen wir, dass zwar keine LLMNR-Pakete mehr empfangen werden, aber immer noch NBT-NS-Anfragen verschickt werden, was der Angreifer ausnutzen kann, um sich als "gibtesnicht" auszugeben:
Es reicht also nicht LLMNR zu deaktivieren. Es muss ebenfalls NBT-NS deaktiviert werden.
NBT-NS deaktivieren
NBT-NS ist nicht ganz so einfach zu deaktivieren wie LLMNR, weil es keine vorgefertigte GPO dafür gibt. Dennoch möchte ich einen Weg zeigen, der meiner Meinung nach auch akzeptabel ist.
In den erweiterten Eigenschaften der TCP/IP-Einstellungen im Netzwerkadapter ist die entsprechende NBT-NS-Einstellung zu finden:
Der dazugehörige Wert wird windowstypisch in der Registry gespeichert. Im Pfad "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NetBT\Parameters\Interfaces" befindet sich für jedes Netzwerkinterface ein Unterordner im Format Tcpip_INTERFACEID. In diesen Schlüsseln befinden sich wiederum die gesuchten Einträge "NetbiosOptions".
Der Eintrag "NetbiosOptions" kann drei Zustände haben:
- 0 NetBIOS-Einstellung werden vom DHCP-Server entgegengenommen. Als Fallback (z.B. wenn der DHCP-Server keine NetBIOS-Einstellung übermittelt oder eine statische IP-Adresse konfiguriert wurde) wird NetBIOS aktiviert.
- 1 NetBIOS ist aktiviert.
- 2 NetBIOS ist deaktiviert.
Meine Lösung zur Deaktivierung von NetBIOS sieht wie folgt aus: Per DHCP-Option NetBIOS deaktivieren und zusätzlich ein Skript erstellen und per GPO verteilen, welches NetBIOS deaktiviert. Dadurch sind alle DHCP-Clients, unabhängig von der Domänenmitgliedschaft, und alle Domänenmitglieder berücksichtigt.
NBT-NS per DHCP-Option deaktivieren
Auf dem DHCP-Server muss die Konfiguration "001 Microsoft NetBIOS-Deaktivierungsoption" aktiviert und auf "0x2" gesetzt werden:
NBT-NS per Skript deaktivieren
Da in einem Netzwerk in der Regel nicht alle Geräte ihre IP-Konfiguration über einen DHCP-Server beziehen, erstelle ich zusätzlich ein Skript, welches ich per GPO verteile.
Zuerst erstelle ich ein neues Skript "nbt-ns-deaktivieren.cmd" in der NETLOGON-Freigabe (C:\Windows\SYSVOL\sysvol\DOMAIN\scripts) auf dem Domänencontroller mit folgendem Inhalt:
wmic nicconfig where (TcpipNetbiosOptions!=Null and TcpipNetbiosOptions!=2) call SetTcpipNetbios 2
Die GPO, mit der das Skript schließlich verteilt wird, ist unter folgendem Pfad zu finden: Computerkonfiguration > Richtlinien > Windows-Einstellungen > Skripts (Start/Herunterfahren). Dort kann per Doppelklick auf "Starten" das Skript entsprechend ausgewählt werden:
Das Skript setzt schließlich bei allen aktiven Netzwerkadaptern den Wert für "NetbiosOptions" in der Registry auf "2".
Verifizieren, dass LLMNR und NBT-NS deaktiviert ist
Ist LLMNR und NetBIOS deaktiviert, ist auch der Ping von Peter nicht mehr erfolgreich (Am Anfang des Artikels wurde der Ping noch vom Angreifer beantwortet). Außerdem werden keine LLMNR und NBT-NS-Pakete mehr versendet:
Damit ist die Sicherheitslücke, die mit LLMNR und NBT-NS einherkommt, vollständig geschlossen.
Weiterführende Links
https://en.hackndo.com/ntlm-relay/
Quellen
https://www.terreactive.ch/de/cyber_blog/rattenfaenger-im-netz-ntlm-relaying-angriff
https://www.crowe.com/cybersecurity-watch/netbios-llmnr-giving-away-credentials
https://infinitelogins.com/2020/11/23/disabling-llmnr-in-your-network/
https://infinitelogins.com/2020/02/11/abusing-llmnr-nbtns-part-1-capturing-hashes/
https://infinitelogins.com/2020/04/16/abusing-llmnr-nbtns-part-2-cracking-ntlmv2-hashes/
https://infinitelogins.com/2020/11/13/abusing-llmnr-nbtns-part-3-relaying-hashes/
https://www.tenaka.net/smb-relay-attack
https://docs.microsoft.com/de-de/troubleshoot/windows-server/networking/disable-netbios-tcp-ip-using-dhcp