DCSync erklärt: Wie sich ein Angreifer als Domänencontroller ausgibt — und die Berechtigung, die keiner prüft.

DCSync ist der Fachbegriff dafür, dass sich ein Angreifer mit einem bereits übernommenen, ausreichend berechtigten Konto gegenüber dem Active Directory wie ein zweiter Domänencontroller verhält und über einen ganz normalen, aber vorgetäuschten Replikationsabgleich die Passwort-Hashes Ihrer Konten anfordert. Es wird dabei keine Lücke aufgebrochen, sondern eine legitime Windows-Funktion missbraucht — deshalb fällt es ohne gezielte Überwachung oft gar nicht auf.

Gerade das macht es gefährlich: Domänencontroller gleichen ihre Daten untereinander ständig ab, das ist gewollt. Wenn ein Angreifer sich in diesen Abgleich einklinkt, sieht der Vorgang für das System zunächst wie reguläre Replikation aus. Hat er erst die Passwort-Hashes aller Konten — inklusive der höchsten Administratorrechte — kann er sich praktisch dauerhaft und unauffällig Zugang verschaffen. Es ist der Punkt, an dem aus „ein Konto übernommen“ effektiv „die ganze Domäne übernommen“ wird.

Dahinter stehen die Replikationsrechte „Replicating Directory Changes“ und „Replicating Directory Changes All“. Eigentlich gehören sie nur den echten Domänencontrollern. In gewachsenen Netzen sammeln sie sich aber unbemerkt bei alten Dienstkonten, Backup- oder Synchronisierungs-Werkzeugen oder über verschachtelte Gruppen an. Weil diese Rechte tief in den Verzeichnis-Berechtigungen liegen und nicht in einer einfachen Übersicht auftauchen, schaut sie im Alltag fast niemand an — bis sie zum Problem werden.

Zwei zusammengehörige Schritte. Erstens: die Replikationsrechte konsequent auf die echten Domänencontroller begrenzen und jedem anderen Konto, das sie aus historischen Gründen noch besitzt, wieder entziehen. Zweitens: einen Alarm einrichten, der anschlägt, sobald ein Replikationsabgleich (Event ID 4662) von einer Adresse kommt, die gar kein Domänencontroller ist. Begrenzt man die Rechte und überwacht den Abgleich, läuft dieser ganze Pfad ins Leere.

Nein. TULPAR ist eine autorisierte Selbstprüfung Ihres eigenen Netzwerks, kein Angriffswerkzeug, und es stellt hier kein Aushändigen von Passwort-Hashes nach. Standardmäßig wird nur angesehen (read-only): TULPAR liest aus, welche Konten die kritischen Replikationsrechte tragen und wie ein Angriffspfad bis dorthin aussehen würde. Ein aktiver Test erfolgt ausschließlich nach Ihrer ausdrücklichen Freigabe und nur in Ihrem eigenen Netz. Es wird nichts angegriffen, was Sie nicht freigeben.

Der entscheidende Hinweis ist ein Replikationsabgleich, der von einer Adresse ausgeht, die kein Domänencontroller ist. Windows protokolliert solche Zugriffe als Event ID 4662. Ohne eine gezielte Auswertung geht dieser eine Eintrag jedoch in der Masse normaler Protokolle unter. TULPAR macht im Klartext sichtbar, ob die nötige Überwachung greift und ob es Konten gibt, die den missbrauchbaren Abgleich überhaupt anstoßen könnten — bevor es jemand ausnutzt.

DCSync ist meist nicht der erste Schritt, sondern das Ziel. Davor liegt oft eine Kette: ein vergessener Server mit bekannter Lücke, eine weitergereichte Anmeldung über NTLM-Relay, ein Dienstkonto mit schwachem Passwort. Erst über solche Zwischenschritte gelangt ein Angreifer an ein Konto mit genug Rechten, um den Replikationsabgleich anzustoßen. Genau diesen Zusammenhang zeigt TULPAR als Pfad — und macht deutlich, dass ein einziger geschlossener Schritt früher die ganze Kette unterbrechen kann.

Ein sauber begrenztes Berechtigungskonzept und nachvollziehbare Schwachstellen-Dokumentation sind Bausteine, die in NIS2-Risikomanagement, BSI-Einstiegschecks oder einen Cyberversicherungsantrag einfließen können — Versicherer fragen ein Berechtigungskonzept und privilegierte Zugänge gezielt ab. TULPAR liefert dafür technische Belege, ist aber keine Zertifizierung und keine Rechtsberatung und macht Sie nicht automatisch konform. Ob und wie Sie von NIS2 betroffen sind, hängt von Ihrem Sektor und Ihrer Größe ab; das klären Sie individuell.