Active Directory Computerobjekte Angriffsfläche: Das Maschinenidentitäts-Risiko, das niemand auditiert

Die Angriffsfläche von Active-Directory-Computerobjekten ist der Sammelbegriff für die Delegations-, Replikationsrechte- und Gruppenmitgliedschaftsrisiken, die Maschinenkonten routinemäßig tragen — Konten, die Active Directory automatisch für jede domänenverbundene Maschine anlegt und die selten so auditiert werden wie Benutzerkonten. Anders als Benutzerkonten erhalten Computerkonten kaum individuelle Aufmerksamkeit: Niemand prüft ihre Delegationseinstellungen, ihre Gruppenmitgliedschaften oder ihren Patch-Stand so, wie man das bei einem privilegierten Benutzer tun würde. Genau diese Lücke nutzen mehrere etablierte Angriffstechniken aus.

Dieser Artikel behandelt speziell die Angriffsfläche von Computerobjekten — abgegrenzt von Kerberos Delegation Attacks: From Unconstrained to RBCD Abuse, der die Delegationsmechanismen selbst erklärt, und ACL Abuse and DCSync: The Silent Paths to Domain Admin, der ACL-basierte Rechteausweitung allgemein behandelt. Hier liegt der Fokus enger: welche Computerobjekte in Ihrer Domäne gefährliche Rechte tragen — und warum das so leicht übersehen wird.

Was ist die Angriffsfläche von Active-Directory-Computerobjekten?

Jede domänenverbundene Windows-Maschine erhält ein Computerkonto in Active Directory — ein vollwertiges Sicherheitsprinzipal mit eigener SID, eigenen Kerberos-Credentials (automatisch rotiert, typischerweise alle 30 Tage) und der Fähigkeit, Gruppenmitgliedschaften und Delegationsrechte zu halten, genau wie ein Benutzerkonto. Das ist der Sinn dahinter: Dienste, die als SYSTEM auf einer domänenverbundenen Maschine laufen, authentifizieren sich gegenüber dem Rest der Domäne als dieses Computerkonto.

Das Risiko folgt direkt aus diesem Design. Einem Computerkonto können — bewusst oder durch Drift — dieselben Kategorien gefährlicher Rechte zugewiesen werden wie einem Benutzerkonto: Delegation, die es erlaubt, andere Benutzer zu impersonieren, Replikationsrechte, die DCSync ermöglichen, oder Mitgliedschaft in einer privilegierten Gruppe. Der Unterschied liegt in der Sichtbarkeit: Sicherheitsteams prüfen routinemäßig, welche Benutzer Domain Admins sind, fragen aber selten, welche Computer sich wie einer verhalten können.

Warum Computerobjekte durchs Raster fallen

Provisioning-Workflows legen Computerobjekte automatisch an, oft über Imaging, Autopilot-Enrollment oder SCCM/Intune-Deployment — ohne menschliche Prüfung der Rechte des resultierenden Objekts zum Zeitpunkt der Erstellung. Angriffspfade wie die in Active Directory Attack Paths to Domain Admin beschriebenen verketten genau diese Art unüberprüfter Rechtevergabe mit anderen Fehlkonfigurationen, um Domain Admin zu erreichen; Computerobjekte sind in dieser Kette überproportional häufig das verbindende Glied, gerade weil sie selten Gegenstand eines eigenen Review-Zyklus sind, wie es bei privilegierten Benutzerkonten der Fall ist.

Uneingeschränkte Delegation auf einem Computerobjekt

Wenn ein Computerkonto für uneingeschränkte Delegation konfiguriert ist (das TRUSTED_FOR_DELEGATION-Flag in UserAccountControl), wird bei jedem Benutzer, der sich gegenüber einem Dienst auf dieser Maschine authentifiziert, sein vollständiges Ticket Granting Ticket (TGT) — nicht nur ein Service-Ticket — im Speicher dieser Maschine zwischengespeichert. Laut der vielzitierten Analyse dieses Risikos von Sicherheitsforscher Sean Metcalf bedeutet das: Ein einzelner kompromittierter Host mit uneingeschränkter Delegation kann die TGTs jedes Benutzers ansammeln, der sich bei ihm authentifiziert — einschließlich der Domänencontroller selbst, wenn diese zu einer Verbindung veranlasst werden.

Warum es das immer noch gibt

Uneingeschränkte Delegation war das ursprüngliche Delegationsmodell in Windows 2000 und wurde für legitime Anwendungsfälle von eingeschränkter Delegation und RBCD abgelöst; Microsofts eigene Empfehlung rät von ihrer Nutzung ab. Ihr Hauptrisiko heute ist Legacy-bedingt: Server, die vor Jahren dafür konfiguriert wurden — oft für Druckserver, frühe Webanwendungs-Deployments oder ad-hoc-Administrationswerkzeuge — und nie wieder überprüft wurden, nachdem die ursprüngliche Begründung in Vergessenheit geraten war.

Missbrauch von Resource-Based Constrained Delegation (RBCD)

Resource-Based Constrained Delegation (RBCD) funktioniert anders als die älteren Delegationsmodelle: Statt auf dem Konto konfiguriert zu werden, das delegieren muss, wird sie auf der Zielressource selbst konfiguriert, über das Attribut msDS-AllowedToActOnBehalfOfOtherIdentity. Wer auch immer in diesem Attribut aufgeführt ist, kann beliebige Benutzer gegenüber dieser spezifischen Ressource impersonieren.

Die sicherheitsrelevante Tragweite wurde in Elad Shamirs Forschung von 2019, „Wagging the Dog: Abusing Resource-Based Constrained Delegation to Attack Active Directory“, im Detail dargelegt. Die zentrale Erkenntnis: Jedes Prinzipal mit Schreibzugriff auf das Attribut msDS-AllowedToActOnBehalfOfOtherIdentity eines Computerobjekts kann RBCD dafür konfigurieren — ohne die domänenadministrator-ähnlichen Rechte zu benötigen, die ältere Delegationsmodelle erforderten. Das schließt ein Prinzipal mit lediglich GenericAll-, GenericWrite- oder WriteDacl-/WriteProperty-Rechten auf dem Ziel-Computerobjekt ein. Shamirs Forschung zeigte außerdem, dass S4U2Self bei jedem Konto mit einem SPN funktioniert, unabhängig von dessen TrustedToAuthForDelegation-Einstellung, und dass Microsofts Reaktion zum damaligen Zeitpunkt war, dies sei „kein Problem, das über ein Sicherheitsupdate behoben wird“ — das Missbrauchspotenzial von RBCD ist eine Konsequenz seines Designs, kein patchbarer Fehler.

Warum RBCD ein ACL-Problem ist, kein Delegationsproblem

Das macht RBCD-Missbrauch grundlegend zu einem ACL-Problem auf Computerobjekten, nicht zu einem Problem der Delegationskonfiguration. Ein Computerkonto mit einer scheinbar risikoarmen ACL-Vergabe aus einem vergangenen Projekt oder aus Standard-Installerverhalten kann zu einem vollwertigen Impersonations-Primitiv werden. Wer nur den Wert von msDS-AllowedToActOnBehalfOfOtherIdentity selbst prüft, übersieht die eigentliche Exposition — der tatsächliche Kontrollpunkt ist, wer berechtigt ist, dorthin zu schreiben.

DCSync-Rechte auf einem Maschinenkonto

DCSync missbraucht die erweiterten Rechte DS-Replication-Get-Changes und DS-Replication-Get-Changes-All, die normalerweise Domänencontrollern vorbehalten sind, um über das Directory-Replikationsprotokoll Passwort-Hashes für beliebige Konten abzuziehen. Computerkonten von Domänencontrollern halten diese Rechte legitim. Das hier behandelte Risiko ist ein anderes: ein Nicht-DC-Computerkonto, dem DCSync-fähige Rechte gewährt wurden, bewusst oder versehentlich (zum Beispiel durch eine zu breit gefasste ACL-Vorlage, die an der Domänenwurzel angewendet wurde, oder Replikationsrechte, die einem Backup-/Monitoring-Dienstkonto gewährt wurden, das zufällig maschinengebunden ist).

Die BloodHound-Dokumentation von SpecterOps beschreibt die DCSync-Kante als die Kombination dieser beiden Rechte auf einem beliebigen Prinzipal — Benutzer, Gruppe oder Computer — und weist darauf hin, dass sie auch indirekt durch Fehlkonfigurationen bei eingeschränkter Delegation entstehen kann, ohne dass das Objekt die Replikationsrechte je explizit hält.

Computer in privilegierten Gruppen

Ein Computerkonto, das einer privilegierten Gruppe hinzugefügt wird (Domain Admins, Enterprise Admins oder eine benutzerdefinierte Tier-0-Gruppe), verleiht Domain-Admin-äquivalente Rechte an alles, was als SYSTEM auf dieser Maschine läuft — was in der Praxis bedeutet: an jeden, der Codeausführung auf ihr erlangen kann. Das ist ein anderes Expositionsprofil als bei einem privilegierten Benutzerkonto: Eine Workstation oder ein Anwendungsserver lässt sich in der Regel leichter kompromittieren als ein gehärteter administrativer Endpunkt, und sein SYSTEM-Kontext steht weit mehr Codepfaden zur Verfügung (geplante Aufgaben, Dienste, lokale Admin-Konten) als einer einzelnen interaktiven Benutzersitzung.

Das ist dasselbe strukturelle Problem, das in Dangerous Group Nesting: Hidden Paths to Domain Admin behandelt wird — eine Gruppenmitgliedschaft, die für sich genommen unauffällig wirkt, wird gefährlich, sobald man nachvollzieht, wer tatsächlich die effektive Kontrolle über die Maschine hat, die sie hält.

Veraltete Betriebssysteme, die noch in der Domäne sind

Computerobjekte, die Windows-Versionen jenseits ihres Support-Lebenszyklus betreiben — Windows XP, Windows Server 2003 oder älter — erhalten von Microsoft keine Sicherheitsupdates mehr, auch nicht für aktiv ausgenutzte Schwachstellen. Ein Domänencontroller oder Mitgliedsserver auf einem veralteten Betriebssystem ist ein dauerhafter, nicht patchbarer Schwachpunkt, und weil diese Systeme oft für eine spezifische Legacy-Anwendung online gehalten werden, werden sie tendenziell aus den routinemäßigen Patch- und Schwachstellenmanagement-Prozessen ausgeschlossen, statt als die höchste Prioritäts-Exposition markiert zu werden, die sie darstellen.

Diese Systeme überschneiden sich häufig mit dem in Stale Privileged Accounts: Hidden Risk in Active Directory beschriebenen Muster: Beide sind Expositionen, die genau deshalb fortbestehen, weil niemand die Entscheidung verantwortet, sie zu entfernen.

Erkennung

Behebung

1. Sensible Konten als nicht delegierbar markieren

Setzen Sie das Flag „Konto ist vertraulich und kann nicht delegiert werden“ (Account is sensitive and cannot be delegated) für hochwertige Konten, damit sie nicht einmal von einem kompromittierten Host mit uneingeschränkter Delegation erbeutet werden können.

2. Uneingeschränkte Delegation überall entfernen, wo möglich

Migrieren Sie legitime Anwendungsfälle zu eingeschränkter Delegation oder RBCD, die die Impersonation auf spezifische Zieldienste begrenzen.

3. Jede RBCD-Konfiguration auditieren — und die ACLs, die ihre Einrichtung erlauben

Prüfen Sie msDS-AllowedToActOnBehalfOfOtherIdentity auf allen Computerobjekten und — noch wichtiger — prüfen Sie, wer GenericAll-/GenericWrite-/WriteDacl-Rechte hält, mit denen er das Attribut überhaupt erst konfigurieren könnte.

4. DCSync-fähige Rechte von Nicht-DC-Prinzipalen entfernen

Auditieren Sie Vergaben von DS-Replication-Get-Changes / DS-Replication-Get-Changes-All an der Domänenwurzel und jeder delegierten OU.

5. Computerkonten aus privilegierten Gruppen entfernen

Sofern kein spezifischer, dokumentierter und überprüfter Grund für die Mitgliedschaft vorliegt, behandeln Sie jeden Treffer als zu behebenden Befund, nicht als zu duldende Konfiguration.

6. Systeme mit veraltetem Betriebssystem stilllegen oder isolieren

Wo eine Stilllegung nicht sofort möglich ist, isolieren Sie das System im Netzwerk und entfernen Sie alle privilegierten Rechte oder Gruppenmitgliedschaften, die es hält.

# Computerobjekte auflisten, die für uneingeschränkte Delegation konfiguriert sind
Get-ADComputer -Filter 'TrustedForDelegation -eq $true' -Properties TrustedForDelegation, OperatingSystem

# Computerobjekte mit gesetzter RBCD-Konfiguration auflisten
Get-ADComputer -Filter * -Properties msDS-AllowedToActOnBehalfOfOtherIdentity |
  Where-Object { $_.'msDS-AllowedToActOnBehalfOfOtherIdentity' }

Wie EtcSec das erkennt

Die Kategorie „Computers“ von EtcSec deckt diese Angriffsfläche direkt ab: COMPUTER_UNCONSTRAINED_DELEGATION, COMPUTER_RBCD, COMPUTER_DCSYNC_RIGHTS und COMPUTER_IN_ADMIN_GROUP markieren die oben beschriebenen Delegations-, Replikationsrechte- und Gruppenmitgliedschaftsrisiken, während COMPUTER_OS_OBSOLETE_XP und COMPUTER_OS_OBSOLETE_2003 Betriebssysteme jenseits ihres Supportendes markieren, die noch in der Domäne vorhanden sind.

Primärquellen

• Elad Shamir: Wagging the Dog — Abusing Resource-Based Constrained Delegation to Attack Active Directory
• ADSecurity.org (Sean Metcalf): Active Directory Security Risk #101 — Kerberos Unconstrained Delegation
• SpecterOps BloodHound Documentation: DCSync edge
• SpecterOps BloodHound Documentation: CoerceToTGT edge
• hackndo: Resource-Based Constrained Delegation — Risks
• Microsoft Learn: Making the second hop in PowerShell Remoting (delegation background)