mirror of
https://github.com/HackTricks-wiki/hacktricks.git
synced 2025-10-10 18:36:50 +00:00
69 lines
5.3 KiB
Markdown
69 lines
5.3 KiB
Markdown
# Abusing Active Directory ACLs/ACEs
|
||
|
||
{{#include ../../../banners/hacktricks-training.md}}
|
||
|
||
## Overview
|
||
|
||
I Delegated Managed Service Accounts (**dMSAs**) sono un nuovo tipo di principale AD introdotto con **Windows Server 2025**. Sono progettati per sostituire gli account di servizio legacy consentendo una “migrazione” con un clic che copia automaticamente i Service Principal Names (SPNs), le appartenenze ai gruppi, le impostazioni di delega e persino le chiavi crittografiche dell'account precedente nel nuovo dMSA, offrendo alle applicazioni un passaggio senza soluzione di continuità ed eliminando il rischio di Kerberoasting.
|
||
|
||
I ricercatori di Akamai hanno scoperto che un singolo attributo — **`msDS‑ManagedAccountPrecededByLink`** — indica al KDC quale account legacy un dMSA “sostituisce”. Se un attaccante può scrivere quell'attributo (e attivare **`msDS‑DelegatedMSAState` → 2**), il KDC costruirà felicemente un PAC che **eredita ogni SID della vittima scelta**, consentendo effettivamente al dMSA di impersonare qualsiasi utente, inclusi gli Amministratori di Dominio.
|
||
|
||
## What exactly is a dMSA?
|
||
|
||
* Basato sulla tecnologia **gMSA** ma memorizzato come la nuova classe AD **`msDS‑DelegatedManagedServiceAccount`**.
|
||
* Supporta una **migrazione su richiesta**: chiamando `Start‑ADServiceAccountMigration` si collega il dMSA all'account legacy, si concede all'account legacy l'accesso in scrittura a `msDS‑GroupMSAMembership` e si attiva `msDS‑DelegatedMSAState` = 1.
|
||
* Dopo `Complete‑ADServiceAccountMigration`, l'account superato viene disabilitato e il dMSA diventa completamente funzionale; qualsiasi host che precedentemente utilizzava l'account legacy è automaticamente autorizzato a prelevare la password del dMSA.
|
||
* Durante l'autenticazione, il KDC incorpora un suggerimento **KERB‑SUPERSEDED‑BY‑USER** in modo che i client Windows 11/24H2 riprovino in modo trasparente con il dMSA.
|
||
|
||
## Requirements to attack
|
||
1. **Almeno un Windows Server 2025 DC** affinché la classe LDAP del dMSA e la logica KDC esistano.
|
||
2. **Qualsiasi diritto di creazione di oggetti o scrittura di attributi su un OU** (qualsiasi OU) – ad esempio, `Create msDS‑DelegatedManagedServiceAccount` o semplicemente **Create All Child Objects**. Akamai ha scoperto che il 91 % dei tenant nel mondo reale concede tali permessi “benigni” sugli OU a non amministratori.
|
||
3. Capacità di eseguire strumenti (PowerShell/Rubeus) da qualsiasi host unito al dominio per richiedere ticket Kerberos.
|
||
*Non è richiesto alcun controllo sull'utente vittima; l'attacco non tocca mai direttamente l'account target.*
|
||
|
||
## Step‑by‑step: BadSuccessor*privilege escalation
|
||
|
||
1. **Individua o crea un dMSA che controlli**
|
||
```bash
|
||
New‑ADServiceAccount Attacker_dMSA `
|
||
‑DNSHostName ad.lab `
|
||
‑Path "OU=temp,DC=lab,DC=local"
|
||
```
|
||
|
||
Poiché hai creato l'oggetto all'interno di un OU a cui puoi scrivere, possiedi automaticamente tutti i suoi attributi.
|
||
|
||
2. **Simula una “migrazione completata” in due scritture LDAP**:
|
||
- Imposta `msDS‑ManagedAccountPrecededByLink = DN` di qualsiasi vittima (ad esempio `CN=Administrator,CN=Users,DC=lab,DC=local`).
|
||
- Imposta `msDS‑DelegatedMSAState = 2` (migrazione completata).
|
||
|
||
Strumenti come **Set‑ADComputer, ldapmodify** o anche **ADSI Edit** funzionano; non sono necessari diritti di amministratore di dominio.
|
||
|
||
3. **Richiedi un TGT per il dMSA** — Rubeus supporta il flag `/dmsa`:
|
||
|
||
```bash
|
||
Rubeus.exe asktgs /targetuser:attacker_dmsa$ /service:krbtgt/aka.test /dmsa /opsec /nowrap /ptt /ticket:<Machine TGT>
|
||
```
|
||
|
||
Il PAC restituito ora contiene il SID 500 (Amministratore) più i gruppi Domain Admins/Enterprise Admins.
|
||
|
||
## Gather all the users passwords
|
||
|
||
Durante le migrazioni legittime, il KDC deve consentire al nuovo dMSA di decrittografare **i ticket emessi all'account precedente prima del passaggio**. Per evitare di interrompere le sessioni attive, inserisce sia le chiavi correnti che le chiavi precedenti all'interno di un nuovo blob ASN.1 chiamato **`KERB‑DMSA‑KEY‑PACKAGE`**.
|
||
|
||
Poiché la nostra falsa migrazione afferma che il dMSA sostituisce la vittima, il KDC copia diligentemente la chiave RC4‑HMAC della vittima nella lista delle **chiavi precedenti** – anche se il dMSA non ha mai avuto una password “precedente”. Quella chiave RC4 non è salata, quindi è effettivamente l'hash NT della vittima, dando all'attaccante la capacità di **cracking offline o “pass‑the‑hash”**.
|
||
|
||
Pertanto, il collegamento di massa di migliaia di utenti consente a un attaccante di estrarre hash “su larga scala”, trasformando **BadSuccessor in un primitivo sia di escalation dei privilegi che di compromissione delle credenziali**.
|
||
|
||
## Tools
|
||
|
||
- [https://github.com/akamai/BadSuccessor](https://github.com/akamai/BadSuccessor)
|
||
- [https://github.com/logangoins/SharpSuccessor](https://github.com/logangoins/SharpSuccessor)
|
||
- [https://github.com/LuemmelSec/Pentest-Tools-Collection/blob/main/tools/ActiveDirectory/BadSuccessor.ps1](https://github.com/LuemmelSec/Pentest-Tools-Collection/blob/main/tools/ActiveDirectory/BadSuccessor.ps1)
|
||
|
||
## References
|
||
|
||
- [https://www.akamai.com/blog/security-research/abusing-dmsa-for-privilege-escalation-in-active-directory](https://www.akamai.com/blog/security-research/abusing-dmsa-for-privilege-escalation-in-active-directory)
|
||
|
||
|
||
{{#include ../../../banners/hacktricks-training.md}}
|