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

Was sind AD-Trust-Angriffe?

AD-Trust-Angriffe nutzen die Beziehungen zwischen Domänen aus, um Berechtigungen, Authentifizierung oder administrative Wege domänenübergreifend zu missbrauchen. Der häufigste Denkfehler in realen Umgebungen ist, eine Unterdomäne als eigene Sicherheitsgrenze zu behandeln. Microsoft macht seit langem klar, dass im klassischen Active Directory nicht die Child Domain, sondern die Gesamtstruktur die eigentliche Sicherheitsgrenze ist. Wenn ein Angreifer also eine Unterdomäne tief genug kompromittiert, muss das Incident-Response-Team sofort prüfen, welche Wege in Richtung Forest Root, privilegierte Gruppen, Replikationsrechte und Admin-Sessions offenstehen.

Der Trust selbst ist dabei oft nur der sichtbare Teil des Problems. Wirklich kritisch werden AD-Trust-Angriffe dann, wenn Administratoren dieselben Konten in mehreren Domänen verwenden, wenn privilegierte Sessions auf Systemen der Unterdomäne landen oder wenn historische Delegationen und Gruppenverschachtelungen nie bereinigt wurden. Ein sauberer Review betrachtet deshalb nicht nur das Trust-Objekt, sondern das gesamte administrative Bewegungsmuster zwischen den Domänen.

AD-Trust-Angriffe: Wo das Risiko tatsächlich entsteht

Bereich	Typisches Problem	Warum es kritisch ist
Parent-Child innerhalb derselben Gesamtstruktur	Child Domain wird als "weniger kritisch" behandelt	Ein tiefer Kompromiss dort kann Wege zum Forest Root öffnen
Externe Trusts	SID filtering oder selective authentication sind zu schwach	Fremde Sicherheitsannahmen werden zu großzügig akzeptiert
Administrative Praxis	dieselben Admin-Konten, Jump Hosts oder Support-Pfade werden geteilt	Der Trust erbt operative Schwächen
Replikation und privilegierte Rechte	Konten in der Child Domain haben indirekt Einfluss auf Tier-0-Ziele	Eskalation wird nicht über das Trust-Objekt, sondern über Berechtigungen erreicht

In Assessments ist genau das der Regelfall: Nicht der Trust allein führt zum Problem, sondern die Kombination aus Trust, Session Exposure, Delegation und Altlasten in Gruppen oder ACLs.

Wie AD-Trust-Angriffe in der Praxis aussehen

1. Ausgangspunkt in der Unterdomäne

Der Einstieg muss nicht spektakulär sein. Häufig beginnt er mit einem Kerberoastable Service Account, einer zu starken ACL, einer schlecht geschützten Admin-Workstation oder einer veralteten privilegierten Gruppe in der Unterdomäne.

2. Inventar der Domänenbeziehungen und Abhängigkeiten

Ein Minimum an Inventar sollte Trust-Richtung, Typ, SID filtering, selective authentication, privilegierte Gruppen und administrative Session-Pfade umfassen.

Get-ADTrust -Filter * |
  Select-Object Name,Source,Target,Direction,TrustType,SIDFilteringQuarantined,SelectiveAuthentication

Get-ADForest | Select-Object RootDomain,Domains,GlobalCatalogs

Zusätzlich müssen Sie wissen, welche Konten aus der Unterdomäne Server, Gruppen, GPOs oder Support-Zugänge in der Root-Domäne oder in anderen Domänen der Gesamtstruktur beeinflussen.

3. Suche nach verwertbaren Übergängen

Die eigentliche Eskalation kann über sehr unterschiedliche Wege entstehen:

privilegierte Sessions aus der Root-Domäne auf Systemen der Unterdomäne
Gruppen oder ACLs, die domänenübergreifend weitervererbt wurden
Replikations- oder Verwaltungsrechte auf sensiblen Objekten
externe oder historische Trusts ohne saubere Einschränkung
sidHistory-Missbrauch in Migrations- oder Altlast-Szenarien

4. Eskalation Richtung Gesamtstruktur

Ist ein solcher Weg vorhanden, braucht der Angreifer keinen magischen "Trust-Exploit". Der Trust dient nur als Brücke, während die eigentliche Kontrolle aus Sitzungen, Berechtigungen, Replikation oder schlecht getrennten Admin-Pfaden kommt.

Was Sie zuerst prüfen sollten

Trust-Typen und Schutzmechanismen

Trennen Sie sauber zwischen:

Parent-Child-Trusts innerhalb derselben Gesamtstruktur
Tree-Root-Trusts
Forest Trusts
externen Trusts

Bei externen Trusts müssen SIDFilteringQuarantined und SelectiveAuthentication aktiv und begründet sein, wo immer der Zugriff stark eingegrenzt werden soll. Bei Parent-Child-Trusts ist die wichtigere Frage jedoch: Welche Wege machen aus einem Child-Domain-Kompromiss einen Forest-Risk?

Administrative Abhängigkeiten über Domänengrenzen hinweg

Suchen Sie gezielt nach:

gemeinsam genutzten Admin-Konten
Helpdesk- oder Server-Teams mit Rechten in mehreren Domänen
RDP- oder WinRM-Zugängen quer über Domänengrenzen
Gruppenmitgliedschaften, die aus historischen Projekten stammen
Tier-0-Sessions auf Systemen außerhalb der Root-Domäne

Replikation und sensible Identitäten

Wer in einer Child Domain schon Rechte nahe DCSync, ResetPassword, WriteDacl oder GPO-Kontrolle erreicht, muss in Bezug auf die Gesamtstruktur anders bewertet werden als ein normaler Server-Admin. Gerade die Pfade zu krbtgt, zu DCs, zu Backup-Workflows und zu Zertifikatsdiensten gehören hier in den Scope.

Erkennung und Telemetrie

Es gibt kein einzelnes Event, das zuverlässig "Trust-Angriff" meldet. Nützlich ist die Korrelation aus Directory-Änderungen, Gruppenänderungen, Kerberos-Traffic und privilegierten Logons.

Typische Signale

Änderungen an Trust-Objekten oder an deren Schutzmechanismen
ungewöhnliche Kerberos-Logons zwischen Domänen
Mitgliedschaftsänderungen in hoch privilegierten Gruppen
Änderungen an ACLs oder Replikationsrechten
privilegierte Sessions aus der Root-Domäne auf Child-Domain-Systemen

Relevante Event IDs

5136 für Änderungen im Verzeichnis
4728 / 4732 für Gruppenänderungen
4768 / 4769 für Kerberos-Muster, die nicht zum Betriebsmodell passen
4662 für sensible Objektzugriffe, wenn die Überwachung sauber konfiguriert ist

Remediation und Härtung

1. Behandeln Sie einen Child-Domain-Kompromiss als Forest-Risiko

Die wichtigste Entscheidung ist operativ: Ein tiefer Kompromiss in der Unterdomäne darf nicht als lokales Problem heruntergestuft werden. Incident Response, Session Review, Passwort- und Ticket-Hygiene müssen sofort auf Gesamtstruktur-Ebene gedacht werden.

2. Reduzieren Sie administrative Querbeziehungen

Entfernen Sie permanente Admin-Pfade zwischen Child und Root, beseitigen Sie überflüssige delegierte Gruppen, härten Sie Jump Hosts und stellen Sie sicher, dass Root-Admins nicht auf Systemen der Unterdomäne arbeiten, die weniger geschützt sind.

3. Härten Sie externe Trusts

Externe Trusts brauchen restriktive Defaults. Prüfen Sie SID filtering, selective authentication und jede Ausnahme einzeln. Wenn ein Team nicht erklären kann, warum ein externer Trust großzügig sein muss, ist er zu großzügig.

4. Überprüfen Sie Replikations- und Tier-0-Pfade

Konten mit Replikationsrechten, Backup-Rechten oder indirektem Einfluss auf Domain Controller müssen neu bewertet werden. Ein Trust bleibt gefährlich, solange privilegierte Wege in den Forest Root operativ offenstehen.

Validierung nach dem Fix

Trust-Inventar erneut ziehen und mit dem alten Zustand vergleichen
privilegierte Sessions zwischen Child und Root erneut messen
prüfen, ob Root-Admins noch auf Child-Systemen landen
externe Trusts mit ihren Schutzmechanismen dokumentiert testen
offene Ausnahmen, Restrisiken und verbliebene Abhängigkeiten schriftlich festhalten

Zusätzliche technische Prüfpunkte

Prüfen Sie getrennt, ob Root-Admins interaktiv auf Systemen der Unterdomäne angemeldet sind, ob Backup-, Monitoring- oder PKI-Konten still domänenübergreifende Rechte behalten und ob alte Migrationsausnahmen rund um sidHistory noch dokumentiert sind. Gerade diese operativen Restpfade erklären oft, warum ein formal "normaler" Trust in Wirklichkeit ein Forest-Risiko bleibt.

SID filtering und sidHistory getrennt bewerten

In Trust-Reviews werden SID filtering und sidHistory häufig vermischt, obwohl sie unterschiedliche Fragen beantworten. sidHistory ist in Microsoft-Dokumentation ein Migrationsmechanismus: Er hilft dabei, Berechtigungen während einer Migration beizubehalten. Genau deshalb ist jede verbliebene sidHistory auf privilegierten Konten oder Gruppen review-würdig, sobald die Migration abgeschlossen ist. SID filtering ist dagegen ein Trust-Schutz, der verhindern soll, dass unzulässige SIDs über einen Trust hinweg wirksam werden. Für externe Trusts und Partnerbeziehungen ist diese Trennung zentral: Ein Team muss sowohl wissen, ob alte sidHistory-Werte noch existieren, als auch ob der Trust überhaupt so gebaut ist, dass fremde SID-Informationen nicht blind akzeptiert werden.

Operativ bedeutet das: Prüfen Sie nicht nur das Trust-Objekt, sondern auch die privilegierten Konten, Gruppen und Migrationsreste auf beiden Seiten. Wenn niemand mehr erklären kann, warum eine sidHistory noch gebraucht wird, ist das kein neutraler Altwert, sondern ein Risikoindikator.

Session-Pfade zwischen Child und Root ausdrücklich messen

Viele AD-Trust-Angriffe werden nicht über eine exotische Trust-Eigenschaft möglich, sondern über schlechte Session-Hygiene. Wenn Root-Admins sich regelmäßig auf Servern der Unterdomäne anmelden, Support-Teams mit denselben Konten in mehreren Domänen arbeiten oder Jump Hosts nicht sauber nach Tier getrennt sind, liefert der Trust nur noch die Richtung des Missbrauchs. Deshalb gehört in jeden Trust-Review eine kurze, harte Messung: Welche hoch privilegierten Konten waren in den letzten Tagen oder Wochen auf Child-Systemen aktiv, welche Admin-Gruppen dürfen sich dort überhaupt anmelden und welche Betriebsprozesse erzwingen diese Querbewegung noch?

Diese Sicht ist wichtig, weil viele Teams ihre Trust-Konfiguration sauber dokumentieren, aber ihre Admin-Sessions nicht. In realen Vorfällen ist genau diese Lücke oft der schnellste Weg vom Child-Domain-Kompromiss zum Forest-Risiko.

Selective Authentication praktisch testen

Bei externen Trusts reicht es nicht, Selective Authentication nur als Häkchen zu sehen. Validieren Sie mit Testkonten, auf welchen Servern Allowed to Authenticate tatsächlich gesetzt ist, ob Administrationsserver versehentlich freigegeben wurden und ob Support-Gruppen über historische ACEs mehr Systeme erreichen als beabsichtigt. Ein Trust kann formal restriktiv aussehen und operativ trotzdem zu breit sein, wenn zu viele Ressourcen den Zugriff schon im Vorfeld erlauben.

Forest-nahe Dienste separat inventarisieren

Viele reale Eskalationspfade hängen nicht direkt am Trust-Objekt, sondern an Diensten rund um den Forest Root: PKI, Backup, Virtualisierungsverwaltung, Identitätssynchronisation oder Management-Jump-Hosts. Wenn Konten aus der Child Domain dort lokale Administratorrechte, Service-Steuerung oder Passwort-Reset-Möglichkeiten halten, wird der Trust nur noch zum Transportweg. Ein belastbarer Review zieht deshalb zusätzlich eine Liste dieser Dienste, ihrer Owner, der zugelassenen Admin-Konten und der Domänen, aus denen diese Konten stammen. Erst dann lässt sich sauber beantworten, ob ein Child-Domain-Kompromiss wirklich lokal bleibt oder praktisch bereits im Forest endet.

Kontrolle von Migrationskonten und Admin-Hosts

Ergänzend sollte jedes Team prüfen, ob alte Migrationskonten, Staging-Hosts oder temporäre Jump-Systeme noch domänenübergreifende Rechte behalten. Gerade diese Objekte werden in Trust-Reviews oft übersehen, obwohl sie nach Projekten oder Konsolidierungen lange bestehen bleiben. Wenn ein Konto aus der Child Domain noch immer auf Root-nahe Systeme zugreifen darf oder ein alter Admin-Host Anmeldedaten mehrerer Domänen sammelt, bleibt der Trust operativ gefährlich, selbst wenn das eigentliche Trust-Objekt sauber aussieht.

Referenzen

Microsoft Learn: Security boundaries and Active Directory forests
Microsoft Learn: Get-ADTrust
Microsoft Open Specifications: SID filtering and claims transformation in MS-PAC
Microsoft Learn: Using DsAddSidHistory

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