Kerberos-Delegationsangriffe: Von Unkontrolliert bis RBCD-Missbrauch

Was sind Kerberos-Delegationsangriffe?

Kerberos-Delegationsangriffe missbrauchen legitime Active-Directory-Delegationsfunktionen, die es einem Dienst erlauben, im Namen eines Benutzers auf einen anderen Dienst zuzugreifen. Delegation existiert für reale Anwendungsszenarien, etwa wenn eine Web-Tier mit der Identität des Benutzers auf eine Datenbank-Tier zugreift. Das Sicherheitsproblem beginnt, wenn der Delegationsumfang breiter ist, als die Anwendung tatsächlich benötigt, oder wenn ein Angreifer die Delegationsbeziehung verändern kann.

Die drei Delegationsmodelle, die Verteidiger in der Regel prüfen müssen, sind:

• Unkontrollierte Delegation (Unconstrained Delegation), bei der ein vertrauenswürdiger Dienst delegierbares Kerberos-Material erhalten und über einen einzelnen Backend-Dienst hinaus verwenden kann.
• Eingeschränkte Delegation (Constrained Delegation), bei der der Frontend-Dienst auf bestimmte, in Active Directory hinterlegte Dienstprinzipalnamen beschränkt ist.
• Ressourcenbasierte eingeschränkte Delegation (RBCD), bei der die Zielressource selbst festlegt, welche Prinzipale im Namen von Benutzern gegenüber dieser Ressource handeln dürfen.

Diese Modelle sollten nicht als gleichwertiges Risiko behandelt werden. Unkontrollierte Delegation hat meist die höchste Priorität, weil die Kompromittierung des delegierten Hosts wiederverwendbare delegierte Anmeldeinformationen offenlegen kann. Eingeschränkte Delegation und RBCD können dennoch gefährlich sein, insbesondere wenn die zulässigen Dienste zu breit gefasst sind oder wenn Schreibrechte einem Angreifer erlauben, die Delegationsattribute zu ändern.

Wie Kerberos-Delegation Funktioniert

Kerberos-Delegation erweitert die normale Kerberos-Dienstauthentifizierung. In einem Standard-Kerberos-Ablauf erhält ein Benutzer vom Key Distribution Center (KDC) ein Ticket-Granting-Ticket (TGT) und fordert anschließend Dienst-Tickets für bestimmte Dienste an. Delegation fügt die Möglichkeit hinzu, dass ein Dienst im Namen des Benutzers Tickets für einen anderen Dienst erhält oder verwendet.

Bei unkontrollierter Delegation ist das Konto oder der Computer als vertrauenswürdig für Delegation markiert. Authentifiziert sich ein Benutzer bei diesem Dienst mit aktivierter Delegation, kann der Dienst delegierbares Kerberos-Material empfangen. Wird der Host kompromittiert, kann der Angreifer diesen delegierten Zugriff unter Umständen wiederverwenden. Deshalb behandelt Microsoft Defender for Identity unkontrollierte Kerberos-Delegation als Punkt der Sicherheitsbewertung: Die Einstellung kann privilegierte Anmeldeinformationen offenlegen, wenn sensible Benutzer sich bei delegierten Diensten authentifizieren.

Eingeschränkte Delegation verengt den Umfang. Statt Delegation an jeden beliebigen Dienst zu erlauben, darf das Konto nur an konfigurierte Dienste delegieren, dargestellt durch Werte wie msDS-AllowedToDelegateTo. Protokollübergang (Protocol Transition) verändert das Risiko erneut, weil der Dienst ein delegiertes Ticket für einen Benutzer erhalten kann, ohne dass sich dieser zuvor per Kerberos beim Frontend-Dienst authentifiziert hat, sofern die Konfiguration ein beliebiges Authentifizierungsprotokoll zulässt.

RBCD kehrt einen Teil des administrativen Modells um. Die Ressource selbst speichert die Liste der Prinzipale, die im Namen von Benutzern gegenüber dieser Ressource handeln dürfen, im Attribut msDS-AllowedToActOnBehalfOfOtherIdentity. Das macht RBCD für bestimmte Anwendungsszenarien nützlich, bedeutet aber auch, dass Schreibkontrolle über ein Computerobjekt zu einem Delegationspfad werden kann.

Voraussetzungen, Die Delegationsmissbrauch Ermöglichen

Delegationseinstellungen sind für sich genommen nicht automatisch ausnutzbar. Die gefährlichen Fälle kombinieren meist mehrere Bedingungen:

• ein Server oder Dienstkonto ist für unkontrollierte Delegation konfiguriert und leichter zu kompromittieren als die Benutzer, die sich dort authentifizieren
• privilegierte Benutzer oder Domain Controller authentifizieren sich bei Systemen, die delegierte Anmeldeinformationen empfangen können
• Computerobjekte haben schwache ACLs, die es nicht-administrativen Prinzipalen erlauben, delegationsbezogene Attribute zu ändern
• Dienstkonten haben breite Ziele für eingeschränkte Delegation, die nicht mehr dem tatsächlichen Anwendungsbedarf entsprechen
• RBCD-Einträge existieren ohne dokumentierten Eigentümer, Anwendungsabhängigkeit oder Ablaufprozess
• Domain Controller exponieren Coercion-Pfade, die dazu führen, dass sich Maschinenkonten bei Systemen authentifizieren, wo delegiertes Material abgefangen oder wiederverwendet werden kann

Die defensive Schlussfolgerung ist praktisch: Eine Delegationsprüfung ist nicht nur eine Liste von Attributen. Sie muss Host-Härtung, Anmeldepfade privilegierter Konten, Objekt-ACLs und Anwendungs-Ownership umfassen.

Die Angriffskette

Ein Delegationsangriff folgt normalerweise einer Abfolge und nicht einem einzelnen Ereignis.

1. Der Angreifer identifiziert Computer oder Dienstkonten, die für Delegation konfiguriert sind.
2. Der Angreifer kompromittiert einen delegierten Host, ein Dienstkonto oder eine Identität mit Schreibzugriff auf ein Computerobjekt.
3. Der Angreifer wartet auf oder erzwingt die Authentifizierung eines wertvollen Kontos oder ändert RBCD so, dass ein vom Angreifer kontrollierter Prinzipal Benutzer gegenüber einer Zielressource imitieren kann.
4. Der Angreifer nutzt den resultierenden delegierten Zugriff, um einen sensibleren Dienst zu erreichen.
5. Erreicht der Pfad Replikationsrechte für Domain Controller, Tier-0-Systeme oder privilegierte administrative Dienste, kann der Angriff zur vollständigen Domänenkompromittierung werden.

Bei unkontrollierter Delegation betreffen die schwerwiegendsten Fälle privilegierte Konten oder Domain-Controller-Maschinenkonten, die sich bei einem kompromittierten delegierten Server authentifizieren. Bei RBCD lautet die Schlüsselfrage anders: Wer kann das Delegationsattribut des Zielcomputerobjekts schreiben, und entspricht die resultierende Vertrauensbeziehung einer legitimen Anwendungsabhängigkeit?

Erkennung

Kein einzelnes Windows-Ereignis beweist einen Kerberos-Delegationsangriff. Die Erkennung entsteht durch die Korrelation von Delegationsinventar, Objektänderungen, Kerberos-Dienstticket-Aktivität, Anmeldeereignissen und Host-Telemetrie.

Signale Aus Dem Delegationsinventar

Beginnen Sie mit Konfigurationsdaten:

• Konten oder Computer mit aktivierter unkontrollierter Delegation
• Konten mit aktiviertem TrustedToAuthForDelegation
• befüllte msDS-AllowedToDelegateTo-Werte
• befüllte msDS-AllowedToActOnBehalfOfOtherIdentity-Werte
• privilegierte Konten, die nicht als sensibel markiert und daher weiterhin für Delegationspfade in Frage kommen
• schwache ACLs auf Computerobjekten, die unerwarteten Prinzipalen erlauben, delegationsbezogene Attribute zu schreiben

Das Inventar allein reicht nicht aus, gibt Erkennungen jedoch den nötigen Kontext. Ein 4769-Dienstticket-Ereignis ist aussagekräftiger, wenn bekannt ist, dass das Dienstkonto für riskante Delegation konfiguriert ist.

Zu Korrelierende Windows-Ereignisse

Ereignis 5136 erfordert die richtige Überwachungsrichtlinie und SACL-Abdeckung. Microsoft dokumentiert, dass es generiert wird, wenn ein Active-Directory-Objekt geändert wird — eine nützliche Erkennung hängt jedoch davon ab, Objekt-, Attribut- und Operationsdetails aufzubewahren.

Detektionsmuster Mit Hohem Signalwert

Priorisieren Sie diese Erkennungen, bevor Sie breite Anomalieregeln schreiben:

• ein neuer oder geänderter msDS-AllowedToActOnBehalfOfOtherIdentity-Wert auf einem Computerobjekt
• unkontrollierte Delegation aktiviert auf einem Nicht-DC-System
• ein privilegiertes Konto authentifiziert sich bei einem für unkontrollierte Delegation konfigurierten System
• Anmeldeaktivität von Domain-Controller-Maschinenkonten bei unerwarteten Mitgliedsservern
• delegationsbezogene Attributänderungen durch Konten, die die Anwendung nicht besitzen
• RBCD-Einträge, bei denen der handelnde Prinzipal neu erstellt, selten genutzt oder nicht mit dem Zieldienst verbunden ist

Der Alarm sollte beide Seiten der Beziehung enthalten: das Konto oder den Computer, der delegieren darf, und den Dienst oder die Ressource, an die delegiert wird.

Behebung

Behandeln Sie unkontrollierte Delegation auf Nicht-DC-Systemen als hochprioritären Befund. Benötigt eine Anwendung weiterhin Delegation, wechseln Sie zu einem engeren Modell und belegen Sie, dass die Zielliste korrekt ist.

1. Unkontrollierte Delegation Wo Möglich Entfernen

Identifizieren Sie Computer und Konten, die für unkontrollierte Delegation vertrauenswürdig sind, bestätigen Sie die Anwendungs-Ownership und entfernen Sie die Einstellung von Systemen ohne aktuellen geschäftlichen Bedarf.

Get-ADComputer -Filter {TrustedForDelegation -eq $true} -Properties TrustedForDelegation |
  Select-Object Name, DistinguishedName, TrustedForDelegation

Deaktivieren Sie Delegation auf Produktions-Anwendungsservern nicht blind, ohne zu testen. Manche Legacy-Anwendungen können von Delegation für die Benutzer-zu-Backend-Authentifizierung abhängen. Der sichere Behebungspfad lautet: Inventarisierung, Bestätigung des Eigentümers, Staging, Änderung und Validierung.

2. Eingeschränkte Delegation Verengen

Für Dienste, die weiterhin Delegation benötigen, schränken Sie die zulässigen Zieldienste auf die kleinste tragfähige Menge ein. Prüfen Sie die Werte von msDS-AllowedToDelegateTo und entfernen Sie veraltete SPNs. Ist Protokollübergang aktiviert, verifizieren Sie, dass die Anwendung ihn wirklich benötigt und dass das Dienstkonto wie eine privilegierte Identität geschützt wird.

3. RBCD Prüfen Und Bereinigen

Prüfen Sie für RBCD jeden befüllten msDS-AllowedToActOnBehalfOfOtherIdentity-Wert. Jeder Eintrag sollte auf eine dokumentierte Anwendungsabhängigkeit abgebildet sein. Existiert der Eintrag nur, weil er vor Monaten zur Fehlerbehebung nötig war, entfernen Sie ihn. Prüfen Sie außerdem, wer das Zielcomputerobjekt beschreiben kann, denn die Schreibkontrolle ist oft die eigentliche Schwachstelle.

4. Privilegierte Konten Vor Delegationsexposition Schützen

Privilegierte Benutzer sollten sich nicht interaktiv bei Servern mit geringerem Vertrauen anmelden. Nutzen Sie gestufte Administration, dedizierte Admin-Workstations und Anmeldebeschränkungen, damit Tier-0-Anmeldeinformationen nicht auf delegierten Hosts landen. Prüfen Sie für sensible Konten die Kontoeinstellungen und das Betriebsmodell, das Delegationsexposition verhindert.

5. Coercion-Exposition Auf Domain Controllern Reduzieren

Wird der Print-Spooler-Dienst auf Domain Controllern nicht benötigt, entfernt seine Deaktivierung einen bekannten Authentifizierungspfad über Maschinenkonten, der in Delegationsmissbrauchsketten genutzt wird. Betrachten Sie dies als eine Schutzebene, nicht als alleinige Lösung. Das Grundproblem bleibt unsichere Delegation und Anmeldeinformations-Exposition.

Validierung Nach Der Behebung

Delegationsbehebung ist erst abgeschlossen, wenn Sie sowohl Sicherheit als auch Anwendungsverhalten validiert haben:

• bestätigen Sie, dass Nicht-DC-Systeme keine unkontrollierte Delegation mehr haben, sofern nicht ausdrücklich genehmigt
• bestätigen Sie, dass die verbleibenden Ziel-SPNs der eingeschränkten Delegation dem Anwendungsdesign entsprechen
• bestätigen Sie, dass RBCD-Einträge dokumentierte Eigentümer und keine unerwarteten handelnden Prinzipale haben
• testen Sie den Anwendungsablauf, der zuvor Delegation benötigte
• überwachen Sie Ereignis 5136 auf erneute Delegationsattribut-Schreibvorgänge nach der Bereinigung
• überwachen Sie privilegierte Anmeldungen bei delegierten Hosts für mindestens ein Änderungsfenster nach der Behebung
• prüfen Sie Computerobjekt-ACLs, um sicherzustellen, dass Angreifer den Delegationspfad nicht wiederherstellen können

Die abschließende Validierungsfrage ist einfach: Kann ein Angreifer, der morgen denselben Anwendungsserver kompromittiert, weiterhin delegierten Zugriff auf eine höher vertrauenswürdige Ressource sammeln oder erzeugen?

So Erkennt EtcSec Dies

EtcSec prüft Delegationseinstellungen bei jedem AD-Scan über Computer und Dienstkonten hinweg.

UNCONSTRAINED_DELEGATION identifiziert Systeme und Konten, die für unkontrollierte Delegation konfiguriert sind.

CONSTRAINED_DELEGATION hebt riskante oder zu breit gefasste Einstellungen der eingeschränkten Delegation hervor.

RBCD_ABUSE deckt Beziehungen der ressourcenbasierten eingeschränkten Delegation auf, die eine Prüfung verdienen, weil sie einen unerwarteten Impersonationspfad bieten können.

Verwandte Kontrollen

Die Delegationsprüfung gehört neben Kerberoasting Erkennung Prävention: Wie sich knackbare Dienstkonten finden und schützen lassen, ACL-Missbrauch und DCSync: Wie stille Rechte Domain Admin öffnen, AD-Sicherheitsüberwachung: Event-IDs und SIEM, GPO-Fehlkonfigurationen als Angriffsvektor und Golden Ticket Angriff: Die Schlüssel zu Ihrer Domain. In realen Umgebungen werden diese Pfade meist verkettet statt isoliert ausgenutzt.

Primärquellen

• Microsoft Defender for Identity: Bewertung der Konten-Sicherheitslage (Unsichere Kerberos-Delegation)
• 5136: Ein Verzeichnisdienstobjekt wurde geändert
• 4738: Ein Benutzerkonto wurde geändert
• Windows-Ereignisüberwachung für Microsoft Defender for Identity konfigurieren
• Kerberos-eingeschränkte Delegation mit Microsoft Entra ID (Application Proxy)