Domain Trust Discovery erkennen: die Pfade zwischen den Domänen

Mit Domain Trust Discovery schließt der Discovery-Block ab. Nach der Suche nach Netzfreigaben, der Erkundung erreichbarer Systeme und dem Blick auf die Abwehr folgt die Frage nach den Grenzen der eigenen Domäne: Welche Vertrauensstellungen gibt es, und wohin führen sie? In gewachsenen AD-Landschaften sind Trusts zwischen Domänen und Forests der Schlüssel zu Systemen, die ein Angreifer sonst nicht erreicht. Wer die Trusts kennt, kennt die Pfade - und oft auch die Abkürzungen zu höheren Rechten. Diese Abfrage ist für die Erkennung besonders wertvoll, weil sie der domänenübergreifenden Bewegung unmittelbar vorausgeht. Der Beitrag nimmt die Erkennung in den Blick und bleibt auf der Verteidigerseite.

Was der Angreifer tut

Die Erkundung der Vertrauensstellungen läuft auf der Ebene des Prinzips, nicht als Anleitung, in wenigen Varianten ab:

• Bordmittel zuerst. nltest /domain_trusts und /trusted_domains listen die Trusts der Domäne und des Forests - schnell und ohne zusätzliche Software.
• Mit PowerView. Get-DomainTrust und Get-NetForestTrust liefern dieselben Informationen samt Richtung und Typ des Trusts - ein beliebtes Angreifer-Werkzeug.
• Über .NET. Die AD-Klassen von .NET mit GetAllTrustRelationships fragen die Trusts ab, ganz ohne das AD-Modul und ohne eigene Datei.
• Den Pfad planen. Aus Richtung und Typ der Trusts ergibt sich der nächste Schritt: welche Domäne erreichbar ist, wo ein Trust-Missbrauch lohnt, wohin die seitliche Bewegung führt.

Für die Erkennung ist entscheidend: Die Abfrage ist spezifisch und selten. Die nltest-Trust-Schalter, die PowerView-Funktionen und der .NET-Aufruf haben im Normalbetrieb eines Arbeitsplatzes kaum einen Grund.

Welche Logquellen die Technik zeigt

• Prozess-Telemetrie. Event 4688 und Sysmon Event 1 zeigen nltest, die PowerShell oder dsquery samt Kommandozeile im Klartext - die wichtigste Quelle.
• PowerShell-Protokolle. Script Block Logging macht Get-ADTrust, die PowerView-Funktionen und den .NET-Aufruf sichtbar, auch bei Verschleierung.
• Verzeichnisdienst-Zugriff. Auf dem Domaincontroller belegt Event 4662 den Zugriff auf trustedDomain-Objekte - die LDAP-Variante der Abfrage.
• Kontext statt Einzelzeile. Trust-Abfrage nach System- und Kontenerkundung ergibt das Bild; Grundlagen zur Endpunkt-Telemetrie unter Sysmon einrichten.

Das Muster im Log

Das klarste Signal ist die Kommandozeile: nltest mit /domain_trusts oder /trusted_domains, eine PowerView-Funktion wie Get-DomainTrust oder der .NET-Aufruf mit GetAllTrustRelationships. nltest ist zwar bordeigen, doch die Trust-Schalter sind spezifisch - ein Arbeitsplatz-Endpunkt, der die Vertrauensstellungen abfragt, gehört selten zum Normalbetrieb. Das zweite Signal sind die PowerView-Funktionen, für die es keinen legitimen Grund gibt. Das dritte ist der .NET-Weg über die AD-Klassen, der ohne das AD-Modul auskommt und gerade deshalb verdächtig ist. Legitime Trust-Abfragen stammen von Administratoren und AD-Werkzeugen auf bekannten Verwaltungshosts. Wie immer trennt der Blick auf Werkzeug, Abfrageziel und Herkunft den Alltag vom Angriff.

Drei Sigma-Regeln

Die Regeln sind mit sigma-cli geprüft und nehmen die drei Wege: nltest, die PowerShell-Funktionen und den .NET- oder dsquery-Weg.

1. Trust-Erkundung per nltest (T1482). nltest mit /domain_trusts oder /trusted_domains. Die Regel steht auf level: medium, auf Arbeitsplatz-Endpunkten aber auffällig.

title: Vertrauensstellungen-Erkundung per nltest
id: 2b07b630-c2f7-4c1d-bbe2-0fb78d0ce8c2
status: experimental
description: |
  Erkennt die Abfrage von Active-Directory-Vertrauensstellungen ueber nltest - /domain_trusts und
  /trusted_domains listen die Trusts der Domaene und des Forests. Ein Angreifer sucht damit nach
  Pfaden in andere Domaenen und Forests, um sein Ziel ueber Vertrauensgrenzen hinweg zu erreichen.
references:
  - https://attack.mitre.org/techniques/T1482/
author: blue-team.net
tags:
  - attack.discovery
  - attack.t1482
logsource:
  product: windows
  category: process_creation
detection:
  sel_img:
    Image|endswith: '\nltest.exe'
  sel_cmd:
    CommandLine|contains:
      - 'domain_trusts'
      - 'trusted_domains'
  condition: sel_img and sel_cmd
falsepositives:
  - Administrative Diagnose auf Servern und Admin-Hosts - nach Host und Konto als Baseline ausnehmen
level: medium

2. Trust-Erkundung per PowerShell (T1482). Get-ADTrust oder die PowerView-Funktionen. Die PowerView-Treffer sind eindeutig. Ebenfalls level: medium.

title: Vertrauensstellungen-Erkundung per PowerShell
id: 1ea69fd1-09a3-412f-b288-b2f3f435847c
status: experimental
description: |
  Erkennt die Abfrage von AD-Vertrauensstellungen ueber PowerShell - das bordeigene Get-ADTrust
  oder die PowerView-Funktionen Get-DomainTrust, Get-NetDomainTrust und Get-NetForestTrust. Die
  PowerView-Funktionen haben keinen legitimen Grund und sind ein starkes Angreifer-Signal in der
  Orientierungsphase.
references:
  - https://attack.mitre.org/techniques/T1482/
author: blue-team.net
tags:
  - attack.discovery
  - attack.t1482
logsource:
  product: windows
  category: process_creation
detection:
  sel_img:
    Image|endswith:
      - '\powershell.exe'
      - '\pwsh.exe'
  sel_cmd:
    CommandLine|contains:
      - 'Get-ADTrust'
      - 'Get-DomainTrust'
      - 'Get-NetDomainTrust'
      - 'Get-NetForestTrust'
      - 'Get-DomainForeignUser'
  condition: sel_img and sel_cmd
falsepositives:
  - Administrations- und Inventar-Skripte mit Get-ADTrust - bekannte Skripte und Konten als Baseline ausnehmen
level: medium

3. Trusts über .NET oder dsquery (T1482). GetAllTrustRelationships über die AD-Klassen oder dsquery nach trustedDomain. Ebenfalls level: medium.

title: Vertrauensstellungen ueber .NET oder dsquery
id: 78556fea-aec8-4d58-8e36-189a46bad158
status: experimental
description: |
  Erkennt die Abfrage von Vertrauensstellungen ueber die .NET-Klasse
  System.DirectoryServices.ActiveDirectory mit GetAllTrustRelationships oder ueber dsquery nach
  trustedDomain-Objekten. Diese Wege kommen ohne das AD-Modul aus und werden von Angreifern genutzt,
  um Trusts unauffaellig abzufragen.
references:
  - https://attack.mitre.org/techniques/T1482/
author: blue-team.net
tags:
  - attack.discovery
  - attack.t1482
logsource:
  product: windows
  category: process_creation
detection:
  sel_net:
    CommandLine|contains:
      - 'GetAllTrustRelationships'
      - 'DirectoryServices.ActiveDirectory.Forest'
      - 'DirectoryServices.ActiveDirectory.Domain'
  sel_dsquery:
    Image|endswith: '\dsquery.exe'
    CommandLine|contains: 'trustedDomain'
  condition: sel_net or sel_dsquery
falsepositives:
  - Einzelne Verwaltungs- und Verzeichnis-Skripte, die Trusts auslesen - bekannte Skripte und Konten als Baseline ausnehmen
level: medium

Härtung: der Angriff, der ins Leere läuft

• PowerShell härten. Script Block Logging und Constrained Language Mode machen die Trust-Abfragen sichtbar und erschweren PowerView und den .NET-Weg.
• LOLBins einhegen. nltest und dsquery dort per Anwendungssteuerung (WDAC oder AppLocker) einschränken, wo normale Nutzer sie nicht brauchen.
• Trusts aufräumen. Nicht mehr benötigte Vertrauensstellungen entfernen und bestehende mit SID-Filtering und selektiver Authentifizierung absichern - so bringt die Erkundung dem Angreifer wenig.
• Verzeichnis-Auditing nutzen. Auf den Domaincontrollern den Zugriff auf trustedDomain-Objekte überwachen und ungewöhnliche Abfragen alarmieren.

Der Test

Die Erkennung lässt sich im Lab gefahrlos prüfen, auf isolierten Systemen mit aktivem Sysmon:

• Für Regel 1 nltest /domain_trusts in der eigenen Testdomäne ausführen. In Event 4688 muss die Kommandozeile mit dem Trust-Schalter erscheinen.
• Für Regel 2 Get-ADTrust -Filter * aufrufen und den Eintrag in der PowerShell- und Prozess-Telemetrie prüfen.
• Für Regel 3 den .NET-Aufruf mit GetAllTrustRelationships ausführen oder dsquery nach trustedDomain abfragen und das Erscheinen in der Prozess-Telemetrie kontrollieren.
• Breiter wird der Test mit den Fällen zu T1482 aus Atomic Red Team.

Fehlalarme und Tuning

• Administration und AD-Werkzeuge. nltest und Get-ADTrust gehören zur AD-Verwaltung. Bekannte Verwaltungshosts, Konten und Skripte als Baseline ausnehmen.
• Verwaltungshosts gesondert behandeln. Auf Admin- und DC-Systemen sind Trust-Abfragen alltäglich. Diese Systeme eigens bewerten und vom Arbeitsplatz-Umfeld trennen.
• PowerView und .NET sind eindeutig. Get-DomainTrust und GetAllTrustRelationships haben keinen legitimen Grund - diese Treffer hochpriorisieren.
• Kette schlägt Einzelabfrage. Trust-Erkundung nach System- und Kontenerkundung ist aussagekräftiger als eine Abfrage allein - die Korrelation schärft die Bewertung.

Fazit

Domain Trust Discovery ist der Blick über die Grenzen der eigenen Domäne: Trusts sind die Pfade in benachbarte Domänen und Forests, oft mit einer Abkürzung zu höheren Rechten. Die verlässlichen Signale sind die nltest-Trust-Schalter, die PowerView-Funktionen und der .NET-Aufruf mit GetAllTrustRelationships. Die wirksamste Härtung härtet PowerShell, hegt die LOLBins ein und sichert die Trusts selbst mit SID-Filtering und selektiver Authentifizierung. Damit ist der Discovery-Block komplett: von der Suche nach Netzfreigaben über die Erkundung erreichbarer Systeme und den Blick auf die Abwehr bis zu den Vertrauensstellungen. Verwandt ist auf Binärebene das Living off the Land. Alle Techniken dieser Taktik sammelt das Lexikon nach Taktik unter Discovery.