← Active Directory

Angriffspfade & Abwehr

Vier Funde, Kapazität für einen. Das knackbare Dienstkonto klingt dringlicher — der Anwendungsserver mit unbeschränkter Delegation, an dem sich Administratoren anmelden, ist es. Angriffspfade sind Graphen, keine Listen: Die Knoten sind Objekte, die Kanten sind Rechte und Anmeldungen, und keine einzelne Kante ist falsch vergeben — erst ihre Verkettung ergibt einen Weg. Dieses Modul behandelt die bekannten AD-Pfade aus Verteidigersicht: Roasting als Offline-Angriff auf Entropie, Replikationsrechte als Domänen-Geheimnisse, unbeschränkte Delegation als stille Tier-0-Erhebung eines gewöhnlichen Servers, gefälschte Tickets samt der Frage, warum krbtgt zweimal zurückgesetzt werden muss — und die Reihenfolge der Eindämmung, wenn ein Fund kein Konfigurationsfehler mehr ist.

Lehrtext · 12 Abschnitte · zuletzt geprüft: 2026-09-06

Das Denkmodell: Angriffe folgen der Mechanik, nicht der Magie

Die bekannten AD-Angriffspfade sind kein „Hacken“ im Filmsinn. Sie missbrauchen legitime Mechanik — die Art, wie Kerberos Tickets ausstellt, wie Domain Controller replizieren und wie Berechtigungen (ACLs) vererbt werden. Als Verteidiger brauchst du deshalb nicht jeden Exploit auswendig, sondern das mentale Modell: Welche Fähigkeit missbraucht der Angriff, und wo sitzt die Barriere, die ihn stoppt?

Priorisieren heißt: Pfade, die direkt zu Tier-0 führen (Domänen-Secrets, krbtgt, Domain Admins), zuerst schließen. Ein Kerberoasting-Fund auf einem unwichtigen Dienstkonto ist ärgerlich; ein Nicht-DC mit Replikationsrechten oder unconstrained delegation ist ein direkter Weg zur Domänenübernahme.

LeitfrageFür jeden Fund: Welches Geheimnis oder welche Fähigkeit wird missbraucht — und ist die Abwehr die Ursache (Recht/Flag/Entropie) oder nur ein Symptom (Ticket, Port, Netz)? Symptombekämpfung lässt den Pfad offen.

Wo Kerberos-Angriffe ansetzen

Vier der sechs Pfade hängen am Kerberos-Ablauf. Es hilft, sie an der Stelle im Ticket-Fluss zu verorten, an der sie ansetzen:

ClientKDCDomain-ControllerServiceper SPN① AS-REQ (Identität)② TGT (verschlüsselt)③ TGS-REQ (TGT + SPN)④ Service-Ticket⑤ AP-REQ (Ticket vorlegen)AS gibt das TGT, TGS tauscht es gegen ein Service-Ticket — das Passwort geht nie an den Service.
AS-Exchange (TGT holen): Konten ohne Pre-Authentication geben hier knackbares Material preis → AS-REP-Roasting. TGS-Exchange (Service-Ticket holen): jeder Domänennutzer darf Service-Tickets für SPN-Konten anfordern → Kerberoasting. Wer den `krbtgt`-Hash besitzt, fälscht ein beliebiges TGT → Golden Ticket. Wer den Schlüssel eines Dienstkontos besitzt, fälscht dessen Service-Ticket am AP-Exchange vorbei am KDC → Silver Ticket.
MerksatzKerberos vertraut jedem, der den passenden Schlüssel hat, ohne den KDC erneut zu fragen. Deshalb sind Kontopasswörter und der krbtgt-Schlüssel die eigentlichen Kronjuwelen — nicht die Tickets selbst.

Roasting: offline knacken, was der DC jedem ausgibt

Zwei Angriffe nutzen aus, dass der DC verschlüsseltes Material ohne besondere Rechte herausgibt — das der Angreifer dann offline knackt (keine fehlgeschlagenen Logins, keine Lockouts):

Kerberoasting
Jeder authentifizierte Domänennutzer darf ein Service-Ticket für jedes Konto mit SPN anfordern. Das Ticket ist mit dem Passwort-abgeleiteten Schlüssel des Dienstkontos verschlüsselt → offline knackbar. Betrifft Nutzerkonten mit SPN (typisch alte Dienstkonten mit schwachem, selten geändertem Passwort).
AS-REP-Roasting
Konten mit gesetztem Flag „Kerberos-Pre-Authentication nicht erforderlich“ liefern beim AS-Exchange ein AS-REP, dessen verschlüsselter Teil offline knackbar ist — ganz ohne vorher gültige Credentials des Angreifers.
Abwehr-PrinzipBeide brechen an Entropie und Angriffsfläche: Für SPN-Konten gMSA (automatisch verwaltete, 240-Zeichen-Zufallspasswörter) oder lange Zufallspasswörter, unnötige SPNs entfernen. Für AS-REP: Pre-Authentication erzwingen — das Flag ist die Wurzel, nicht das schwache Passwort allein.
Warum der Fund oft nicht auffälltBeide Angriffe erzeugen im Verzeichnis nichts Ungewöhnliches: Ein Ticket anzufordern ist die alltäglichste Operation der Domäne, und das Knacken passiert danach offline auf dem Rechner des Angreifers — dort sieht niemand zu. Erkennung setzt deshalb nicht am Knacken an, sondern an der Anforderung: ungewöhnlich viele Ticketanforderungen von einem Konto, Anforderungen für Dienste, mit denen dieses Konto nie zu tun hat, oder Anforderungen mit veralteten Verschlüsselungstypen.

DCSync: Replikationsrechte sind Domänen-Secrets

Domain Controller replizieren das Verzeichnis untereinander per Directory Replication Service. Wer die Extended Rights `Replicating Directory Changes` und `Replicating Directory Changes All` auf das Domänen-Root-Objekt besitzt, kann sich als DC ausgeben und die Passwort-Hashes jedes Kontos anfordern — inklusive krbtgt. Das ist DCSync.

  • Diese Rechte sind standardmäßig auf Domain Admins, Enterprise Admins und die DCs selbst begrenzt. Gefährlich wird es, wenn sie an ein Nicht-DC-Konto delegiert wurden (oft versehentlich, oder für ein Sync-Tool).
  • DCSync läuft von jedem domänengejointen Host über legitime RPC-Aufrufe — nicht nur vom DC. Deshalb ist es per Netzwerk-Port kaum sauber vom echten DC-Traffic zu trennen.
  • Legitime Ausnahme: Verzeichnis-Sync-Konten (z. B. Entra/Azure AD Connect) benötigen genau diese Rechte. Vor dem Entfernen also den Zweck klären und solche Konten als gehärtetes Tier-0 behandeln.
Abwehr-PrinzipEin Recht, das so mächtig ist wie ein Domain Controller, gehört ausschließlich auf DCs/Tier-0. Abwehr = least privilege am ACL des Domänen-Objekts und Alarm auf Replikationsanfragen aus Nicht-DC-Quellen — nicht Ports sperren.
Der Fund, der zähltReplikationsverkehr zwischen Domain Controllern ist normal und unauffällig. Auffällig ist Replikationsverkehr von einer Quelle, die kein Domain Controller ist — das ist das Muster, auf das eine Erkennungsregel zielt. Der zweite Fund ist statisch und billiger zu prüfen: die Liste derer, die diese Rechte im Verzeichnis überhaupt besitzen. Sie ist kurz, sie ändert sich selten, und jede Abweichung vom Sollbestand ist eine Frage wert.

Unconstrained Delegation: ein Nicht-DC mit Tier-0-Sprengkraft

Ein Server mit unconstrained delegation cached ein weiterreichbares TGT jedes Nutzers, der sich bei ihm authentifiziert. Ein Angreifer, der diesen Server kontrolliert, kann eine privilegierte Identität — bis hin zu einem DC-Computerkonto — zur Authentifizierung zwingen (Auth-Coercion) und dann deren TGT abgreifen. Ergebnis: Domänenübernahme.

  • Abwehr an der Fähigkeit: unconstrained delegation eliminieren, auf constrained oder RBCD umstellen (begrenzt auf definierte Ziel-SPNs, kein gecachtes Nutzer-TGT).
  • Abwehr an der Identität: privilegierte Konten als „Account is sensitive and cannot be delegated“ markieren und in die Gruppe Protected Users aufnehmen — dann können ihre Tickets gar nicht erst delegiert werden.
  • „Nur intern erreichbar“ ist keine Vertrauensgrenze: Auth-Coercion läuft über interne Protokolle, ein einziger kompromittierter Host im selben Netz genügt.
MerksatzUnconstrained delegation hebt einen gewöhnlichen Server auf Tier-0-Kritikalität, weil dort fremde TGTs liegen. Umzäunen reicht nicht — die Fähigkeit selbst muss weg.

Golden vs. Silver Ticket: gefälschte Tickets und der krbtgt-Reset

Wer die richtigen Schlüssel besitzt, fälscht Tickets, die Kerberos ohne Rückfrage akzeptiert:

Golden Ticket
Gefälschtes TGT, geschmiedet aus dem `krbtgt`-Hash. Erlaubt, sich als beliebiger Nutzer (auch Domain Admin) auszugeben — domänenweit, langlebig. Voraussetzung ist ein früherer krbtgt-Diebstahl (z. B. via DCSync).
Silver Ticket
Gefälschtes Service-Ticket, geschmiedet aus dem Schlüssel eines Dienstkontos. Begrenzt auf diesen einen Dienst, aber am KDC vorbei — der Dienst prüft nur mit seinem eigenen Schlüssel.
Reaktion bei krbtgt-VerdachtDas krbtgt-Konto behält eine Passwort-Historie von zwei (N und N-1). Ein einziger Reset lässt mit dem alten Hash geschmiedete Golden Tickets weiter gültig. Deshalb: krbtgt-Passwort zweimal zurücksetzen — mit Warten auf vollständige Replikation zwischen den beiden Resets, sonst riskierst du Authentifizierungs- und Replikationsstörungen. Der Reset allein ist keine vollständige IR: Der ursprüngliche Zugangsweg muss geschlossen werden, sonst wird krbtgt erneut extrahiert.
Warum zweimal zurücksetzenDas krbtgt-Konto führt eine Kennworthistorie von zwei Werten — dem aktuellen und dem vorherigen. Ein einzelner Wechsel entwertet daher gefälschte Tickets nicht: Der alte Schlüssel bleibt gültig. Erst der zweite Wechsel schiebt ihn aus der Historie. Zwischen beiden muss allerdings genug Zeit für die vollständige Replikation liegen — wer sie zu schnell hintereinander ausführt, sperrt Domain Controller aus, die den ersten Wechsel noch nicht kennen. Aus einer Abwehrmaßnahme wird dann ein selbst verursachter Ausfall.

ACL-Eskalation & AdminSDHolder

Angriffspfade verlaufen in AD über effektive Berechtigungen (DACLs), nicht nur über sichtbare Gruppenmitgliedschaften. Gefährliche ACLs wie `GenericAll` oder `WriteDACL` auf ein sensibles Objekt bedeuten: Wer sie hält, kontrolliert die Identität — er kann das Passwort setzen, sich zur Gruppe hinzufügen oder die ACL weiter aufweichen, ohne je „Mitglied“ zu sein. Ein Mitgliedschafts-Review sieht das nicht.

  • Abwehr: effektive Rechte auf privilegierte Objekte auditieren (Tooling wie BloodHound macht diese Pfade sichtbar) und überbreite/verwaiste ACLs entfernen — aber vorher legitime delegierte Verwaltung ausschließen.
  • AdminSDHolder/SDProp: Ein Schutzobjekt, dessen ACL der SDProp-Prozess periodisch auf geschützte privilegierte Konten und Gruppen (adminCount=1) zurückschreibt. Das verhindert ACL-Drift auf Tier-0 — aber Angreifer manipulieren umgekehrt AdminSDHolder selbst als Persistenz. Deshalb dieses Objekt überwachen.
MerksatzWer Kontrolle über ein Objekt hat, kontrolliert dessen Identität. Abwehr heißt effektive Rechte auditieren — nicht nur Gruppenlisten lesen.

Ein Angriffspfad ist ein Graph, keine Liste

Verteidiger denken in Listen: privilegierte Gruppen, kritische Server, offene Ports. Angreifer denken in Pfaden — und ein Pfad entsteht aus Beziehungen, die einzeln jeweils harmlos aussehen.

Angriffspfad — Eine Kette von Beziehungen, die von einem Startpunkt zu einem Ziel führt. Die Knoten sind Objekte — Konten, Gruppen, Computer, OUs, GPOs —, die Kanten sind Rechte und Anmeldungen: „ist Mitglied von“, „darf Kennwort zurücksetzen“, „hat Vollzugriff auf“, „hat sich hier angemeldet“.

Das erklärt, warum eine Umgebung mit sauberen Mitgliederlisten trotzdem in wenigen Schritten übernommen werden kann. Keine einzelne Berechtigung ist falsch vergeben; erst ihre Verkettung ergibt einen Weg. Und weil jede Kante für sich begründbar ist, findet man sie in keiner Prüfung, die Objekte einzeln betrachtet.

Was daraus für die Priorisierung folgtNicht jeder Fund ist gleich viel wert. Die entscheidende Frage lautet: Verkürzt dieser Fund einen Pfad nach Tier 0 — und um wie viel? Ein einzelner überberechtigter Dienst tief in Tier 2 ist Hygiene. Dieselbe Fehlkonfiguration an einem Objekt, das eine Kante zu einer privilegierten Gruppe trägt, ist ein Vorfall. Dieselbe Einstellung, zwei völlig verschiedene Dringlichkeiten.
Der Grund, warum Angreifer im Vorteil sindEin Verteidiger muss alle Pfade schließen, ein Angreifer braucht einen. Diese Asymmetrie lässt sich nicht auflösen, aber verschieben: Wer die Kanten mit der größten Reichweite entfernt — Rechte auf privilegierte Objekte, Anmeldungen höherwertiger Konten an niedrigeren Hosts —, zerschneidet viele Pfade auf einmal, statt einzelne Funde abzuarbeiten.

Drei Ebenen der Abwehr — und warum die Reihenfolge zählt

Zu jedem der Pfade gibt es Gegenmaßnahmen auf drei Ebenen. Sie sind nicht gleichwertig, und die verbreitetste Fehlentscheidung ist, auf der falschen anzufangen.

Ursache
Die missbrauchte Fähigkeit oder das Recht selbst beseitigen — unbeschränkte Delegation entfernen, Replikationsrechte entziehen, Vorauthentifizierung erzwingen. Wirkt dauerhaft, kostet Abstimmung.
Härtung
Den Missbrauch unattraktiv machen, ohne die Fähigkeit zu entfernen — Entropie erhöhen, verwaltete Dienstkonten, kurze Ticket-Lebensdauern. Wirkt sofort, verschiebt die Grenze nur.
Erkennung
Den Missbrauch sichtbar machen. Verhindert nichts, ist aber der einzige Weg, einen bereits laufenden Angriff überhaupt zu bemerken.
Die Reihenfolge im BetriebUrsache schlägt Härtung schlägt Erkennung — aber nur, wenn die Ursache tatsächlich beseitigt werden kann. Wo eine Altanwendung eine Fähigkeit erzwingt, ist Härtung die ehrliche Antwort, und Erkennung wird zur Pflicht statt zur Ergänzung. Was nicht trägt, ist die umgekehrte Reihenfolge: eine Erkennungsregel zu bauen und die Ursache stehen zu lassen, weil das Entfernen Abstimmung gekostet hätte.
Und der Zusatz, den man vorher klärtZu jeder Maßnahme gehört die Frage nach der bereits erfolgten Kompromittierung. Ein Recht zu entziehen schließt den Weg für die Zukunft. Wurde es bereits missbraucht, sind Geheimnisse abgeflossen, die durch das Entfernen des Rechts nicht ungültig werden — dann folgt auf die Korrektur zwingend ein Austausch der betroffenen Anmeldedaten.

Durchgerechnet: ein Fund und seine Bewertung

Ein Dienstkonto mit SPN und schwachem Kennwort

Szenario

Eine Bestandsaufnahme zeigt: Ein Dienstkonto trägt einen SPN, sein Kennwort wurde zuletzt vor sechs Jahren gesetzt, und es ist Mitglied einer Gruppe, die auf einem Anwendungsserver lokale Administratorrechte hat.

Anforderungen

  • Die Dringlichkeit begründen, nicht behaupten
  • Die Maßnahme der richtigen Ebene zuordnen

Schritte

  1. Was ist die Fähigkeit? Ein Konto mit SPN gibt dem Verzeichnis Anlass, jedem authentifizierten Anfrager verschlüsseltes Material auszuhändigen. Das ist kein Fehler, sondern der Normalbetrieb von Kerberos.
  2. Wo ist die Schwäche? Nicht in der Ausgabe, sondern in der Entropie: Ein sechs Jahre altes, von Menschen gesetztes Kennwort ist offline angreifbar. Die Fähigkeit bleibt, die Schwäche ist ersetzbar.
  3. Wie weit reicht der Pfad? Lokale Administratorrechte auf einem Anwendungsserver. Damit ist der Fund kein Endpunkt, sondern eine Kante — die nächste Frage lautet, wer sich auf diesem Server anmeldet. Meldet sich dort ein Tier-1-Administrator an, verlängert sich der Pfad sofort.
  4. Maßnahme auf der richtigen Ebene: Ursache wäre, den SPN zu entfernen, falls der Dienst ihn nicht braucht. Geht das nicht, ist Härtung die Antwort — ein verwaltetes Dienstkonto mit maschinell erzeugtem Kennwort entzieht dem Offline-Angriff die Grundlage.
  5. Und der Nachtrag: Das alte Kennwort war sechs Jahre gültig. Ob es in dieser Zeit bereits abgegriffen wurde, weiß niemand — die Migration ersetzt es, und die Frage nach Spuren gehört trotzdem gestellt.

Merksatz: Ein Fund wird erst durch seinen Kontext zur Priorität. Dieselbe Konfiguration ist an einem isolierten System Hygiene und an einem gut vernetzten Objekt ein Vorfall — und die Maßnahme unterscheidet sich entsprechend.

Was nach dem Fund kommt: Eindämmung ohne Warnung an den Angreifer

Ein bestätigter Tier-0-Fund ist kein Konfigurationsfehler mehr, sondern ein Vorfall. Damit ändert sich die Reihenfolge: Nicht die schnellste Korrektur gewinnt, sondern die, die den Angreifer nicht vorzeitig informiert.

  • Beweise vor Korrektur. Wer eine unautorisierte Berechtigung sofort entfernt, vernichtet die Spur, die zeigt, wer sie wann gesetzt hat — und weiß danach nicht, was sonst noch geändert wurde.
  • Umfang vor Maßnahme. Ein einzelner Fund ist selten allein. Bevor etwas geschlossen wird, gehört ermittelt, welche weiteren Objekte betroffen sind; sonst schließt man eine Tür und lässt drei offene stehen.
  • Zugangsweg vor Symptom. Wird nur der Missbrauch beseitigt und nicht der Weg hinein, kommt derselbe Angreifer über denselben Weg zurück — nur diesmal vorsichtiger.
  • Anmeldedaten danach. Was in der Reichweite des Angreifers lag, gilt als abgeflossen und wird ausgetauscht, nicht bewertet.
Die Ausnahme von der RegelDiese Reihenfolge gilt für einen laufenden, noch nicht eskalierten Zugriff. Steht die Übernahme unmittelbar bevor — etwa bei aktiver Nutzung von Replikationsrechten —, kehrt sich die Abwägung um: Dann ist sofortige Eindämmung richtig, auch um den Preis verlorener Spuren und einer gewarnten Gegenseite. Diese Entscheidung trifft nicht die Technik, sondern die Vorfallsleitung — und sie fällt schneller, wenn vorher jemand festgelegt hat, ab welchem Befund sie ansteht.

Zusammenfassung — gleich im Check

Kurzcheck

Ein Scan meldet zwei Funde: (A) ein Dienstkonto mit SPN und altem Kennwort in einer Tier-2-Anwendung, (B) ein Anwendungsserver mit unbeschränkter Delegation, an dem sich täglich Administratoren anmelden. Womit fängst du an?

  • Mit (A) — ein knackbares Dienstkonto ist der klassische Einstiegspunkt und deshalb dringlicher.
  • Mit (B) — dort liegen weiterreichbare Tickets angemeldeter Administratoren, das ist der kürzere Weg zu Tier 0.
  • Mit beiden gleichzeitig — eine Priorisierung ist bei Sicherheitsfunden nicht sinnvoll.

Treffer. Richtig. Ein Server mit unbeschränkter Delegation hält die Tickets aller, die sich dort authentifizieren. Melden sich Administratoren an, ist er faktisch ein Tier-0-System — und der Pfad dorthin ist kurz.

Die Achsen dieses Moduls: Kerberoasting (gMSA/Entropie) und AS-REP-Roasting (Pre-Auth erzwingen) als Offline-Cracking; DCSync (Replikationsrechte auf Tier-0 begrenzen); Unconstrained-Delegation-Abuse (Fähigkeit eliminieren, Tier-0 undelegierbar machen); Golden vs. Silver Ticket (Schlüssel-Diebstahl, krbtgt zweimal resetten); und ACL-Eskalation (effektive Rechte, AdminSDHolder).

Gleich im CheckIn sechs Entscheidungen wählst du für konkrete Fund-Situationen die beste Abwehr oder Reaktion — und siehst pro Option, warum sie die Ursache trifft oder aus welchem benannten Grund nur ein Symptom.

Jetzt anwenden

Diesen Stoff gibt es als Modul mit bewerteten Entscheidungs-Checks — dieselbe Einführung, danach die Übungen.

Zum Modul →
Quellen & Aktualität25 Primärquellen · zuletzt geprüft:
  1. 01MITRE ATT&CK T1558.003 — Steal or Forge Kerberos Tickets: Kerberoasting
  2. 02MITRE ATT&CK T1558.004 — Steal or Forge Kerberos Tickets: AS-REP Roasting
  3. 03MITRE ATT&CK T1003.006 — OS Credential Dumping: DCSync
  4. 04MITRE ATT&CK T1558.001 / T1558.002 — Golden Ticket / Silver Ticket; T1187 — Forced Authentication
  5. 05Microsoft Learn — Group Managed Service Accounts (gMSA) Overview
  6. 06Microsoft Learn — Kerberos Pre-Authentication (Do not require Kerberos preauthentication)
  7. 07Microsoft Learn — Protected Users Security Group und „Account is sensitive and cannot be delegated“
  8. 08Microsoft Learn — AdminSDHolder, Protected Accounts and Groups, SDProp
  9. 09Microsoft / CISA — KRBTGT account maintenance und Reset-Guidance (Passwort-Historie 2, zweimaliges Zurücksetzen mit Replikation)
  10. 10learn.microsoft.com/en-us/windows-server/ident…ing-active-directory
  11. 11learn.microsoft.com/en-us/windows-server/secur…hentication-overview
  12. 12Microsoft Learn — Kerberos preauthentication and the 'Do not require Kerberos preauthentication' account option
  13. 13Microsoft Learn — Group Managed Service Accounts overview
  14. 14Microsoft Learn — Replicating Directory Changes permission
  15. 15Microsoft Learn — Kerberos constrained delegation overview
  16. 16Microsoft Learn — Resource-based constrained delegation
  17. 17Microsoft Learn — Protected Users security group
  18. 18Microsoft Learn — Active Directory access control and ACLs
  19. 19MITRE ATT&CK T1098 — Account Manipulation
  20. 20MITRE ATT&CK T1558.001 — Golden Ticket
  21. 21Microsoft Learn — AD Forest Recovery: Reset the krbtgt password
  22. 22Microsoft Learn — AD Forest Recovery: Determine how to recover the forest
  23. 23attack.mitre.org/detectionstrategies/DET0594
  24. 24learn.microsoft.com/en-us/troubleshoot/windows…mission-adma-service
  25. 25learn.microsoft.com/en-us/entra/identity/hybri…ds-connector-account