DCSync erkennen: Replikationsrechte außerhalb der Domain Controller

DCSync erkennen ist die Erkennung, die das Ende eines Angriffs auf Active Directory sieht: Wer DCSync ausführen kann, hat bereits so viele Rechte, dass er sich die Schlüssel zur gesamten Domäne holen kann, ohne je einen Domain Controller zu betreten. Die Technik missbraucht das Replikationsprotokoll, mit dem sich Domain Controller untereinander abgleichen, und weil dieser Abgleich legitim ist, sieht die Anfrage aus wie normaler Betrieb, es sei denn, man achtet darauf, wer sie stellt. Was der krbtgt-Hash mit dem Kerberos-Ticket-Fluss zu tun hat, steht unter Kerberos verstehen. Dieser Beitrag beschreibt, wie DCSync funktioniert, welche Berechtigung es voraussetzt, welche Logquellen es zeigen, das Muster, das einen Angreifer von einem echten Domain Controller unterscheidet, eine Sigma-Regel, den Test und die wenigen Fehlalarme, die es bei dieser Technik gibt.

Was der Angreifer tut

Active Directory verteilt Änderungen über ein Replikationsprotokoll: Wenn auf einem Domain Controller ein Passwort geändert wird, holen sich die anderen die Änderung über den Aufruf DsGetNCChanges im Verzeichnisreplikationsdienst (drsuapi). Dieser Aufruf liefert auf Wunsch die geheimen Attribute eines Kontos mit, also den aktuellen und die alten Passwort-Hashes. DCSync gibt sich gegenüber einem echten Domain Controller als replizierender Partner aus und fordert genau diese Daten für ein oder alle Konten an. Das Werkzeug ist meist Mimikatz mit dem Befehl lsadump::dcsync oder das secretsdump-Skript aus Impacket. Der Angreifer braucht dazu keinen Zugriff auf einen Domain Controller und keine Datei darauf; er braucht nur ein Konto mit den Replikationsrechten. Diese Rechte hat standardmäßig nur, wer Domain-Admin, Enterprise-Admin oder Domain Controller ist, aber sie lassen sich einzelnen Konten zuweisen, und genau diese unauffällige Zuweisung an ein sonst harmloses Konto ist ein beliebter Persistenzweg. In ATT&CK ist die Technik T1003.006 unter Credential Access; sie ist der direkteste Weg an das krbtgt-Konto, dessen Hash die Grundlage für das dauerhafteste aller Active-Directory-Hintertüren ist, das Golden Ticket.

Welche Logquellen die Technik zeigen

4662 ist nur brauchbar, wenn die Überwachung des Verzeichnisdienstzugriffs aktiviert ist und die Überwachung für das Domänenobjekt so gesetzt wurde, dass diese Zugriffe protokolliert werden; ohne diese Konfiguration entsteht das Ereignis nicht, und dann ist dce_rpc.log die einzige Quelle. Beides gemeinsam ist das Ziel, weil das eine das Konto liefert und das andere die Quelle unabhängig vom Endpunkt bestätigt. Die Ereignisdetails stehen in der Referenz zu den Event-IDs.

Das Muster im Log

Das Muster ist bei DCSync einfacher als bei den meisten anderen Techniken, weil es eine klare Regel gibt: Replikation ist etwas, das nur Domain Controller untereinander tun. Jede Anfrage mit den Get-Changes-Rechten, die nicht von einem Domain-Controller-Konto und nicht von der Adresse eines Domain Controllers kommt, ist verdächtig, und wenn sie die Get-Changes-All-Berechtigung enthält, mit der auch die Passwort-Hashes repliziert werden, ist sie fast immer ein Angriff. Die Erkennung besteht also aus einer Selektion auf 4662 mit den Replikations-GUIDs und einem Filter, der die echten Domain Controller ausnimmt, nach Konto und nach Adresse. Zwei Verfeinerungen erhöhen die Aussagekraft. Erstens das Zielkonto, soweit sichtbar: Ein DCSync, das gezielt krbtgt oder ein einzelnes Admin-Konto abfragt, unterscheidet sich von der vollständigen Replikation und ist ein noch stärkeres Signal. Zweitens die Vorbereitung: Wenn kurz vor der Replikationsanfrage in 5136 eine Änderung an den Berechtigungen des Domänenobjekts steht, hat der Angreifer sich die Rechte gerade erst zugewiesen, und beide Ereignisse zusammen zeigen die ganze Kette. Weil ein einziger echter Treffer eine kompromittierte Domäne bedeutet, ist diese Regel eine der wenigen, die ohne Zählung und ohne Schwelle auskommt: Ein Ereignis genügt.

Die Sigma-Regel

title: DCSync Replication Request From Non-DC Account
id: 4e9c2b7a-8d3f-4a1e-b6c5-9f0a1d2e3b4c
status: test
description: Ein Konto, das kein Domain Controller ist, fordert per
  Replikationsprotokoll Verzeichnisaenderungen an. Kennzeichen von DCSync.
references:
  - https://attack.mitre.org/techniques/T1003/006/
author: Blue Team
date: 2026-09-13
tags:
  - attack.credential_access
  - attack.t1003.006
logsource:
  product: windows
  service: security
detection:
  selection:
    EventID: 4662
    Properties|contains:
      - '1131f6aa-9c07-11d1-f79f-00c04fc2dcd2'   # DS-Replication-Get-Changes
      - '1131f6ad-9c07-11d1-f79f-00c04fc2dcd2'   # DS-Replication-Get-Changes-All
      - '89e95b76-444d-4c62-991a-0facbeda640c'   # Get-Changes-In-Filtered-Set
  filter_dc_accounts:
    SubjectUserName|endswith: '$'                # Computerkonten der Domain Controller
  filter_msol:
    SubjectUserName|startswith: 'MSOL_'          # Entra Connect Sync-Konto
  filter_known_service:
    SubjectUserName|startswith: 'svc-adsync'      # dokumentiertes Synchronisationskonto
  condition: selection and not 1 of filter_*
falsepositives:
  - Verzeichnissynchronisation (Entra Connect), Backup- und Migrationswerkzeuge mit Replikationsrechten
level: critical

Der Filter auf Computerkonten mit dem Dollarzeichen nimmt die echten Domain Controller heraus, weil ihre Replikation über ihr Computerkonto läuft. Die beiden weiteren Filter nennen die legitimen Ausnahmen, die es tatsächlich gibt: Das Synchronisationskonto von Entra Connect repliziert Passwort-Hashes in die Cloud und braucht die Get-Changes-All-Berechtigung, ebenso manche Backup- und Migrationswerkzeuge. Genau diese Konten sind die einzigen legitimen Nicht-DC-Quellen, und sie gehören namentlich in den Filter, nicht als pauschale Ausnahme. Wer sie kennt und einträgt, hat eine Regel, die sonst nur bei einem echten Angriff auslöst. Die Übersetzung in das eigene SIEM steht im Beitrag zu Sigma-Regeln; eine zweite Regel auf 5136 mit den Replikationsrechten im geänderten Berechtigungseintrag fängt die Vorbereitung und ist in der Community-Sammlung vorhanden.

Der Test

Der Test gehört ausschließlich ins Homelab, niemals in eine Produktivumgebung, weil er echte Passwort-Hashes abzieht. Voraussetzung ist die aktivierte Überwachung des Verzeichnisdienstzugriffs auf dem Domain Controller. Von der Kali-VM aus mit dem Konto eines Domänen-Admins ein Aufruf von secretsdump.py mit der Option, nur über DRSUAPI zu arbeiten, oder auf einem Client als Admin ein Mimikatz-Aufruf lsadump::dcsync mit dem Ziel krbtgt. Erwartet wird auf dem Domain Controller 4662 mit einer der Replikations-GUIDs, ausgelöst vom Testkonto und nicht von einem Computerkonto, und die Regel muss auf Stufe kritisch treffen. Im Zeek-Sensor erscheint im dce_rpc.log der Aufruf DsGetNCChanges von der Adresse der Quelle. Wer den Test mit dem Ziel krbtgt fährt, sieht zugleich, warum die Technik so gefährlich ist: Mit diesem Hash ließe sich ein Golden Ticket bauen. Atomic Red Team hat für T1003.006 einen Test mit Mimikatz. Ergebnis und Datum in den Navigator, und weil dies eine der Techniken ist, deren Erkennung im Ernstfall über alles entscheidet, gehört der Test in die regelmäßige Purple-Team-Übung.

Fehlalarme und Tuning

• Entra Connect Sync. Das Synchronisationskonto, meist mit dem Präfix MSOL_ oder als AAD_-Konto, repliziert Hashes legitim in die Cloud und ist der häufigste Fehlalarm. Es kommt namentlich in den Filter, und seine Quelladresse, der Server mit Entra Connect, wird zusätzlich geprüft: Repliziert das Konto von einem anderen System aus, ist das ein Angriff mit gestohlenen Anmeldeinformationen des Sync-Kontos.
• Backup- und Migrationswerkzeuge. Manche AD-Backup-Lösungen und Migrationswerkzeuge nutzen Replikation. Sie bekommen einen Filter nach Konto und Zeitplan; eine Replikation außerhalb des Backup-Fensters ist auch bei ihnen ein Alarm.
• Neue Domain Controller. Beim Hochstufen eines neuen Domain Controllers repliziert dieser die gesamte Domäne. Das geschieht über sein Computerkonto und fällt damit unter den Filter; ein DCSync gibt sich nicht als Computerkonto aus.
• Das Volumen von 4662. Mit aktivierter Verzeichnisüberwachung erzeugt 4662 auf einem Domain Controller sehr viele Ereignisse, weil jeder Objektzugriff protokolliert wird. Die Filterung auf die drei Replikations-GUIDs vor dem SIEM reduziert das auf eine Handvoll pro Tag; ohne diese Filterung wird die Quelle zu teuer, wie im Beitrag zum SIEM beschrieben.
• Die Gegenmaßnahme, die die Regel entlastet. Die Replikationsrechte regelmäßig prüfen: Welche Konten außer den Domain Controllern und dem Sync-Konto haben Get-Changes-All? Jedes unerwartete Konto ist entweder ein Fehler oder eine Hintertür. Dazu die Absicherung der privilegierten Konten, damit ihr Hash gar nicht erst gestohlen wird, wie im Beitrag zu Pass-the-Hash beschrieben, denn ohne die Rechte eines Admins gibt es kein DCSync.

Fazit

DCSync ist die Technik, bei der die Erkennung am einfachsten und der Vorfall am schwersten ist: eine klare Regel, ein Ereignis, keine Schwelle, aber ein einziger echter Treffer bedeutet, dass der Angreifer die Schlüssel zur Domäne hat und die Wiederherstellung das zweimalige Zurücksetzen von krbtgt und im Zweifel den Neuaufbau des Vertrauens einschließt. Wer die drei Replikations-GUIDs in 4662 filtert, die echten Domain Controller und das Sync-Konto namentlich ausnimmt und die Regel im Lab gegen krbtgt testet, hat die gefährlichste Active-Directory-Technik abgedeckt, und das ist die Erkennung, bei der ein Blue Team hofft, dass sie nie auslöst, und froh ist, dass sie es würde.