Kerberos-Delegation erkennen: Unconstrained und Constrained Delegation

Kerberos-Delegation ist eine legitime und oft notwendige Funktion: Ein Webserver nimmt die Anmeldung eines Benutzers entgegen und muss in dessen Namen auf eine Datenbank im Hintergrund zugreifen. Damit das geht, darf der Webserver stellvertretend ein Ticket für den Datenbankdienst anfordern. Genau diese Stellvertretung wird gefährlich, wenn sie zu weit gefasst ist oder an der falschen Stelle aktiviert wird, denn dann kann ein kompromittiertes System die Identität beliebiger Benutzer übernehmen, bis hin zum Domain Admin. Dieser Beitrag beschreibt die Erkennung missbräuchlicher Delegationskonfigurationen aus Verteidigersicht: die Mechanismen Unconstrained und Constrained Delegation sauber getrennt, die Attribute und Flags dahinter, die Windows-Ereignisse der Änderung und der Nutzung, vier Sigma-Regeln, die Blindspots, die Härtung, den Lab-Test und die Checkliste. Resource-Based Constrained Delegation (RBCD) kommt nur als Abgrenzung vor, weil ihre Erkennung in einem eigenen Beitrag steht; und es geht nicht um ein allgemeines Kerberos-Tutorial - der Ticket-Fluss aus TGT und TGS steht unter Kerberos verstehen.

Was der Angreifer tut

Alle Spielarten der Delegation laufen auf dieselbe Frage hinaus: Welches Konto darf sich gegenüber welchen Diensten als welcher Benutzer ausgeben? Der Angriff besteht darin, diese Erlaubnis zu schaffen oder auszuweiten und sie dann zu nutzen. Drei Mechanismen sind zu unterscheiden:

Unconstrained Delegation

Beim Flag TRUSTED_FOR_DELEGATION (Bit 0x80000 im Attribut userAccountControl) erhält ein System das vollständige, weiterleitbare TGT jedes Benutzers, der sich daran authentifiziert, und kann sich damit gegenüber jedem beliebigen Dienst als dieser Benutzer ausgeben. Das Flag gilt für Computer- wie Benutzerobjekte. Legitim tragen es von Haus aus nur die Domain Controller; ein Mitgliedsserver mit diesem Flag ist eine offene Flanke, denn wer ihn kontrolliert und einen Domain Admin dort anmelden lässt (oder per Zwangsauthentifizierung anlockt), hält dessen TGT in der Hand. Entscheidend für die Erkennung: Allein das Flag ist kein Incident. Es gibt Systeme, die Delegation historisch brauchen (ältere Web- und Middleware-Anwendungen). Das Signal ist die neue Aktivierung an einem Konto, das sie vorher nicht hatte.

Constrained Delegation

Eingeschränkte Delegation begrenzt die Stellvertretung auf bestimmte Dienste. Welche das sind, steht im Attribut msDS-AllowedToDelegateTo als Liste von Ziel-SPNs; das Konto darf über S4U2Proxy nur für genau diese Dienste Tickets im Namen anderer anfordern. Kommt der Protokollübergang hinzu (Flag TRUSTED_TO_AUTH_FOR_DELEGATION, Bit 0x1000000), darf das Konto per S4U2Self sogar ein weiterleitbares Ticket für einen beliebigen Benutzer erzeugen, ohne dass dieser sich jemals angemeldet hat - die Stellvertretung wird dann von der tatsächlichen Anmeldung des Benutzers entkoppelt. Die Gefahr steckt im Ziel: Zeigt msDS-AllowedToDelegateTo auf einen Dienst eines Domain Controllers (etwa ldap/ eines DC), wird daraus ein Weg zu DCSync-ähnlichen Rechten. Hier ist die Konfigurationsänderung (Attribut gesetzt) von der tatsächlichen Nutzung (Ticket weitergereicht) zu trennen - beide haben eigene Ereignisse.

RBCD (nur zur Abgrenzung)

Resource-Based Constrained Delegation dreht die Richtung um: Nicht das stellvertretende Konto trägt die Erlaubnis, sondern das Zielobjekt legt im Attribut msDS-AllowedToActOnBehalfOfOtherIdentity fest, wer in seinem Namen handeln darf. Das ist ein beliebter Eskalationsweg, aber ein eigenes Thema mit eigener Telemetrie und eigener Erkennung; dieser Beitrag baut dafür bewusst keine zweite, vollständige Detection. Alles zu msDS-AllowedToActOnBehalfOfOtherIdentity und msDS-KeyCredentialLink steht in RBCD und Shadow Credentials erkennen.

Welche Logquellen die Technik zeigen

Voraussetzungen. 4738 und 4742 entstehen mit der Unterkategorie "Benutzerkontenverwaltung" bzw. "Computerkontenverwaltung überwachen"; 5136 mit "Verzeichnisdienständerungen überwachen" und einer SACL für Schreibzugriffe auf die betroffenen Objekte; 4769 mit "Kerberos-Dienstticketvorgänge überwachen". Alle Domain Controller müssen ins SIEM liefern. Welche Quelle führt: Für die reine Attributänderung ist 5136 am belastbarsten, weil der neue Wert direkt im Ereignis steht; 4738/4742 sind bequemer, wenn der Parser die Flag-Änderung als Klartext liefert, hängen aber stärker vom Parsing ab. In der Praxis werden beide Wege genutzt und im SIEM zusammengeführt. Die Einstellungen stehen in der Referenz zu den Event-IDs.

Das Muster im Log: Konfiguration und Nutzung

Die Erkennung hat zwei Ebenen, und sie dürfen nicht verwechselt werden.

• Die Flags in userAccountControl. TRUSTED_FOR_DELEGATION (0x80000) ist Unconstrained Delegation, TRUSTED_TO_AUTH_FOR_DELEGATION (0x1000000) der Protokollübergang der Constrained Delegation. In 4738/4742 erscheinen sie als Klartext im Feld "User Account Control"; in 5136 steht der komplette neue Zahlenwert von userAccountControl, aus dem das SIEM das betroffene Bit herausrechnet. Entscheidend ist das Wort "Enabled" bzw. das neu gesetzte Bit - ein bereits lange gesetztes Flag erzeugt kein Ereignis.
• Das Attribut msDS-AllowedToDelegateTo. Hier steht, auf welche Ziel-SPNs eingeschränkte Delegation erlaubt ist. In 5136 ist der hinzugefügte Ziel-SPN direkt lesbar (AttributeValue), und genau der entscheidet über die Kritikalität: cifs/ oder host/ auf einem Fileserver ist Alltag, ldap/ auf einem Domain Controller ist ein Eskalationspfad.
• Die Nutzung in 4769. Ist bei einer Diensticket-Anforderung das Feld TransmittedServices gefüllt, lief S4U2Proxy, also eingeschränkte Delegation. Das ist der Beleg der Nutzung - aber korrekt eingerichtete Serviceketten erzeugen es ständig. Ein einzelnes 4769 mit TransmittedServices beweist keinen Missbrauch; aussagekräftig wird es erst im Kontext.

Mehrstufig denken. Der belastbare Nachweis ist eine Kette: (1) Delegation wird neu aktiviert oder erweitert; (2) das betroffene Konto oder System ist ungewöhnlich oder sensibel (ein Mitgliedsserver, der vorher keine Delegation hatte; ein privilegiertes Konto); (3) der Ziel-SPN ist kritisch (ein Dienst auf einem Domain Controller); (4) die Änderung stammt von einem ungewöhnlichen Principal oder Host; (5) danach folgt auffällige Kerberos-Nutzung (eine Fächerung von 4769 mit TransmittedServices über viele imitierte Benutzer). Keine dieser Stufen ist für sich ein Angriff, und nicht jede Delegationsänderung ist bösartig. Die Korrelation über Zeit und über dasselbe Konto gehört ins SIEM; eine einzelne portable Sigma-Regel kann die Sequenz aus Konfigurationsänderung und späterer Nutzung nicht zuverlässig abbilden. Die vier Regeln unten decken deshalb die einzelnen Stufen sauber ab, und die Checkliste beschreibt die Verkettung.

Vier Sigma-Regeln

Die erste Regel fängt die Aktivierung von Unconstrained Delegation über das Flag TRUSTED_FOR_DELEGATION in 4738 und 4742. Sie prüft die Klartext-Form, die die meisten Parser liefern; welche Form im eigenen SIEM ankommt, zeigt der Lab-Test.

title: Unconstrained Delegation an einem Konto aktiviert (TRUSTED_FOR_DELEGATION)
id: 9c243b05-72f1-4db1-a4ed-d9d7d3de927e
status: experimental
description: |
  Kontoaenderung (4738 fuer Benutzer, 4742 fuer Computer), bei der im Feld
  UserAccountControl das Flag TRUSTED_FOR_DELEGATION (0x80000) gesetzt wird. Das ist
  uneingeschraenkte (unconstrained) Delegation: Meldet sich danach ein Benutzer an dem
  betroffenen System an, erhaelt das System dessen weiterleitbares TGT und kann sich
  gegenueber jedem beliebigen Dienst als dieser Benutzer ausgeben - faellt ein Domain
  Admin darauf herein, ist die Domaene kompromittiert. Viele SIEM-Parser loesen die
  Aenderung im Feld UserAccountControl als Klartext "'Trusted For Delegation' - Enabled"
  auf; andere liefern einen Meldungscode. Welche Form ankommt, wird im Lab geprueft.
  Legitim tragen nur Domain Controller dieses Flag von Haus aus; ein neues Konto oder
  ein Mitgliedsserver, der es ploetzlich bekommt, ist der Befund. Allein das Flag ist
  kein Incident, sondern ein Pruefauftrag: betroffenes Objekt, ausfuehrender Principal
  (SubjectUserName) und Change-Ticket entscheiden. Voraussetzung: Unterkategorie
  "Benutzerkontenverwaltung ueberwachen" bzw. "Computerkontenverwaltung ueberwachen".
references:
  - https://attack.mitre.org/techniques/T1098/
  - https://learn.microsoft.com/en-us/windows/security/threat-protection/auditing/event-4742
author: blue-team.net
date: 2026-10-10
tags:
  - attack.privilege-escalation
  - attack.persistence
  - attack.t1098
logsource:
  product: windows
  service: security
detection:
  selection:
    EventID:
      - 4738
      - 4742
    UserAccountControl|contains: "'Trusted For Delegation' - Enabled"
  condition: selection
falsepositives:
  - Hochstufung eines neuen Domain Controllers (Computerkonto erhaelt das Flag planmaessig)
  - Dokumentierte Altanwendung, die uneingeschraenkte Delegation wirklich braucht - Objekt und Change-Ticket abgleichen, mittelfristig auf Constrained Delegation umstellen
level: high

Die zweite Regel zielt auf den Protokollübergang TRUSTED_TO_AUTH_FOR_DELEGATION, der die Stellvertretung von der tatsächlichen Anmeldung des imitierten Benutzers entkoppelt und deshalb besonders gefährlich ist.

title: Protokolluebergang fuer Delegation aktiviert (TRUSTED_TO_AUTH_FOR_DELEGATION)
id: db8dc793-200d-4bd1-af51-98ead153a275
status: experimental
description: |
  Kontoaenderung (4738 fuer Benutzer, 4742 fuer Computer), bei der im Feld
  UserAccountControl das Flag TRUSTED_TO_AUTH_FOR_DELEGATION (0x1000000) gesetzt wird -
  der Protokolluebergang (protocol transition) der eingeschraenkten Delegation. Damit
  darf das Konto ueber S4U2Self ein weiterleitbares Diensticket fuer einen beliebigen
  Benutzer anfordern, ohne dass dieser sich jemals angemeldet hat, und es ueber S4U2Proxy
  an die in msDS-AllowedToDelegateTo gelisteten Dienste weiterreichen. In Kombination mit
  einem sensiblen Ziel-SPN ist das ein direkter Weg zur Identitaetsuebernahme. Viele
  Parser loesen die Aenderung als Klartext "'Trusted to Authenticate for Delegation' -
  Enabled" auf; die genaue Form wird im Lab geprueft. Allein das Flag ist kein Incident:
  betroffenes Objekt, Ziel-SPNs, ausfuehrender Principal und Change-Ticket entscheiden.
  Voraussetzung: Unterkategorie "Benutzer-/Computerkontenverwaltung ueberwachen".
references:
  - https://attack.mitre.org/techniques/T1098/
  - https://learn.microsoft.com/en-us/windows/security/threat-protection/auditing/event-4742
author: blue-team.net
date: 2026-10-10
tags:
  - attack.privilege-escalation
  - attack.persistence
  - attack.t1098
logsource:
  product: windows
  service: security
detection:
  selection:
    EventID:
      - 4738
      - 4742
    UserAccountControl|contains: "'Trusted to Authenticate for Delegation' - Enabled"
  condition: selection
falsepositives:
  - Einrichtung von Diensten mit Protokolluebergang (z. B. Web- oder Middleware-Anwendungen, die Vorauthentifizierung ueber ein anderes Protokoll kapseln) - Konto und Ziel-SPNs dokumentieren
  - Geplante Delegationsaenderungen durch das AD-Team im Wartungsfenster
level: high

Die dritte Regel erfasst das Setzen eingeschränkter Delegation über das Attribut msDS-AllowedToDelegateTo in 5136. Der hinzugefügte Ziel-SPN steht im Ereignis; die Bewertung, ob das Ziel kritisch ist (ein Dienst auf einem Domain Controller), macht der Analyst oder eine umgebungsspezifische Verschärfung.

title: Constrained Delegation gesetzt oder geaendert (msDS-AllowedToDelegateTo)
id: d52978d3-378b-4e7c-bf92-537682c43bbc
status: experimental
description: |
  Aenderung des Verzeichnisobjekts (Event 5136), bei der dem Attribut
  msDS-AllowedToDelegateTo ein Wert hinzugefuegt wird. Dieses Attribut traegt die
  Ziel-SPNs, an die ein Konto per eingeschraenkter Delegation (S4U2Proxy) Tickets
  weiterreichen darf; sein Setzen konfiguriert also, wen das Konto gegenueber welchen
  Diensten imitieren kann. 5136 ist hier die belastbarere Quelle als 4742, weil der neue
  Wert (der Ziel-SPN) direkt im Ereignis steht (AttributeValue) und OperationType %%14674
  den hinzugefuegten Wert markiert. Besonders kritisch ist ein Ziel-SPN auf einem Domain
  Controller oder einem Dienst der Verzeichnisreplikation: Zeigt der Wert auf ldap/ eines
  DC, ist das ein delegationsbasierter Weg zu DCSync-aehnlichen Rechten. Die Bewertung
  braucht das Ziel, den betroffenen Principal und das Change-Ticket; nicht jede
  Delegationsaenderung ist ein Angriff. Voraussetzung: Unterkategorie
  "Verzeichnisdienstaenderungen ueberwachen" und eine SACL fuer Schreibzugriffe am Objekt.
references:
  - https://attack.mitre.org/techniques/T1098/
  - https://learn.microsoft.com/en-us/windows/win32/adschema/a-msds-allowedtodelegateto
author: blue-team.net
date: 2026-10-10
tags:
  - attack.privilege-escalation
  - attack.t1098
logsource:
  product: windows
  service: security
  definition: 'Audit Directory Service Changes auf dem Domain Controller'
detection:
  selection:
    EventID: 5136
    AttributeLDAPDisplayName: 'msDS-AllowedToDelegateTo'
    OperationType|contains:
      - '%%14674'
      - 'Value Added'
  condition: selection
falsepositives:
  - IIS-, SQL-, SharePoint- und Middleware-Dienste, die eingeschraenkte Delegation planmaessig nutzen (Serviceketten) - Konto und Ziel-SPNs allowlisten
  - Cluster- und Backup-Produkte mit Delegationsbedarf; Migrationen und Service-Account-Onboarding im Wartungsfenster
level: high

Die vierte Regel belegt die Nutzung: ein 4769 mit gefülltem TransmittedServices (S4U2Proxy). Sie steht bewusst auf Stufe mittel und ist ein Hunting- und Korrelationssignal, kein Einzelbeweis - korrekt eingerichtete Delegation erzeugt sie im Normalbetrieb.

title: Diensticket ueber Delegation weitergereicht (4769 mit TransmittedServices)
id: 6ddcebce-73bb-4123-b155-2ca11f146c8b
status: experimental
description: |
  Diensticket-Anforderung (Event 4769), bei der das Feld TransmittedServices gefuellt ist.
  Dieses Feld wird nur bei S4U2Proxy belegt, also wenn ein Konto per eingeschraenkter
  Delegation ein Ticket im Namen eines anderen Benutzers an einen Zieldienst weiterreicht;
  es nennt die Dienste der Delegationskette. Damit ist dies das Ereignis der tatsaechlichen
  Delegationsnutzung - im Gegensatz zu den Konfigurationsregeln (uAC-Flags,
  msDS-AllowedToDelegateTo). Wichtig: Ein einzelnes 4769 mit TransmittedServices beweist
  keinen Missbrauch; korrekt eingerichtete Delegation (IIS/SQL/SharePoint-Serviceketten)
  erzeugt es im Normalbetrieb staendig. Die Regel ist deshalb ein Hunting- und
  Korrelationssignal: wertvoll vor allem kurz nach einer Delegationsaenderung (Regel 1-3),
  bei einem ungewoehnlichen weiterreichenden Konto, einem sensiblen ServiceName oder einer
  untypischen Faecherung ueber viele imitierte Benutzer. Die Zaehlung und die zeitliche
  Verknuepfung mit der Konfigurationsaenderung gehoeren ins SIEM, nicht in eine einzelne
  portable Regel. Das Matchen auf "/" prueft nur, ob das Feld einen SPN traegt (gefuellt ist).
references:
  - https://attack.mitre.org/techniques/T1558/
  - https://learn.microsoft.com/en-us/windows/security/threat-protection/auditing/event-4769
author: blue-team.net
date: 2026-10-10
tags:
  - attack.credential-access
  - attack.t1558
logsource:
  product: windows
  service: security
detection:
  selection:
    EventID: 4769
    TransmittedServices|contains: '/'
  condition: selection
falsepositives:
  - Korrekt konfigurierte eingeschraenkte Delegation im Normalbetrieb (IIS/SQL/SharePoint, Middleware, Cluster) - erzeugt dieses Ereignis regulaer; nur im Kontext einer Konfigurationsaenderung oder eines sensiblen Ziels bewerten
  - Dokumentierte Serviceketten; weiterreichendes Konto und Zieldienst allowlisten
level: medium

Alle vier Regeln sind mit sigma-cli geprüft. Das heißt: syntaktisch korrekt und gegen das verwendete ATT&CK-Dataset validiert, nicht produktiv getestet. EventID, UserAccountControl, AttributeLDAPDisplayName, AttributeValue, OperationType und TransmittedServices entsprechen den nativen Feldern des Security-Logs in der Sigma-Windows-Taxonomie und müssen zum eigenen SIEM-Mapping passen. Backendabhängig ist vor allem, ob die Flag-Änderung in 4738/4742 als Klartext ("'Trusted For Delegation' - Enabled") oder als Meldungscode ankommt und ob 5136 das Attribut msDS-AllowedToDelegateTo mit Wert liefert; beides wird im Lab geprüft. Die Übersetzung in die eigene Abfragesprache steht im Beitrag zu Sigma-Regeln.

Blindspots

• Bestehende Delegation. Eine Delegation, die schon vor der Protokollierung bestand, erzeugt kein Änderungsereignis. Sie findet nur ein Inventar (Konten mit Delegationsflags, Konten mit msDS-AllowedToDelegateTo) oder die Expositionsanalyse mit BloodHound, nicht die Detection.
• Nutzung ohne vorherige Änderung. Wer eine bereits bestehende, zu weit gefasste Delegation ausnutzt, löst keine Konfigurationsregel aus. Dann bleibt nur die Nutzungssicht (4769 mit TransmittedServices) im Kontext - und die ist von legitimer Nutzung schwer zu trennen.
• Parsing der Flags. Liefert der Parser die uAC-Änderung in 4738/4742 weder als Klartext noch als auswertbaren Code, laufen Regel 1 und 2 ins Leere. Dann ist 5136 auf userAccountControl der Rückfallweg, erfordert aber das Herausrechnen des Bits im SIEM.
• RBCD. Die ressourcenbasierte Variante läuft über msDS-AllowedToActOnBehalfOfOtherIdentity und wird von diesen Regeln bewusst nicht erfasst; ihre Erkennung steht in Post 1267.
• Domain Controller ohne Anbindung. Wie bei allen AD-Ereignissen ist ein Domain Controller, der nicht ins SIEM liefert, ein blinder Fleck für die ganze Technik.

Fehlalarme und Tuning

• IIS, SQL, SharePoint und Legacy-Anwendungen. Der Haupt-Fehlalarm. Klassische Serviceketten (Webfrontend zu Datenbank) nutzen eingeschränkte Delegation planmäßig und erzeugen regelmäßig msDS-AllowedToDelegateTo-Werte und 4769 mit TransmittedServices. Die bekannten Konten und ihre Ziel-SPNs kommen in eine gepflegte Allowlist.
• Cluster- und Middleware-Systeme. Failover-Cluster und manche Middleware brauchen Delegation. Ihre Konten werden dokumentiert; eine Änderung außerhalb des bekannten Musters bleibt ein Alarm.
• Migrationen und Service-Account-Onboarding. Bei Migrationen und der Einrichtung neuer Dienste werden Delegationen gesetzt. Sie bekommen ein befristetes Änderungsfenster; was danach eintrifft, wird geprüft.
• Geplante AD-Änderungen. Delegationsänderungen durch das AD-Team im Wartungsfenster sind kein Vorfall, aber kein Grund, die Regel stummzuschalten: Der Analyst gleicht mit dem Change-Ticket ab.
• Der Kontext entscheidet. Für die Bewertung zählen immer dieselben Größen: betroffenes Konto oder Computer, der Ziel-SPN und Zieldienst, das Änderungsfenster, der ausführende Principal, der Host und die nachfolgende Kerberos-Nutzung. Unconstrained Delegation auf einem Nicht-DC und ein Ziel-SPN auf einem Domain Controller heben die Priorität sofort an.

Härtung

• Delegation nur wo nötig. Jede Delegation ist eine Erlaubnis zur Identitätsübernahme. Wo sie nicht gebraucht wird, wird sie entfernt; neue Delegation läuft über ein Change mit benanntem Konto und Ziel-SPN.
• Unconstrained Delegation vermeiden. Uneingeschränkte Delegation gehört, außer auf Domain Controllern, abgeschafft. Wo eine Anwendung sie zu brauchen scheint, ist eingeschränkte Delegation (möglichst ohne Protokollübergang) fast immer die bessere Lösung.
• Privilegierte Konten gegen Delegation schützen. Die Kontooption "Konto ist vertraulich und kann nicht delegiert werden" (Flag NOT_DELEGATED) setzt man auf allen Tier-0- und Admin-Konten; die Gruppe Protected Users erzwingt dies zusätzlich. Dann nützt auch eine fremde Delegation nichts, weil die Tickets dieser Konten nicht weiterleitbar sind.
• Delegationsinventar. Regelmäßig alle Konten mit Delegationsflags und mit msDS-AllowedToDelegateTo listen, mit Ziel-SPNs und Verantwortlichem. Diese Liste ist die Grundlage für die Allowlist der Regeln und zugleich das, was ein Angreifer im BloodHound-Graphen sieht.
• Change Monitoring und Tiering. Delegationsänderungen an sensiblen Objekten laufen über Freigabe und Fenster; ein sauberes Tiering verhindert, dass ein Konto niedriger Stufe überhaupt Delegation auf einen Tier-0-Dienst setzen kann.

Der Test

Der Test gehört ausschließlich ins Homelab. Er aktiviert eine ungefährliche Delegationskonfiguration auf einem Testobjekt, erzeugt die Ereignisse und nimmt die Änderung wieder zurück - keine produktionsnahe Missbrauchskette.

1. Ausgangszustand. Ein Testcomputer und ein Testdienstkonto ohne Delegation. Mit Get-ADComputer lab-web01 -Properties TrustedForDelegation,msDS-AllowedToDelegateTo,userAccountControl den Ist-Zustand festhalten; beide Delegationsmerkmale sind leer.
2. Constrained Delegation aktivieren. Dem Testkonto per Set-ADUser bzw. Set-ADComputer ein ungefährliches msDS-AllowedToDelegateTo setzen, etwa auf einen Testdienst (z. B. http/lab-app01). Erwartung: 5136 mit AttributeLDAPDisplayName msDS-AllowedToDelegateTo, OperationType "Value Added" bzw. %%14674 und dem Ziel-SPN im neuen Wert; Regel 3 greift. Parallel in 4742/4738 das Feld AllowedToDelegateTo ansehen.
3. Flags prüfen. An einem zweiten Testobjekt TRUSTED_FOR_DELEGATION setzen und wieder entfernen. Erwartung: 4742 (bzw. 4738) mit "'Trusted For Delegation' - Enabled"; Regel 1 greift. Dabei ablesen, welche Darstellung der eigene Parser liefert (Klartext oder Meldungscode). Den Protokollübergang analog für Regel 2.
4. Kontrollierte Nutzung. Mit dem konfigurierten Testkonto eine eingeschränkte Delegation gegen den Testdienst auslösen (S4U2Proxy, etwa über die Anmeldung der Testanwendung). Erwartung: 4769 mit gefülltem TransmittedServices; Regel 4 greift als Hunting-Signal. So lässt sich die Nutzung zeigen, ohne eine echte Eskalation gegen einen sensiblen Dienst zu fahren.
5. Rücknahme. Delegationsattribut und Flags wieder entfernen, Ist-Zustand gegen Schritt 1 prüfen, Parser-Darstellung und Datum in den Purple-Team-Navigator. Die Testobjekte bleiben isoliert; kein produktives oder privilegiertes Konto wird angefasst.

Analysten-Checkliste

• Welches Objekt wurde geändert? ObjectDN aus 5136 bzw. das Konto aus 4738/4742. Benutzer- oder Computerkonto, Mitgliedsserver oder privilegiertes Konto?
• Welche Delegationsart? Unconstrained (TRUSTED_FOR_DELEGATION), Constrained mit oder ohne Protokollübergang (msDS-AllowedToDelegateTo, TRUSTED_TO_AUTH_FOR_DELEGATION) oder RBCD (dann weiter mit Post 1267)?
• Welcher alte und neue Wert? Flag neu gesetzt oder schon vorhanden; welche Ziel-SPNs kamen hinzu? 5136 liefert den neuen Wert, der Vergleich mit dem alten (oder einer Baseline) zeigt die Differenz.
• Wer hat geändert? SubjectUserName, und über das 4624 mit gleicher SubjectLogonId der Host. Gehört der Principal zu den Konten, die Delegation vergeben dürfen?
• Welche Ziel-SPNs? cifs/ oder host/ auf einem Fileserver ist etwas anderes als ldap/ auf einem Domain Controller. Der Zieldienst entscheidet über die Kritikalität.
• Steht das System auf der genehmigten Delegationsliste? Abgleich mit dem Inventar. Ein Konto ohne Eintrag ist ein Befund.
• Betrifft es Tier 0? Delegation an oder auf Domain Controller, Admin-Konten oder deren Dienste hebt die Priorität auf kritisch.
• Gab es danach ungewöhnliche 4769? Eine Fächerung von Diensttickets mit TransmittedServices über viele imitierte Benutzer, besonders kurz nach der Konfigurationsänderung.
• Gab es parallele ACL- oder Account-Änderungen? Delegationsänderungen treten oft zusammen mit anderen Rechteänderungen auf; der AD-ACL-Missbrauch am selben Objekt oder Principal gehört mitgeprüft.
• Ist RBCD betroffen? Zeigt die Änderung auf msDS-AllowedToActOnBehalfOfOtherIdentity, ist es RBCD - dann Post 1267 heranziehen.

Fazit

Kerberos-Delegation ist kein Angriff, sondern eine Funktion - gefährlich wird erst ihre falsche Konfiguration. Die Erkennung sitzt deshalb an der Änderung: an den Flags TRUSTED_FOR_DELEGATION und TRUSTED_TO_AUTH_FOR_DELEGATION in 4738/4742, am Attribut msDS-AllowedToDelegateTo in 5136 und, als Nutzungssicht, am Feld TransmittedServices in 4769. Wer diese vier Signale erfasst, sie gegen ein Delegationsinventar und die genehmigte Liste hält und den Ziel-SPN sowie die Stufe des betroffenen Kontos bewertet, trennt die seltene missbräuchliche Änderung von der alltäglichen Serviceketten-Delegation. Entscheidend ist die Disziplin, Konfigurationszustand, Änderung und Nutzung auseinanderzuhalten und kein einzelnes 4769 zum Beweis zu erklären. Die Nachbarthemen in dieser Serie: RBCD und Shadow Credentials für die ressourcenbasierte Variante, AD-ACL-Missbrauch für Berechtigungsänderungen allgemein, Kerberoasting und AS-REP Roasting für die offline geknackten Kerberos-Geheimnisse und DCSync für den letzten Schritt zur Domäne. Weitere Techniken dieser Taktik führt das Lexikon nach Taktik unter Privilege Escalation.