AD-Hintertüren erkennen: DSRM, SID-History, AdminSDHolder und Delegierung

AD-Hintertüren erkennen ist die Disziplin nach dem eigentlichen Einbruch. Ein Angreifer mit Domain-Admin-Rechten rechnet damit, entdeckt zu werden, und sorgt dafür, später wieder hereinzukommen, auch wenn sein ursprünglicher Zugang geschlossen wird. Die dafür genutzten Wege sind keine Schadsoftware, sondern legitime Funktionen von Active Directory, und genau deshalb fallen sie bei einer normalen Prüfung der Gruppe Domain Admins nicht auf. Erkennen lassen sie sich nur, wenn man gezielt die Spuren sucht, die ihr Einrichten und ihre Nutzung im Log hinterlassen. Dieser Beitrag aus der Serie „Angriff erkennen“ beschreibt die vier häufigsten Hintertüren aus Verteidigersicht, die zugehörigen Ereignisse, zwei Sigma-Regeln, den Test im Lab und die wenigen Fehlalarme. Die Grundlagen zur Absicherung stehen im Beitrag Active Directory härten.

Was der Angreifer tut

Allen vier Techniken ist gemeinsam, dass sie Rechte nicht über eine sichtbare Gruppenmitgliedschaft vergeben, sondern über einen verdeckten Mechanismus. In ATT&CK fallen sie unter Persistenz und Privilegienausweitung; die SID-History hat mit T1134.005 eine eigene Technik. Hier die vier Wege im Überblick, bewusst auf der Ebene des Prinzips, nicht als Anleitung:

• DSRM-Konto. Jeder Domain Controller besitzt ein lokales Administratorkonto für den Verzeichnisdienst-Wiederherstellungsmodus (Directory Services Restore Mode). Sein Passwort wird bei der Hochstufung gesetzt und oft nie wieder geändert. Über eine Registry-Einstellung lässt sich dieses Konto so umkonfigurieren, dass es sich auch im laufenden Betrieb anmelden kann. Da es ein lokales Konto ist, bleibt es von einem Passwortwechsel der Domänenkonten unberührt und ist ein dauerhafter Zugang zum Domain Controller selbst.
• SID-History. Das Attribut sIDHistory ist eigentlich für Domänenmigrationen gedacht: Ein Konto behält die Berechtigungen seiner alten Domäne, indem seine alte SID im neuen Konto mitgeführt wird. Trägt jemand dort die SID einer privilegierten Gruppe ein, erhält ein sonst unauffälliges Konto deren Rechte, ohne je Mitglied der Gruppe zu sein.
• AdminSDHolder. Ein spezielles Objekt im Verzeichnis gibt die Berechtigungen vor, die der Prozess SDProp regelmäßig auf alle geschützten (privilegierten) Konten zurückschreibt. Wird die Berechtigungsliste dieses Objekts um einen Eintrag erweitert, verteilt SDProp diesen Eintrag von selbst auf alle Admin-Konten, und das wiederholt, selbst wenn man ihn dort einzeln entfernt.
• Delegierung an Computerkonten. Über die Kerberos-Delegierung kann ein Computerkonto so eingestellt werden, dass es im Namen anderer Konten Dienste anfordert. Eine unbefugt gesetzte, uneingeschränkte oder ressourcenbasierte Delegierung ist ein versteckter Weg zu privilegierten Diensten. Die Kerberos-Grundlagen dazu stehen unter Kerberos verstehen.

Welche Logquellen die Techniken zeigen

Mehrere dieser Ereignisse entstehen nur bei aktivierter Überwachung des Verzeichnisdienstzugriffs und mit der passenden Überwachung (SACL) auf den betroffenen Objekten. 4765 und 4766 erfordern die Unterkategorie Benutzerkontenverwaltung, 5136 und 4662 die Überwachung der Verzeichnisdienständerungen beziehungsweise des -zugriffs mit einer SACL auf AdminSDHolder. Welche Einstellungen das sind, steht in der Referenz zu den Event-IDs; ohne sie fehlen genau die Spuren, die diese Hintertüren verraten.

Das Muster im Log

Der gemeinsame Nenner aller vier Techniken ist ihre Seltenheit. Keine dieser Änderungen gehört zum Tagesgeschäft, und jede einzelne ist deshalb schon für sich ein starkes Signal, das keine Schwelle und keine Zählung braucht. Entscheidend ist, die Ereignisse überhaupt zu erfassen und sie dem Kontext zuzuordnen.

• DSRM: Eine Änderung an DsrmAdminLogonBehavior auf Wert 1 oder 2 oder eine 4794-Meldung ohne geplante Wiederherstellungsarbeit ist verdächtig. Legitim ist das Setzen des DSRM-Passworts nur im Rahmen dokumentierter Wartung.
• SID-History: 4765 außerhalb einer laufenden, angekündigten Domänenmigration ist fast immer ein Angriff. Besonders klar wird es, wenn die eingetragene SID zu einer privilegierten Gruppe der eigenen Domäne gehört, denn für eine echte Migration stammt die alte SID aus einer anderen Domäne.
• AdminSDHolder: Jedes 5136 auf dem ntSecurityDescriptor dieses einen Objekts ist zu prüfen. Ein neuer Berechtigungseintrag für ein nicht-administratives Konto ist die Vorbereitung einer Persistenz; das kurz darauf folgende Zurückschreiben durch SDProp auf die Admin-Konten bestätigt die Kette.
• Delegierung: Ein 4742, das an einem Computerkonto eine uneingeschränkte oder ressourcenbasierte Delegierung einschaltet, gehört geprüft, vor allem wenn das Konto zuvor keine Delegierung hatte.

Zwei Sigma-Regeln

Die erste Regel deckt die SID-History-Manipulation ab, die am eindeutigsten ist. Sie selektiert die beiden Ereignisse und kennt keine normale Ausnahme außerhalb einer Migration.

title: SID-History Added To Account
id: 7c0f2d14-3a6b-4e9d-9c21-5b8e0a7d4f61
status: test
description: Der SID-History eines Kontos wurde ein Wert hinzugefuegt (4765)
  oder ein solcher Versuch schlug fehl (4766). Ausserhalb einer Domaenen-
  migration ein Kennzeichen fuer Persistenz ueber SID-History.
references:
  - https://attack.mitre.org/techniques/T1134/005/
author: blue-team.net
date: 2026-10-02
tags:
  - attack.privilege-escalation
  - attack.t1134.005
logsource:
  product: windows
  service: security
detection:
  selection:
    EventID:
      - 4765
      - 4766
  condition: selection
falsepositives:
  - Laufende, angekuendigte Domaenenmigration mit SID-History-Uebernahme
level: high

Die zweite Regel überwacht das Objekt AdminSDHolder. Sie setzt eine SACL auf das Objekt voraus, damit 5136 überhaupt entsteht, und meldet jede Änderung an dessen Berechtigungen.

title: AdminSDHolder ACL Modified
id: 2b9e4c88-1f3a-4d57-a0c6-7e2f9b1d8a40
status: test
description: Der Berechtigungseintrag des Objekts AdminSDHolder wurde geaendert.
  SDProp verteilt solche Eintraege auf alle geschuetzten Konten, daher ein
  typischer Persistenzweg in Active Directory.
references:
  - https://attack.mitre.org/techniques/T1098/
author: blue-team.net
date: 2026-10-02
logsource:
  product: windows
  service: security
detection:
  selection:
    EventID: 5136
    ObjectDN|contains: 'CN=AdminSDHolder,CN=System'
    AttributeLDAPDisplayName: 'nTSecurityDescriptor'
  condition: selection
falsepositives:
  - Dokumentierte Aenderung der Standardberechtigungen privilegierter Konten durch das AD-Team
level: high

Die Übersetzung in das eigene SIEM steht im Beitrag zu Sigma-Regeln. Für DSRM ergänzt eine Regel auf den Registry-Wert DsrmAdminLogonBehavior (über 4657 oder Sysmon Event 13) und eine auf 4794; für Delegierung eine auf 4742 mit den Delegierungsattributen.

Der Test

Alle Tests gehören ausschließlich ins Homelab, niemals in eine Produktivumgebung. Ziel ist jeweils nur, zu prüfen, ob das erwartete Ereignis entsteht und die Regel trifft, nicht, eine funktionierende Hintertür zu bauen.

• SID-History: Atomic Red Team T1134.005 enthält einen Test, der einem Testkonto per Mimikatz eine SID in die SID-History einträgt. Erwartet wird auf dem Domain Controller 4765, und die erste Sigma-Regel muss auf Stufe hoch treffen.
• AdminSDHolder: Mit aktivierter SACL auf dem Objekt im Lab einen Berechtigungseintrag für ein Testkonto hinzufügen und wieder entfernen. Erwartet wird 5136 auf den ntSecurityDescriptor, und nach spätestens 60 Minuten die Verteilung durch SDProp auf die geschützten Konten.
• DSRM: Den Wert DsrmAdminLogonBehavior im Lab setzen und zurücksetzen. Erwartet wird 4657 beziehungsweise Sysmon 13 auf den Schlüssel unter Lsa.

Ergebnis und Datum jeweils in den ATT&CK-Navigator, denn diese Erkennungen entscheiden im Ernstfall darüber, ob ein Angreifer dauerhaft im Verzeichnis bleibt. Deshalb gehören sie in die regelmäßige Purple-Team-Übung.

Fehlalarme und Tuning

• Domänenmigration. Der einzige reguläre Grund für einen neuen SID-History-Eintrag. Läuft eine Migration, wird das betreffende Werkzeug und sein Zeitfenster dokumentiert und die Regel für diese Zeit begleitet beobachtet, nicht stummgeschaltet; jede eingetragene SID aus der eigenen Domäne bleibt auch dann ein Alarm.
• Geplante DSRM-Wartung. Das Zurücksetzen des DSRM-Passworts ist eine legitime Pflege und sollte es regelmäßig sein. Sie gehört in ein Wartungsfenster und wird mit Change-Ticket abgeglichen; 4794 ohne Ticket bleibt übrig und ist genau das Signal.
• Änderungen durch das AD-Team an AdminSDHolder. In seltenen Fällen passt das Verzeichnis-Team die Standardberechtigungen privilegierter Konten bewusst an. Solche Änderungen sind geplant, nachvollziehbar und selten; sie werden einzeln geprüft, nicht pauschal gefiltert.
• Delegierung aus Anwendungsbetrieb. Manche Anwendungen brauchen eine (möglichst eingeschränkte) Delegierung. Die bekannten Konten kommen namentlich in den Filter; eine neu eingeschaltete uneingeschränkte Delegierung bleibt meldepflichtig.
• Die Gegenmaßnahme, die die Regeln entlastet. Regelmäßig prüfen: Wer kann sich per DSRM anmelden, welche Konten tragen eine SID-History, wie sieht die Berechtigungsliste von AdminSDHolder aus, welche Computerkonten haben eine Delegierung. Jeder unerwartete Eintrag ist entweder ein Fehler oder eine Hintertür. Das SIEM macht aus diesen seltenen Ereignissen einen Alarm, bevor der Angreifer den Weg zurück nutzt.

Fazit

AD-Hintertüren sind die Versicherung des Angreifers gegen die eigene Entdeckung, und sie wirken nur, solange niemand gezielt nach ihnen sucht. DSRM, SID-History, AdminSDHolder und Delegierung nutzen vier legitime Funktionen des Verzeichnisses, hinterlassen aber jeweils ein seltenes und damit aussagekräftiges Ereignis: 4794 und der Registry-Wert für DSRM, 4765 und 4766 für SID-History, 5136 und 4662 auf AdminSDHolder, 4742 für Delegierung. Wer diese Ereignisse erfasst, ihre Voraussetzungen (Überwachung und SACL) einrichtet und die Regeln im Lab gegen einen echten Test prüft, schließt die Lücke, durch die ein einmal vertriebener Angreifer sonst immer wieder zurückkommt. Der Rest ist Disziplin: die privilegierten Wege regelmäßig inventarisieren, wie es ein Blue Team ohnehin tut.