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 offre 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 Kerberoasting, i dMSA legano l'autenticazione direttamente alle macchine autorizzate 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 dal gruppo (gMSA). Windows Server 2012 ha risolto il limite della multi-macchina, consentendo identità di servizio condivise tra cluster, bilanciatori di carico e servizi distribuiti, pur mantenendo i vantaggi di sicurezza dell'MSA.
• Account di servizio gestiti delegati (dMSA). L'ultima innovazione di Windows Server 2025 passa dalla gestione centralizzata delle password all'autenticazione legata alle macchine, 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 attaccante, la capacità di enumerare i dMSA come utente non privilegiato è 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 inizia con il file CreateDelegatedServiceAccount comando che Figura 1 spettacoli.

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

È qui che si incontra il primo ostacolo. Un utente privilegiato può visualizzare l'account senza problemi, ma un utente non privilegiato non ottiene assolutamente nulla: risultati vuoti(Figura 3). Perché? Tutto dipende dalle impostazioni predefinite degli elenchi di controllo degli accessi (ACL) dell'account. E credetemi, nessun amministratore vuole fare confusione con queste liste.

Notate qualcosa di sospetto nella Figura 4? Sia gli utenti autenticati che Tutti 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 rivelano il loro scopo, ma la Figura 6 mostra la documentazione ufficiale di Microsoft per renderlo più chiaro.

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

Ora viene la parte più eccitante: Vediamo cosa succede quando scateniamo queste funzioni Win32(Figura 7).

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

Questo metodo ha successo perché evita completamente LDAP, aggirando di fatto le ACL restrittive. Ecco il bello tecnico: LsaLookupSids e LsaOpenPolicy non si basano affatto su LDAP. Invece, il protocollo LSA comunica attraverso \PIPE\lsarpc come endpoint RPC su SMB.

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

Ecco la parte più intelligente: Segnaliamo come sospetti tutti i conti che terminano con $. Poi eliminiamo sistematicamente i conti macchina e i gMSA.

Voilà! Abbiamo un inventario completo di tutti i dMSA del 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 supplementare.

Grazie ai miei colleghi Andrea Pierini e Shai Laronne, abbiamo scoperto 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 root KDS è il gioiello della corona dell'infrastruttura gMSA di Microsoft. È la mente crittografica del Key Distribution Service di Microsoft, il motore che genera e distribuisce le password per i 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 la rende così potente: La chiave principale del KDS funge da chiave master definitiva. Da essa vengono ricavate 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 radice del KDS risiede in genere sul DC radice della foresta, la proprietà immobiliare più protetta di AD. Microsoft non stava giocando con la sicurezza. Le ACL su queste chiavi sono incredibilmente restrittive(Figura 10) e limitano 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

La raccomandazione di Microsoft è di mantenere una sola chiave radice KDS per 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 le mie ricerche ho scoperto qualcosa di ancora più interessante. Anche in ambienti con più chiavi di root KDS, il sistema utilizza sempre la prima chiave di root KDS (la più vecchia) per motivi di compatibilità. Ciò significa che la chiave originale che abbiamo compromesso potrebbe essere preservata dal progetto 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 stiamo immergendo nel cuore dell'attacco: l'estrazione dei dati del 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 di derivazione, che lavorano insieme alla chiave radice del KDS per calcolare matematicamente la password attuale del gMSA.

Se questo vi suona familiare, avete assolutamente ragione. La grande 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 incontriamo il primo grande ostacolo. Le ACL restrittive che abbiamo scoperto in precedenza ci impediscono completamente di leggere questi dati critici sugli account dMSA. Dovevamo scavare più a fondo 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 della 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 (lo approfondiremo più avanti)
• L1Index: Valore intero che rappresenta una variabile temporale (lo approfondiremo più avanti)
• L2Index: Valore intero che rappresenta una variabile temporale (lo approfondiremo 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 scade, 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 qualcosa di fondamentale: I valori di L1 e L2 sono limitati a 31 (inclusi). Questa non è solo teoria, ma è confermata sia nella DLL (Figura 19) e Microsoft 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'algoritmo di Golden gMSA, ho scoperto che crea questi 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 l'intuizione critica.

• 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 testato questa conclusione calcolando la password e l'hash NTLM corretti per ogni vettore, quindi ho tentato gli attacchi Pass the Hash utilizzando Impacket ^smbclient2(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 sua documentazione, Microsoft afferma che "il segreto di dMSA non può essere recuperato o trovato da nessuna parte se non sul DC", evidenziando una differenza fondamentale tra i meccanismi di autenticazione gMSA e dMSA. Con le gMSA, il processo è semplice. Un'entità si autentica e richiede direttamente le credenziali (password) della gMSA, quindi riceve la password vera e propria per l'autenticazione.

I dMSA funzionano secondo un principio completamente diverso. Devono autenticarsi utilizzando l'identità della macchina per ottenere un ticket per l'utente dMSA. La password del dMSA non lascia mai il DC. Viene invece utilizzata per crittografare il ticket che viene restituito alla macchina 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 tutto. Golden dMSA aggira completamente le normali protezioni di Credential Guard(Figura 28). Non stiamo più giocando secondo le normali regole di autenticazione.

Invece di seguire il flusso di autenticazione previsto da Microsoft, le credenziali dMSA vengono utilizzate direttamente utilizzando l'attacco crittografico(Figura 29). Ciò significa che:

• Non è richiesta l'identità della macchina. Non è necessario compromettere il computer host.
• Credential Guard diventa irrilevante. Poiché non stiamo rubando le credenziali della macchina, questa protezione non offre alcuna difesa.

Microsoft ha comunicato che "a partire dall'aggiornamento di sicurezza di aprile di Windows(KB5055523), gli account macchina protetti da Credential Guard sono temporaneamente disabilitati in Windows Server 2025 e Windows 11, versione 24H2. Questa funzione è stata disattivata a causa di un problema con la rotazione delle password del computer utilizzando Kerberos. La funzione rimane disabilitata fino a quando non sarà disponibile una correzione permanente".

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 solo di ottenere l'accesso a un account di servizio. Si tratta di sfruttare questo punto d'appoggio per un movimento laterale devastante. Inoltre, questa tecnica consente agli aggressori di decifrare le password e ottenere le autorizzazioni degli account di servizio che hanno avviato e completato la migrazione al dMSA compromesso.

È qui che l'attacco diventa davvero terrificante dal punto di vista della sicurezza. L'attacco Golden dMSA non è limitato dai confini del dominio. Opera a livello di foresta. Una volta compromessa la chiave di root KDS di un singolo dominio all'interno della foresta, possiamo colpire e compromettere sistematicamente ogni account dMSA in tutti i domini della 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 scala in modo esponenziale. Quello che inizia con la compromissione di un solo DC diventa il possesso di ogni servizio protetto da dMSA in un'intera foresta aziendale. Non si tratta di una semplice escalation di 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 Base64(Figura 34) perché potrebbe includere caratteri non stampabili. Per verificare la validità del ticket, ho creato un nuovo utente, nascosto nel DC root, che solo l'account dMSA può leggere. Se riusciamo a leggere 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 che può minare l'ultima innovazione di sicurezza di Microsoft in Windows Server 2025. Questa tecnica sfrutta la base architettonica dei Managed Service Account delegati. L'attacco fa leva su 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 questo fenomeno particolarmente devastante è la sua portata a livello di foresta. Un'unica estrazione riuscita della chiave consente il movimento laterale tra i domini e l'accesso persistente a tutti gli account di servizio gestiti e alle loro risorse a tempo indeterminato, poiché le chiavi di root KDS non hanno data di scadenza. La vulnerabilità trasforma la tecnologia di account di servizio più sicura di Microsoft in una potenziale backdoor a livello aziendale, aggirando protezioni moderne come Credential Guard e mettendo fondamentalmente in discussione i presunti vantaggi di sicurezza dell'autenticazione legata alle macchine.

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 utente. Queste funzioni non sono mai state pensate 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.