mitm6: Wenn aktiv gelassenes IPv6 die Tür zum Active Directory öffnet

Bei internen Audits zeigt sich immer wieder dasselbe Bild: ein Netzwerk, in dem auf IPv4-Seite alles sauber wirkt, Firewalls vorhanden, VLANs segmentiert, Patches eingespielt. Und dennoch kann ein einziger Arbeitsplatz genügen, um die gesamte Domäne in weniger als einer Stunde zu übernehmen. Zu den unauffälligsten Einfallstoren gehört in diesem Fall ein Protokoll, das kaum jemand überwacht: IPv6, unter Windows standardmäßig aktiviert und unkonfiguriert gelassen. Dieser Artikel beschreibt den mitm6-Angriff Schritt für Schritt, samt dem Kontext, der erklärt, warum er Jahre nach seiner Veröffentlichung noch immer so wirksam ist.

IPv6: das Protokoll, das niemand konfiguriert

Seit Windows Vista ist IPv6 auf allen Arbeitsplätzen und Servern standardmäßig aktiv. Mehr noch (oder schlimmer, je nach Sichtweise): Der Netzwerkstack von Windows bevorzugt IPv6 gegenüber IPv4. Diese Präferenz ist keineswegs willkürlich, sie ergibt sich aus RFC 6724, die die Reihenfolge der Adressauswahl festlegt. Konkret sendet ein Rechner beim Start oder bei der Erneuerung seiner Konfiguration Anfragen aus, um einen Router und einen Adressserver zu finden: Router Solicitation-Nachrichten und DHCPv6-Anfragen. In nahezu allen Unternehmensnetzen antwortet niemand, weil nie ein IPv6-Dienst bereitgestellt wurde. Der Rechner wartet also, ohne IPv6-Gateway und ohne IPv6-DNS-Server, bis eines Tages ein Angreifer nur zu gern beides liefert.

Zur Erinnerung: Ein DNS-Server übersetzt lesbare Namen (wie fichiers.entreprise.local) in Netzwerkadressen. Wer den DNS eines Rechners kontrolliert, kontrolliert weitgehend, was dieser kontaktiert, und kann ihn somit zu Servern seiner Wahl umleiten.

Diese Situation, ein eingeschaltetes, aber nie verwaltetes Protokoll, schafft genau das Vakuum, das ein Eindringling füllt. Die dem Angriff zugrunde liegende Forschung, veröffentlicht von dem Sicherheitsforscher Dirk-jan Mollema, hat gezeigt, dass es genügt, höflich auf diese Anfragen zu antworten, um einen bösartigen Rechner mitten in die Kommunikation einzuschleusen.

mitm6: sich als DNS ausgeben

Das Tool mitm6 lauscht im Netzwerksegment und beantwortet diese unbeantwortet gebliebenen Anfragen. Es weist dem Windows-Rechner eine IPv6-Adresse zu und meldet sich vor allem per DHCPv6-Antwort als dessen IPv6-DNS-Server an. Da Windows IPv6 bevorzugt, schwenkt der Rechner sofort um: Er schickt seine Namensauflösungen fortan an den Angreifer statt an den legitimen DNS der Domäne.

mitm6 -d entreprise.local

Die Option -d beschränkt das Poisoning auf die Zieldomäne, um unauffällig zu bleiben und nicht das gesamte Netz zu stören. Von da an beantwortet der Angreifer die Auflösungen mit eigenen Adressen und fängt die automatischen Authentifizierungen ab, die Windows ständig an interne Server sendet, ohne jedes Zutun des Benutzers.

WPAD: der Komplize, der die Authentifizierung auslöst

Bleibt noch, eine verwertbare Authentifizierung zu provozieren. Hier kommt WPAD (Web Proxy Auto-Discovery) ins Spiel, ein Mechanismus, mit dem Browser und zahlreiche Windows-Komponenten automatisch nach einer Proxy-Konfigurationsdatei im Netz suchen. mitm6 beantwortet die Anfrage nach wpad, liefert eine gefälschte Konfigurationsdatei, und der Rechner versucht daraufhin, sich beim bösartigen Proxy zu authentifizieren. Windows sendet von sich aus die Identität des angemeldeten Benutzers in Form einer NTLM-Authentifizierung, ohne je um Bestätigung zu bitten.

Kurz gesagt: Der Benutzer klickt nichts an und gibt kein Passwort ein. Sein Rechner bietet seine Identität von selbst dem ersten Server an, der höflich danach fragt.

NTLM-Relay: vom Mithören zur Übernahme

DNS abzufangen und eine Authentifizierung einzusammeln reicht noch nicht aus. Der zweite und entscheidende Baustein ist das NTLM-Relay, umgesetzt mit ntlmrelayx, einem Tool der Impacket-Suite. Das Prinzip ist elegant und gefährlich zugleich: Statt ein Passwort zu knacken, leitet der Angreifer die empfangene Authentifizierung unverändert an einen Dienst des Active Directory weiter, typischerweise an das LDAP eines Domänencontrollers. Diese Weiterleitung ist allerdings nur möglich, wenn der Zieldienst keine Signierung seiner Kommunikation erzwingt: Ohne LDAP-Signierung (oder SMB-Signierung) bindet nichts die Authentifizierung an den legitimen Server, und der Angreifer kann sie anderswo wiederverwenden. Ein kommender Artikel widmet sich diesen Signierungsmechanismen und der Art, wie sie NTLM-Relay unterbinden.

ntlmrelayx.py -6 -t ldaps://dc.entreprise.local -wh attaquant-wpad --delegate-access

Kurz gesagt: Der Zielrechner glaubt, mit einem legitimen Server zu sprechen, spricht in Wirklichkeit aber mit dem Angreifer, der diese Identität sofort gegenüber dem Verzeichnis wiederverwendet, mit allen damit verbundenen Rechten.

Je nach den Privilegien der weitergeleiteten Identität steigt die Tragweite:

• das gesamte Active-Directory-Verzeichnis auslesen, einschließlich der Übersicht über Gruppen und Administratoren;
• ein neues Computer- oder Benutzerkonto anlegen, das vollständig vom Angreifer kontrolliert wird;
• eine Delegierung von Rechten einrichten (über das Attribut msDS-AllowedToActOnBehalfOfOtherIdentity), die es erlaubt, sich als andere Konten auszugeben, mitunter bis hin zum Domänenadministrator.

Und das alles, ohne eine einzige Softwareschwachstelle auszunutzen: ausschließlich native Windows-Funktionen, die zweckentfremdet werden. Kein Sicherheitspatch „repariert“ dieses Verhalten, denn es handelt sich um eine vorgesehene Funktionsweise des Protokolls.

Wie der Angriff bei einem internen Audit abläuft

Im Rahmen eines internen Audits verläuft dieser IPv6-Angriff fast immer gleich. Ein Rechner wird an eine Netzwerkdose in einem offenen Arbeitsbereich angeschlossen, häufig in einem frei zugänglichen Besprechungsraum. mitm6 startet, und innerhalb weniger Minuten stellen die ersten Rechner, die gerade hochfahren oder aus dem Ruhezustand erwachen, ihren DNS um. ntlmrelayx sammelt die eingehenden Authentifizierungen und leitet sie an einen Domänencontroller weiter. Gehört auch nur eine dieser Authentifizierungen zu einem Konto mit Schreibrechten auf das Verzeichnis, ist die Partie entschieden: genug, um ein Konto anzulegen, eine Delegierung einzurichten und sich Schritt für Schritt bis zu den Administrationsrechten der Domäne hochzuarbeiten. Aus Sicht des Benutzers bleibt alles passiv, er arbeitet weiter, ohne etwas zu bemerken.

Die geschäftlichen Auswirkungen sind entsprechend: Die Kompromittierung eines Domänencontrollers bedeutet die Kontrolle über die Zugänge der gesamten Organisation, die Möglichkeit, Dateifreigaben zu lesen, Ransomware in großem Maßstab zu verteilen oder Daten zu exfiltrieren. Eine schlecht segmentierte Netzwerkdose in einem Empfangsbereich wird so zum Ausgangspunkt eines schwerwiegenden Vorfalls.

Den Angriff im Netzwerk erkennen

Diese Vorgänge hinterlassen charakteristische Spuren: ein Rechner, der plötzlich IPv6-Konfigurationen verteilt, unerwartete Router Advertisements, das Auftauchen eines DHCPv6-Servers, wo es nie einen gab, eine Flut von Authentifizierungen, die an die Domänencontroller weitergeleitet werden. Die Oxyscan BOX überwacht diese Signale direkt im Netzwerk und meldet das Auftauchen eines unrechtmäßigen DHCPv6- oder IPv6-DNS-Servers, ein starkes Indiz dafür, dass ein Angriff vom Typ mitm6 läuft. Im Dauerbetrieb eingesetzt, ermöglicht sie es, im gesamten Bestand die Rechner zu identifizieren, die für diese Art des Abfangens anfällig sind. Wer diese Vorbereitungsphase früh erkennt, unterbricht den Angriff vor dem ersten erfolgreichen Relay.

Im Netzwerk sind diese Nachrichten im Mitschnitt sichtbar: Sobald das Tool aktiv wird, häufen sich Router Advertisements und Neighbor Solicitations über ICMPv6.

Die Schwachstelle beheben: IPv6 neutralisieren, ohne es abzuschalten

Die erste Reaktion, IPv6 einfach komplett abzuschalten, ist selten die richtige. Microsoft rät von dieser vollständigen Deaktivierung ab, da Windows mit aktivem IPv6 getestet wird und manche Komponenten (Exchange, Failovercluster) sich ohne IPv6 fehlerhaft verhalten können. Ziel ist also nicht, IPv6 zu entfernen, sondern zu verhindern, dass ein Rechner eine von einem Unbekannten verteilte IPv6-Konfiguration übernimmt.

Die sauberste Maßnahme besteht darin, über die Windows-Firewall, per GPO in der gesamten Domäne ausgerollt, die beiden Bausteine zu blockieren, die der Angriff benötigt: DHCPv6-Antworten und Router Advertisements. Drei vordefinierte Regeln werden auf Blockieren gesetzt:

• (Eingehend) Core Networking, Dynamic Host Configuration Protocol for IPv6 (DHCPV6-In), UDP-Port 546;
• (Eingehend) Core Networking, Router Advertisement (ICMPv6-In), ICMPv6-Typ 134;
• (Ausgehend) Core Networking, Dynamic Host Configuration Protocol for IPv6 (DHCPV6-Out).

Diese Konfiguration neutralisiert den Angriff und behält zugleich die Link-Local-IPv6-Adressen bei, sie hat also keine Nebenwirkungen auf die Windows-Komponenten.

Auf Netzwerkseite ergänzen die Funktionen RA Guard und DHCPv6 Guard auf den Switches den Schutz: Sie blockieren am Rand Router Advertisements und DHCPv6-Antworten, die von einem nicht autorisierten Port stammen, und schützen auch Linux- und macOS-Rechner, die von der Windows-Härtung nicht erfasst werden. Auf diesen Systemen lassen sich Router Advertisements zudem lokal ablehnen (zum Beispiel sysctl net.ipv6.conf.all.accept_ra=0 unter Linux).

Eine Variante besteht darin, IPv4 gegenüber IPv6 zu priorisieren, wodurch die vom Angreifer verteilte Konfiguration ihren Vorrang vor der legitimen Konfiguration verliert. Auch diese Einstellung wird per GPO ausgerollt, über eine Registrierungseinstellung:

HKLM\SYSTEM\CurrentControlSet\Services\Tcpip6\Parameters
DisabledComponents = 0x20 (DWORD 32 Bit)

Nur als letztes Mittel, falls eine interne Richtlinie die vollständige Deaktivierung von IPv6 vorschreibt, erfolgt diese per PowerShell auf jedem Rechner. Mit derselben Befehlsfamilie lässt sich übrigens der Zustand des Protokolls auf den Netzwerkadaptern überprüfen:

Disable-NetAdapterBinding -Name "*" -ComponentID ms_tcpip6

Diese Methode erfasst allerdings nur die vorhandenen Netzwerkadapter und lässt sich, anders als die beiden vorherigen, nicht nativ per GPO ausrollen. Unabhängig von der gewählten Option bleiben schließlich SMB-Signierung, LDAP-Signierung und LDAP Channel Binding unverzichtbar: Selbst wenn ein Rechner in die Falle ginge, verhindern diese Schutzmechanismen die Wiederverwendung der abgefangenen Authentifizierung und damit das Relay, das den eigentlichen Reiz des Angriffs ausmacht.

Fazit

mitm6 veranschaulicht ein Prinzip, das sich bei jedem Einsatz bestätigt: Eine standardmäßig aktivierte und nie konfigurierte Funktion ist eine vollwertige Angriffsfläche. IPv6 ist an sich nicht gefährlich, gefährlich ist, es sich selbst zu überlassen. Einige gezielte Maßnahmen schließen die Lücke, ohne Bestehendes zu beeinträchtigen, und die meisten davon empfiehlt die ANSSI seit Langem in ihren Leitfäden zur Härtung des Active Directory.

Empfehlungen: IPv6 auf Arbeitsplätzen nur deaktivieren, wenn es nicht genutzt wird (und sauber per Gruppenrichtlinie statt durch improvisierte Eingriffe), DHCPv6 Guard und RA Guard auf den Switches aktivieren, um bösartige Ankündigungen zu blockieren, LDAP-Signierung sowie Channel Binding (Extended Protection for Authentication) auf den Domänencontrollern erzwingen, um jedes Relay wirkungslos zu machen, und öffentlich zugängliche Netzwerkdosen segmentieren.

Weiterführende Informationen

• Cybersicherheitsberatung und Begleitung durch Oxydian, um die Gegenmaßnahmen (RA Guard, DHCPv6 Guard, SMB- und LDAP-Signierung) umzusetzen, ohne Bestehendes zu beeinträchtigen.
• Der Artikel über Kerberoasting, bei dem das Offline-Cracking auf die Dienstkonten des Active Directory zielt.
• MITRE ATT&CK, Technik T1557 (Adversary-in-the-Middle), die Referenz, die Abfang- und Relay-Angriffe klassifiziert und dokumentiert.
• ANSSI, Leitfäden zur Absicherung von Active Directory und zur Härtung von Windows.
• Projekt mitm6 von Dirk-jan Mollema, die Forschung und das Tool, auf die die Technik zurückgeht.
• Impacket-Suite (ntlmrelayx), der Open-Source-Werkzeugkasten für NTLM-Relay.
• Microsoft Learn, LDAP-Signierung auf den Domänencontrollern aktivieren.