LLMNR – das oft vergessene Einfallstor ins Netzwerk

Ein Artikel von IT Security Consultant Florian Kock

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 Si­cher­heits­me­cha­nis­men enthält, lässt es sich sehr leicht für Angriffe missbrauchen. Wie ein sol­cher Angriff aussieht und was die Konsequenzen sein können, wird weiter unten be­schrie­ben. 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 Ver­gang­en­heit den Dienst nicht explizit ausgeschaltet hat, findet in seinem Netzwerk höchst­wahr­schein­lich noch immer LLMNR-Pakete.

Viele Firmen verwenden noch immer Windows 10-Versionen in ihren Netzwerken (ich stoße in Pe­ne­tra­tions­tests 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 Com­pu­ter zunächst im lokalen Netzwerk, ob der Host mit dem Namen XY bekannt ist. Dies geschieht nor­ma­ler­wei­se ü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ämt­li­che 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 Do­mä­nen­in­for­ma­tion­en 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?

  1. LLMNR und NBT-NS auf allen Geräten deaktivieren (z. B. via Group Policy).
  2. Starke Passwörter oder besser Passphrasen verwenden.
  3. Wo es möglich ist, Verschlüsselung verwenden (z. B. HTTPS statt HTTP, SMB Signing erzwingen).
  4. Netzwerksegmentierung: Server und Clients in separaten Subnetzen organisieren.

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.

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