Active Directory Audit riskanter ACEs auf verwaisten und Cross-Domain-SIDs: Der ACL-Missbrauch, den die meisten Tools nicht einmal auflösen können

Ein Active Directory Audit für riskante ACEs auf verwaisten und Cross-Domain-SIDs stellt eine Frage, die ein Standard-ACL-Review nie erreicht: Welche Berechtigungen in Ihrem Verzeichnis werden von Trustees gehalten, die niemand benennen kann? Jeder Access Control Entry (ACE) in einer AD-DACL identifiziert seinen Trustee über eine Security Identifier (SID), und Review-Tools lösen diese SID fast immer in einen sprechenden Namen auf, bevor sie ihn anzeigen. Aber was passiert, wenn die SID zu gar nichts auflöst — und der ACE, in dem sie steckt, volle Kontrolle gewährt?

Das ist eine andere Frage als die, die ein normales Review stellt. Ein normales Review fragt: „Welche aktiven Konten besitzen GenericAll auf Tier 0?" Dieses hier fragt: „Welche Berechtigungen werden von Trustees gehalten, die mein Verzeichnis nicht benennen kann?" Beide erzeugen völlig unterschiedliche Befunde, und der zweite wird routinemäßig übersprungen: Ein Eintrag, dessen Trustee sich nicht auflösen lässt, wird von einem Report leicht als leere Zeile, als Rohstring oder gar nicht dargestellt.

Was ein Active Directory Audit für riskante ACEs auf verwaisten und Cross-Domain-SIDs prüft

Eine SID ist kein Name. Microsofts Referenz Security Identifiers beschreibt die Struktur präzise: Bei einem Domänenkonto wird „die SID eines Sicherheitsprinzipals durch Verkettung der SID der Domäne mit einem Relative Identifier (RID) für das Konto erzeugt." Alles vor dem letzten -RID-Segment ist der Domänenbezeichner; das letzte Segment identifiziert den Prinzipal innerhalb dieser Domäne.

Diese Struktur macht eine defekte Referenz klassifizierbar. Nehmen Sie eine Trustee-SID, die zu keinem Benutzer, keiner Gruppe, keinem Computer, keiner Organisationseinheit und keinem well-known Principal auflöst, und vergleichen Sie ihr Domänenpräfix mit Ihrer eigenen Domänen-SID:

Der Unterschied ist wichtig wegen einer Garantie, die Microsoft in derselben Referenz explizit gibt: „SIDs bleiben immer eindeutig. Sicherheitsautoritäten vergeben niemals dieselbe SID zweimal und verwenden SIDs gelöschter Konten nie erneut." Eine verwaiste lokale SID kann daher nicht durch das Anlegen eines neuen Kontos mit demselben Namen zurückerlangt werden — das neue Konto erhält eine neue RID. Das ist tatsächlich beruhigend, und deshalb ist dieser Fall kein Fünf-Alarm-Feuer.

Der domänenübergreifende Fall bietet keine solche Garantie, weil der Prinzipal schlicht irgendwo existieren kann, wo Sie ihn nicht sehen. Eine legitime domänenübergreifende Berechtigung materialisiert sich normalerweise in Ihrem Verzeichnis als Foreign-Security-Principal-Objekt — „der Sicherheitsprinzipal aus einer externen Quelle." Existiert kein passendes foreignSecurityPrincipal, betrachten Sie entweder eine beabsichtigte Berechtigung, deren begleitendes Objekt nie erstellt wurde, oder ein Überbleibsel eines Trusts, der inzwischen entfernt oder umkonfiguriert wurde.

Die Rechte, die einen nicht auflösbaren Trustee gefährlich machen

Nicht jeder ACE mit defektem Trustee ist relevant. Relevant sind die, die Rechte tragen, mit denen der Inhaber das Objekt übernehmen kann. Microsofts Referenz ADS_RIGHTS_ENUM nennt die genauen Bits:

Hier lauert eine Falle, die selbstgebaute Audit-Skripte still und leise ruiniert. Die obigen generischen Bits sind die rohen ADSI-Werte. Die .NET-Enumeration ActiveDirectoryRights, die PowerShell verwendet, nutzt stattdessen die gemappten Directory-Service-Werte: GenericAll ist 983551 (0xF01FF), nicht 0x10000000. Und 0xF01FF ist ein zusammengesetzter Wert, der ReadProperty (16) und ListChildren (4) enthält.

Ein Skript, das $ace.ActiveDirectoryRights -band 'GenericAll' schreibt und ein Ergebnis ungleich Null als volle Kontrolle behandelt, markiert also praktisch jeden lesenden ACE im Verzeichnis. Der korrekte Test ist ein Gleichheitstest gegen die vollständige Maske, plus separate Prüfungen der rohen generischen Bits und der Standard-Schreibrechte:

$mask = [int]$ace.ActiveDirectoryRights
$isDangerous =
    (($mask -band 0x10000000) -ne 0) -or          <# ADS_RIGHT_GENERIC_ALL   #>
    (($mask -band 0x40000000) -ne 0) -or          <# ADS_RIGHT_GENERIC_WRITE #>
    (($mask -band 0x000F01FF) -eq 0x000F01FF) -or <# volle Kontrolle (gemappt) #>
    (($mask -band 0x00040000) -ne 0) -or          <# WRITE_DAC               #>
    (($mask -band 0x00080000) -ne 0)              <# WRITE_OWNER             #>

Microsoft hat selbst einen davon ausgeliefert

Der überzeugendste Beleg dafür, dass defekte SID-Referenzen ein systemisches Phänomen sind und keine Kuriosität, stammt aus Microsofts eigener Dokumentation dessen, was adprep /domainprep mit Ihrem Verzeichnis anstellt.

Die Referenz Active Directory domain-wide schema updates listet die Operationen auf, die bei der Vorbereitung eines Windows Server 2016-Domänencontrollers ausgeführt werden. Operation 85 wird beschrieben als Änderung des Domain Naming Context, „um domain\Key Admins und rootdomain\Enterprise Key Admins zu erlauben, das Attribut msds-KeyCredentialLink zu ändern." Die Berechtigungsspalte hält dann fest, was tatsächlich passiert ist:

(OA;CI;RPWP;5b47d60f-6090-40b2-9f37-2a4de88f3063;;Key Admins)
(OA;CI;RPWP;5b47d60f-6090-40b2-9f37-2a4de88f3063;;Enterprise Key Admins in root
 domain, but in nonroot domains resulted in a bogus domain-relative ACE with a
 nonresolvable -527 SID)

Lesen Sie diese letzte Klausel noch einmal. Microsoft dokumentiert hier, dass diese Operation in jeder Nicht-Root-Domäne eines Multi-Domain-Forests einen ACE hinterlassen hat, dessen Trustee eine nicht auflösbare SID ist. Enterprise Key Admins ist eine Forest-Ebenen-Gruppe, die im Forest-Root liegt; die Operation baute die SID relativ zur lokalen Domäne auf und erzeugte damit eine -527-Referenz auf einen Prinzipal, den diese Domäne nicht hat.

Zwei weitere Operationen räumen im Nachhinein auf — und sie werden nicht zusammen ausgeliefert, was entscheidet, ob Ihre Domäne einen oder beide Fixes erhalten hat. Operation 87 steht in derselben Windows-Server-2016-Tabelle (Operationen 82-88, wonach das revision-Attribut auf CN=ActiveDirectoryUpdate,CN=DomainUpdates,CN=System auf 15 gesetzt wird); sie löscht „den ACE, der der falschen domänenrelativen Enterprise-Key-Admins-Gruppe volle Kontrolle gewährt" und fügt einen korrekten hinzu. Operation 89 steht in einer anderen Tabelle — Windows Server (Semi-Annual Channel) domain-wide updates, die dasselbe revision-Attribut auf 16 setzen — und geht weiter: Sie löscht den breiten Eintrag (A;CI;RPWPCRLCLOCCDCRCWDWOSDDTSW;;;Enterprise Key Admins) und ersetzt ihn durch (OA;CI;RPWP;5b47d60f-6090-40b2-9f37-2a4de88f3063;;Enterprise Key Admins) — volle Kontrolle über den Naming Context wird auf Schreibzugriff auf ein einziges Attribut verengt. Dieser Revision-Wert verrät, welchen der beiden Cleanups Ihre Domäne tatsächlich erhalten hat.

Diese SDDL-Strings lassen sich über Microsofts Referenz ACE Strings dekodieren: A ist ein Access-Allowed-ACE, OA ein objektspezifischer, CI markiert Container-Vererbbarkeit, und RPWPCRLCLOCCDCRCWDWOSDDTSW verkettet Read Property, Write Property, Control Access, List Children, List Object, Create Child, Delete Child, Read Control, Write DAC, Write Owner, Delete, Delete Tree und Self-Write. Das ist volle Kontrolle unter anderem Namen — inklusive der beiden Rechte, mit denen ein Inhaber die DACL neu schreiben und den Besitz an sich reißen kann.

🚨 Gefahr: Wenn Ihr Forest mit den originalen Windows-Server-2016-Medien vorbereitet wurde und die späteren Cleanup-Operationen nie liefen, sitzt möglicherweise noch immer ein -527-ACE mit weitreichenden Rechten über einen gesamten Domain Naming Context in einer Child-Domäne — und zeigt ins Leere.

Warum die beiden Fälle unterschiedlich schwer wiegen

Eine verwaiste lokale SID und eine domänenübergreifende SID sehen in einer DACL identisch aus — ein nicht auflösbarer Trustee —, verdienen aber unterschiedliche Priorität.

Verwaiste lokale SID. Niemand kann diese Berechtigung über eine normale Anmeldung ausüben. Weil AD keine RIDs recycelt, würde die Wiedererlangung genau dieser SID das Einschleusen in die sIDHistory eines Kontos erfordern — und das setzt bereits den privilegierten Zugriff voraus, den ein Angreifer mit dieser Berechtigung erst erlangen wollte. Es ist ein Aufräumposten und ein Problem für den Audit-Trail, kein aktiver Pfad. Lassen Sie ihn liegen, überlebt er den Vorfall, der ihn erzeugt hat, und vergrößert still den Blast Radius jeder künftigen Migration.

Domänenübergreifende SID. Diese ist lebendig, sobald die referenzierte Domäne jemals erreichbar wird. Microsofts Leitfaden zur SID-Filterung beschreibt den Mechanismus unverblümt: „Unter bestimmten Umständen ist es Angreifern oder betrügerischen Administratoren, die einen Domänencontroller in einer vertrauenswürdigen Domäne kompromittiert haben, möglich, das SID-History-Attribut (sIDHistory) zu nutzen, um SIDs mit neuen Benutzerkonten zu verknüpfen und sich so unautorisierte Rechte zu verschaffen." Microsoft Defender for Identitys Accounts-Posture-Assessment formuliert die Forest-Ebenen-Version erneut: „Wenn Sie einen Forest-Trust ohne aktivierte SID-Filterung (auch Quarantine genannt) haben, ist es möglich, eine SID aus einem anderen Forest einzuschleusen; sie wird bei der Authentifizierung dem Benutzer-Token hinzugefügt und für Zugriffsentscheidungen verwendet."

Zusammengenommen wird eine veraltete domänenübergreifende ACE zu einer vorpositionierten Berechtigung. Ein Angreifer, der die referenzierte Domäne kontrolliert — oder später wiederherstellt — muss Ihre DACL überhaupt nicht ändern. Die Berechtigung steht bereits geschrieben da. Er braucht nur ein Token, das diese SID trägt. Das ist dieselbe Trust-Boundary-Logik, die in Active Directory Trust-Angriffe und im Audit zu Trust-SID-Filterung und selektiver Authentifizierung behandelt wird; der Unterschied ist hier, dass die Berechtigung die Löschung des Trusts überlebt, weil das Löschen eines Trusts keine ACLs bereinigt.

Zwei weitere Rechte im selben blinden Fleck

Defekte SID-Referenzen teilen einen blinden Fleck mit zwei weiteren Berechtigungsmustern, die Standard-Reviews aus einem anderen Grund übersehen: Sie sind kein GenericAll, weshalb keyword-getriebene Audits sie nie zu Gesicht bekommen.

Self-Membership auf Gruppen. Das validierte Schreibrecht Self-Membership, GUID bf9679c0-0de6-11d0-a285-00aa003049e2, wird dokumentiert als „Validiertes Schreibrecht, um die Aktualisierung der Mitgliedschaft einer Gruppe im Sinne von Hinzufügen/Entfernen des eigenen Kontos zu ermöglichen." Sein Anzeigename im ACL-Editor lautet Sich selbst als Mitglied hinzufügen/entfernen, und es gilt nur für die Klasse Group. Auf einer privilegierten Gruppe gewährt, ist es eine einstufige Eskalation, bei der nie ein Dritter member schreibt — der Prinzipal fügt sich selbst hinzu. Microsofts Dsacls-Referenz bestätigt die Eingrenzung: Die Berechtigung WS ist „nur bei Gruppenobjekten und wenn {ObjectType | Property} 'member' ist, sinnvoll." Das ist die Rechtefamilie, die gefährliche Gruppenverschachtelung noch schlimmer macht, als sie aussieht.

Enterprise Key Admins über msDS-KeyCredentialLink. Laut Active Directory Security Groups trägt Enterprise Key Admins die well-known RID 527, ist eine globale Gruppe in CN=Users, hat keine Standardmitglieder und wird durch AdminSDHolder geschützt. Das Attribut, das sie kontrolliert, msDS-KeyCredentialLink (schemaIdGuid 5b47d60f-6090-40b2-9f37-2a4de88f3063), „enthält Schlüsselmaterial und Nutzungsinformationen" und wurde „erstmals in Windows Server 2016 implementiert."

Schreibzugriff auf dieses Attribut ist der gesamte Shadow-Credentials-Angriff. In Elad Shamirs ursprünglicher Shadow-Credentials-Recherche: „Wenn Sie auf die msDS-KeyCredentialLink-Eigenschaft eines Benutzers schreiben können, können Sie ein TGT für diesen Benutzer erhalten" und „Sie können den NT-Hash dieses Benutzers abrufen." Die Voraussetzungen sind ein Windows-Server-2016-Domänencontroller, ein Server-Authentication-Zertifikat darauf und die Windows-Server-2016-Funktionsebene — und der platzierte Credential „würde selbst dann bestehen bleiben, wenn der Benutzer/Computer sein Passwort ändert." Die Technik selbst behandeln wir in Shadow Credentials: Missbrauch von msDS-KeyCredentialLink.

Die Audit-Frage ist enger gefasst als der Angriff. Enterprise Key Admins wird leer ausgeliefert. Was Sie prüfen, ist, ob der ACE der Gruppe über Ihren Domain Naming Context das begrenzte RPWP auf 5b47d60f-… ist, das Operation 89 installiert, oder der unbegrenzte Full-Control-Eintrag, den die ursprüngliche Vorbereitung hinterlassen hat — und ob der Trustee überhaupt auflöst.

Erkennung

Das Auditieren dafür braucht zwei Durchläufe: einen punktuellen Sweep der vorhandenen DACLs und Change-Auditing, damit neue defekte Referenzen erkannt werden, sobald sie auftauchen.

Vorhandene DACLs nach nicht auflösbaren gefährlichen Trustees durchsuchen

Fordern Sie die rohen SIDs an, nicht Kontonamen. .NET von vornherein nach NTAccount-Objekten zu fragen, wirft genau bei den Einträgen eine Ausnahme, nach denen Sie suchen: SecurityIdentifier.Translate löst IdentityNotMappedException aus, wenn „einige oder alle Identity-Referenzen nicht übersetzt werden konnten."

Import-Module ActiveDirectory

$domainSid = (Get-ADDomain).DomainSID.Value
$root      = (Get-ADRootDSE).defaultNamingContext

Get-ADObject -SearchBase $root -LDAPFilter '(objectClass=*)' -Properties nTSecurityDescriptor |
  ForEach-Object {
    $dn = $_.DistinguishedName
    $_.nTSecurityDescriptor.GetAccessRules(
        $true, $true, [System.Security.Principal.SecurityIdentifier]) |
      Where-Object { $_.AccessControlType -eq 'Allow' } |
      ForEach-Object {
        $mask = [int]$_.ActiveDirectoryRights
        $dangerous =
            (($mask -band 0x10000000) -ne 0) -or
            (($mask -band 0x40000000) -ne 0) -or
            (($mask -band 0x000F01FF) -eq 0x000F01FF) -or
            (($mask -band 0x00040000) -ne 0) -or
            (($mask -band 0x00080000) -ne 0)
        if (-not $dangerous) { return }

        $sid = $_.IdentityReference
        try {
            $null = $sid.Translate([System.Security.Principal.NTAccount])
            return
        } catch [System.Security.Principal.IdentityNotMappedException] { }

        $scope = if ($sid.Value.StartsWith("$domainSid-")) {
                     'Verwaiste lokale SID'
                 } else {
                     'Domänenübergreifende SID'
                 }

        [pscustomobject]@{
            ObjectDN = $dn
            Trustee  = $sid.Value
            Rights   = $_.ActiveDirectoryRights
            Scope    = $scope
        }
      }
  } | Sort-Object Scope, ObjectDN | Format-Table -AutoSize

Führen Sie dies zunächst gegen eine einzelne OU aus. Ein vollständiger Naming-Context-Sweep liest jeden Security Descriptor der Domäne und ist nichts, was Sie während der Geschäftszeiten auf einen Produktions-DC loslassen sollten.

Die beiden spezifischen Muster prüfen

Beide Abfragen unten fordern SecurityIdentifier-Trustees aus demselben Grund wie der Sweep: Die .Access-Eigenschaft übersetzt nach NTAccount und wirft IdentityNotMappedException genau bei den ACEs, um die es in diesem Artikel geht.

$root    = (Get-ADRootDSE).defaultNamingContext
$sidType = [System.Security.Principal.SecurityIdentifier]

<# Key Admins (-526) und Enterprise Key Admins (-527) auf dem Domain NC:
   begrenzt, oder volle Kontrolle? Nach der RID matchen, nicht nach dem Namen — in einer
   Nicht-Root-Domäne ist der falsche Trustee genau der, der sich nicht zu
   "Key Admins" auflösen lässt, ein Namensfilter übersieht den Befund also stillschweigend. #>
(Get-ADObject $root -Properties nTSecurityDescriptor).nTSecurityDescriptor.GetAccessRules(
    $true, $true, $sidType) |
  Where-Object { $_.IdentityReference.Value -match '-52[67]$' } |
  Select-Object IdentityReference, ActiveDirectoryRights, ObjectType

<# Self-Membership-Berechtigungen auf Gruppen: das validierte Schreibrecht, oder ein unbegrenztes DS_SELF #>
$selfMembership = [guid]'bf9679c0-0de6-11d0-a285-00aa003049e2'
Get-ADGroup -Filter * -Properties nTSecurityDescriptor | ForEach-Object {
    $g = $_
    $g.nTSecurityDescriptor.GetAccessRules($true, $true, $sidType) |
      Where-Object {
        $_.AccessControlType -eq 'Allow' -and (
          $_.ObjectType -eq $selfMembership -or
          ($_.ObjectType -eq [guid]::Empty -and
           ([int]$_.ActiveDirectoryRights -band 0x8) -ne 0)
        )
      } |
      Select-Object @{n='Group';e={$g.DistinguishedName}},
                    IdentityReference, ActiveDirectoryRights
}

Ein ObjectType von 5b47d60f-6090-40b2-9f37-2a4de88f3063 bei der ersten Abfrage ist die begrenzte, erwartete Form. Ein leeres ObjectType mit einer Full-Control-Maske ist der unbegrenzte Eintrag, der ersetzt hätte werden sollen — und ein -527-Trustee, den Sie keiner lebenden Enterprise-Key-Admins-Gruppe zuordnen können, ist der nicht auflösbare Fall selbst.

Neue Fälle erkennen, sobald sie auftreten

Microsofts Referenz zu Event 5136 legt die Voraussetzungen und die Leseregeln fest. Das Ereignis gehört zur Subkategorie Audit Directory Service Changes, und „damit dieses Ereignis erzeugt wird, muss das geänderte Objekt einen passenden Eintrag in der SACL haben: die Write-Auditierung für bestimmte Attribute" — das alleinige Aktivieren der Subkategorie reicht nicht, die SACL muss auf den Objekten existieren, die Sie interessieren.

Erwarten Sie Paare, keine Einzelereignisse: „Bei einer Änderungsoperation sehen Sie typischerweise zwei 5136-Ereignisse für eine Aktion, mit unterschiedlichen Operation-Type-Feldern: 'Value Deleted' und dann 'Value Added'." Microsofts eigene Empfehlung ist, auf das Value-Added-Ereignis zu alarmieren und über die Correlation ID den vorherigen Wert aus seinem Partner zu ziehen.

Ein Detail derselben Seite dient zugleich als Diagnose für diesen ganzen Artikel: „Event Viewer versucht automatisch, SIDs aufzulösen und den Kontonamen anzuzeigen. Lässt sich die SID nicht auflösen, sehen Sie die Rohdaten im Ereignis." Eine rohe SID, wo Sie einen Namen erwartet haben, ist der Hinweis — in einem Ereignis und in einem ACL-Report.

Behebung

1. Bestätigen, dass der adprep-Cleanup lief. Prüfen Sie in jeder Nicht-Root-Domäne die DACL des Domain NC auf ACEs, deren Trustee auf -527 endet. Finden Sie einen Full-Control-Eintrag — insbesondere einen, der nicht auflöst — sehen Sie den Zustand vor Operation 87/89. Das revision-Attribut auf CN=ActiveDirectoryUpdate,CN=DomainUpdates,CN=System verrät, wie weit die Vorbereitung kam: 15 bedeutet, die Operationen 82-88 sind abgeschlossen, 16 bedeutet, Operation 89 ebenfalls.

2. Klassifizieren, bevor Sie löschen. Vergleichen Sie für jeden nicht auflösbaren Trustee das Domänenpräfix mit Ihrer Domänen-SID und mit den SIDs jeder Domäne, der Sie vertrauen. Eine domänenübergreifende SID, die zu einem aktuellen Trust-Partner passt, ist wahrscheinlich eine beabsichtigte Berechtigung ohne ihr foreignSecurityPrincipal-Objekt, und sie zu löschen wird etwas kaputtmachen. Eine, die zu keinem aktuellen Trust passt, ist eine veraltete Referenz.

3. Nach SID entfernen, nicht nach Name. Hier wehrt sich das Tooling. Microsofts Dsacls-Referenz dokumentiert /R mit einem Trustee „als Benutzer@Domäne oder als Domäne\Benutzer" — eine Namensform, die per Definition für eine SID nicht existiert, die sich nicht auflösen lässt. Nutzen Sie PowerShell und übergeben Sie der API direkt eine SecurityIdentifier:

$dn  = 'DC=child,DC=corp,DC=local'
$sid = [System.Security.Principal.SecurityIdentifier]'S-1-5-21-1004336348-1177238915-682003330-527'

$acl = Get-Acl -Path "AD:\$dn"
$acl.GetAccessRules($true, $false, [System.Security.Principal.SecurityIdentifier]) |
  Where-Object { $_.IdentityReference -eq $sid } |
  ForEach-Object { $null = $acl.RemoveAccessRuleSpecific($_) }

Set-Acl -Path "AD:\$dn" -AclObject $acl

Beachten Sie das $false für vererbte Rechte: Ein geerbter ACE kann nicht am Kind entfernt werden, nur an dem Objekt, das ihn definiert. Beheben Sie das Elternobjekt und lassen Sie die Vererbung propagieren.

4. Den beabsichtigten Umfang wiederherstellen, nicht nur löschen. Wo der Eintrag Enterprise Key Admins über den Domain NC war, ist der Zielzustand dokumentiert: ein objektspezifischer ACE, der RPWP gewährt, begrenzt auf 5b47d60f-6090-40b2-9f37-2a4de88f3063, container-vererbbar. Löschen ohne Ersatz entfernt eine Berechtigung, die Windows Hello for Business Provisioning erwartet.

5. SID-Filterung aktiviert lassen — und nicht mit Quarantining verwechseln. Eine domänenübergreifende ACE ist nur ausnutzbar, wenn eine fremde SID Ihr Access-Token erreichen kann, und SID-Filterung ist das, was das verhindert. Über einen Forest-Trust ist die Filterung strukturell, nicht optional: MS-PAC legt fest, dass ein Cross-Forest-Trust „keine SIDs zulässt, die lokal zu seinem Forest gehören, über einen Cross-Forest-Trust zu passieren", und dass ForestSpecific-SIDs „für QuarantinedWithinForest-, CrossForest-, External- und QuarantinedExternal-Trust-Grenzen herausgefiltert werden." Defender for Identity, oben zitiert, behandelt das Fehlen dieser Filterung als den Befund. SID-Filter-Quarantining ist ein separater, strengerer Modus, und Microsofts Warnungen beziehen sich allein darauf: Quarantining nicht „auf Trusts innerhalb eines Forests anwenden, der nicht die Windows-Server-2003-Forest-Funktionsebene nutzt, weil das SIDs entfernt, die für die Active-Directory-Replikation erforderlich sind", und es „sollte nicht auf Forest-Trusts angewendet werden." Lesen Sie das als Anweisung zum Quarantine-Flag — niemals als Freibrief, SID-Filterung insgesamt abzuschalten.

6. Eine SACL auf die Objekte legen, die Ihnen wichtig sind. Event 5136 braucht sie. Mindestens: das Domain-NC-Objekt, CN=AdminSDHolder,CN=System, CN=Keys und jede Tier-0-Gruppe und -OU. Das Auditieren von nTSecurityDescriptor- und msDS-KeyCredentialLink-Schreibvorgängen macht aus dem nächsten Auftreten einen Alarm statt eines Befunds ein Jahr später. Der Artikel AdminSDHolder-SDProp-Hintertür behandelt, warum dieser Container ein dauerhaftes Monitoring verdient.

7. In das wiederkehrende Review einbetten. Verwaiste Trustees sammeln sich durch normale Vorgänge an — stillgelegte Dienstkonten, abgeschlossene Übernahmen, aufgelöste Trusts. Behandeln Sie den Sweep als Teil des laufenden Active-Directory-Sicherheitsaudits, nicht als einmaliges Remediation-Projekt.

Wie EtcSec dies erkennt

EtcSec teilt das Problem defekter Referenzen in zwei Prüfungen auf, genau weil die beiden Fälle unterschiedliches Risiko tragen. ORPHANED_SID_DANGEROUS_ACE meldet gewährende ACEs mit GenericAll, voller Kontrolle, WriteDACL, WriteOwner oder GenericWrite an einen Trustee, dessen Domänenpräfix mit der auditierten Domäne übereinstimmt, der aber zu keinem lebenden Prinzipal auflöst — den wahrscheinlich-gelöschtes-Konto-Fall, eingestuft als High. CROSS_DOMAIN_SID_DANGEROUS_ACE meldet dieselben Rechte an einen Trustee aus einer völlig anderen Domäne, eingestuft als Critical, weil diese Referenz in dem Moment ausnutzbar wird, in dem die referenzierende Domäne wieder erreichbar ist. Beide schließen bewusst eingebaute administrative Trustees und Deny-ACEs aus, sodass die Ausgabe die tatsächliche Exposition zeigt und nicht die normale Form des Verzeichnisses.

Daneben markiert ACL_SELF_MEMBERSHIP das validierte Schreibrecht Add/Remove-Self-as-Member auf Gruppenobjekten — begrenzt auf Gruppen, und bewusst ohne volle Kontrolle, damit es nicht einfach erneut meldet, was ACL_GENERICALL bereits gefunden hat. ENTERPRISE_KEY_ADMINS_FULL_ACCESS markiert den -527-Trustee mit entweder unbegrenzter voller Kontrolle oder Schreibzugriff auf msDS-KeyCredentialLink auf Domänenobjekten — der Zustand, den die Operationen 87 und 89 korrigieren sollen. ACL_WRITEDACL und ACL_WRITEOWNER decken dieselben beiden Rechte ab, wenn der Trustee doch auflöst, und TRUST_SID_FILTERING_DISABLED deckt die Trust-seitige Kontrolle ab, die entscheidet, ob eine domänenübergreifende Referenz je ein Token erreichen kann.

Zusammen mit den umfassenderen Prüfungen zu ACL-Missbrauch und DCSync und dem Audit zu DPAPI, Tombstone und Schema-Berechtigungen schließen diese die Lücke zwischen „wer besitzt gefährliche Rechte" und „welche gefährlichen Rechte werden von Prinzipalen gehalten, die niemand benennen kann."