# Angriffspfade & Abwehr

> Die verbreiteten AD-Angriffspfade als Verteidiger verstehen und priorisieren: Kerberoasting, AS-REP-Roasting, DCSync, Delegation-Abuse, Golden/Silver Tickets und ACL-basierte Eskalation.

Track: [Active Directory](https://physar.tech/learn/active-directory)  
Kanonische Fassung: https://physar.tech/learn/active-directory/attack-paths  
Stand: 2026-07-26  
Interaktiver Teil: 7 Checks (nur im Browser)

## Angriffspfade & Abwehr: Kerberos, Replikation, Delegation, ACLs

### 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**.

> **Leitfrage:** Fü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:

_[Abbildung: 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.]_

> **Merksatz:** Kerberos 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-Prinzip:** Beide 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.

### 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-Prinzip:** Ein 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.

### 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.

> **Merksatz:** Unconstrained 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-Verdacht:** Das `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.

### 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.

> **Merksatz:** Wer Kontrolle über ein Objekt hat, kontrolliert dessen Identität. Abwehr heißt **effektive Rechte** auditieren — nicht nur Gruppenlisten lesen.

### Zusammenfassung — gleich im Check

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 Check:** In 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.

## Quellen

- MITRE ATT&CK T1558.003 — Steal or Forge Kerberos Tickets: Kerberoasting
- MITRE ATT&CK T1558.004 — Steal or Forge Kerberos Tickets: AS-REP Roasting
- MITRE ATT&CK T1003.006 — OS Credential Dumping: DCSync
- MITRE ATT&CK T1558.001 / T1558.002 — Golden Ticket / Silver Ticket; T1187 — Forced Authentication
- Microsoft Learn — Group Managed Service Accounts (gMSA) Overview
- Microsoft Learn — Kerberos Pre-Authentication (Do not require Kerberos preauthentication)
- Microsoft Learn — Protected Users Security Group und „Account is sensitive and cannot be delegated“
- Microsoft Learn — AdminSDHolder, Protected Accounts and Groups, SDProp
- Microsoft / CISA — KRBTGT account maintenance und Reset-Guidance (Passwort-Historie 2, zweimaliges Zurücksetzen mit Replikation)
- Microsoft Learn — Group Managed Service Accounts overview
- Microsoft Learn — Kerberos preauthentication and the 'Do not require Kerberos preauthentication' account option
- Microsoft Learn — Replicating Directory Changes permission
- Microsoft Learn — Kerberos constrained delegation overview
- Microsoft Learn — Resource-based constrained delegation
- Microsoft Learn — Protected Users security group
- MITRE ATT&CK T1558.001 — Golden Ticket
- Microsoft Learn — AD Forest Recovery: Reset the krbtgt password
- Microsoft Learn — AD Forest Recovery: Determine how to recover the forest
- Microsoft Learn — Active Directory access control and ACLs
- MITRE ATT&CK T1098 — Account Manipulation
- attack.mitre.org/detectionstrategies/DET0594 — https://attack.mitre.org/detectionstrategies/DET0594/
- learn.microsoft.com/en-us/troubleshoot/windows…mission-adma-service — https://learn.microsoft.com/en-us/troubleshoot/windows-server/windows-security/grant-replicating-directory-changes-permission-adma-service
- learn.microsoft.com/en-us/entra/identity/hybri…ds-connector-account — https://learn.microsoft.com/en-us/entra/identity/hybrid/connect/how-to-connect-configure-ad-ds-connector-account