Sommario
Analisi riassuntiva
- Per valutarne l'efficacia, i ricercatori di Akamai hanno analizzato la patch di Microsoft alla ricerca della vulnerabilità nota come BadSuccessor (CVE-2025-53779).
- Abbiamo concluso che, sebbene la patch fosse efficace nel mitigare una parte significativa del rischio associato a BadSuccessor, la tecnica continua a rimanere efficace e rilevante in alcuni scenari.
- In questo post del blog, vengono descritte due tecniche che si basano sugli stessi principi di BadSuccessor e che possono consentire ai criminali di eseguire il dumping delle credenziali e di compromettere gli account utente.
In occasione della DEF CON 2025, abbiamo presentato la storia di BadSuccessor, una vulnerabilità di Active Directory (AD) che consente di violare il nuovo tipo di account di Windows Server 2025: dMSA (delegated Managed Service Account). La vulnerabilità consente a un utente con privilegi ridotti di passare direttamente al ruolo di amministratore di dominio
Meno di una settimana dopo, Microsoft ha assegnato l'ID CVE-2025-53779 alla vulnerabilità e ha inviato una patch. Il percorso di escalation diretta è chiuso.
In questo post del blog, analizzeremo la patch, spiegheremo cosa è cambiato, cosa non è stato fatto e dimostreremo che, mentre BadSuccessor non fornisce più una funzione di escalation immediata, i suoi meccanismi di base sono ancora importanti.
Per la storia di origine, leggete il nostro post del blog precedente su BadSuccessor.
Descrizione di BadSuccessor (pre-patch)
BadSuccessor ha violato il dMSA, un tipo di account di Windows Server 2025 concepito per semplificare la gestione degli account di servizio. Quando un dMSA controllato è stato collegato a un account in AD, il KDC (Key Distribution Center) considerava il dMSA come successore durante l'autenticazione.
Questo collegamento singolo ha eseguito contemporaneamente due operazioni pericolose: ha unito i privilegi effettivi dell'account di destinazione nel certificato PAC (Privilege Attribute Certificate) del dMSA e ha restituito un pacchetto di chiavi dMSA che includeva le chiavi Kerberos della destinazione (credenziali). Nessuna modifica ai gruppi né strumenti specializzati: solo un semplice collegamento e le utilità di Windows integrate.
Purtroppo, lo standard era basso, quindi per sferrare un attacco era sufficiente assumere il controllo su qualsiasi unità organizzativa (OU). A questo punto, un criminale può creare un dMSA e collegarlo a qualsiasi destinazione, persino a responsabili e amministratori di dominio, utenti protetti o account contrassegnati come sensibili che non possono essere delegati, per poi violarla immediatamente.
Per un approfondimento e per guardare una demo, consultate il nostro post del blog precedente su BadSuccessor.
La patch di Microsoft per la CVE-2025-53779
Prima della patch, la nostra ipotesi era semplice: il bug principale consisteva nel fatto che non era necessario eseguire una migrazione reale tramite l'operazione rootDSE migrateADServiceAccount, ma era sufficiente modificare gli attributi del collegamento su un dMSA per farli accettare dal KDC.
Ci aspettavamo che Microsoft proteggesse tale attributo in modo da poterlo impostare solo tramite il percorso di migrazione corretto, impedendo di eseguire migrazioni "simulate".
Dopo aver installato la patch, abbiamo provato il test più ovvio: con il ruolo di utente che controlla un dMSA, ho scritto l'attributo del collegamento esattamente come prima. Sono comunque riuscito a scriverlo perché non esisteva nessuna nuova protezione dell'attributo e potevo collegare un dMSA a qualsiasi account. Tuttavia, quando ho effettuato l'autenticazione come dMSA per "ereditare" i privilegi e le chiavi del sistema preso di mira, il KDC si è rifiutato di emettere un ticket (Figura).
The error when authenticating a dMSA with a one-sided link — failure occurs at ticket issuance
Allora, siamo passati ad esaminare il KDC stesso. Le modifiche apportate al file kdcsvc.dll forzano il KDC a verificare la relazione al momento di emettere un ticket. Un unico collegamento dal dMSA al sistema preso di mira non funziona più.
Nel nostro test, l'unico modo per ottenere un ticket valido per un dMSA collegato a un altro account dopo la patch è stato quello di creare il collegamento reciproco, ossia anche la destinazione deve fare riferimento al dMSA, riflettendo ciò che produce una migrazione reale. Quindi, a differenza di prima, per la riuscita dell'operazione ora è richiesto il controllo dell'oggetto dell'account stesso, non solo del dMSA.
Ciò significa che l'applicazione delle patch è stata implementata nella verifica del KDC, non nelle protezioni lato directory sull'attributo. L'attributo può ancora essere scritto, ma non sarà accettato dal KDC a meno che l'associazione non sembri una migrazione legittima.
Un altro aspetto interessante è che la migrazione funziona ancora anche se l'account di destinazione rimane abilitato (mentre il flusso di migrazione formale lo disabilita al momento del completamento).
Descrizione di BadSuccessor (post-patch)
Anche se la vulnerabilità può essere corretta con una patch, BadSuccessor continua a rimanere una tecnica, ovvero, la verifica del KDC rimuove il percorso di escalation pre-patch, ma non risolve completamente il problema.
Poiché la patch non ha introdotto alcuna protezione per l'attributo del collegamento, un criminale può comunque ereditare un altro account collegando un dMSA controllato e un account di destinazione.
Questo aspetto consente (almeno) due pratiche primitive che gli addetti alla sicurezza dovrebbero aspettarsi e monitorare:
- Acquisizione di credenziali e privilegi
- Salvataggio delle credenziali del sistema preso di mira nei domini proprietari
Primitiva 1: acquisizione di credenziali e privilegi (credenziali ombra alternative)
Oggi, se un criminale controlla le credenziali principali del sistema preso di mira (ad esempio, il controllo GenericWrite su un utente o un computer), può violarle aggiungendo una credenziale ombra o eseguendo un attacco Kerberoasting mirato.
BadSuccessor apre un nuovo percorso di attacco: se un criminale controlla un dMSA, può eseguire un'associazione reciproca e richiedere un ticket per il dMSA allo scopo di:
- Agire con i privilegi effettivi del sistema preso di mira utilizzando l'identità dMSA (utile se l'account di destinazione viene monitorato attentamente)
- Ottenere le chiavi del sistema preso di mira dal pacchetto di chiavi dMSA, che è un modo più veloce e affidabile che non l'aggiunta di un SPN e un attacco Kerberoasting (in modalità solo utente, vulnerabile e meno tranquillo)
- Spostare la telemetria in modo che l'attacco generi solo i registri sulle↔modifiche dei collegamenti al sistema preso di mira e sull'emissione di un TGT (Ticket Granting Ticket) per il dMSA
Primitiva 2: dumping di credenziali mirate in domini proprietari (DCSync alternativa)
In un dominio già compromesso, BadSuccessor offre un modo per eseguire il dumping delle chiavi delle credenziali principali attraverso la normale emissione del ticket. Non si tratta di una sostituzione di DCSync, ma di un percorso diverso con segnali diversi che potrebbero eludere i rilevamenti esistenti.
Come rilevare una violazione di BadSuccessor dopo la patch
BadSuccessor può ancora essere sfruttato tramite due primitive diverse dopo l'emissione della patch di Microsoft. Per rilevare una potenziale attività, provare con:
- Elenchi di controllo degli accessi (ACL) del sistema: verificare la creazione del dMSA e le modifiche agli attributi del collegamento di migrazione su entrambi i lati: il collegamento del dMSA e il collegamento dell'account precedente/sostituito
- Informazioni comportamentali:
- voci di registro ripetute a indicare che è stata recuperata una password dMSA in un breve intervallo di tempo
- Un utente abilitato che sembra essere collegato a un dMSA (comportamento insolito)
- Un utente precedentemente disabilitato che viene collegato a un nuovo dMSA
Per indicazioni più dettagliate sul rilevamento, leggete il nostro post del blog precedente su BadSuccessor.
Mitigazione
- Applicare prima la patch. Aggiornare i controller di dominio di Windows Server 2025 per la CVE-2025-53779.
- Ridurre la superficie di attacco. Rivedere le autorizzazioni sulle OU, sui container e sugli stessi oggetti del dMSA. Rafforzare le deleghe e rimuovere i diritti più ampi in modo che solo gli amministratori di livello 0 possano creare o modificare i dMSA e i relativi attributi del collegamento di migrazione.
Conclusione
Microsoft ha chiuso il percorso di escalation diretta richiedendo un'associazione reciproca che sembra una migrazione reale; un collegamento unilaterale non comporta più privilegi o chiavi. Tuttavia, BadSuccessor è da sempre più di un semplice bug, è una tecnica. Si tratta di un problema in crescita nel settore: anche se viene risolta una vulnerabilità principale, i criminali possono sempre accedere in modo alternativo.
BadSuccessor persiste dopo la patch come (1) credenziale e privilegio di acquisizione primitivo quando un criminale controlla le credenziali principali del sistema preso di mira e un dMSA, e come (2) percorso privo di replica per eseguire il dumping dei segreti nei domini proprietari.
Questi risultati non sono nuovi: esistono altri modi per raggiungere queste due condizioni, che, tuttavia, sono dotati di requisiti e telemetria diversi: ecco perché un criminale potrebbe preferire BadSuccessor.
Nota finale
Una breve nota sullo stesso dMSA: a mio avviso, il dMSA post-patch rappresenta un'importante aggiunta alla sicurezza di AD perché, se utilizzato nel modo previsto, migliora la protezione degli account di servizio e riduce il numero di segreti di lunga durata. In un post di blog di follow-up, condividerò ulteriori informazioni sul dMSA e perché penso che si tratti di un'ottima aggiunta. Ci sentiamo presto!
Tag
