Schlagwort: Active Directory

12. Oktober 202612. Oktober 2026Allgemein, Netzwerk, Security Engineering

DHCPv6-Spoofing verhindern: IPv6-Sicherheit im Netzwerk

In internen Penetrationstests beobachten wir regelmäßig, dass Clients und Server IPv6 standardmäßig aktiviert haben, ohne dass der Einsatz bewusst geplant oder abgesichert wurde. Daraus entsteht ein Sicherheitsproblem: Ein Angreifer im selben Netzwerksegment kann über DHCPv6-Spoofing oder bösartige Router Advertisements (RA) Einfluss auf die IPv6- und DNS-Konfiguration von Systemen nehmen. Besonders relevant ist das in Windows- und Active-Directory-Umgebungen. Dort führt ein Manipulation der IPv6-Konfiguration dazu, das angegriffene Systeme einen vom Angreifer kontrollierten DNS-Server verwenden und deren Netzwerkverkehr beliebig umgeleitet werden kann. Auf diese Weise lassen sich Verbindungen abhören und sensible Daten, wie Klartext-Passwörter und Hashes, mitlesen. Diese ermöglichen wiederum die Kompromittierung konkreter Systeme und Dienste.

Was ist DHCPv6-Spoofing?

Beim DHCPv6-Spoofing gibt sich ein Angreifer im lokalen Netzsegment als DHCPv6-Server aus und verteilt manipulierte IPv6-Konfigurationen an andere Systeme. Da DHCPv6 für diesen Anwendungsfall keine eingebaute Authentisierung bietet, akzeptieren Systeme die empfangenen Konfigurationsdaten zunächst ohne weitere Prüfung. Ein typisches Ziel ist es, Systemen einen vom Angreifer kontrollierten DNS-Server zuzuweisen. Nutzt ein System anschließend diesen DNS-Server, kann der Angreifer die Namensauflösung beeinflussen und Verbindungen gezielt auf eigene Systeme umleiten. Häufig wird dazu das Tool mitm6 verwendet [1].

Die folgende Grafik veranschaulicht den Ablauf des Angriffs:

Welche Rolle spielen Router Advertisements?

Router Advertisements sind ICMPv6-Nachrichten, die von IPv6-Routern im lokalen Netzsegment versendet werden, um Systemen Konfigurationsinformationen wie Präfixe, DNS-Server oder ein Default Gateway mitzuteilen.

Auch wenn DHCPv6 im Netz unterbunden wird, etwa per Host-Firewall, bleiben Angriffe über Router Advertisements weiterhin möglich. In diesem Fall gibt sich der Angreifer als IPv6-Router aus und versendet Router Advertisements, über die Systeme ebenfalls konfiguriert werden können. ICMPv6 bietet hier, genauso wie DHCPv6, keine eingebaute Authentisierung, sodass Systeme die empfangenen Konfigurationsdaten zunächst ohne weitere Prüfung akzeptieren. Auf diese Weise kann Systemen ebenfalls ein bösartiger DNS-Server zugewiesen werden. Darüber hinaus ist es möglich, ein vom Angreifer kontrolliertes System als Default Gateway zu platzieren und so Netzwerkverkehr umzuleiten.

Warum greifen die manipulierten Konfigurationen?

Ist auf einem Client keine IPv6-Konfiguration vorhanden, liefert der Angreifer die erste und einzige IPv6-Konfiguration. Windows präferiert diese standardmäßig gegenüber IPv4. Bei Linux-Systemen hängt das Standardverhalten von der Distribution ab.

Ist bereits eine legitime IPv6-Konfiguration vorhanden und in Nutzung, akzeptieren Systeme dennoch zusätzliche oder konkurrierende Konfigurationsdaten, zum Beispiel weitere DNS-Server. In beiden Fällen ist es also möglich, manipulierte Konfigurationen einzuschleusen, die dann vom System für die weitere Kommunikation genutzt werden. Ausnahmen bestehen zwar, aber darauf kann sich nicht verlassen werden.

Auswirkungen der Angriffe

Über die beschriebenen Angriffe kann ein Angreifer eine Machine-in-the-Middle-Position erreichen oder Folgeangriffe ermöglichen.

Windows

Im Active-Directory-Kontext kann ein Angreifer, das Routing von Windows-Systemen über sein System leiten und dabei die NTLM-Hashes von Authentisierungsanfragen abfangen oder umleiten. Diese lassen sich je nach Szenario für weiterführende Angriffe, etwa Brute-Force- oder Relay-Angriffe, missbrauchen. Im schlimmsten Fall kann das zur Übernahme des betroffenen Benutzer- oder Computerkontos führen.

Linux

Linux-Systeme verhalten sich je nach Distribution, Netzwerk-Stack und Konfiguration teilweise anders als Windows. Insbesondere die Verarbeitung von DHCPv6 und Router Advertisements ist nicht einheitlich. Die genaue Anfälligkeit hängt daher stark vom jeweiligen Setup ab. Relevant bleibt das Thema dennoch auch hier, da Angreifer je nach Konfiguration Einfluss auf DNS, Routing oder die allgemeine Netzwerkkommunikation nehmen können.

Empfehlung

Mithilfe der folgenden Maßnahmen lassen sich DHCPv6-Spoofing und Rogue Router Advertisement Angriffe verhindern. Wurde bisher keine der nachfolgend genannten Maßnahmen umgesetzt, ist das Netzwerk mit hoher Wahrscheinlichkeit für die beschriebenen Angriffe anfällig.

RA Guard und DHCPv6 Guard aktivieren

Das Aktivieren von RA Guard und DHCPv6 Guard auf allen Switches schützt die Systeme im Netzwerk unabhängig ihres Betriebssystems und wird deshalb als primäre Maßnahme empfohlen. Beide Funktionen sind bei vielen aktuellen, gemanagten Switches verfügbar. Die Grundidee ist, dass DHCPv6-Nachrichten und Router Advertisements nur auf vertrauenswürdigen Ports akzeptiert und auf allen anderen Ports verworfen werden.

Dazu werden ausschließlich Ports zu legitimen Netzwerkkomponenten als vertrauenswürdig markiert. Alle übrigen Ports werden so eingeschränkt, dass von dort keine DHCPv6- oder RA-Nachrichten an andere Systeme weitergegeben werden. Sendet ein Angreifer auf einem solchen Port bösartige Nachrichten, verwirft der Switch diese, bevor andere Geräte sie verarbeiten können. Die genaue Umsetzung hängt vom Switch-Hersteller und Modell ab. Wir empfehlen daher, die Konfiguration nach der Aktivierung nicht nur zu prüfen, sondern auch praktisch zu testen.

DHCPv6 und Router Discovery deaktivieren

Wenn eine Umsetzung von RA Guard und DHCPv6 Guard nicht möglich ist, sollten DHCPv6 und Router Discovery direkt auf den Client- und Server-Systemen deaktiviert werden. Damit werden die hier beschriebenen Angriffswege unterbunden. Wichtig ist jedoch: Wird nur einer der beiden Mechanismen deaktiviert, bleibt der jeweils andere Angriffsweg weiterhin bestehen.

Um DHCPv6 und Router Discovery auf allen Interfaces eines Windows-Systems zu deaktivieren, kann der folgende PowerShell-Befehl verwendet werden:

Set-NetIPInterface -AddressFamily IPv6 -InterfaceIndex $(Get-NetIPInterface -AddressFamily IPv6 | Select-Object -ExpandProperty InterfaceIndex) -Dhcp Disabled -RouterDiscovery Disabled

Auf Systemen, die IPv6 auf bestimmten Interfaces benötigen, sollte die Konfiguration gezielt pro Interface erfolgen. Im oben genannten Befehl wird dazu als Wert des Parameters „`-InterfaceIndex„` das konkrete Interface angegeben.

Unter Linux kann Router Discovery wie folgt deaktiviert werden:

sysctl -w net.ipv6.conf.all.accept_ra=0
sysctl -w net.ipv6.conf.default.accept_ra=0

Auch hier kann Router Discovery auf einzelnen Interfaces erlaubt werden, wenn dies benötigt wird. Dafür kann zusätzlich zu den oben genannten Befehlen accept_ra für einzelne Interfaces auf 1 gesetzt werden.

Der konkrete Befehl zum Deaktivieren von DHCPv6 unter Linux unterscheidet sich je nach Distribution. Entsprechend können wir hier keinen allgemeingültigen Befehl zeigen.

Nicht empfohlene Maßnahmen

Einige Maßnahmen wirken auf den ersten Blick sinnvoll, bieten in der Praxis aber keinen wirksamen Schutz vor den beschriebenen Angriffen.

IPv6 deaktivieren

Das vollständige Deaktivieren von IPv6 ist zwar eine wirksame Maßnahme, wird aber nicht generell empfohlen. Microsoft rät für Windows explizit davon ab [2]. Auch unter Linux ist es sinnvoller, gezielt DHCPv6 und Router Discovery zu deaktivieren oder die Angriffsfläche netzwerkseitig über Guard-Funktionen zu begrenzen.

Präferenz von IPv6 gegenüber IPv4 ändern

Auf Windows Systemen gibt es einen Registry-Eintrag, der die Präferenz von IPv6 gegenüber IPv4 steuert [3]. Naheliegend wäre die Annahme, dass ein Angriff dadurch wirkungslos wird, weil bevorzugt der bereits konfigurierte IPv4-DNS-Server genutzt wird. In praktischen Tests hat sich das jedoch nicht bestätigt. Diese Einstellung ist daher keine wirksame Gegenmaßnahme.

Autorisierte DHCP-Server

Im Active Directory gibt es das Konzept autorisierter DHCP-Server. Dabei handelt es sich jedoch nur um einen Mechanismus, der den versehentlichen Betrieb nicht autorisierter DHCP-Server im AD-Umfeld verhindern soll. Ein Schutz vor Rogue Router Advertisements oder einem bösartigen DHCPv6-Server im lokalen Netz lässt sich damit nicht erreichen.

Bereits ausgerollte IPv6-Konfiguration

Eine bereits vorhandene oder regulär ausgerollte IPv6-Konfiguration ist für sich genommen keine wirksame Gegenmaßnahme. Systeme warten weiterhin auf Router Advertisements und verarbeiten – abhängig von Betriebssystem und Konfiguration – auch zusätzliche DHCPv6-Informationen. Dadurch können später empfangene, bösartige Konfigurationsdaten weiterhin Auswirkungen auf DNS, Routing oder die genutzten Kommunikationswege haben.

Fazit

Unzureichend abgesichertes IPv6 stellt einen relevanten Angriffsvektor dar, den wir in Penetrationstests regelmäßig erfolgreich ausnutzen können. Ohne Schutzmechanismen auf Switch- oder Host-Ebene können Systeme unter Umständen mit wenig Aufwand dazu gebracht werden, vom Angreifer kontrollierte IPv6-Konfigurationsdaten zu übernehmen. Besonders in Windows-Domänen kann das erhebliche Auswirkungen haben, weil sich darüber Namensauflösung und Kommunikationswege beeinflussen lassen. Wer IPv6 intern nicht aktiv nutzen möchte, sollte den Protokollstack nicht einfach ignorieren, sondern gezielt absichern oder die relevanten Mechanismen deaktivieren.

Referenzen:

[1] Github-Repository des mitm6-Tools:
https://github.com/dirkjanm/mitm6

[2] Deaktivieren von IPv6 unter Microsoft Windows:
https://learn.microsoft.com/en-us/troubleshoot/windows-server/networking/configure-ipv6-in-windows#unbind-ipv6-from-an-interface

[3] „Prefer IPv4 over IPv6“-Registry-Schlüssel:
https://learn.microsoft.com/en-us/troubleshoot/windows-server/networking/configure-ipv6-in-windows#use-registry-key-to-configure-ipv6

19. September 202519. September 2025Allgemein, Passwörter

Kennwortrichtlinien im Active Directory. Ein Missverständnis mit Folgen

Das Problem

In unserer täglichen Arbeit fällt uns ein weitverbreitetes Missverständnis im Umgang mit Kennwortrichtlinien im Active Directory auf. Hier möchten wir kurz für Klarheit sorgen.

Die Standard-Kennwortrichtlinie wird immer in der Default Domain Policy definiert. Diese ist mit der Domäne verknüpft, gilt somit für alle Benutzerobjekte in der ganzen Domäne.

Es ist grundsätzlich eine gute Idee, abgestufte Kennwortrichtlinien für verschieden privilegierte Benutzertypen durchzusetzen. Nur ist das oft erwartete GPO-Verhalten hier der Ursprung des Missverständnisses. Verknüpfe ich ein Gruppenrichtlinienobjekt (Group Policy Object, GPO) mit einer Organisationseinheit (Organizational Unit, OU), dann wirken dessen Einstellungen nicht mehr domänenweit, sondern nur auf die Objekte in dieser OU. Die Annahme ist nun häufig, dass sich ein Benutzerkreis mit Objekten in einer OU so mit anderen Kennwortrichtlinien versehen lässt. Denn die Einstellungen eines mit einer OU verknüpften GPO überschreiben im Normalfall Einstellungen, die aus der Domäne nach unten vererbt werden.

Konkret wird also häufig folgendes konfiguriert: Administrative Konten werden in einer OU versammelt und mit dieser ein neues GPO, nennen wir es „KWRL-Admins“, verknüpft. Schauen wir uns das Verhalten kurz an. In der Laborumgebung haben wir in der Default Domain Policy eine Mindest-Kennwortlänge von vier Zeichen festgelegt. Das GPO „KWRL-Admins“ an einer OU „Admins“ verlangt fünf Zeichen.

Wir nehmen nun einen Benutzer in der OU und setzen dessen Kennwort auf eines mit vier Zeichen zurück. Wir erfüllen also die Default Domain Policy, nicht aber die „KWRL-Admins“. Was passiert?

Wir sehen also, dass die Kennwortrichtlinie aus dem GPO „KWRL-Admins“ keine Rolle spielt. Es bleibt bei der Grundregel: Kennworteinstellungen gelten immer domänenweit. Das oft gewählte Vorgehen, auch die Kennwörter mittels eines GPO an einer OU zu lösen, funktioniert nicht.

Die Folge des Missverständnisses ist also, dass Richtlinien im fehlgeleiteten Verständnis und guter Absicht erstellt werden, diese aber nie wirken. Weiterer Rat sollte also sein, erstellte GPO immer auf die gewünschte Wirksamkeit zu überprüfen.

Tatsächlich ist das GPO nicht nutzlos – nur bezieht es sich nicht auf Benutzerobjekte innerhalb der OU – es wirkt auf Computerobjekte in der entsprechenden OU und bestimmt dann Kennwortrichtlinien für deren lokale Benutzer. Wir verschieben also ein Computerobjekt in die OU und setzen das Kennwort eines lokalen Benutzers neu – und zwar so, dass es das GPO „KWRL-Admins“ erfüllt:

Es lässt sich zudem beobachten, dass die vom GPO vorgegeben Werte für die lokale GPO des Computers übernommen wurden:

Die Lösung

Wie aber lösen wir jetzt das Dilemma, unterschiedliche Kennwortrichtlinien für verschiedene Benutzergruppen durchzusetzen? HiSolutions empfiehlt (Stand 2025) für eingeschränkte Benutzer eine Mindestlänge von zwölf, für administrative Benutzer eine Mindestlänge von 16 und für Dienstkonten eine Mindestlänge von 24 Zeichen.

Die Lösung heißt: Finegrained Password Policies (FGPP)! Diese basieren auf einem sog. Password Setting Object (PSO) und sind bereits seit Server 2008 verfügbar. FGPP überschreiben die Einstellungen der Default Domain Policy und werden an Gruppen gebunden.

Dementsprechend könnte das Vorgehen sein, die Einstellungen für eingeschränkte Benutzerkonten weiterhin über die Default Domain Policy zu realisieren. Dann legt man Gruppen für administrative Konten und Dienstkonten an und schreibt für diese geeignete FGPP nach folgendem Muster. Entweder erledigt man das im GUI im Active-Directory-Verwaltungscenter oder über die PowerShell.

Fazit:

Die Kennwortrichtlinien aus der Default Domain Policy gelten immer domänenweit.
Kennwortrichtlinien aus GPO an OU wirken nicht auf die darin enthaltenen Domänenbenutzer, sondern nur auf darin enthaltene Computer und deren lokale Benutzer.
Verschiedene Kennwortrichtlinien für verschiedene Benutzergruppen werden über Finegrained Password Policies realisiert.

25. März 202126. März 2021Cloud, Hafnium

HAFNIUM-Schwachstellen: Office 365/Microsoft 365/AD FS indirekt auch bedroht

[GTranslate]

Von Inés Atug, Markus Drenger und Daniel Jedecke.

Nach der Veröffentlichung des Out-of-Band-Patches für die als HAFNIUM bekannt gewordenen Schwachstellen in Exchange Servern haben viele Admins, die zuvor eine Migration nach Office 365 (jetzt Microsoft 365) durchgeführt hatten, aufgeatmet. Denn Microsoft zufolge ist Exchange Online von Hafnium nicht betroffen. Hiermit meint der Hersteller jedoch das Produkt an sich: Exchange Online ist weiterhin nicht direkt angreifbar. Aber Vorsicht: Es kann je nach Aufbau dennoch möglich sein, dass Angreifer auf den Cloud-Dienst durchgreifen können.

In vielen Fällen ist in Unternehmen ein hybrider Aufbau etabliert, bei dem ein Exchange-Server weiterhin lokal betrieben wird. Sollte dieser Exchange-Server die HAFNIUM-Schwachstellen aufweisen, könnten Angreifer hierüber Zugriff auf das lokale Netzwerk erhalten (siehe Abbildung Schritt (1)) und sich dann über Lateral Movement im Netz weiterbewegen (Schritt (2)). Mittelbares Ziel des Angriffs ist in der Regel der Zugriff auf ein hochwertiges System wie beispielsweise das Active Directory oder die Active Directory Federation Services (AD FS) zu. Bei Zugriff auf letzteren können die Angreifer unter Umständen den geheimen Schlüssel entwenden (Schritt (3)), sich damit als jeder beliebige legitime Nutzer in der Cloud ausgeben (Schritt (4)) und somit Zugriff (lesen, verändern, löschen) auf alle in der Cloud gespeicherten Daten bekommen (Schritt (5)).

Angriff auf die Cloud/ADFS via HAFNIUM/ProxyLogon

Ob und wie leicht dies möglich ist, hängt stark davon ab, wie der lokale Aufbau umgesetzt ist. Wir erleben im Bereich der Forensik und Beratung hier gute wie auch ungünstige Umsetzungen. Prinzipiell sollte das Ziel immer sein, Lateral Movement in der On-Premise-Umgebung wie auch in der Cloud zu minimieren. Hierfür gibt es bewährte Verfahren, welche sich bei geeigneter Konfiguration dazu eignen, die Bewegungen der Angreifer im Netz zu erschweren:

Frühzeitiges Patchen von Sicherheitslücken: Die wichtigste Maßnahme, die auch bei Hafnium eine Kompromittierung mit hoher Wahrscheinlichkeit unterbunden hätte, ist das schnelle Patchen der Systeme. Hier herrscht bisweilen noch der Irrglaube, dass kritische Sicherheitslücken innerhalb von 30 Tagen zu patchen seien. Dies wurde und wird teilweise sogar noch von IT-Sicherheitsstandards vorgeschlagen. Sicherheitslücken, die mittels Fernzugriff automatisiert und unauthentifiziert ausgenutzt werden können, so wie dies bei Hafnium der Fall ist, zeigen jedoch deutlich, dass hier möglichst innerhalb von Stunden anstatt Tagen gepatcht werden sollte.
Administrative Trennung von Active Directory und Exchange Server: Eine weitere Maßnahme, die lokal umgesetzt werden sollte, ist die administrative Trennung zwischen Active Directory und Exchange. Oft sind die Systeme über Jahre gewachsen und eng miteinander verbunden. So trennt die Angreifer nach erfolgreicher Kompromittierung oft nur ein Powershell Kommando von der AD-Übernahme. Hier ist es wichtig, die 2017 von Microsoft im Rahmen der Konferenzen Blue Hat und Black Hat vorgestellten Probleme zu mitigieren. Hierfür eignet sich Split-Permissions (https://docs.microsoft.com/en-us/exchange/understanding-split-permissions-exchange-2013-help und https://docs.microsoft.com/de-de/exchange/permissions/split-permissions/configure-exchange-for-split-permissions?view=exchserver-2019). Eine weitere Maßnahme ist die Verwendung der Local Administrator Password Solution (LAPS) von Microsoft. Hierbei wird auf jedem Host ein separates Admin-Passwort gesetzt, um so das Springen nach einem erfolgreichen Angriff (beispielsweise mittels Pass-the-Hash-Angriffsarten) zu erschweren.
Umsetzen des Konzepts administrativer Zonen: Da AD FS das Sprungbrett in die Cloud Welt ist, sollte dieser Zugang besonders gesichert werden. Hierzu empfiehlt Microsoft seit längeren einen Aufbau, in dem verschiedene administrative Sicherheitszonen (engl. tiers) voneinander getrennt werden sollten. Ein entsprechend gesicherter Exchange Server würde hier in Zone 1 stehen und ein Active Directory in Zone 0. Ein Sprung zwischen diesen Zonen soll mit den umzusetzenden Maßnahmen stark erschwert werden. Für den AD FS empfiehlt Microsoft ebenfalls den Aufbau in der Zone 0 (https://docs.microsoft.com/de-de/windows-server/identity/ad-fs/design/best-practices-for-secure-planning-and-deployment-of-ad-fs).
Multifaktorauthentifizierung: Sowohl in der Cloud als auch in der lokalen IT-Umgebung sollten administrative Zugriffe mittels starker Multifaktorauthentifizierung abgesichert werden.
Protokollierung und Monitoring: Damit ein unberechtigter Zugriff möglichst schnell bemerkt wird, sollte ein feinmaschiges Monitoring- und Protokollierungskonzept etabliert sein. Insbesondere in der Cloud-Umgebung gehört das Monitoring neben der Zugriffssteuerung zu den wichtigsten Sicherheitsmaßnahmen.
Datenklassifizierung: Sollte es doch zu einem Einbruch gekommen sein und die Angreifer möchten Daten exportieren, dann sollte mittels der Datenklassifizierung Sicherheitsmaßnahmen greifen, die zumindest die als vertraulich oder streng vertraulich klassifizierten Daten außerhalb der Cloud und des Kundennetzwerks unlesbar darstellen.
Datensicherung: Sollte es zu einem Einbruch gekommen sein und es werden die Daten mittels Ransomware verschlüsselt, dann sollte man auf eine unveränderbare extern gespeicherte Datensicherung zurückgreifen können.

Die obigen Ausführungen zeigen, dass ein ganzheitliches und aktuelles Sicherheitskonzept notwendig ist, um möglichen Sicherheitslücken umfassend entgegenzuwirken. Überprüfen Sie daher regelmäßig Ihre Sicherheitsmaßnahmen und passen Sie diese ggfs. an geänderte Anforderungen an. Insbesondere, wenn Sie lokale Dienste von außen erreichbar konfigurieren oder Cloud-Dienste mit der lokalen IT-Umgebung koppeln, sollten das Sicherheitskonzept überprüft und nachgeschärft werden. Sprechen Sie uns gerne dazu an!