BadSuccessor: l'abuso dei dMSA per ottenere privilegi elevati in Active Directory
Analisi riassuntiva
Yuval Gordon, un ricercatore di Akamai, ha individuato una vulnerabilità di escalation dei privilegi in Windows Server 2025 che consente ai criminali di violare le credenziali di un qualsiasi utente di Active Directory (AD).
L'attacco sfrutta la funzione dei dMSA (delegated Managed Service Account), che è stata introdotta in Windows Server 2025, utilizza la configurazione predefinita ed è semplice da implementare.
Questo problema riguarda, probabilmente, la maggior parte delle organizzazioni che si basano su AD. Nel 91% degli ambienti esaminati, abbiamo individuato la presenza di utenti esterni al gruppo degli amministratori del dominio con le autorizzazioni richieste per eseguire questo attacco.
Anche se Microsoft afferma che prevede di risolvere questo problema in futuro, attualmente non è disponibile una patch. Pertanto, le organizzazioni devono intraprendere altre misure proattive per ridurre la loro vulnerabilità a questo tipo di attacco. Microsoft ha esaminato i nostri risultati approvando la pubblicazione delle informazioni qui riportate.
In questo blog, forniamo i dettagli completi su questo attacco, nonché le strategie di rilevamento e mitigazione.
Sommario
Introduzione
In Windows Server 2025, Microsoft ha introdotto i dMSA (delegated Managed Service Account). Un dMSA è un nuovo tipo di account di servizio presente in Active Directory (AD), che amplia le funzionalità offerte dai gMSA (group Managed Service Account). Una delle caratteristiche principali dei dMSA è la loro capacità di migrare gli attuali account di servizio non gestiti convertendoli semplicemente in dMSA.
Curiosando nei meccanismi interni dei dMSA di AD, ci siamo imbattuti in qualcosa di interessante. A prima vista, il meccanismo di migrazione sembrava somigliare ad una soluzione semplice e ben progettata. Tuttavia, qualcosa di nascosto nel suo funzionamento ha attirato la nostra attenzione.
Ad un'analisi più approfondita, abbiamo scoperto una sorprendente vulnerabilità di escalation dei privilegi: abusando dei dMSA, i criminali possono assumere il controllo di un qualsiasi gruppo principale presente nel dominio. Per sferrare questo attacco, tutto ciò che serve ad un criminale è un'autorizzazione ad accedere ad una qualsiasi unità organizzativa (OU) presente nel dominio: un tipo di permesso che, spesso, passa inosservato.
E non finisce qui: l'attacco utilizza la configurazione predefinita, quindi il dominio non deve usare alcun dMSA. Questa funzione diventa disponibile finché esiste in qualsiasi dominio contenente almeno un controller di dominio (DC) di Windows Server 2025.
Questo blog spiega come abbiamo scoperto questa vulnerabilità, come funziona l'attacco e cosa potete fare per rilevarlo o prevenirlo.
Che cosa sono i dMSA?
Prima di approfondire l'argomento degli attacchi, è importante comprendere cosa sono effettivamente i dMSA e qual è il loro funzionamento previsto.
Un dMSA, di solito, viene creato per sostituire un account di servizio tradizionale esistente. Per favorire un'agevole transizione, un dMSA può "ereditare" le autorizzazioni dell'account esistente eseguendo un processo di migrazione, il cui flusso associa strettamente il dMSA al suddetto account, ossia all'account originale che deve essere sostituito. Questo flusso, insieme alle autorizzazioni concesse durante il percorso, rappresenta la parte più interessante dell'intero processo.
Il flusso di migrazione dei dMSA
È possibile avviare il processo di migrazione di un dMSA richiamando il nuovo cmdlet Start-ADServiceAccountMigration, che, internamente, richiama una nuova operazione LDAP rootDSE denominata migrateADServiceAccount,che richiede i seguenti argomenti:
Il nome distinto (DN) del dMSA
Il DN dell'account sostituito
Una costante che corrisponde a StartMigration
Lo stato della migrazione di un dMSA dipende dall'attributo msDS-DelegatedMSAState, un nuovo attributo che determina lo stato corrente del dMSA. Attualmente, non esiste alcuna documentazione ufficiale sull'attributo msDS-DelegatedMSASt, pertanto la tabella riportata di seguito si basa sulle nostre analisi dei comportamenti e sui nostri esperimenti.
Valore |
Significato |
0 |
Sconosciuto (forse disattivato, ma non confermato) |
1 |
Migrazione in corso |
2 |
Migrazione completata |
3 |
dMSA indipendente (nessuna migrazione) |
I valori di migrazione msDS-DelegatedMSAState e i significati correlati
Insieme a questo attributo, durante il processo di migrazione vengono usati altri attributi degni di nota.
Sull'oggetto dMSA:
msDS-GroupMSAMembership: contiene un elenco dei gruppi principali autorizzati all'uso di questo dMSA
msDS-ManagedAccountPrecededByLink: il DN dell'account sostituito
Sull'oggetto dell'account sostituito:
msDS-SupersededManagedAccountLink: il DN del dMSA "sostitutivo"
msDS-SupersededServiceAccountState: stesso significato dell'attributo msDS-DelegatedMSAState, che specifica lo stato della migrazione dell'account originale
All'attivazione di una migrazione, l'operazione effettua i seguenti cambiamenti:
Imposta l'attributo msDS-DelegatedMSAState su 1 (migrazione in corso)
Aggiorna il valore ntSecurityDescriptor del dMSA in modo da concedere l'account sostituito:
Autorizzazioni di lettura
Accesso in scrittura all'attributo msDS-GroupMSAMembership
Imposta il valore msDS-ManagedAccountPrecededByLink del dMSA in modo da fare riferimento all'account sostituito
Imposta il valore msDS-SupersededManagedAccountLink dell'account sostituito in modo da fare riferimento al dMSA
Imposta il valore msDS-SupersededServiceAccountState dell'account sostituito su 1
A questo punto, il dMSA si trova in uno stato di "migrazione in corso". Non è ancora totalmente funzionale, ma ora sa quali sistemi stanno usando il vecchio account di servizio.
Una volta emesso il comando Complete-ADServiceAccountMigration, si verificano le seguenti situazioni:
Il dMSA eredita le configurazioni principali, come SPN, impostazioni di deleghe e altri attributi sensibili dall'account sostituito
L'account sostituito viene disattivato
I valori msDS-DelegatedMSAState e msDS-SupersededServiceAccountState vengono entrambi impostati su 2 (migrazione completata)
La migrazione è completata e i servizi basati sull'account sostituito ora utilizzano il dMSA per l'autenticazione.
L'autenticazione tramite dMSA
Una volta compresi i processi di creazione e migrazione dei dMSA, è ora giunto il momento di focalizzarci sulla modalità di funzionamento dell'autenticazione, sulle modifiche introdotte per supportare i dMSA e sul modo con cui queste modifiche semplificano il processo di migrazione.
Per una migliore comprensione, esaminiamo l'account di servizio svc_sql legacy, che viene usato per eseguire un servizio sul server SQL_SRV$. Ogni volta che il servizio viene richiesto per accedere alle risorse presenti nel dominio, viene eseguita una normale autenticazione tramite l'account svc_sql (Figura 1).
Fig. 1: Legacy service account authentication flow
L'autenticazione durante la migrazione
Ora, viene eseguita la transizione dell'account di servizio ad un nuovo dMSA denominato DMSA$, che attiva un processo di migrazione. Durante il periodo della migrazione, quando il servizio sull'account SQL_SRV$ viene autenticato come svc_sql, il flusso dell'autenticazione risulta leggermente modificato.
Il client invia un valore AS-REQ da autenticare come svc_sql
Il KDC (Key Distribution Center) restituisce un valore AS-REP contenente un campo aggiuntivo: KERB-SUPERSEDED-BY-USER (questo campo include il nome e il dominio del nuovo dMSA DMSA$)
Se l'host supporta i dMSA (Windows Server 2025 o Windows 11 24H2) e ha attivato l'autenticazione tramite dMSA, effettuerà le seguenti operazioni:
Estrae il nome DMSA$
Esegue una query LDAP su DMSA$ per recuperare i seguenti attributi:
msDS-GroupMSAMembership
distinguishedName
objectClass
Poiché il servizio viene eseguito su SQL_SRV$ come svc_sql, l'autenticazione avvia una richiesta di modifica LDAP da svc_sql, che aggiunge SQL_SRV$ all'elenco dei gruppi principali che sono autorizzati a recuperare la password di DMSA$ (Figura 2).
Questa operazione è consentita perché, durante il processo di migrazione, all'account svc_sql è stato concesso l'accesso in scrittura all'attributo msDS-GroupMSAMembership sul dMSA, una modifica con cui il suo computer host viene autorizzato ad accedere alle credenziali dell'account.
Fig. 2: Kerberos authentication flow during dMSA migration
Questa semplice autorizzazione garantisce che, al completamento della migrazione, ogni computer che, in precedenza, ha utilizzato svc_sql verrà elencato nell'attributo msDS-GroupMSAMembership di DMSA$ , che così potrebbe essere autenticato come dMSA.
L'autenticazione dopo la migrazione
Una volta completata la migrazione (tramite Complete-ADServiceAccountMigration), il comportamento risulta nuovamente modificato.
Quando il client cerca di essere autenticato come svc_sql inviando un valore AS-REQ, non riceve più un AS-REP,
Al contrario, il DC risponde con un KRB-ERROR a indicare che l'account svc_sql è stato disattivato
La stringa KRB-ERROR contiene il campo KERB-SUPERSEDED-BY-USER , che consente, quindi, al client di riconoscere che l'account svc_sql è stato migrato e di riprovare automaticamente l'autenticazione tramite DMSA$ (Figura 3).
Fig. 3: Kerberos authentication flow after the dMSA migration is completed
SQL_SRV$ (e altri computer in precedenza basati su svc_sql) ora passano in modo trasparente all'utilizzo di DMSA$.
Un comportamento "imPACciato"
Un aspetto interessante dell'autenticazione Kerberos del dMSA riguarda il suo PAC (Privilege Attribute Certificate).
Durante l'autenticazione, Kerberos incorpora un PAC nei ticket, una struttura utilizzata dai servizi per stabilire il livello di accesso di un client. In un TGT (Ticket Granting Ticket) standard, il PAC include i SID degli utenti e di tutti i gruppi di cui fanno parte.
Tuttavia, al momento di effettuare l'accesso con un dMSA, abbiamo osservato un comportamento insolito.
Il PAC ha incluso non solo il SID del dMSA, ma anche i SID dell'account di servizio sostituito e di tutti i suoi gruppi associati.
Abusare del processo di migrazione dei dMSA per l'escalation dei privilegi
Dopo la migrazione, il KDC concede al dMSA tutte le autorizzazioni dell'account originale (sostituito).
Dal punto di vista della progettazione, questo comportamento appare sensato. L'obiettivo è fornire un'agevole experience di migrazione, in cui il nuovo account si comporta esattamente come quello che sostituisce, ossia con gli stessi SPN, le stesse deleghe e l'iscrizione agli stessi gruppi.
Tuttavia, dal punto di vista di un ricercatore sulla sicurezza, questo tipo di comportamento balza immediatamente all'attenzione. Quando abbiamo notato un sistema che copia automaticamente i privilegi da un account all'altro senza richiedere una riconfigurazione manuale, ci siamo chiesti varie domande: In che modo il sistema decide da quale account copiare i privilegi? Il sistema può essere influenzato in questa decisione? Il sistema può essere oggetto di abusi?
Questa serie di domande ci ha portato direttamente a scoprire qualcosa di fondamentale. Questo interessante comportamento ereditato dal PAC sembra essere controllato da un solo attributo: msDS-ManagedAccountPrecededByLink.
Il KDC si basa su questo attributo per stabilire chi sta "sostituendo" il dMSA: quando viene eseguita l'autenticazione tramite dMSA, il PAC viene creato esclusivamente sulla base di questo link.
Entriamo nella mente dei criminali
Come appare tutto ciò dal punto di vista di un criminale? Esploriamo un possibile scenario di attacco e vediamo cosa riesce a fare un criminale in tal caso.
La nostra prima idea: creare una primitiva per il controllo degli account tramite un dMSA. Supponendo di disporre delle autorizzazioni per il controllo dell'account di un utente, possiamo "migrare" in qualche modo queste autorizzazioni in un nuovo dMSA per violarle di nascosto? Sembra un piano ben congegnato! A questo punto, dobbiamo semplicemente:
Creare un dMSA
Avviare e completare la migrazione tra l'utente preso di mira e il dMSA tramite l'operazione migrateADServiceAccount rootDSE
Effettuare l'autenticazione come dMSA per ottenere tutte le autorizzazioni dell'utente preso di mira
L'unico problema di questo piano è che non funziona.
Anche se possiamo controllare totalmente sia il dMSA che l'account sostituito, non possiamo eseguire una migrazione perché l'operazione migrateADServiceAccount può essere effettuata, per quanto ne sappiamo, solo dagli amministratori di dominio. La Figura 4 mostra un tentativo (non riuscito) di eseguire questa operazione.
Fig. 4: A failed attempt to use a dMSA to create an account takeover primitive
Passiamo alla nostra seconda idea. Chiaramente, dobbiamo creare un piano più complesso, creativo e decisamente tecnico. Pertanto, dobbiamo sperimentare comportamenti non documentati, magari persino eseguendo il reverse engineering di una parte del KDC … oppure potremmo impostare semplicemente due attributi.
Anche se non possiamo eseguire direttamente una migrazione, possiamo "simulare" molto facilmente questa operazione semplicemente impostando gli attributi riportati di seguito direttamente sull'oggetto dMSA.
Scrivere il DN dell'account preso di mira su msDS-ManagedAccountPrecededByLink
Impostare l'attributo msDS-DelegatedMSAState su 2 (migrazione completata)
Da questo momento in poi, ad ogni autenticazione eseguita tramite questo dMSA, il KDC creare il PAC utilizzando i SID dell'account collegato all'attributo msDS-ManagedAccountPrecededByLink, concedendoci così tutte le autorizzazioni dell'account sostituito.
Presentazione di BadSuccessor
Un fatto interessante relativo a questa tecnica di "migrazione simulata" consiste nel fatto che non richiede alcuna autorizzazione per l'account sostituito, ma richiede solo le autorizzazioni in scrittura per accedere agli attribuiti del dMSA o, per meglio dire, di qualsiasi dMSA.
Una volta contrassegnato un dMSA come preceduto da un utente, il KDC suppone automaticamente che sia avvenuta una migrazione legittima e concede allegramente al nostro dMSA tutte le autorizzazioni in possesso dell'utente originale, pensando di trasmetterle al suo "legittimo" successore.
Ma, ovviamente, tutto ciò non funziona per gli account che richiedono privilegi elevati, giusto? Beh, non è proprio così ...
Tra l'altro, questa tecnica, da noi denominata "BadSuccessor", funziona per tutti gli utenti, inclusi gli amministratori di dominio (Figura 5), che controllano un oggetto dMSA e, quindi, possono passare al controllo dell'intero dominio. Tutto qui. Non serve un'effettiva migrazione. Non serve alcuna verifica né una supervisione.
Fig. 5: Full attack flow, showing all steps needed to have a BadSuccessor
Sfruttare i dMSA: dai privilegi minimi al controllo del dominio
A questo punto, potreste pensare: "Beh, visto che non utilizzo alcun dMSA nel mio ambiente, la cosa non mi riguarda". Ripensateci.
Considerate questo caso di abuso: un criminale ottiene il controllo di un dMSA esistente e utilizza questo accesso per sferrare l'attacco BadSuccessor. Tuttavia, si verifica un'altra situazione, che, forse, si presenta molto più spesso per i criminali: il criminale crea un nuovo dMSA.
Quando un utente crea un oggetto in AD, deve disporre delle autorizzazioni complete su tutti i suoi attributi. Pertanto, se un criminale riesce a creare un nuovo dMSA, potrà violare anche l'intero dominio.
Di solito, quando viene creato un dMSA tramite il cmdlet New-ADServiceAccount , viene memorizzato nel container Managed Service Accounts. Anche se qualsiasi utente può ottenere l'accesso a questo container, solo i gruppi di Active Directory incorporati con privilegi dispongono delle relative autorizzazioni per impostazione predefinita. Quindi, non è molto probabile che si riesca a scrivere su questo container.
I dMSA, tuttavia, non sono limitati al container Managed Service Accounts, ma possono essere creati anche in qualsiasi unità organizzativa (OU). Tutti gli utenti che dispongono dei diritti di creazione dell'oggetto msDS-DelegatedManagedServiceAccount o di tutti gli oggetti secondari in una qualsiasi OU possono creare un dMSA.
Creazione del dMSA
Consentire agli utenti di creare oggetti in una OU è una configurazione alquanto comune. Poiché questa capacità viene considerata non dannosa, è improbabile che gli utenti con questo privilegio vengano monitorati e potenziati in modo appropriato.
Per creare il dMSA, iniziamo ad individuare una OU di cui disponiamo i relativi privilegi. Fortunatamente, nel nostro ambiente di esempio, un utente ha creato una OU denominata "temp" e ha concesso al nostro utente senza privilegi autorizzazioni "deboli", che consentono di creare tutti gli oggetti secondari (Figura 6).
Fig. 6: Example of required privileges on an OU
A questo punto, possiamo quindi usare queste autorizzazioni per creare un dMSA tramite il cmdlet New-ADServiceAccount. Come abbiamo visto in Figura 7, anche se l'utente senza privilegi non può creare un dMSA nel container MSA predefinito, possiamo usare l'argomento del percorso per creare il dMSA nella OU che risulta accessibile.
Fig. 7: Creating the dMSA in an allowed location using the New-ADServiceAccount PowerShell cmdlet
In tal modo, siamo ora diventati i felici proprietari di un dMSA non funzionale appena creato. In qualità di creatori e proprietari, possiamo concederci le autorizzazioni per accedere ad un oggetto, incluso l'accesso in scrittura ad entrambi gli attributi che andremo ad usare per questo attacco, che possiamo, quindi, modificare nel modo seguente:
msDS-ManagedAccountPrecededByLink: impostate questo attributo sul DN di qualsiasi utente o computer (controller di dominio, amministratori di dominio, utenti protetti e, ironicamente, persino account sensibili che non possono essere delegati)
msDS-DelegatedMSAState: impostate questo attributo su 2 per simulare una migrazione completata (Figura 8)
Fig. 8: Modifying attributes to mimic successful migration
Come abbiamo già detto in precedenza, questo attacco sembra funzionare su tutti gli account presenti in AD. Non siamo riusciti a trovare alcuna configurazione in grado di impedire l'utilizzo di un account come obiettivo sostituito.
Prendere un TGT per il dMSA
Un modo per effettuare l'autenticazione con il nostro dMSA consiste nel creare un servizio e nel configurarlo per l'esecuzione con l'account dMSA. Ciò è possibile, ma non è così pratico. Fortunatamente grazie ad un'eccellente richiesta effettuata da Joe Dibley, Rubeus ora supporta l'autenticazione tramite dMSA (Figura 9), che, quindi, possiamo usare per richiedere un TGT per il nostro dMSA:
Rubeus.exe asktgs /targetuser:attacker_dmsa$ /service:krbtgt/aka.test /dmsa /opsec /nowrap /ptt /ticket:<Machine TGT>
Fig. 9: Requesting TGT for the new dMSA using Rubeus
dMSA → Amministratore di dominio
Per questo esempio, abbiamo preso di mira l'account dell'amministratore incorporato. Tramite Wireshark, abbiamo esaminato il PAC del ticket da noi ricevuto per il nostro dMSA (Figura 10), che includeva:
Il RID del dMSA (1137)
Il RID dell'account sostituito (500: amministratore)
Tutte le iscrizioni ai gruppi dell'account sostituito (512: amministratori di dominio, 519: amministratori aziendali)
Fig. 10: dMSA’s PAC that includes the Administrator’s groups’ RIDs
Questo è tutto ciò che serve al controller di dominio per considerarci come i "legittimi eredi". Ricordate: non sono richiesti cambiamenti alle iscrizioni ai gruppi, variazioni ai gruppi degli amministratori di dominio né operazioni sospette di scrittura LDAP negli attuali account con privilegi.
Cambiando solo questi due attributi, un nuovo, umile oggetto viene "incoronato" come successore e il KDC non metterà mai in dubbio la sua "discendenza di sangue": se c'è il collegamento, i privilegi verranno comunque concessi. Non abbiamo dovuto cambiare neanche l'iscrizione ad un solo gruppo né richiedere privilegi elevati per un account esistente o inviare i tradizionali avvisi di escalation dei privilegi.
Demo: il flusso di un attacco end-to-end
Guardate questo video per una dimostrazione completa dell'attacco in azione.
Dimostrazione dell'abuso dei dMSA per ottenere privilegi elevati in Active Directory
E non finisce qui... Abusare dei dMSA per violare le credenziali
Prendere un TGT per tutti gli utenti che vogliamo va bene, ma non ci accontentiamo così facilmente. E se volessimo anche le loro credenziali? Fortunatamente, il dMSA è qui per aiutarci anche in questo caso.
Quando richiedete un TGT per un dMSA, viene fornito con una nuova struttura denominataKERB-DMSA-KEY-PACKAGE, che include due campi: current-keys e previous-keys. Secondo MSDN, questi campi dovrebbero contenere le chiavi correlate alle password attuali e precedenti del dMSA ed è effettivamente così, ma non finisce qui.
Siamo rimasti sorpresi nel vedere che, anche quando si richiedeva un TGT per un dMSA appena creato, il campo previous-keys non era vuoto. Poiché era stato appena creato, non ci sarebbe dovuta essere nel campo una password precedente. Pur ignorando questo aspetto, ci siamo poi resi conto di trovarci in una situazione del tutto familiare.
Come mostrato in Figura 11, il secondo elemento della struttura disponeva di una sola chiave di tipo 23 (RC4-HMAC). Questo tipo di crittografia non viene archiviato nella versione salt, quindi password identiche generano chiavi identiche, anche tra gli utenti.
Fig. 11: ASN.1 decoded value of the KERB-DMSA-KEY-PACKAGE, decoded at https://pkitools.net/pages/ca/asn1.html
E che possiamo dire di questa specifica chiave? Tanti anni trascorsi nei laboratori ad utilizzare la stessa password hanno finalmente dato i loro frutti e lo vediamo subito: la chiave corrispondente alla password Aa123456 che abbiamo utilizzato per il nostro account preso di mira durante la dimostrazione.
Cerchiamo di capirci: la chiave per accedere ad un account separato è, in qualche modo, finita nella struttura previous-keys del dMSA.
Violare le chiavi su larga scala
Quindi, cosa succede e perché?
L'attributo msDS-ManagedAccountPrecededByLink non collega soltanto il dMSA all'account sostituito per gli scopi legati all'autorizzazione, ma consente anche al dMSA di ereditare le sue chiavi. In tal modo, è possibile usare questo attacco per ottenere le chiavi di qualsiasi (o di ogni) utente/computer presente nel dominio, quindi usarle per effettuare l'autenticazione con l'account.
Anche se non abbiamo analizzato l'intera implementazione, riteniamo che questo comportamento venga adottato per garantire una perfetta continuità durante la migrazione dell'account a vantaggio dell'utente finale.
Supponiamo di eseguire un servizio con un account di servizio tradizionale. Gli account presenti nel dominio richiedono a questo servizio i ticket , che sono crittografati tramite la chiave dell'account di servizio tradizionale. Ora, supponiamo di aver sostituito l'account tradizionale con un dMSA, completato la migrazione e sostituito l'account di servizio mediante il dMSA, ma il dMSA non riesce ad accedere alla chiave dell'account precedente.
Il risultato: quando un client tenta di effettuare l'autenticazione tramite il proprio ticket esistente, il server non riesce a decrittografarlo mediante la nuova chiave del dMSA, il che rende inutilizzabili tutti i ticket emessi, anche se non sono scaduti.
Per evitare questo tipo di interruzione del servizio, il KDC include le chiavi dell'account precedente nella nuova struttura del pacchetto di chiavi del dMSA, considerandole come se fossero le precedenti credenziali del dMSA, che così è in grado di decrittografare i "vecchi" ticket.
Dopo aver compreso questo comportamento, un'altra "stranezza" inizia a sembrare sensata. Il campo current-keys contiene tre elementi, ognuno dei quali è costituito da un numero intero (che rappresenta il tipo di crittografia) e una stringa di ottetti (la chiave corrispondente). Per una descrizione dei valori dei tipi di crittografia, potete consultare questa pagina. Nel nostro caso, l'elenco include le chiavi RC4-HMAC, AES256 e AES128. Il campo previous-keys, tuttavia, sembra un po' diverso, in quanto contiene una sola chiave, che corrisponde al tipo RC4-HMAC (Figura 12). Perché l'elenco previous-keys contiene un solo tipo di chiave e perché, nello specifico, è del tipo RC4-HMAC?
Fig. 12: KERB-DMSA-KEY-PACKAGE structure, highlighting the different keys
La risposta risiede nei tipi di crittografia che sono supportati dall'account originale (sostituito). I ticket di assistenza sono crittografati solo tramite i tipi di crittografia supportati dal servizio preso di mira. Come spiegato nell'eccellente blog di Harmj0y, l'attributo msDS-SupportedEncryptionTypes controlla questo comportamento. Se questo attributo non è definito (predefinito per gli account degli utenti), il sistema viene impostato per predefinito solo su RC4-HMAC, da cui deriva la chiave lone RC4-HMAC nell'elenco previous-keys.
In altre parole, il KDC fornisce al dMSA solo le chiavi dell'account originale che sono necessarie per decrittografare i ticket di assistenza emessi prima della migrazione sulla base dei tipi di crittografia supportati dal gruppo principale originale, che potete verificare esaminando il relativo attributo msDS-SupportedEncryptionTypes.
La risposta di Microsoft
Abbiamo segnalato queste informazioni a Microsoft tramite MSRC il 1° aprile 2025. Dopo aver esaminato il nostro rapporto e la nostra PoC (Proof-of-Concept), Microsoft ha preso atto del problema e ne ha confermato la validità, classificandolo, tuttavia, come una vulnerabilità di moderata gravità e affermando che non rientra nella soglia attualmente stabilita tale da richiedere un'immediata assistenza.
Secondo Microsoft, la riuscita dell'attacco richiede al criminale di disporre già di specifiche autorizzazioni per l'oggetto dMSA, che è indicativo di privilegi elevati. In risposta al caso di creazione di un nuovo dMSA, Microsoft ha fatto riferimento all'argomento KB5008383, in cui vengono descritti i rischi correlati all'autorizzazione CreateChild.
Anche se apprezziamo la risposta di Microsoft, con tutto il rispetto non siamo assolutamente d'accordo con la classificazione della gravità assegnata.
Questa vulnerabilità introduce un percorso di abuso di alto impatto non conosciuto in precedenza, che consente a qualsiasi utente con autorizzazioni CreateChild su una OU di violare un qualsiasi utente presente nel dominio e di ottenere poteri simili al privilegio Replica modifiche directory utilizzato per sferrare attacchi DCSync.
Inoltre, non abbiamo trovato alcuna indicazione secondo cui gli attuali strumenti o pratiche di settore segnalano l'accesso CreateChild o, più nello specifico, CreateChild per i dMSA, come un problema critico. Riteniamo che, in tal modo, vengano sottolineate la gravità del problema e la sua capacità di rimanere nascosto.
Rilevamento e mitigazione
Rilevamento
Per rilevare potenziali abusi di questo vettore di attacco, le organizzazioni devono focalizzarsi sulle seguenti aree:
Verifica della creazione di un dMSA: configurate un SACL per registrare la creazione di nuovi oggetti msDS-DelegatedManagedServiceAccount (ID evento 5137; Figura 13). Prestate un'attenzione particolare agli account, che, di solito, non sono responsabili della creazione degli account di servizio.
Fig. 13: Event example of dMSA creation
Monitoraggio delle modifiche degli attributi: configurate un SACL per apportare modifiche all'attributo msDS-ManagedAccountPrecededByLink (ID evento 5136; Figura 14). Eventuali modifiche apportate a questo attributo indicano chiaramente un abuso tentato o riuscito.
Fig. 14: Event example of dMSA link creation
Tracciamento dell'autenticazione tramite dMSA: quando un TGT viene generato per un dMSA e include la struttura KERB-DMSA-KEY-PACKAGE, il controller di dominio registra l'evento con ID 2946 (registro del servizio di directory).
Il campo relativo all'oggetto dell'account di servizio gestito del gruppo (anche se si tratta di un dMSA e non di un gMSA) mostra il DN del dMSA da autenticare e il campo relativo al SID del chiamante apparirà come S-1-5-7 (Figura 15). È necessario esaminare gli eventi 2946 frequenti o imprevisti che riguardano i dMSA non comuni.
Fig. 15: Event example of dMSA authentication
Revisione delle autorizzazioni: prestate un'attenzione particolare alle autorizzazioni necessarie per accedere alle OU e ai container. Se le deleghe sono troppo permissive, possono dare adito a questo tipo di abuso.
Mitigazione
Finché non verrà rilasciata una patch formale da parte di Microsoft, i sistemi di difesa adottati dovranno focalizzarsi sulla limitazione della possibilità di creare i dMSA e di rendere le autorizzazioni più rigorose, ove possibile.
Gli addetti alla sicurezza devono identificare tutti i gruppi principali (utenti, gruppi, computer) con le autorizzazioni necessarie per creare i dMSA nel dominio e per limitare tali autorizzazioni solo ad amministratori attendibili.
Per assistere con queste operazioni, abbiamo pubblicato uno script PowerShellche:
Enumera tutti i gruppi principali non predefiniti che possono creare i dMSA
Elenca le OU in cui ogni gruppo principale dispone di queste autorizzazioni
Microsoft ci ha informato che i suoi team addetti alla progettazione stanno lavorando ad una patch, pertanto aggiorneremo la guida alla mitigazione riportata in questo blog una volta che saranno disponibili ulteriori informazioni tecniche.
Conclusione
Questa ricerca evidenzia come anche le autorizzazioni con ambiti limitati, che, spesso, vengono considerate poco rischiose, possono influire notevolmente sugli ambienti Active Directory. I criminali sono alquanto creativi e, se le recenti innovazioni tecnologiche ci hanno insegnato qualcosa, si tratta del fatto che le funzioni apparentemente innocue possono avere conseguenze letali se finiscono nelle mani sbagliate. Il dMSA è stato introdotto come moderna soluzione per la gestione degli account di servizio, che, tuttavia, ha portato a nuove complessità insieme a nuove opportunità di potenziali abusi.
Le organizzazioni devono trattare la capacità di creare nuovi dMSA o di controllare quelli esistenti con lo stesso livello di attenzione che riservano ad altre operazioni riservate. Le autorizzazioni necessarie per gestire questi oggetti devono essere strettamente limitate ed eventuali modifiche apportate devono essere monitorate e verificate regolarmente.
Speriamo che questa ricerca abbia fatto luce sui rischi correlati a Windows Server 2025 in generale (e, nello specifico, ai dMSA) nell'intento di aiutare gli addetti alla sicurezza a comprendere e a mitigare meglio il potenziale impatto esercitato dalle autorizzazioni configurate in modo errato.
