Golden dMSA: cos'è il bypass dell'autenticazione dMSA?

Risultati principali

• Il ricercatore di sicurezza di Semperis Adi Malyanker ha trovato un difetto di progettazione critico negli account di servizio gestiti delegati (dMSA) introdotti in Windows Server 2025.
• Poiché la falla semplifica notevolmente la generazione di password a forza bruta, il suo sfruttamento è di bassa complessità.
• L'attacco Golden dMSA consente agli aggressori di bypassare l'autenticazione e di generare le password per tutti i dMSA e gMSA e gli account di servizio associati.
• Il rilevamento dell'attività di Golden dMSA richiede la configurazione manuale dei registri e l'auditing, rendendo difficile la mitigazione.
• I ricercatori di Semperis classificano questa vulnerabilità come MODERATA perché per sfruttarla gli aggressori devono possedere una chiave di root KDS disponibile solo per gli account più privilegiati: root Domain Admins, Enterprise Admins e SYSTEM.
• Tuttavia, questo attacco può essere ad alto impatto, consentendo il movimento laterale tra i domini e l'accesso persistente a tutti gli account dei servizi gestiti e alle loro risorse per un tempo indefinito.

Windows Server 2025 di Microsoft introduce importanti innovazioni in materia di sicurezza, tra cui l’introduzione degli account di servizio gestiti delegati (dMSA), progettati per rivoluzionare la gestione degli account di servizio. A differenza degli account statici basati su password, che possono essere vittime di attacchi di tipo “kerberoasting”, i dMSA associano l’autenticazione direttamente ai computer autorizzati in Active Directory (AD).

Questo approccio incentrato sulla macchina elimina il furto di credenziali legando l'autenticazione all'identità del dispositivo piuttosto che alle password gestite dall'utente. Solo le macchine esplicitamente autorizzate possono accedere al dMSA.

Questo articolo rivela un nuovo attacco contro i Managed Service Account delegati, chiamato attacco Golden DMSA. La tecnica consente agli aggressori di bypassare l'autenticazione gestita dalla macchina prevista e di generare le password per tutti i dMSA associati offline.

Che cos'è il Golden dMSA?

Golden dMSA è un metodo di persistenza e di scalata dei privilegi che consente agli aggressori di generare le password per tutti i dMSA e i group Managed Service Account (gMSA) e i relativi account di servizio.

L'attacco sfrutta un difetto critico di progettazione: una struttura utilizzata per il calcolo della generazione della password contiene componenti prevedibili basati sul tempo con solo 1.024 combinazioni possibili, rendendo la generazione di password a forza bruta computazionalmente banale.

Questo attacco può essere utilizzato sia per la persistenza che per l'escalation dei privilegi in qualsiasi ambiente AD con account dMSA. Semperis valuta questa vulnerabilità come a rischio moderato perché la sua esecuzione dipende dalla compromissione parziale della foresta.

Continuate a leggere per scoprire come abbiamo scoperto la vulnerabilità che abilita Golden dMSA, i dettagli che abbiamo trovato dietro il difetto di progettazione,
e come è possibile rilevare e mitigare le attività di bypass dell'autenticazione.

Come funziona un attacco Golden dMSA?

Dopo aver ottenuto privilegi elevati all'interno di un dominio, un utente malintenzionato può compromettere sistematicamente tutti gli account dMSA e gMSA attraverso un semplice attacco in quattro fasi.

Fase 1: estrazione del materiale della chiave radice KDS (pre-requisito per l'attacco). L'aggressore estrae materiale crittografico dalla chiave principale di Key Distribution Services (KDS), la base per tutte le password degli account dei servizi gestiti.

Fase 2: enumerazione dei conti dMSA. Nella fase 1, l'utente SYSTEM o Domain Admin non ha le autorizzazioni per enumerare i dMSA in altri domini. In questa seconda fase, l'aggressore tenta, con la forza bruta o utilizzando LDAP, di scoprire dati quali sAMAccountName attributi e identificatori di sicurezza (SID) sugli account dMSA nella foresta AD.

Fase 3: indovinare il ManagedPasswordID. Successivamente, l'attaccante tenta di identificare la corretta ManagedPasswordId e gli hash delle password attraverso l'indovinello mirato.

Fase 4: generazione di password. Utilizzando strumenti specializzati come GoldenDMSA, l'attaccante può generare password valide per qualsiasi gMSA o dMSA associato alla chiave compromessa.

Questo processo non richiede ulteriori accessi privilegiati una volta ottenuta la chiave di root KDS, il che lo rende un metodo di persistenza particolarmente pericoloso.

L'attacco mette in evidenza il limite critico di fiducia degli account dei servizi gestiti. Questi si basano su chiavi crittografiche a livello di dominio per la sicurezza. Sebbene la rotazione automatica delle password fornisca un'eccellente protezione contro i tipici attacchi alle credenziali, gli amministratori di dominio, i DnsAdmin e gli operatori di stampa possono aggirare completamente queste protezioni e compromettere tutti i dMSA e i gMSA della foresta.

Cosa sono i dMSA? Breve storia del conto di servizio

Per decenni, gli amministratori di Windows hanno utilizzato i normali account di dominio per eseguire i servizi, un approccio funzionale ma difettoso che si è evoluto con l'introduzione degli account di servizio. A differenza degli account utente interattivi, che rappresentano persone reali, gli account di servizio esistono solo per fornire un contesto di identità ai processi automatizzati.

I primi account di servizio si basavano su password statiche che creavano incubi operativi. Il coordinamento delle modifiche alle password tra più team, servizi e applicazioni spesso portava a interruzioni e alla resistenza alle best practice di sicurezza.

Peggio ancora, le password statiche consentivano attacchi devastanti. Gli exploit di Kerberoasting consentivano agli aggressori di richiedere ticket di servizio e di decifrare le password offline, mentre le credenziali deboli o invariate fornivano facili obiettivi per l'escalation dei privilegi.

Da allora, Microsoft ha creato diverse versioni di account di servizio.

• Account di servizio gestiti (MSA). Windows Server 2008 R2 ha introdotto la rotazione automatica delle password di 240 caratteri ogni 30 giorni e la gestione automatica del nome del service principal (SPN). Il problema? Gli MSA sono limitati a singole macchine.
• Account di servizio gestiti di gruppo (gMSA). Windows Server 2012 ha risolto la limitazione relativa al numero di macchine, consentendo la condivisione delle identità di servizio tra cluster, bilanciatori di carico e servizi distribuiti, pur mantenendo i vantaggi in termini di sicurezza offerti dagli MSA.
• Account di servizio gestiti delegati (dMSA). L'ultima innovazione di Windows Server 2025 segna il passaggio dalla gestione centralizzata delle password all'autenticazione legata al dispositivo, rappresentando un cambiamento fondamentale nella sicurezza degli account di servizio.

Questa evoluzione dagli account tradizionali a gMSA e dMSA crea un'interessante superficie di attacco, che la tecnica Golden dMSA sfrutta facendo leva sulla base crittografica condivisa tra i sistemi gMSA e dMSA.

Come gli aggressori trovano i dMSA: Rompere la barriera dell'invisibilità

Dal punto di vista di un aggressore, la capacità di enumerare i dMSA come utente senza privilegi è fondamentale per l'escalation dei privilegi e il movimento laterale. Per ottenere la password di un dMSA, è necessario conoscerne il nome e il SID.

Tuttavia, una delle sfide più intriganti quando si ha a che fare con i dMSA è trovare questi conti sfuggenti in primo luogo.

Secondo la documentazione di Microsoft, per creare i dMSA, si parte dal CreateDelegatedServiceAccount comando che Figura 1 spettacoli.

Ora arriva la parte divertente. Proviamo a visualizzare il nostro account DMSA-Demo appena creato utilizzando Get-ADServiceAccount (Figura 2).

È qui che incontriamo il nostro primo ostacolo. Un utente con privilegi può visualizzare l’account senza problemi, ma un utente senza privilegi non vede assolutamente nulla: i risultati sono vuoti (Figura 3). Perché? Tutto dipende dalle impostazioni predefinite nelle liste di controllo degli accessi (ACL) dell’account. E, credetemi, nessun amministratore vuole avere a che fare con queste.

Notate qualcosa di sospetto nella Figura 4? Gli utenti autenticati sono completamente esclusi dalla lettura dei dati di questi account.

Come può un utente non privilegiato accedere alle informazioni sugli account dMSA?

Qui inizia il lavoro investigativo. Dopo innumerevoli indagini e tentativi falliti, ho scoperto che possiamo costruire un elenco di potenziali SID e tradurre ciascuno di essi in oggetti NTAccount. (Per questa magia ho usato C#).

La funzione translate sfrutta queste potenti API Win32: LsaOpenPolicy e LsaLookupSids (Figura 5).

I nomi delle funzioni ne rivelano lo scopo, ma la Figura 6 riporta la documentazione ufficiale di Microsoft per chiarirlo in modo inequivocabile.

È interessante notare che uno strumento di Impacket chiamato lookupsid¹ utilizza esattamente la stessa tecnica, impiegando hLsarOpenPolicy2 e hLsarLookupSids per enumerare i SID.

E ora veniamo alla parte più interessante: vediamo cosa succede quando utilizziamo queste funzioni Win32 (Figura 7).

Bingo! Abbiamo recuperato ogni singolo account del dominio, oltre ad altri oggetti con SID.

Questo metodo funziona perché aggira completamente il protocollo LDAP, eludendo di fatto quelle ACL restrittive. Ecco il bello dal punto di vista tecnico: LsaLookupSids e LsaOpenPolicy Non fare affidamento su LDAP. Il protocollo LSA comunica invece tramite \PIPE\lsarpc come endpoint RPC su SMB.

Ma aspettate: come possiamo identificare quali account di questo enorme elenco sono dMSA?

Ecco il trucco: contrassegniamo come sospetti tutti gli account che terminano con $. Poi eliminiamo sistematicamente gli account automatici e i gMSA.

Ecco fatto! Abbiamo ora un elenco completo di tutti i dMSA presenti nel dominio.

Colpo di scena: questa tecnica funziona anche oltre i confini del dominio! Possiamo enumerare i dMSA di altri domini usando lo stesso metodo.

Ecco una scoperta in più.

Grazie ai miei colleghi Andrea Pierini e Shai Laronne, abbiamo individuato un approccio alternativo basato su LDAP (Figura 8).

Il segreto? Quando iniziamo la ricerca direttamente dal contenitore stesso, possiamo andare a caccia di questi tipi di account specifici. In combinazione con il nostro precedente metodo di enumerazione SID, possiamo estrarre le informazioni SID filtrando gli account gMSA e informatici(Figura 9).

Questo duplice approccio ci consente di disporre di più vettori di attacco per la scoperta di dMSA: una svolta per qualsiasi valutazione della sicurezza.

Perché la chiave radice del KDS è al centro degli attacchi Golden dMSA?

Introdotta per la prima volta in Windows Server 2012, la chiave radice KDS è il fiore all’occhiello dell’infrastruttura gMSA di Microsoft. Consideratela come il cervello crittografico alla base del Key Distribution Service di Microsoft, ovvero il motore che genera e distribuisce le password per gli account gMSA.

L'ottenimento di questa chiave di root è il primo passo critico nella catena di attacco, poiché consente agli aggressori di calcolare le password di qualsiasi gMSA nel dominio offline. Questa capacità è devastante perché i gMSA sono progettati per far ruotare automaticamente le loro password dal controller di dominio (DC), facendole apparire sicure agli amministratori. Tuttavia, con la chiave di root KDS in mano, un utente malintenzionato può ricavare matematicamente la password corrente di qualsiasi account gMSA senza mai connettersi nuovamente al DC.

Ecco cosa lo rende così potente: la chiave radice KDS funge da chiave maestra definitiva. Da essa vengono derivate tutte le password gMSA attraverso un elegante processo di derivazione delle chiavi.

Ma c'è di più. Microsoft ha recentemente esteso la chiave di root KDS al controllo degli account dMSA.

Ora la chiave di root KDS è due volte più preziosa per gli aggressori, poiché sblocca sia le password gMSA che quelle dMSA.

La chiave principale del KDS risiede nel contesto di denominazione della configurazione (CN=Master Root Keys,CN=Group Key Distribution Service,CN=Services,CN=Configuration,DC=,DC=), che si replica su tutti i DC scrivibili della foresta a partire dal DC radice della foresta, ma rimane nascosta agli utenti non privilegiati. Microsoft non ha certo scherzato con la sicurezza in questo caso. Le ACL su queste chiavi sono incredibilmente restrittive (Figura 10) limitando l'accesso solo agli account più privilegiati: root Domain Admins, Enterprise Admins e SYSTEM.

Tuttavia, nonostante queste restrizioni ferree, queste preziose chiavi possono essere recuperate da altri DC in tutta la foresta, ma solo con l'accesso a livello di SISTEMA(Figura 11).

A questo punto si potrebbe pensare che avere i permessi SYSTEM su un DC diminuisca la sfruttabilità di Golden dMSA. Tuttavia, si tratta di un singolo DC dell'intera foresta e il flusso di attacco cambia radicalmente il panorama delle minacce, passando da una compromissione localizzata a una backdoor persistente a livello di foresta.

Ciò significa che, sebbene l'accesso al SISTEMA su un DC rappresenti già una violazione significativa, la tecnica Golden dMSA trasforma tale violazione in una minaccia molto più pericolosa e duratura, consentendo all'aggressore di mantenere un accesso persistente ai gMSA, ai dMSA e agli account di servizio associati nell'intera foresta, senza richiedere la presenza continua sul DC compromesso.

Prestate molta attenzione a questo dettaglio fondamentale: Le chiavi di accesso KDS non hanno una data di scadenza

Microsoft raccomanda di mantenere una sola chiave radice KDS per ogni ambiente.

Fate i conti. In teoria, dopo aver compromesso una singola chiave di root KDS, un utente malintenzionato potrebbe potenzialmente generare le password per tutti i futuri account dMSA e gMSA all'infinito.

Durante la mia ricerca ho scoperto qualcosa di ancora più intrigante. Anche in ambienti con più chiavi radice KDS, il sistema potrebbe utilizzare la vecchia chiave radice KDS a causa della cache (a meno che non si reimposti il servizio KDS in modo specifico). Ciò significa che la chiave originale che abbiamo compromesso potrebbe essere conservata per scelta progettuale di Microsoft, creando una backdoor persistente che potrebbe durare per anni.

Questa decisione architettonica trasforma una singola estrazione di chiave riuscita in un vantaggio strategico a lungo termine per gli aggressori, rendendo la chiave radice del KDS uno degli obiettivi più preziosi in qualsiasi dominio Windows.

Cracking the code: Dalla generazione di password gMSA a quella dMSA

Ora ci addentriamo nel cuore dell'attacco: l'estrazione dei dMSA ManagedPasswordId attributo.

ManagedPasswordId è un attributo memorizzato in AD che contiene i metadati necessari per ricavare la password corrente di un MSA. Dobbiamo acquisire questo attributo perché contiene i parametri crittografici essenziali — tra cui l'identificatore della chiave, l'ora di creazione e altri dettagli relativi alla derivazione — che, insieme alla chiave radice KDS, consentono di calcolare matematicamente la password effettiva del gMSA.

Se questa situazione vi suona familiare, avete assolutamente ragione. L'eccellente ricerca di Yuval Gordon su Attacchi gMSA Active Directory ha fatto conoscere al mondo gMSA d'oro. Questa tecnica di attacco prevede l'estrazione della chiave radice del KDS da AD, l'interrogazione dei gMSA disponibili con il loro SID e il loro SID. ManagedPasswordId e calcolare le password dai dati.

Durante la ricerca di Golden dMSA, la mia ipotesi era semplice ma potente: Microsoft avrebbe potuto riciclare lo stesso codice da gMSA a dMSA per la creazione e il rinnovo delle password. Ma potevamo effettivamente riprodurre l'attacco Golden gMSA contro gli account dMSA?

È qui che abbiamo incontrato il nostro primo ostacolo significativo. Quelle ACL restrittive che avevamo individuato in precedenza ci impediscono completamente di leggere questi dati fondamentali relativi agli account dMSA. Abbiamo dovuto approfondire l'analisi e ampliare il nostro algoritmo.

Reverse engineering della struttura ManagedPasswordId

Per risolvere questo enigma, ho iniziato a indagare sulla ManagedPasswordId struttura stessa. Ho creato un nuovo account dMSA e ho estratto il suo ManagedPasswordID attributo.

Dopo aver analizzato l'array di byte e averlo confrontato con diverse istanze, ho scoperto che contiene i componenti illustrati nella Figura 12 .

Questa struttura mi sembrava familiare. È praticamente identica a quella di gMSA. ManagedPasswordID formato (Figura 13).

La Figura 14 mostra la ripartizione completa di questa struttura, con questi componenti chiave:

• Versione: Valore intero con valore decimale (1,0,0,0)
• Riservato: Valore intero con valore decimale di (75, 68, 83, 75)
• isPublicKey: Valore intero con valore decimale (2,0,0,0)
• L0Index: valore intero che rappresenta una variabile temporale (ne parleremo più avanti)
• L1Index: valore intero che rappresenta una variabile temporale (ne parleremo più avanti)
• L2Index: valore intero che rappresenta una variabile temporale (ne parleremo più avanti)
• RootKeyIdentifier: Valore GUID costruito dall'ID della chiave principale KDS.

Il campo di RootKeyIdentifier può essere costruito dalle chiavi radice KDS (RKL è l'id della chiave radice KDS, cioè f06c3c8d-b2c2-4cc6-9a1a-8b3b3c82b9f0), come Figura 15 spettacoli.

• cbUnknown: valore intero con valore decimale (0, 0, 0, 0)
• cbDomainName: Valore intero che rappresenta (lunghezza del nome del dominio * 2) + 2.
• cbForestName: Valore intero che rappresenta (lunghezza del nome della foresta * 2) + 2.
• NomeDominio: Nome del dominio dell'account dMSA in questo formato speciale
• ForestName: Nome della foresta dell'account dMSA in questo formato speciale

Notate qualcosa nel cbDomainName e cbForestName: Moltiplichiamo per 2 e aggiungiamo 2 perché i byte ASCII con valore 0 vengono inseriti tra ogni carattere. Quindi root.test diventa r.o.o.t…t.e.s.t.. nella struttura attuale.

Studiando il Articolo di Microsoft Learn su msDS-ManagedPassword e il fornitore KDS di Microsoft KdsCli.dll (che implementa la maggior parte della logica delle password), ho tracciato il flusso a partire da GetgMSAPasswordBlob(), come Figura 16 spettacoli.

La logica è elegante. Quando il ManagedPasswordId non esiste o è scaduto, il sistema stabilisce un nuovo orario di inizio e chiama GetPasswordBasedOnTimestamp(), come Figura 17 spettacoli.

Questo ci porta a una delle osservazioni più significative della nostra ricerca. I valori di L0, L1 e L2 sono generati in GetIntervalID(), poi passato a GetKey() quando si costruisce una nuova chiave BLOB (Figura 18).

Da questa osservazione ho scoperto un aspetto fondamentale: i valori di L1 e L2 sono limitati a 31 (incluso). Non si tratta solo di teoria; è confermato sia nella DLL (Figura 19) e Microsoft's GetKey() documentazione (Figura 20).

Il GetPasswordBasedOnTimestamp() sarà richiamato anche quando si rinnova il metodo ManagedPasswordId è necessario.

La scoperta rivoluzionaria

Ora arriva la rivelazione che cambia le carte in tavola.

Possiamo prevedere la maggior parte di ciò che il ManagedPasswordID necessario per calcolare le password gMSA e dMSA. Conosciamo L1Index e L2Index sono vincolati a valori che possiamo ottenere con la forza bruta. La sfida principale sembra essere L0Indexche, come numero intero a 4 byte, può avere miliardi di valori potenziali.

Approfondendo l'analisi dell'algoritmo di Golden gMSA, ho scoperto che crea i seguenti oggetti:

• L0Key, contenente gli attributi della chiave radice KDS (Figura 21)
• L0KeyId, calcolato a partire dall'ora corrente
• GenerateKDFContext e GenerateDerivedKey, che derivano L1Key e L2Key vettori di byte una volta (Figura 21) o un paio di volte (Figura 22)

Ecco il punto fondamentale.

• L0Keyid, L1Keyid, e L2Keyid sono interamente basati sul tempo e indipendenti dall'utente (come Figura 19 mostra sopra).
• L'unico valore controllato dall'utente è il valore ManagedPasswordId che forniamo insieme alla chiave radice KDS, ai nomi dei domini e delle foreste e al SID.

È qui che tutto è scattato. Quando ho tracciato il punto in cui L0Index (dal ManagedPasswordId) è effettivamente utilizzato nell'algoritmo, ho trovato le rivelazioni che Figura 23 e Figura 24 spettacolo.

È un dettaglio sorprendente. L0index non viene utilizzato per niente dal MsdsManagedPasswordId il che significa che non ha importanza il valore che utilizziamo.

Indovinare la password: Mettere tutto insieme

Ora possiamo costruire quasi l'intero ManagedPasswordId il vettore finale necessario per prevedere le password e gli hash di gMSA e dMSA. Dal momento che L0Index viene ignorato e L1Index e L2Index deve essere compreso tra 0-31 (incluso), abbiamo solo 32 × 32 = 1.024 vettori possibili da testare.

Ho verificato questa conclusione calcolando la password corretta e l'hash NTLM per ciascun vettore, quindi ho tentato degli attacchi "Pass the Hash" utilizzando^{lo strumento smbclient2} di Impacket (Figura 25).

Successo! Questo metodo ha funzionato perfettamente per gli account gMSA. Siamo riusciti a prevedere i loro hashish entro 1.024 tentativi, senza bisogno dello specifico ManagedPasswordId.

Tuttavia, non sono riuscito a passare l'hash con l'hash della password di dMSA. Inoltre, dovevamo chiederci come potevamo sfruttare questo attacco quando gli attacchi Pass the Hash sono mitigati da questo dominio.

Dopo aver esaminato gli attributi di uno dei miei dMSA, ho visto che richiede la connessione con il tipo di crittografia Kerberos AES 256, come mostra la Figura 26 . (Come si ricorderà, ho seguito le raccomandazioni di Microsoft per la creazione di un dMSA). (Si ricorda che ho seguito la raccomandazione di Microsoft di applicare AES 256 quando si crea un dMSA).

Ho provato a generare un hash AES 256 dalla password del servizio. Dopo alcuni estenuanti tentativi, ho scoperto che i gMSA e i dMSA utilizzano un formato di sale leggermente diverso per l'hashing AES 256:

<Domain name in UPPER case>host<user's full UPN in lower case (without $)>

Ad esempio:

ROOT.TESThostdmsa-demo8.root.test

Con questo formato di sale, ho potuto finalmente generare ticket Kerberos validi per gli account dMSA.

Mappatura del flusso di attacco Golden dMSA

Il diagramma della Figura 27 riassume l'attacco Golden dMSA.

1. Iniziare con i privilegi SYSTEM su uno dei DC del dominio o con i privilegi di Enterprise Admin per scaricare le chiavi radice di KDS.
2. Forzare i SID degli account dMSA o usare le query LDAP per identificare gli account di destinazione.
3. Creare un elenco di parole contenente tutte le 1.024 possibili ManagedPasswordIds per questo utente specifico.
4. Calcolare la password per ogni possibile coppia (chiavi radice KDS), ManagedPasswordIds) e fare l'hash a NTLM/AES256.
5. Testate l'hash di ogni password con le tecniche Pass the Hash o Overpass the Hash.

Questo attacco trasforma gli account dMSA da obiettivi apparentemente impenetrabili in sfide di forza bruta gestibili, richiedendo solo 1.024 tentativi per decifrare qualsiasi password dMSA nel dominio.

Come un attacco Golden dMSA bypassa la normale autenticazione

Nella propria documentazione, Microsoft afferma che «il segreto del dMSA non può essere recuperato né trovato in nessun altro luogo se non sul DC», sottolineando una differenza fondamentale tra i meccanismi di autenticazione gMSA e dMSA. Con i gMSA, il processo è semplice: un’entità si autentica e richiede direttamente le credenziali (password) del gMSA, ricevendo poi la password effettiva a fini di autenticazione.

I dMSA funzionano secondo un principio completamente diverso. Devono effettuare l'autenticazione utilizzando l'identità del computer per ottenere un ticket per l'utente dMSA. La password del dMSA non esce mai dal DC. Viene invece utilizzata per crittografare il ticket che viene restituito al computer richiedente.

Per evitare che un aggressore rubi l'hash del computer e lo usi per richiedere un ticket, Microsoft consiglia di utilizzare Credential Guard. Questa mitigazione crea una solida barriera che dovrebbe bloccare la maggior parte degli attacchi di furto di credenziali.

Ma è qui che l'attacco Golden dMSA cambia completamente le carte in tavola. Il Golden dMSA aggira completamente le normali protezioni di Credential Guard (Figura 28). Non stiamo più seguendo le normali regole di autenticazione.

Anziché seguire il flusso di autenticazione previsto da Microsoft, le credenziali dMSA vengono utilizzate direttamente ricorrendo a un attacco crittografico (Figura 29). Ciò significa che:

• Non è richiesta alcuna identità della macchina. Non è necessario compromettere la macchina host.
• Credential Guard diventa superfluo. Dato che non stiamo rubando le credenziali del computer, questa protezione non offre alcuna difesa.

Microsoft ha confermato che: «A partire dall'aggiornamento di sicurezza di Windows di aprile (KB5055523), la protezione degli account macchina tramite Credential Guard è temporaneamente disabilitata in Windows Server 2025 e Windows 11, versione 24H2. Questa funzionalità è stata disabilitata a causa di un problema relativo alla rotazione delle password macchina tramite Kerberos. La funzionalità rimarrà disabilitata fino a quando non sarà disponibile una soluzione definitiva».

Qual è il vero rischio della Golden dMSA? Devastazione dell'intera foresta

Una volta che un aggressore è riuscito a compromettere un account dMSA utilizzando la tecnica “Golden dMSA”, inizia il vero divertimento. Non si tratta semplicemente di ottenere l’accesso a un singolo account di servizio, ma di sfruttare quel punto d’appoggio per compiere movimenti laterali devastanti. Inoltre, questa tecnica consente agli aggressori di violare le password e ottenere le autorizzazioni degli account di servizio che hanno avviato e completato la migrazione verso il dMSA compromesso.

È qui che l'attacco diventa davvero terrificante dal punto di vista della sicurezza. L'attacco Golden dMSA non è limitato dai confini dei domini. Opera a livello di foresta. Una volta compromessa la chiave radice KDS di un singolo dominio all'interno della foresta, possiamo prendere di mira e compromettere sistematicamente ogni account dMSA in tutti i domini di quella foresta.

Ciò significa che una singola estrazione di chiave radice KDS riuscita si trasforma in:

• Compromissione di account cross-domain. Nessun confine di dominio può fermarci.
• Raccolta di credenziali a livello di foresta. Ogni dMSA in ogni dominio diventa vulnerabile.
• Movimento laterale illimitato. Possiamo passare da un dominio all'altro a piacimento utilizzando account dMSA compromessi.
• Accesso persistente. Senza scadenza delle chiavi KDS, questo accesso potrebbe durare indefinitamente.

L'attacco si espande in modo esponenziale. Quello che inizia con la compromissione di un singolo DC si trasforma in il controllo di tutti i servizi protetti da dMSA all'interno dell'intera foresta aziendale. Non si tratta solo di un'escalation dei privilegi. Si tratta di un dominio digitale a livello aziendale attraverso un'unica vulnerabilità crittografica.

Che cos'è lo strumento Golden dMSA?

Per capire come viene sfruttata questa tecnica di attacco, abbiamo preso la logica dell'attacco e l'abbiamo inserita in uno strumento chiamato ^GoldenDMSA3. Lo strumento incorpora i principi strutturali dello strumento^GoldenGMSA4.

Un utente malintenzionato può utilizzare lo strumento GoldenDMSA per enumerare tutti i gMSA, i dMSA e le chiavi root KDS associate, utilizzare attacchi di forza bruta per ottenere le password e ottenere i ticket per gli account. Un utente malintenzionato con privilegi elevati può anche utilizzare lo strumento GoldenDMSA per eseguire il dump delle chiavi di root KDS.

Per dimostrare lo strumento in azione, analizziamo uno sfruttamento tra i domini di una foresta.

Per iniziare, l'attaccante si trova in un dominio chiamato child.root.test (Figura 30) e cerca di ottenere i dMSA da root.test (Figura 31).

Poi, l'attaccante deve creare un elenco di parole (Figura 32) che verrà utilizzato per il file ManagedPasswordIds attacco di forza bruta.

Infine, lanceremo un attacco di forza bruta con l'aiuto della lista di parole(Figura 33).

La password è codificata in Base64 (Figura 34) poiché potrebbe contenere caratteri non stampabili. Per verificare la validità del ticket, ho creato un nuovo utente — nascosto nel DC root — che solo l'account dMSA poteva leggere. Se riusciamo a leggere correttamente i dati dell'utente, sappiamo che il ticket generato è valido.

Come rilevare il Golden dMSA: scoprire gli indicatori nascosti

Per impostazione predefinita, non vengono registrati eventi di sicurezza quando una chiave root KDS viene compromessa. Per rilevare gli attacchi Golden dMSA, i difensori devono configurare manualmente un elenco di controllo dell'accesso al sistema (SACL) sugli oggetti della chiave principale KDS per verificare l'accesso in lettura alla chiave principale. msKds-RootKeyData attributo.

A tal fine, aprire lo strumento Active Directory Editor Interface (ADSI Edit) e:

• Selezionare il contesto di denominazione Configurazione
• Spostarsi su Servizi, quindi fare clic su Servizio di distribuzione delle chiavi di gruppo.
• Selezionare Master Root Keys e fare clic con il tasto destro del mouse sulla chiave radice KDS in questione.
• Andare alla scheda Sicurezza, fare clic sul pulsante Avanzate
• Selezionare la scheda Auditing e configurare una regola di audit per l'accesso in lettura su Utenti autenticati/Tutti.

Quando questa SACL è attiva, qualsiasi tentativo non autorizzato di estrarre i dati della chiave radice KDS attiverà l'evento di sicurezza 4662 sul CC (Figura 35). Questo evento mostrerà un tipo di oggetto di msKds-ProvRootKey e un nome di account che non è un DC, il che indica una potenziale attività dannosa.

Il nuovo indicatore di sicurezza DSP aiuta a rilevare Golden dMSA

Come si può notare, il rilevamento manuale della compromissione della chiave root KDS è impegnativo per la maggior parte dei team. Semperis ha fornito un nuovo modulo di protezione degli account di servizio, un miglioramento delle funzionalità di Directory Services Protector DSP). Il modulo include un indicatore di sicurezza chiamato KDS root key ACL was modified, che ricerca le modifiche ACL sulle chiavi root KDS(Figura 36) che potrebbero consentire agli aggressori di leggere tali chiavi e lanciare un attacco Golden dMSA.

Ulteriori indizi da tenere d'occhio

Inoltre, i difensori devono:

• Monitoraggio di volumi anomali di richieste di autenticazione AS-REQ che si rivolgono allo stesso conto di servizio (identificabile con i conti che terminano con $), in particolare se seguiti da PREAUTH-FAILED (codice di errore 24). Questo schema può indicare un tentativo di attacco Overpass the Hash.
• Cercare richieste anomale di Ticket-Granting Ticket (TGT) da parte di account dMSA, soprattutto se lanciate da account utente.

Istantanea Semperis

L'attacco Golden dMSA sfrutta una vulnerabilità crittografica in grado di compromettere l'ultima innovazione di sicurezza introdotta da Microsoft in Windows Server 2025. Questa tecnica sfrutta le fondamenta architetturali degli account di servizio gestiti delegati. L'attacco sfrutta un difetto di progettazione critico: il ManagedPasswordId La struttura contiene componenti prevedibili basati sul tempo con solo 1.024 combinazioni possibili, rendendo la generazione di password a forza bruta computazionalmente banale.

Ciò che rende questa vulnerabilità particolarmente devastante è la sua portata a livello di foresta. Una singola estrazione riuscita della chiave consente il movimento laterale tra domini e l’accesso persistente a tutti gli account di servizio gestiti e alle relative risorse a tempo indeterminato, poiché le chiavi root KDS non hanno una data di scadenza. La vulnerabilità trasforma la tecnologia degli account di servizio più sicura di Microsoft in una potenziale backdoor a livello aziendale, aggirando le moderne protezioni come Credential Guard e mettendo fondamentalmente in discussione i presunti vantaggi di sicurezza dell’autenticazione legata al dispositivo.

Divulgazione

Il problema è stato inizialmente segnalato al Microsoft Security Response Center (MSRC) il 27 maggio 2025.

L'8 luglio 2025, Microsoft ha risposto in parte: «Se si dispone dei segreti utilizzati per ricavare la chiave, è possibile autenticarsi come quell'utente. Queste funzionalità non sono mai state concepite per proteggere da una compromissione di un controller di dominio».

Per saperne di più sulle minacce agli account di servizio gestiti

• BadSuccessor: Come rilevare e mitigare l'escalation dei privilegi in dMSA
• Come bloccare BadSuccessor
• Attacchi gMSA Active Directory

Note finali

1. https://github.com/fortra/impacket/blob/master/examples/lookupsid.py
2. https://github.com/fortra/impacket/blob/master/examples/smbclient.py
3. https://github.com/Semperis/GoldenDMSA/tree/main
4. https://github.com/Semperis/GoldenGMSA

Esclusione di responsabilità

Questo contenuto è fornito solo a scopo educativo e informativo. Il suo scopo è quello di promuovere la consapevolezza e la correzione responsabile delle vulnerabilità di sicurezza che possono esistere sui sistemi di cui si è proprietari o che si è autorizzati a testare. È severamente vietato l'uso non autorizzato di queste informazioni per scopi malevoli, sfruttamento o accesso illegale. Semperis non approva né condona alcuna attività illegale e declina ogni responsabilità derivante dall'uso improprio del materiale. Inoltre, Semperis non garantisce l'accuratezza o la completezza dei contenuti e non si assume alcuna responsabilità per eventuali danni derivanti dal loro utilizzo.