Nuova vulnerabilità Windows Server 2025 sui dMSA

Microsoft ha introdotto con Windows Server 2025 un nuovo tipo di account gestito, ovvero i delegated Managed Service Accounts (dMSA), pensati per semplificare la sostituzione di account di servizio tradizionali. Ma una nuova vulnerabilità (BadSuccessor) ha scatenato l’allarme nella community IT. Con un semplice abuso dell’attributo msDS-ManagedAccountPrecededByLink , un utente malintenzionato con diritti limitati può far credere al sistema che una dMSA stia sostituendo un account ad alto privilegio, come ad esempio un Domain Admin.
👉 Il risultato? Accesso completo al dominio, Privilege Escalation e conseguente compromissione dell’intera infrastruttura Active Directory.

Che cosa sono i dMSA in Windows Server 2025?

Con Windows Server 2025, Microsoft ha introdotto una nuova funzionalità chiamata dMSA, che sta per delegated Managed Service Account.
Ma cosa significa, in parole semplici?

Tradizionalmente, nelle reti aziendali, per far funzionare servizi o applicazioni (come SQL Server, IIS, o servizi custom) si usano account di servizio, ovvero utenti creati apposta per “far girare” questi servizi. Il problema è che spesso questi account sono gestiti manualmente: bisogna preoccuparsi delle password, dei permessi, delle policy… insomma, un incubo da gestire in ambienti complessi. Microsoft già da tempo (prima release con Windows Server 2008 R2) ha proposto i Managed Service Accounts (MSA), cioè account che vengono gestiti automaticamente da Active Directory: la password viene cambiata in automatico dal sistema, la sicurezza è più elevata e l’errore umano si riduce.

I dMSA sono una evoluzione di questi account. La novità è che permettono di delegare la gestione dell’account a un altro oggetto e, soprattutto, sostituire un vecchio account di servizio con un nuovo dMSA senza perdere i privilegi o le configurazioni già assegnate.

In pratica:

• Crei un dMSA.

• Gli dici quale account sta rimpiazzando.

• Il sistema “eredita” in automatico permessi, gruppi e identità del vecchio account.

Questo è molto comodo quando vuoi fare una migrazione sicura e senza intoppi… ma proprio questa “comodità” è anche ciò che ha aperto la porta alla vulnerabilità BadSuccessor, se non si configura il tutto correttamente.

La vulnerabilità BadSuccessor

La vulnerabilità BadSuccessor sfrutta il modo in cui il Key Distribution Center (KDC) gestisce l’attributo msDS-ManagedAccountPrecededByLink, che indica quale account è stato sostituito dalla dMSA. Un attaccante con permessi di scrittura su una dMSA può manipolare questo attributo per far credere al KDC che la dMSA stia sostituendo un account con privilegi elevati, come un amministratore di dominio. Di conseguenza, il KDC concede alla dMSA tutti i privilegi dell’account sostituito, inclusi i SID e i gruppi di appartenenza, permettendo all’attaccante di ottenere accesso completo al dominio.

In pratica, se un utente ha permessi di scrittura su un dMSA, può manualmente forzare quel campo e indicare che il suo account sostituisce un account ad alto privilegio… come un Domain Admin.

💥 Il risultato?
Il KDC (Key Distribution Center) prende per buono il collegamento e attribuisce alla dMSA tutti i diritti dell’account “precedente”. In un attimo, un utente con privilegi minimi può ottenere il controllo completo del dominio.

Come verificare se un utente ha permessi di scrittura su un dMSA

Verificare se un utente ha permessi di scrittura su un oggetto Active Directory (come ad esempio un dMSA) è fondamentale per identificare potenziali rischi di escalation di privilegi, come nella vulnerabilità BadSuccessor.

Modalità tramite Powershell

Puoi verificare i permessi su un oggetto AD (come un dMSA) usando questi comandi:

# 1. Ottieni l’oggetto dMSA
$account = Get-ADServiceAccount -Identity NomeDmsa

# 2. Ottieni il suo DistinguishedName
$dn = $account.DistinguishedName

# 3. Controlla i permessi (Access Control List)
$acl = Get-ACL “AD:$dn”
$acl.Access

Osservando l’output del comando verificare:

• IdentityReference -> rappresenta l’utente o il gruppo da controllare

• ActiveDirectoryRights include WriteProperty, GenericWrite, WriteDacl, ecc.

• AccessControlType è Allow

Modalità GUI tramite strumenti nativi Active Directory

Tramite lo snap-in Active Directory User & Computer (con la modalità avanzata attiva), una volta individuato l’account dMSA:

• Fai clic destro > Properties

• Sulla scheda Security, poi Advanced

• Cercare l’utente o il gruppo e verifica se ha diritti di scrittura su:

  • attributi come msDS-ManagedAccountPrecededByLink

  • permessi generici come Write, Full Control

Modalità tramite strumenti avanzati di Security (PowerView)

Se si sta operando in contesti di auditing avanzato o Red Teaming (con autorizzazione), è possibile PowerView, tramite il seguente comando:

# Cerca permessi scrivibili sull’oggetto
Find-InterestingDomainObject -DomainObject “CN=nomeDmsa,OU=…,DC=…” -Verbose

Implicazioni e mitigazioni

Questa vulnerabilità è particolarmente insidiosa perché:

• Può essere sfruttata anche in ambienti che non utilizzano attivamente le dMSA, purché sia presente almeno un controller di dominio Windows Server 2025.

• Richiede solo permessi di scrittura su una dMSA, che possono essere concessi a utenti non privilegiati.

• Microsoft ha classificato il problema come di gravità moderata e non ha ancora rilasciato una patch ufficiale.

Per mitigare il rischio, è consigliabile:

• Limitare i permessi di creazione e modifica delle dMSA agli utenti strettamente necessari.

• Monitorare attentamente le modifiche agli attributi delle dMSA, in particolare msDS-ManagedAccountPrecededByLink.

• Utilizzare strumenti di auditing per rilevare attività sospette legate alle dMSA.

Conclusioni

Se vuoi approfondire come funzionano questi account e come gestirli in sicurezza, ti consiglio il nostro corso su Windows Server 2025: spieghiamo tutto con esempi pratici e scenari reali.