Das Link-Local Multicast Name Resolution (LLMNR)-Protokoll begleitet die Windows-Welt seit 2007, als Microsoft es im Request for Comments (RFC) 4795 veröffentlichte. LLMNR dient zur Namensauflösung in lokalen Netzwerken, wenn kein Domain Name System (DNS) vorhanden ist – was heutzutage so gut wie nie vorkommt. Da LLMNR keine Sicherheitsmechanismen enthält, lässt es sich sehr leicht für Angriffe missbrauchen. Wie ein solcher Angriff aussieht und was die Konsequenzen sein können, wird weiter unten beschrieben. Aber warum kümmern wir uns überhaupt im Jahr 2024 um einen Dienst aus dem Jahr 2007, wenn er gar nicht mehr benötigt wird? In allen Windows-Versionen seit der Einführung von LLMNR hatte Microsoft den Dienst standardmäßig aktiviert. Erst in Windows 11 ist dies nicht mehr der Fall und der Dienst ist standardmäßig deaktiviert. Wer also in der Vergangenheit den Dienst nicht explizit ausgeschaltet hat, findet in seinem Netzwerk höchstwahrscheinlich noch immer LLMNR-Pakete.
Viele Firmen verwenden noch immer Windows 10-Versionen in ihren Netzwerken (ich stoße in Penetrationstests sogar immer noch auf Windows 7!). Wir können also davon ausgehen, dass wir noch eine ganze Zeit mit Windows 10-Systemen in lokalen Netzwerken zu tun haben werden. Dementsprechend ist zu erwarten, dass auch in den nächsten Jahren noch sehr viele Netzwerke existieren werden, in denen LLMNR Verwendung findet.
Was ist aber nun so schlimm an LLMNR? Wie gesagt, dient LLMNR der Namensauflösung im lokalen Netzwerk. Wenn ein Dienst irgendeinen anderen Netzwerkdienst kontaktieren möchte, fragt der Computer zunächst im lokalen Netzwerk, ob der Host mit dem Namen XY bekannt ist. Dies geschieht normalerweise über DNS. Wenn DNS den Host aber nicht kennt (z. B. bei einem Tippfehler), wird auf LLMNR zurückgegriffen. Darüber hinaus haben Angreifer weitere Möglichkeiten, Anfragen auf das eigene Gerät umzuleiten. Wer neugierig ist, kann ja mal mit dem Tool „Wireshark“ den Netzwerkverkehr mitlesen – aber Vorsicht! Nicht jede Firma sieht es gern, wenn Wireshark auf Arbeitsplatz-PCs ausgeführt wird. Daher ist es vielleicht besser, diesen Versuch im Heimnetzwerk durchzuführen. Ein Angreifer könnte nun also diese LLMNR-Anfrage mit seiner eigenen IP-Adresse beantworten, in der Hoffnung, dass der fremde Computer die nächsten Anfragen an ihn anstatt des eigentlichen Computers sendet.
Interessant wird das Beantworten der LLMNR-Anfragen bei Autorisierungsanfragen, etwa für SMB-Freigaben. Ein Angreifer kann sich im Netzwerk platzieren und nach LLMNR-Anfragen lauschen. Da es sich um einen Broadcast handelt, empfangen alle Geräte im Netzwerk(-segment) den Broadcast. Ein Angreifer kann nun sämtliche Anfragen mit seiner eigenen IP beantworten. Akzeptiert der anfragende Computer die Antwort, werden die folgenden Authentisierungsanfragen an den Angreifer gesendet. Besonders gut lässt sich dies bei SMB-Anfragen anwenden, wenn kein SMB Signing verwendet wird (sog. Relay-Angriffe).
Der Angreifer erhält so den NetNTLMv2-Hash des Nutzers, der sich am Netzlaufwerk anmelden wollte. Zwar kann der NetNTLMv2-Hash nicht für Pass-the-Hash-Angriffe genutzt werden, der Angreifer kann aber versuchen, den Hash mit Tools wie „John the Ripper“ oder „hashcat“ zu cracken. Besonders lohnend wird dies, wenn es sich um einen Administratoraccount handelt und dieser kein wirklich starkes Passwort verwendet. Sobald das Passwort geknackt wurde, kann der Angreifer ein valides Konto verwenden, um sich im Netzwerk weiter auszubreiten. Zu beachten ist, dass der Angreifer weder Nutzernamen noch Passwörter kannte. Allein dadurch, dass im Netzwerk LLMNR verwendet wurde, sind nun bereits die ersten Nutzer und Systeme kompromittiert. Wenn es sich bei dem erlangten Nutzerkonto um ein Domänenkonto handelt, kann der Angreifer dieses Konto verwenden, um als authentifizierter Nutzer nun sämtliche Domäneninformationen abzufragen. Dazu zählt unter anderem die vollständige Liste aller Nutzerkonten. Diese Nutzernamen können anschließend für weitere Angriffe verwendet werden, z. B. gezieltes Phishing oder Password Spraying.
Wie kann man sich also dagegen schützen?
Und sollte es Geräte geben, die auch bei einem Ausfall des DNS-Servers auf die Namensauflösung angewiesen sind, könnte bei diesen Geräten die lokale Hosts-Datei genutzt werden.
18.02.2025
- 20.02.2025
Hack3: Angriffe auf Windows-basierte Netzwerke
25.02.2025
- 26.02.2025
Hack5: Exploit Development
03.03.2025
- 04.03.2025
Hack8: WLAN Hacking und WLAN Security
04.03.2025
Awe2: Phishing Awareness
Ihr direkter Kontakt zu SySS +49 (0)7071 - 40 78 56-0 oder anfrage@syss.de | IN DRINGENDEN FÄLLEN AUSSERHALB DER GESCHÄFTSZEITEN +49 (0)7071 - 40 78 56-99
Als Rahmenvertragskunde wählen Sie bitte die bereitgestellte Rufbereitschaftsnummer
Ihr direkter Kontakt zu SySS +49 (0)7071 - 40 78 56-0 oder anfrage@syss.de
IN DRINGENDEN FÄLLEN AUSSERHALB DER GESCHÄFTSZEITEN +49 (0)7071 - 40 78 56-99
Als Rahmenvertragskunde wählen Sie bitte die bereitgestellte Rufbereitschaftsnummer
Direkter Kontakt
+49 (0)7071 - 40 78 56-0 oder anfrage@syss.de
IN DRINGENDEN FÄLLEN AUSSERHALB DER GESCHÄFTSZEITEN
+49 (0)7071 - 40 78 56-99
Als Rahmenvertragskunde wählen Sie bitte die bereitgestellte Rufbereitschaftsnummer