BadSuccessor dMSA Privilege Escalation: come un utente con pochi privilegi diventa Domain Admin

BadSuccessor dMSA privilege escalation — battezzata BadSuccessor da Akamai — è una tecnica che abusa dei Delegated Managed Service Account (dMSA), una funzionalità introdotta in Windows Server 2025, per consentire a un utente con pochi privilegi di impersonare qualsiasi account del dominio, fino a Domain Admin. È stata documentata dal ricercatore Akamai Yuval Gordon nel maggio 2025 e le è stato assegnato l'identificativo CVE-2025-53779; Microsoft ha rilasciato una correzione nell'aggiornamento di sicurezza del 12 agosto 2025 (KB5064010).

Questo articolo spiega il meccanismo, perché colpisce una parte così ampia degli ambienti reali, e come rilevarlo e correggerlo — incluso cosa ha effettivamente cambiato la patch e cosa dice la ricerca pubblica su cosa vale ancora la pena monitorare in seguito.

Per percorsi di escalation Active Directory correlati, vedi Delega Kerberos non vincolata: dall'abuso al RBCD e Abuso ACL e DCSync: i percorsi silenziosi verso Domain Admin. BadSuccessor è un meccanismo distinto da entrambi — non tocca l'ACL né le impostazioni di delega di un account esistente; abusa dei diritti di creazione di oggetti su una OU per fabbricarne uno nuovo. Condivide anche un'aria di famiglia con Shadow Credentials: abuso di msDS-KeyCredentialLink in Active Directory — entrambe le tecniche scalano i privilegi scrivendo in un attributo di collegamento dell'identità anziché craccando una credenziale.

Cos'è BadSuccessor dMSA Privilege Escalation?

I Delegated Managed Service Account (dMSA) sono una funzionalità di Windows Server 2025 progettata per consentire alle organizzazioni di migrare i vecchi account di servizio verso un modello di identità gestito e senza password, senza dover riconfigurare ogni dipendenza. Parte di questo design di migrazione include un meccanismo di "successione": un dMSA può essere collegato a un account più vecchio che è destinato a sostituire, e Active Directory trasferisce parte dell'accesso di quell'account durante la transizione.

Perché esiste il dMSA

Microsoft ha progettato il dMSA per risolvere un problema operativo reale: i vecchi account di servizio autonomi spesso portano password statiche, raramente ruotate, e privilegi ampi e permanenti, perché migrare verso un modello di identità gestito tradizionalmente significava riconfigurare ogni applicazione dipendente. Il modello di successione del dMSA — collegare il nuovo account gestito a quello vecchio che sostituisce — mirava a rendere questa migrazione quasi trasparente. BadSuccessor abusa della fiducia integrata in quella trasparenza, non di un bug nella gestione delle password in sé.

Il meccanismo di BadSuccessor

Secondo la ricerca originale di Akamai (confermata da Unit 42, Semperis e Tarlogic), l'attacco abusa di due attributi dMSA di cui il KDC si fida senza verifica incrociata durante la "migrazione" che rappresentano:

• msDS-ManagedAccountPrecededByLink — un collegamento (DN, distinguished name) all'account che il dMSA è destinato a "succedere". La ricerca pubblica descrive il KDC pre-patch come colui che costruisce il PAC (Privilege Attribute Certificate) dell'account a partire da qualsiasi DN presente in questo campo, senza verificare che esista una vera relazione di migrazione.
• msDS-DelegatedMSAState — lo stato di migrazione (0 = nessuno, 1 = in corso, 2 = completato).

Passo dopo passo: come funzionava l'attacco pre-patch

1. L'attaccante identifica una OU o un contenitore dove possiede diritti CreateChild — secondo i test di Akamai, un permesso al tempo stesso comune e raramente controllato nel dettaglio.
2. L'attaccante crea un nuovo oggetto dMSA in quella OU.
3. L'attaccante scrive il DN dell'account target (ad esempio, un Domain Admin) in msDS-ManagedAccountPrecededByLink.
4. L'attaccante imposta msDS-DelegatedMSAState a 2 ("completato"), segnando la migrazione fabbricata come conclusa.
5. La ricerca pubblica descrive che il KDC pre-patch trattava quindi ogni autenticazione successiva come dMSA come se fosse una continuazione dell'identità dell'account target — costruendo il PAC con i SID e le appartenenze ai gruppi del target, senza che l'account target venisse mai modificato.

I test di Akamai hanno riportato che il 91% degli ambienti esaminati aveva almeno un utente non amministratore con permessi sufficienti per portare a termine questo attacco, in gran parte perché la delega CreateChild a livello di OU è comune e raramente controllata nel dettaglio.

Impatto della patch di agosto 2025

L'aggiornamento del 12 agosto 2025 di Microsoft (KB5064010, CVE-2025-53779) ha cambiato il modo in cui kdcsvc.dll convalida la relazione di successione: l'emissione dei ticket ora richiede che il collegamento rifletta un accoppiamento reciproco genuino, invece di accettare una scrittura unidirezionale su msDS-ManagedAccountPrecededByLink. Il semplice fatto di puntare un dMSA appena creato verso un account privilegiato, come descritto sopra, non produce più un ticket di impersonificazione dopo l'aggiornamento.

La valutazione di gravità di Microsoft

MSRC ha inizialmente valutato il problema segnalato come non conforme alla soglia per una correzione immediata e lo ha classificato come di gravità moderata quando Akamai lo ha segnalato per la prima volta; è stato rilasciato come correzione ordinaria nel ciclo di Patch Tuesday di agosto 2025, anziché come pubblicazione fuori banda. La valutazione attuale di Microsoft giudica lo sfruttamento "meno probabile", e i rapporti pubblici non descrivono, alla data di pubblicazione, alcuno sfruttamento confermato in the wild.

Cosa dice la ricerca sulla patch

La ricerca di follow-up di Akamai stessa ("BadSuccessor Is Dead, Long Live BadSuccessor(?)") e un successivo articolo della community pubblicato da AlteredSecurity ("BetterSuccessor") descrivono entrambi la patch come la chiusura del percorso diretto a collegamento unidirezionale, notando al contempo che la ricerca sull'abuso dei dMSA è proseguita in scenari più circoscritti. Questo articolo non riproduce quelle tecniche derivate; considera la patch come una chiusura sostanziale — non necessariamente completa — del percorso BadSuccessor originale, e dai priorità ai passaggi di rilevamento e irrigidimento della delega descritti di seguito, indipendentemente dallo stato della patch.

Perché è così diffuso

BadSuccessor è insolita tra le tecniche di escalation dei privilegi AD perché non richiede una configurazione errata nel senso tradizionale. Funziona contro il modello di permessi predefinito del dMSA non appena esiste un DC Windows Server 2025 nel dominio. L'esposizione reale deriva da quanto ampiamente i diritti CreateChild su OU e contenitori vengono delegati negli ambienti reali — spesso a team di help desk, team applicativi, o deleghe ereditate mai riesaminate. La ricerca pubblica di Semperis e Unit 42 punta entrambe alla stessa causa radice: pratiche di delega di OU e di radice del dominio più ampie del previsto, non una singola patch mancante.

Questo si collega direttamente a uno schema trattato in Percorsi di attacco AD: come si concatenano le configurazioni errate: le esposizioni più pericolose quasi mai sono un singolo bug critico — sono deleghe e permessi accumulati che nessuno ha riesaminato da quando sono stati impostati.

Rilevamento

Correzione — passaggi concreti

1. Applica prima la patch

Applica l'aggiornamento di sicurezza del 12 agosto 2025 (KB5064010 / CVE-2025-53779) su ogni controller di dominio Windows Server 2025.

2. Controlla e limita la delega CreateChild

Rivedi i permessi di OU e della radice del dominio per account e gruppi che possono creare oggetti — in particolare oggetti msDS-DelegatedManagedServiceAccount — e rimuovi le deleghe non attivamente necessarie. Questo è il controllo che determina se il percorso di attacco esiste, indipendentemente dallo stato della patch.

3. Abilita l'audit basato su SACL

Configura l'audit per la creazione di oggetti dMSA (ID evento 5137) e per le modifiche a msDS-ManagedAccountPrecededByLink / msDS-DelegatedMSAState (ID evento 5136), e genera avvisi per qualsiasi modifica di questo tipo effettuata da un account non privilegiato.

4. Inventaria i dMSA esistenti

Conferma che ogni dMSA del dominio corrisponda a una migrazione legittima e prevista, e rivedi il valore di msDS-ManagedAccountPrecededByLink per ciascuno.

# Inventariare tutti gli oggetti dMSA e il loro collegamento di successione, per revisione manuale
Get-ADServiceAccount -Filter "ObjectClass -eq 'msDS-DelegatedManagedServiceAccount'" -Properties msDS-ManagedAccountPrecededByLink, msDS-DelegatedMSAState |
  Select-Object Name, msDS-ManagedAccountPrecededByLink, msDS-DelegatedMSAState

Come EtcSec rileva questo

Il catalogo delle vulnerabilità AD di EtcSec include un controllo dedicato, BADSUCCESSOR_DMSA_ESCALATION, che segnala questo rischio di escalation tramite dMSA. Poiché l'esposizione radice è l'ampiezza della delega piuttosto che un singolo oggetto mal configurato, EtcSec segnala anche i risultati DELEGATION_PRIVILEGE — deleghe ampie a livello di OU o di radice del dominio — come la condizione sottostante che rende BadSuccessor praticabile in un determinato ambiente, indipendentemente dalla presenza o meno di un DC Windows Server 2025. I team che già monitorano la deriva degli accessi privilegiati con Deriva degli accessi privilegiati in Active Directory: come i diritti di amministratore ritornano dopo gli audit stanno osservando lo stesso problema di fondo — una delega mai riesaminata — da un'angolazione diversa.

Riferimenti principali

• Akamai: BadSuccessor — Abusing dMSA to Escalate Privileges in Active Directory
• Akamai: BadSuccessor Is Dead, Long Live BadSuccessor(?)
• Microsoft Security Update Guide: CVE-2025-53779
• NVD: CVE-2025-53779
• Help Net Security: Microsoft fixes "BadSuccessor" Kerberos vulnerability (CVE-2025-53779)
• Unit 42 (Palo Alto Networks): When Good Accounts Go Bad — Exploiting Delegated Managed Service Accounts in Active Directory
• Semperis: BadSuccessor — How to Detect and Mitigate dMSA Privilege Escalation
• Tarlogic: BadSuccessor — Escalating Privilege Using dMSA Abuse in Active Directory
• AlteredSecurity: BetterSuccessor — Still Abusing dMSA for Privilege Escalation (BadSuccessor After Patch)