SIDHistory Injection: Rechteeskalation über Bekannte SID zum Domain Admin

Was Ist SIDHistory-Injection? Rechteeskalation über Bekannte SIDs Erklärt

SIDHistory-Injection mit einer bekannten SID ist eine Active-Directory-Persistenz- und Rechteeskalationstechnik, bei der ein Angreifer eine bekannte privilegierte SID — etwa die RID-512-Suffix (Domain Admins) oder RID-519-Suffix (Enterprise Admins) der Domänen-SID — in das Attribut sIDHistory eines unprivilegierten Kontos schreibt. MITRE ATT&CK katalogisiert dies als Sub-Technik T1134.005 — Access Token Manipulation: SID-History Injection.

Da jede in sIDHistory gespeicherte SID in das Kerberos-PAC (Privilege Attribute Certificate) des Kontos kopiert wird und dieses PAC wiederum beim Logon in dessen Zugriffstoken einfließt, erbt das gering privilegierte Konto effektiv Domain-Admin-Rechte, ohne jemals der Gruppe Domain Admins hinzugefügt worden zu sein. Gruppenmitgliedschaftsprüfungen, Reviews verschachtelter Gruppen und net group /domain-Abfragen liefern durchweg ein sauberes Ergebnis — die Eskalation bleibt für alles unsichtbar, das nur die Gruppenmitgliedschaft betrachtet.

Funktionsweise: sIDHistory und Bekannte SIDs

sIDHistory ist ein legitimes Active-Directory-Attribut für Migrationen zwischen Domänen und Gesamtstrukturen: Wechselt ein Konto in eine neue Domäne, bleibt seine alte SID in sIDHistory erhalten, sodass es weiterhin Zugriff auf Ressourcen behält, für die es bereits autorisiert war, ohne dass ein Administrator jede ACL manuell umschreiben muss. Microsofts Funktion DsAddSidHistory und die Trust-Einstellung EnableSIDHistory existieren genau für dieses Migrationsszenario.

Das Problem ist, dass Windows keinen Unterschied macht zwischen einer während einer legitimen Migration hinzugefügten SID und einer von einem Angreifer eingeschleusten. Beim Logon baut der Domain Controller das PAC des Benutzers aus jeder mit dem Konto verknüpften SID — primäre Gruppe, alle Gruppenmitgliedschaften und der vollständige Inhalt von sIDHistory — und dieses PAC wird zum Zugriffstoken, dem jeder nachgelagerte Dienst vertraut. Das ist eine grundlegend andere Persistenzfläche als gefährliche Gruppenverschachtelung, wo das Privileg wenigstens in der Mitgliederliste einer Gruppe sichtbar ist — hier ändert sich niemals eine Gruppenmitgliedschaft.

Normale Domänenkonten und selbst die meisten administrativen Tools können nicht einfach per Set-ADUser -Replace @{sidHistory=...} über LDAP darauf zugreifen; sIDHistory ist ein konstruiertes/geschütztes Attribut. In der Praxis erreichen Angreifer es über:

• Mimikatz' Module sid::patch und sid::add, direkt auf einem Domain Controller mit privilege::debug ausgeführt — das erfordert Domain-Admin-/SYSTEM-äquivalenten Zugriff auf dem DC selbst, und sid::patch funktioniert unter Windows Server 2016 und neuer nicht mehr.
• DSInternals' Add-ADDBSidHistory bearbeitete die ntds.dit-Datenbank offline und erforderte das Anhalten des NTDS-Dienstes — es griff direkt auf die Datenbank eines DCs zu statt über die normale Replikations-API. Zum Zeitpunkt dieses Artikels wurde das Cmdlet aus dem aktuellen DSInternals-PowerShell-Modul entfernt (seine Dokumentation bleibt nur zu Referenzzwecken erhalten); das gepflegte Äquivalent ist Add-ADReplSidHistory, das die Injection online über das MS-DRSR-Replikationsprotokoll durchführt und weiterhin DC-äquivalente Replikationsrechte erfordert.
• Die legitime DsAddSidHistory-API, für domänenübergreifende Migrationen gedacht, die manches Tooling auf unbeabsichtigte Weise missbraucht, wenn der Angreifer bereits DC-äquivalente Rechte kontrolliert.

In jedem Fall benötigt der Angreifer bereits replikationsstufigen oder Domain-Controller-stufigen Zugriff, um in sIDHistory zu schreiben — dies ist eine Post-Compromise-Persistenz- und Stealth-Technik, kein initialer Zugriffsvektor. Was eine eigene Erkennung rechtfertigt, ist das, was danach passiert: Das eingeschleuste Privileg ist in der Gruppenmitgliedschaft nicht sichtbar, übersteht Passwort-Resets und bleibt von der Entfernung des Kontos aus jeglicher Gruppe unberührt (weil es nie Mitglied einer solchen war).

Die Angriffskette

Schritt 1 — DC-stufigen oder replikationsäquivalenten Zugriff erlangen

Der Angreifer benötigt zunächst Rechte, die einem Domain Admin entsprechen, oder direkten Zugriff auf einen Domain Controller — etwa durch einen vorherigen DCSync-Kompromiss, direkten DC-Konsolen-/RDP-Zugriff oder eine exfiltrierte ntds.dit-Kopie. Dieser Schritt ist dieselbe Voraussetzung wie bei einem DCSync-Angriff oder einem gefälschten Golden Ticket.

Schritt 2 — Zielkonto und bekannte SID identifizieren

Der Angreifer wählt ein gering privilegiertes, wenig auffälliges Konto (ein Dienstkonto, ein altes Vertragspartner-Konto oder ein neu erstelltes) sowie die Domänen-SID mit der bekannten RID, die eingeschleust werden soll:

Schritt 3 — Die SID in sIDHistory einschleusen

Auf einem kompromittierten DC, mit Mimikatz:

privilege::debug
sid::patch
sid::add /sam:lowpriv-svc /new:S-1-5-21-XXXXXXXXXX-XXXXXXXXXX-XXXXXXXXXX-512

Historisch, offline gegen eine kopierte ntds.dit, mit DSInternals:

Add-ADDBSidHistory -SamAccountName lowpriv-svc -SidHistory S-1-5-21-XXXXXXXXXX-XXXXXXXXXX-XXXXXXXXXX-512 -DatabasePath .\ntds.dit

Schritt 4 — Als das gering privilegierte Konto authentifizieren

Beim nächsten Logon baut der DC ein PAC für lowpriv-svc, das die eingeschleuste Domain-Admins-SID enthält. Jeder Dienst, der Kerberos-Autorisierungsdaten vertraut, gewährt dem Konto nun Domain-Admin-äquivalenten Zugriff — während seine tatsächliche Gruppenmitgliedschaft weiterhin unauffällig aussieht.

🚨 Gefahr: Weil die eingeschleuste SID auf dem Kontoobjekt selbst liegt statt in einem gefälschten Ticket, bleibt sie bei jedem zukünftigen Logon bestehen, bis jemand gezielt sIDHistory prüft und bereinigt — anders als ein Golden Ticket, das abläuft oder durch eine KRBTGT-Rotation ungültig wird.

Erkennung

Änderungen an sIDHistory sind in einer gesunden Umgebung außerhalb eines aktiven Migrationsfensters selten, was sie zu einer hochwertigen Erkennungsfläche macht — allerdings nur, wenn die richtige Audit-Richtlinie aktiviert ist und die richtigen RIDs geprüft werden.

Die Event-IDs 4765/4766 erfordern die erweiterte Audit-Unterkategorie „Audit User Account Management" — sie ist in vielen Umgebungen nicht standardmäßig aktiviert, daher die Audit-Richtlinie prüfen, bevor Abdeckung angenommen wird.

Erfassen Sie bestehende Konten auf befüllte sIDHistory und filtern Sie speziell nach bekannten privilegierten RIDs, nicht nur nach irgendeinem historischen Wert:

$domainSid = (Get-ADDomain).DomainSID.Value
$privilegedRids = @(512, 516, 518, 519)

Get-ADUser -Filter { SIDHistory -like '*' } -Properties SIDHistory |
    ForEach-Object {
        foreach ($sid in $_.SIDHistory) {
            $rid = ($sid.Value -split '-')[-1]
            if ($sid.Value -like "$domainSid-*" -and $privilegedRids -contains [int]$rid) {
                [PSCustomObject]@{
                    Account = $_.SamAccountName
                    InjectedSid = $sid.Value
                    RID = $rid
                }
            }
        }
    }

Microsoft Defender for Identity liefert eine Sicherheitslage-Bewertung für Konten mit einem sIDHistory-Wert und enthält Verhaltenserkennungslogik, die auf unerwartete Änderungen des SID-History-Attributs außerhalb von Migrationsaktivitäten abgestimmt ist — eine nützliche kompensierende Kontrolle, wo die erweiterte Audit-Richtlinie Lücken aufweist.

Behebung

1. Erweiterte Audit-Richtlinie für Kontoverwaltung aktivieren. Schalten Sie „Audit User Account Management" ein, damit die Event-IDs 4765/4766 tatsächlich ausgelöst werden, und leiten Sie sie mit Alarmierung bei jedem Treffer außerhalb eines bekannten Migrationsänderungsfensters an Ihr SIEM weiter.
2. DC-stufigen und replikationsäquivalenten Zugriff einschränken und überwachen. Da das Einschleusen in sIDHistory Domain-Admin-/SYSTEM-Zugriff auf einem DC oder eine Kopie von ntds.dit erfordert, ist die wirksamste Kontrolle dieselbe, die auch DCSync und Golden-Ticket-Angriffe stoppt: Konten mit DS-Replication-Get-Changes-All minimieren und prüfen sowie interaktive/RDP-Anmeldung an Domain Controllern einschränken.
3. sIDHistory domänenweit regelmäßig prüfen, nicht nur nach einer bekannten Migration. Jeder befüllte Wert mit einer bekannten privilegierten RID, der nicht an ein dokumentiertes, zeitlich begrenztes Migrationsprojekt gebunden ist, sollte als kritischer Vorfall behandelt werden.
4. sIDHistory nach Abschluss von Migrationen bereinigen. Sobald ACLs auf die neuen SIDs umgestellt wurden, entfernen Sie die veralteten sIDHistory-Werte — eine kleinere Angriffsfläche ohne Restwerte lässt sich leichter überwachen als eine, bei der „etwas SID History ist zu erwarten" gilt.
5. Ein Identity Threat Detection and Response (ITDR)-Tool einsetzen, etwa Microsoft Defender for Identity, um Verhaltensabdeckung für sIDHistory-Änderungen zu ergänzen, die statische Audit-Log-Regeln ergänzt.

# Alle sIDHistory-Werte von einem Konto entfernen, sobald Migration/Bereinigung abgeschlossen ist
Set-ADUser -Identity lowpriv-svc -Clear sIDHistory

So Erkennt EtcSec Dies

Das Active-Directory-Audit von EtcSec unterscheidet gezielt SID-History-Hygieneprobleme von aktiven Rechteeskalations-Indikatoren:

• SIDHISTORY_WELLKNOWN_SIDS (Kritisch) — kennzeichnet jedes Konto, dessen sIDHistory-Attribut eine bekannte privilegierte RID (Domain Admins, Enterprise Admins, Schema Admins, Domain Controllers) enthält, die zur eigenen SID der Domäne passt — genau das in diesem Artikel beschriebene Muster, nicht generisches SID-History-Vorkommen.
• SID_HISTORY (Hoch) — kennzeichnet jedes Konto mit befüllter sIDHistory, damit legitime Bereinigungsarbeiten nach einer Migration nachverfolgt und abgeschlossen werden können.
• SIDHISTORY_RECENT_CHANGES (Info) — zeigt Objekte auf, bei denen sich sIDHistory kürzlich geändert hat, um sie mit dokumentierten Migrationsfenstern zu korrelieren.
• DCSYNC_CAPABLE — kennzeichnet das Einstiegsprivileg (Nicht-DC-Konten mit Replikationsrechten), das typischerweise Voraussetzung dafür ist, überhaupt einen DC zu erreichen und die Injection durchzuführen.

Prüfprioritäten

SIDHistory-Injection mit bekannten SIDs sollte als Befund auf Domain-Dominanz-Niveau behandelt werden, nicht als Routine-Hygienelücke. Beginnen Sie damit, jedes Konto mit nicht leerer sIDHistory zu erfassen, und trennen Sie dann dokumentierte Migrationsartefakte von unerklärten Werten — insbesondere jedem, der zu einer bekannten privilegierten RID auf der eigenen SID der aktuellen Domäne passt. Bestätigen Sie, welche Domain Controller für welche Administratoren und Dienstkonten während des vermuteten Zeitfensters erreichbar waren, da die Technik DC-stufigen oder replikationsäquivalenten Zugriff zur Ausführung erfordert. Weil das eingeschleuste Privileg die Gruppenmitgliedschaftsprüfung vollständig umgeht, wird jeder Remediationsplan, der nur die Gruppenmitgliedschaft prüft, es übersehen — das Attribut selbst muss die Quelle der Wahrheit sein.

Benachbarte Kontrollen Mitprüfen

SIDHistory-Injection steht selten allein: Der dafür nötige DC-stufige Zugriff ist derselbe Zugriff, der DCSync-Credential-Extraktion, Golden-Ticket-Fälschung und direkten ntds.dit-Diebstahl ermöglicht. Prüfen Sie bei der Untersuchung einer vermuteten Injection, wer während des Expositionsfensters Replikationsrechte und DC-Logon-Zugriff hatte, ob KRBTGT kürzlich rotiert wurde und ob andere privilegierte Konten Anzeichen von Manipulation zeigen. Ein Fix, der nur die sIDHistory eines Kontos bereinigt, ohne den zugrunde liegenden DC-Zugriffspfad zu schließen, lässt dem Angreifer die Möglichkeit, sie erneut einzuschleusen — oder in ein anderes Konto.

Weiterführende Themen

Dieses Thema sollte immer gemeinsam mit Golden Ticket Angriff: Die Schlüssel zu Ihrer Domain, ACL-Missbrauch und DCSync: Wie stille Rechte Domain Admin öffnen, AD-Trust-Angriffe: Wie Unterdomänen das Gesamtstruktur-Risiko erhöhen, Active Directory Privilegierte Konten: Protected Users, Delegation und Dienstkonto-Lücken, AD Gruppenverschachtelung: Versteckte DA-Pfade und AD Sicherheitsüberwachung: Event IDs und SIEM bewertet werden.

• Golden Ticket Angriff: Die Schlüssel zu Ihrer Domain
• ACL-Missbrauch und DCSync: Wie stille Rechte Domain Admin öffnen
• AD-Trust-Angriffe: Wie Unterdomänen das Gesamtstruktur-Risiko erhöhen
• Active Directory Privilegierte Konten: Protected Users, Delegation und Dienstkonto-Lücken
• AD Gruppenverschachtelung: Versteckte DA-Pfade
• AD Sicherheitsüberwachung: Event IDs und SIEM

Validierungs-Checkliste

Bevor Sie den Review abschließen, führen Sie die Enumeration bekannter privilegierter RIDs in sIDHistory erneut gegen die Produktivumgebung aus und bestätigen Sie, dass keine unerklärten Treffer mehr bestehen. Verifizieren Sie, dass die erweiterte Audit-Richtlinie auf jedem Domain Controller aktiviert ist, sodass die Event-IDs 4765/4766 tatsächlich generiert werden und nicht nur theoretisch verfügbar sind. Bestätigen Sie, dass Replikationsrechte und DC-Logon-Zugriff auf die Konten beschränkt wurden, die sie wirklich benötigen, und dokumentieren Sie die Belege — die Enumerationsausgabe und den Zustand der Audit-Richtlinie — als Baseline für das nächste wiederkehrende Audit.