AD-Trust-Angriffe: Risiko von Unterdomäne bis Root

Was sind AD-Trust-Angriffe?

AD-Trust-Angriffe missbrauchen die Authentifizierungs- und Autorisierungspfade, über die eine Domäne oder Gesamtstruktur auf Ressourcen einer anderen zugreifen kann. Trusts sind ein normaler Bestandteil von AD DS. Parent-Child-Trusts innerhalb einer Gesamtstruktur, externe Trusts, Shortcut-Trusts und Forest-Trusts existieren alle, um reale Zugriffsanforderungen zu unterstützen. Das Risiko besteht darin, dass ein Trust auch die Sicherheitsgrenze erweitert, die Verteidiger verstehen müssen.

Ein Trust bedeutet nicht automatisch eine Kompromittierung. Das praktische Risiko hängt von Trust-Typ, Richtung, Transitivität, SID-Filtering-Verhalten, Selective Authentication, administrativer Tiering-Struktur und dem Kompromittierungsgrad in der Quelldomäne ab. Aber in einer Multi-Domain-Gesamtstruktur kann eine Kompromittierung einer Unterdomäne zu einem Vorfall auf Gesamtstruktur-Ebene werden, wenn der Angreifer Kerberos-Trust-Pfade, privilegierte SIDs oder administrativen Zugriff missbrauchen kann, der die Grenze überschreitet.

Ein guter Review beginnt mit drei Fragen:

welche Trusts existieren und wer sie besitzt
welche Trusts noch eine aktuelle geschäftliche Anforderung haben
ob jeder Trust die domänenübergreifende Autorisierung auf den vorgesehenen Umfang begrenzt

Wie Active-Directory-Trusts funktionieren

Microsoft dokumentiert, dass AD DS Domain- und Forest-Trust-Beziehungen nutzt, um Authentifizierung über Domänen und Gesamtstrukturen hinweg bereitzustellen. Bevor ein Zugriff über einen Trust möglich ist, berechnet Windows einen Trust-Pfad zwischen dem Domänencontroller für die Ressource und einem Domänencontroller in der Domäne des anfragenden Kontos.

Trusts können ein- oder zweiseitig sein. Sie können außerdem transitiv oder nicht-transitiv sein. In einer On-Premises-AD-DS-Gesamtstruktur erstellen neue Unterdomänen automatisch zweiseitige, transitive Trust-Beziehungen mit der übergeordneten Domäne. Diese Transitivität lässt Authentifizierungsanfragen entlang der Trust-Pfade über den Domänenbaum hinweg folgen, sofern die Berechtigungen den Zugriff erlauben.

Dieses Verhalten ist nützlich, bedeutet aber, dass Verteidiger eine Unterdomäne nicht als Verzeichnis mit geringer Konsequenz behandeln sollten. Wenn eine Unterdomäne schlecht administriert, übermäßig vertraut oder auf Domänencontroller-Ebene kompromittiert ist, muss die Gesamtstruktur als verbundenes Sicherheitssystem überprüft werden.

Wo SID-Filtering ansetzt

Kerberos-Tickets enthalten Autorisierungsdaten, einschließlich SIDs, die für Zugriffsentscheidungen verwendet werden. SID History existiert für Migrationsszenarien, in denen ein Konto den Zugriff auf Ressourcen behalten muss, die noch auf eine alte SID verweisen. Microsofts DsAddSidHistory-Dokumentation weist darauf hin, dass das Hinzufügen von SIDs zum sIDHistory-Attribut eines Sicherheitsprinzipals eine sicherheitskritische Operation ist, und dass ein nicht autorisierter Benutzer unautorisierten Zugriff auf die Ressourcen einer gestohlenen oder nicht autorisierten SID erhalten kann, wenn eine Ressourcendomäne der Kontodomäne dieser SID vertraut.

SID-Filtering wurde entwickelt, um dieses Risiko an Trust-Grenzen zu reduzieren. Microsofts PAC-Spezifikation beschreibt das SID-Filtering-Verhalten über Trust-Grenzen hinweg, einschließlich Cross-Forest- und externer Trusts. Das genaue Verhalten hängt von der Trust-Grenze und der SID-Kategorie ab. Es ist daher wichtig, das Thema nicht auf ein einzelnes Flag zu reduzieren, ohne den Trust-Typ zu verstehen.

Bei externen Trusts prüfen Administratoren üblicherweise den Quarantäne- oder SID-Filtering-Status. Bei Forest-Trusts können außerdem Selective Authentication und Forest-Trust-Einstellungen relevant sein. Bei Parent-Child-Trusts innerhalb derselben Gesamtstruktur ist das größere Thema oft architektonisch: Alle Domänen sind Teil desselben Forest-Trust-Gefüges, sodass eine Domänenkompromittierung Folgen haben kann, die über die lokale Domäne hinausgehen.

Umfang und Voraussetzungen

Dies ist keine Behauptung, dass jeder AD-Trust ausnutzbar ist. Trust-Missbrauch mit hoher Auswirkung erfordert normalerweise eine starke Voraussetzung, etwa:

die Kompromittierung eines Domänencontrollers oder eines gleichwertigen domänenweiten Geheimnisses in der Quelldomäne
die Fähigkeit, Kerberos-Autorisierungsdaten zu fälschen oder zu manipulieren
einen Trust-Pfad, der den resultierenden Autorisierungskontext akzeptiert
Zielressourcen, die den Zugriff anhand privilegierter SIDs oder domänenübergreifender Gruppen autorisieren
eine schwache Trennung administrativer Tiers über Domänen hinweg

Deshalb sollte der Trust-Review an Incident-Response-Annahmen gekoppelt sein. Wenn das krbtgt-Geheimnis einer Unterdomäne oder deren Domänencontroller kompromittiert sind, behandeln Sie den Vorfall nicht als isoliert, bevor Trust-Pfade, privilegierte Sitzungen und domänenübergreifende Autorisierung überprüft wurden.

Häufige Trust-Missbrauchsmuster

Von der Unterdomäne zum Parent oder Forest Root

Das klassische Eskalationsszenario beginnt mit einer Domänenkompromittierung in einer Unterdomäne. Kontrolliert der Angreifer die Quelldomäne tief genug, versucht er möglicherweise, Kerberos-Material zu fälschen, das privilegierte Autorisierungsdaten in Richtung einer übergeordneten oder Forest-Root-Ressource trägt. Ob dies gelingt, hängt vom Trust-Verhalten und der Filterung ab, aber die Lehre für Verteidiger ist klar: Unterdomänen benötigen Schutz auf Tier-0-Niveau, wenn sie Teil derselben Gesamtstruktur sind.

Veraltete externe Trusts

Alte externe Trusts sind nach Migrationen, Partnerintegrationen, Übernahmen oder befristeten Projekten üblich. Ein veralteter Trust kann weiterhin Authentifizierungspfade zulassen, die niemand mehr aktiv besitzt. Selbst wenn SID-Filtering aktiviert ist, bleibt ein unnötiger Trust eine unnötige Angriffsfläche.

Schwaches Trust-Ownership

Ein Trust ohne Owner wird schwer zu ändern, weil niemand die Entfernung genehmigen kann. Das führt zu dauerhaften Ausnahmen. Jeder verbleibende Trust sollte einen Anwendungs- und einen Business-Owner, eine Authentifizierungsrichtung, erwartete Nutzer und ein Review-Datum haben.

Privilegierte Administration über Grenzen hinweg

Trusts werden gefährlicher, wenn Administratoren privilegierte Anmeldeinformationen domänen- oder gesamtstrukturübergreifend verwenden. Eine privilegierte Sitzung in einer Domäne mit geringerer Governance kann Anmeldeinformationen oder Token offenlegen, die eine Bewegung in eine sensiblere Domäne ermöglichen. Trust-Härtung und die Härtung des privilegierten Zugriffs müssen gemeinsam betrachtet werden.

Erkennung

Kein einzelnes Windows-Event beweist einen Trust-Angriff. Die Erkennung erfordert ein Trust-Inventar, die Auswertung von Kerberos-Events, den Kontext privilegierter Logons und Change-Monitoring.

Windows-Event- und Log-Quellen

Signal	Warum es wichtig ist
4769 Kerberos-Serviceticket-Anfragen	Hilft bei der Untersuchung domänen- oder realmübergreifender Serviceticket-Aktivität.
4624 erfolgreiche Anmeldungen	Zeigt administrative oder domänenübergreifende Logons auf Zielsystemen.
4672 Zuweisung besonderer Rechte	Nützlich, wenn ein Logon unerwartet hochprivilegierte Rechte erhält.
Änderungen an Trust-Objekten	Änderungen an Trust-Richtung, -Attributen oder Filterverhalten können die Grenze verändern.
Änderungen privilegierter Gruppen	Domänenübergreifende Gruppenmitgliedschaft oder verschachtelte Gruppenänderungen können Trust-basierte Pfade offenlegen.

Event-Daten benötigen Kontext. Ein domänenübergreifendes 4769-Event kann für eine Anwendung normal sein. Ein domänenübergreifender administrativer Logon von einem unerwarteten Konto, nach einem Vorfall in der Unterdomäne, ist etwas ganz anderes.

Trust-Inventar-Review

Inventarisieren Sie alle Trusts und klassifizieren Sie sie:

Get-ADTrust -Filter * |
  Select-Object Name, TrustType, TrustDirection, ForestTransitive, SelectiveAuthentication, SIDFilteringQuarantined

Nutzen Sie das Ergebnis zur Triage. SIDFilteringQuarantined = False ist nicht automatisch ein Beweis für Kompromittierung oder Fehlkonfiguration, sollte aber einen Owner und eine Begründung haben. Wenn niemand erklären kann, warum der Trust seine aktuellen Einstellungen benötigt, gehört er in die Cleanup-Queue.

Remediation

Der sicherste Trust ist der, der nicht mehr existiert, weil die geschäftliche Abhängigkeit beendet wurde. Härten Sie die verbleibenden Trusts entsprechend ihrem Typ und Zweck.

1. Veraltete Trusts entfernen

Prüfen Sie zuerst alte Partner-, Migrations-, Test- und Übernahme-Trusts. Wenn ein Trust keinen Owner, keine aktive Anwendungsabhängigkeit und keine aktuelle Zugriffsanforderung hat, entfernen Sie ihn über den normalen Change-Prozess.

2. SID-Filtering und Quarantäne überprüfen

Aktivieren Sie bei externen Trusts, wo kompatibel, Quarantäne oder SID-Filtering und validieren Sie die abhängigen Workflows. Der Microsoft-Befehl netdom trust unterstützt die Option /Quarantine für die Trust-Verwaltung, und die Befehlsdokumentation weist darauf hin, dass No jede SID akzeptiert. Diese Einstellung sollte nicht dem historischen Zufall überlassen bleiben.

3. Selective Authentication dort einsetzen, wo angemessen

Bei Forest-Trusts kann Selective Authentication einschränken, welche Benutzer aus der vertrauten Gesamtstruktur sich bei bestimmten Ressourcen authentifizieren können. Es ist kein Ersatz für gute ACLs oder gute Hygiene beim privilegierten Zugriff, reduziert aber die breite Authentifizierungsreichweite.

4. Unterdomänen als hochkonsequent behandeln

Gehen Sie nicht davon aus, dass eine Unterdomäne eine administrative Zone mit geringem Risiko ist. Sichern Sie Domänencontroller, privilegierte Gruppen, den Umgang mit krbtgt und administrative Workstations der Unterdomäne mit derselben Ernsthaftigkeit wie den Forest Root, wenn Trust-Pfade domänenübergreifenden Zugriff erlauben.

5. Privilegierte Sitzungen über Grenzen hinweg reduzieren

Verwenden Sie nicht routinemäßig privilegierte Konten des Forest Root oder der übergeordneten Domäne in weniger vertrauten Unterdomänen. Wenn Administratoren die Grenze überschreiten müssen, verwenden Sie dedizierte Konten, kontrollierte Admin-Workstations und Protokollierung, die die Sitzung sichtbar macht.

Was Sie nicht blind ändern sollten

Aktivieren oder entfernen Sie Trust-Kontrollen nicht, ohne den abhängigen Authentifizierungsablauf zu testen. SID-Filtering, Quarantäne und Selective Authentication können Legacy-Zugriffsmuster, Migrations-Workflows oder Anwendungen brechen, die auf breitem domänenübergreifendem Zugriff aufgebaut wurden. Dieses Kompatibilitätsrisiko ist kein Grund, den Trust unsicher zu lassen; es ist ein Grund, die Abhängigkeit zu dokumentieren, in einem kontrollierten Fenster zu testen und breiten Trust nach Möglichkeit durch expliziten Zugriff zu ersetzen. Kann das Unternehmen einen riskanten Trust nicht sofort entfernen, sollte die Ausnahme einen Owner, ein Enddatum, einen Monitoring-Plan und kompensierende Kontrollen für privilegierten Zugriff enthalten.

Validierung nach der Trust-Härtung

Validieren Sie nach einer Trust-Änderung sowohl Sicherheit als auch Geschäftsfunktion:

führen Sie das Trust-Inventar erneut aus und dokumentieren Sie Richtung, Typ, Transitivität, Selective Authentication und SID-Filtering-Status
bestätigen Sie, dass Anwendungsteams die vom Trust abhängigen Workflows erneut getestet haben
überprüfen Sie, ob alte Migrations- oder Partner-Trusts entfernt und nicht nur dokumentiert wurden
überprüfen Sie Kerberos- und Logon-Aktivität über den Trust hinweg nach der Änderung
prüfen Sie, ob sich privilegierte Benutzer weiterhin über die Grenze hinweg authentifizieren
dokumentieren Sie Ausnahmen mit Owner, Ablaufdatum und kompensierenden Kontrollen

Ein Trust-Review ist nur erfolgreich, wenn die verbleibenden Trusts beabsichtigt, im Besitz, überwacht und auf den vom Unternehmen weiterhin benötigten Zugriff beschränkt sind.

Wie EtcSec dies erkennt

EtcSec auditiert Trust-Beziehungen und hebt Trust-Pfade hervor, die die Wahrscheinlichkeit einer domänenübergreifenden Eskalation erhöhen.

Trust-bezogene Findings sind am nützlichsten, wenn sie mit dem umgebenden Angriffspfad korreliert werden: ob eine Unterdomäne bereits eine schwache administrative Hygiene aufweist, ob ein veralteter externer Trust noch existiert und ob hochwertige Identitäten oder delegierte Rechte auf beiden Seiten der Grenze liegen.

AD-Trust-Angriffe: Wie Unterdomänen das Gesamtstruktur-Risiko erhöhen