RBCD und Shadow Credentials erkennen: moderne AD-Rechteausweitung

RBCD erkennen und Shadow Credentials erkennen gehören heute zu den wichtigsten AD-Erkennungen, weil beide Techniken leise sind und trotzdem direkt zur Rechteausweitung führen. Sie setzen kein Passwort und keine Schwachstelle voraus, sondern nur ein Schreibrecht auf das Zielobjekt, etwa auf ein Computerkonto. Woher dieses Schreibrecht kommt, ist zweitrangig: aus einer zu weit vergebenen Berechtigung, aus einem per NTLM-Relay auf LDAP gestohlenen Kontext oder aus einer missbrauchten Delegierung. Hat der Angreifer es, schreibt er ein einziges Attribut und authentifiziert sich danach als das Zielkonto. Dieser Beitrag aus der Serie „Angriff erkennen“ zeigt beide Techniken aus Verteidigersicht, mit drei Sigma-Regeln und dem Test.

Was der Angreifer tut

Beide Techniken folgen demselben Dreischritt: Schreibrecht beschaffen, ein Attribut setzen, sich als das Zielkonto anmelden. Bewusst auf der Ebene des Prinzips, nicht als Anleitung:

• RBCD (Resource-Based Constrained Delegation). Der Angreifer setzt am Zielcomputer das Attribut msDS-AllowedToActOnBehalfOfOtherIdentity so, dass ein von ihm kontrolliertes Konto für beliebige Benutzer Tickets zu diesem Computer anfordern darf. Über die Kerberos-Erweiterungen S4U2Self und S4U2Proxy besorgt er sich dann ein Ticket als Administrator für das Ziel.
• Shadow Credentials. Der Angreifer hängt in das Attribut msDS-KeyCredentialLink des Zielkontos ein eigenes Schlüsselpaar ein. Damit kann er sich per PKINIT, also zertifikatbasiert, als das Zielkonto bei Kerberos anmelden, ähnlich wie beim AD-CS-Missbrauch, nur ohne Zertifizierungsstelle.
• Das kontrollierte Konto. Für RBCD braucht der Angreifer ein Konto mit einem Dienstprincipalnamen. Weil jeder Benutzer standardmäßig bis zu zehn Computerkonten anlegen darf (MachineAccountQuota), legt er sich dieses Konto oft einfach selbst an.

Der gemeinsame Nenner für die Erkennung ist die Attributänderung am Verzeichnis. Beide Techniken schreiben ein sehr spezifisches Attribut, das legitim selten und nur von wenigen Stellen gesetzt wird. Genau darauf zielen die Regeln unten.

Welche Logquellen die Technik zeigt

• Attributänderung. Event 5136 zeigt die Änderung eines Verzeichnisobjekts mit Attributname, altem und neuem Wert sowie auslösendem Konto. Das ist die wichtigste Quelle und setzt die Überwachung Audit Directory Service Changes auf den Domain Controllern voraus.
• Neues Computerkonto. Event 4741 zeigt das Anlegen eines Computerkontos samt erstellendem Konto. Ein Benutzer, der ein Computerkonto anlegt, ist das Zeichen für den MachineAccountQuota-Missbrauch.
• Zertifikatsanmeldung. Event 4768 mit PreAuthType 15 zeigt die PKINIT-Anmeldung, die nach dem Setzen von Shadow Credentials folgt, oft von einem untypischen Client.
• Delegierte Tickets. Event 4769 zeigt die Service-Ticket-Anfragen, bei RBCD samt der S4U-Kette zum Zielcomputer.

Das Muster im Log

Das stärkste Signal ist die Attributänderung selbst, weil sie so spezifisch ist. Ein msDS-AllowedToActOnBehalfOfOtherIdentity, das außerhalb eines geplanten Delegierungsvorhabens gesetzt wird, hat fast immer einen bösartigen Hintergrund. Bei msDS-KeyCredentialLink ist mehr Kontext nötig, weil Windows Hello for Business dasselbe Attribut legitim setzt; verdächtig ist es vor allem an Konten, die nicht an der Geräteregistrierung teilnehmen, etwa an Servern oder privilegierten Konten. Noch überzeugender wird der Fall in der Kette: ein Benutzer legt ein Computerkonto an, setzt kurz darauf eine Delegierung oder einen KeyCredentialLink und meldet sich dann per PKINIT an. Wer diese Abfolge sieht, sieht eine Rechteausweitung in Echtzeit.

Drei Sigma-Regeln

Die Regeln sind mit sigma-cli geprüft. Die erste und zweite fangen die Attributänderungen von RBCD und Shadow Credentials, die dritte das selbst angelegte Computerkonto. Alle drei hängen an der Verzeichnisüberwachung am Domain Controller.

1. RBCD-Delegierung gesetzt (T1098). Diese Regel erkennt das Setzen von msDS-AllowedToActOnBehalfOfOtherIdentity. Sie ist hochwertig, weil dieses Attribut legitim nur selten und gezielt gesetzt wird.

title: RBCD-Delegierung an einem Objekt gesetzt (msDS-AllowedToActOnBehalfOfOtherIdentity)
id: fdd5dc82-5a3f-48f1-8c78-e98125c68c8c
status: experimental
description: Erkennt das Setzen des Attributs msDS-AllowedToActOnBehalfOfOtherIdentity
  an einem Computer- oder Benutzerobjekt. Damit wird Resource-Based Constrained
  Delegation eingerichtet, die einem kontrollierten Konto erlaubt, sich gegenueber
  dem Zielobjekt als beliebiger Benutzer auszugeben. Ausserhalb geplanter
  Delegierungsaenderungen ist das ein starkes Zeichen fuer Rechteausweitung.
references:
  - https://attack.mitre.org/techniques/T1098/
author: blue-team.net
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-AllowedToActOnBehalfOfOtherIdentity'
  condition: selection
falsepositives:
  - Dokumentierte Einrichtung von Delegierung durch das AD-Team im Wartungsfenster
level: high

2. Shadow Credentials gesetzt (T1098). Diese Regel erkennt das Setzen von msDS-KeyCredentialLink. Sie steht bewusst auf level: medium, weil Windows Hello for Business dasselbe Attribut legitim schreibt; den Kontext grenzt du über die betroffenen Konten ein.

title: Shadow Credentials an einem Objekt gesetzt (msDS-KeyCredentialLink)
id: bd9f632d-4da3-42ce-80f8-fd106c1274d9
status: experimental
description: Erkennt das Setzen des Attributs msDS-KeyCredentialLink an einem
  Computer- oder Benutzerobjekt. Angreifer hinterlegen damit ein alternatives
  Schluesselpaar (Shadow Credentials) und melden sich anschliessend per PKINIT als
  das Zielkonto an. Windows Hello for Business und die Geraeteregistrierung
  schreiben dieses Attribut ebenfalls, weshalb der Kontext entscheidet.
references:
  - https://attack.mitre.org/techniques/T1098/
author: blue-team.net
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-KeyCredentialLink'
  condition: selection
falsepositives:
  - Windows Hello for Business und Geraeteregistrierung setzen dieses Attribut legitim
level: medium

3. Computerkonto von einem Benutzer angelegt (T1136.002). Legt ein normales Benutzerkonto ein Computerkonto an, ist das der typische MachineAccountQuota-Missbrauch als Vorbereitung für RBCD.

title: Computerkonto von einem Benutzerkonto angelegt (MachineAccountQuota)
id: bb8152fe-42a9-42f3-bd1f-d0e6591d3ebc
status: experimental
description: Erkennt das Anlegen eines Computerkontos durch ein normales
  Benutzerkonto. Standardmaessig darf jeder Benutzer bis zu zehn Computerkonten
  anlegen (MachineAccountQuota). Angreifer nutzen ein selbst angelegtes
  Computerkonto als kontrollierten Principal fuer RBCD und aehnliche Angriffe.
references:
  - https://attack.mitre.org/techniques/T1136/002/
author: blue-team.net
tags:
  - attack.persistence
  - attack.t1136.002
logsource:
  product: windows
  service: security
detection:
  selection:
    EventID: 4741
  filter_machine:
    SubjectUserName|endswith: '$'
  condition: selection and not filter_machine
falsepositives:
  - Administratoren und Bereitstellungsdienste, die planmaessig Computerkonten anlegen
level: medium

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

• MachineAccountQuota auf null setzen. Der Standardwert von zehn erlaubt jedem Benutzer, Computerkonten anzulegen. Setze ihn auf null und lege Computerkonten nur noch kontrolliert über das IT-Team an.
• Schreibrechte prüfen. Beide Techniken brauchen Schreibrechte auf das Zielobjekt. Prüfe mit BloodHound oder vergleichbaren Werkzeugen regelmäßig, wer auf Computer- und privilegierte Konten schreiben darf, und räume zu weite Rechte aus.
• LDAP absichern. Weil diese Rechte oft per NTLM-Relay auf LDAP erlangt werden, gehören LDAP-Signierung und Channel Binding erzwungen. Details unter NTLM-Relay und Responder erkennen.
• Tiering einhalten. Ein sauberes Berechtigungsmodell verhindert, dass ein kompromittiertes Konto der unteren Ebene überhaupt auf privilegierte Objekte schreiben kann.

Der Test

Die Erkennung lässt sich im Lab mit AD-Bordmitteln prüfen, ausschließlich auf einem isolierten Test-Domain-Controller mit aktiver Verzeichnisüberwachung:

• Für Regel 1 das Setzen von msDS-AllowedToActOnBehalfOfOtherIdentity an einem Testcomputer, etwa per PowerShell mit Set-ADComputer. Event 5136 muss die Änderung zeigen und die Regel auslösen.
• Für Regel 2 das Hinzufügen eines KeyCredentialLink an einem Testkonto. Event 5136 muss das Attribut nennen. Danach ein echtes Windows-Hello-Gerät prüfen, um die legitime Form als Ausnahme zu erkennen.
• Für Regel 3 das Anlegen eines Computerkontos mit einem normalen Testbenutzer. Event 4741 muss das erstellende Benutzerkonto zeigen und die Regel greifen.

Fehlalarme und Tuning

• Windows Hello for Business. Die größte Fehlalarmquelle ist Regel 2, weil WHfB und die Geräteregistrierung msDS-KeyCredentialLink legitim setzen. Grenze die Regel auf Konten ein, die nicht an WHfB teilnehmen, etwa Server und privilegierte Konten.
• Geplante Delegierung. Legitime RBCD-Einrichtung kommt vor, ist aber selten und dokumentiert. Halte die geplanten Vorhaben fest, damit die Treffer von Regel 1 zugeordnet werden können.
• Bereitstellung von Computerkonten. Manche Bereitstellungsdienste legen Computerkonten über Benutzerkonten an. Nimm diese bekannten Dienste als Ausnahme auf und behalte den Rest scharf.
• Priorität. Ein Treffer von Regel 1 gehört zu den hochprioren Alarmen. Kombiniert mit einem frisch angelegten Computerkonto und einer PKINIT-Anmeldung ist der Fall eindeutig.

Fazit

RBCD und Shadow Credentials sind leise, aber nicht unsichtbar: Beide schreiben ein sehr spezifisches Attribut, das sich sauber überwachen lässt, und beide brauchen ein Schreibrecht, das sich prüfen und entziehen lässt. Die drei Regeln hier fangen die Attributänderungen und das vorbereitete Computerkonto; die eigentliche Abwehr liegt in MachineAccountQuota, sauberen ACLs und abgesichertem LDAP. Weil die nötigen Rechte oft aus NTLM-Relay oder aus der Aufklärung mit BloodHound stammen, lohnt der Blick auf beide, und verwandte AD-Hintertüren stehen unter AD-Hintertüren erkennen. Weitere Techniken dieser Taktik stehen im Lexikon nach Taktik.