Jorge de Almeida Pinto

Risultati principali

  • BadSuccessor, una tecnica di escalation dei privilegi che sfrutta i Managed Service Accounts (dMSA) delegati, presenta un rischio elevato per le organizzazioni che utilizzano anche un solo controller di dominio (DC) di Windows Server 2025. La tecnica può essere utilizzata per impersonare qualsiasi account in Active Directory (AD), persino gli amministratori di dominio, l'account KRBTGT o qualsiasi altro account abilitato o disabilitato con privilegi elevati.
  • Jorge de Almeida Pinto, Senior Incident Response Lead di Semperis, ha scoperto un modo per bloccare completamente il caso d'uso della migrazione dMSA, impedendo di fatto agli aggressori di utilizzare in modo improprio un dMSA per impadronirsi potenzialmente di un dominio AD.
  • La soluzione è configurata nello schema AD e deve essere applicata a ogni foresta AD.
  • Questa mitigazione del rischio può essere implementata fino a quando Microsoft non avrà rilasciato una patch per mitigare la vulnerabilità.

Fino a Windows Server 2025, AD e Windows supportavano gli account di servizio gestito standalone (sMSA) e gli account di servizio gestito di gruppo (gMSA). Windows Server 2025 introduce un nuovo tipo di account di servizio gestito: gli account di servizio gestito delegati.

Questo nuovo tipo di account è progettato per migliorare la gestione delle credenziali degli account di servizio basati sull'utente, supportando la migrazione dall'account di servizio legacy a un dMSA.

I ricercatori di Akamai1 hanno scoperto che gli aggressori possono facilmente creare e configurare un dMSA, quindi abusarne per impersonare qualsiasi preside di sicurezza autenticabile in AD. Hanno chiamato la tecnica di attacco BadSuccessor.

In questo post del blog, forniamo un'introduzione dettagliata e informazioni per mitigare la vulnerabilità, compreso il codice PowerShell per implementare la soluzione suggerita per bloccare il caso d'uso della migrazione.

Perché è necessario bloccare BadSuccessor?

Se utilizzata come previsto, la migrazione dMSA supporta ufficialmente solo gli account di servizio legacy come origine (tipo di account user). Tuttavia, l'attacco BadSuccessor funziona con qualsiasi tipo di account autenticabile come origine, compresi gli account di computer, sMSA, gMSA e persino dMSA. Inoltre, non importa se l'account di origine è abilitato o disabilitato.

Gli unici componenti necessari per eseguire questo attacco sono:

  • Almeno un DC 2025 scrivibile
  • Un dMSA (vulnerabile) e l'attrezzatura corretta

Inoltre, non è necessario che l'attacco avvenga su Windows Server 2025.

Il nucleo dell'attacco BadSuccessor inizia con la capacità di creare un nuovo dMSA o di controllare un dMSA esistente. Pertanto, la delega del controllo di qualsiasi dominio AD esistente richiede una revisione e un'azione immediata.2

Dato il potenziale di compromissione completa del dominio AD, è necessario adottare misure per mitigare questo rischio non appena si introduce il primo DC scrivibile di Windows Server 2025, anche se non si utilizzano ancora i dMSA.

Come rilevare BadSuccessor: Indicatori di esposizione e compromissione

Microsoft non ha ancora fornito una patch per mitigare questa vulnerabilità. Semperis ha aggiunto capacità di rilevamento in Directory Services Protector DSP) per difendersi da BadSuccessor. La piattaforma DSP è stata potenziata con un nuovo indicatore di esposizione (IOE) e tre nuovi indicatori di compromissione (IOC) che consentono di rilevare e mitigare le attività dannose che coinvolgono i dMSA.

Quali sono i casi d'uso di dMSA?

Microsoft ha progettato il dMSA per un caso d'uso specifico e difficile da risolvere che molte organizzazioni hanno oggi. In pratica, un dMSA supporta due casi d'uso.

A causa dei molteplici casi d'uso, ogni dMSA ha uno stato che determina l'utilizzo del dMSA e che viene registrato nell'attributo msDS-DelegatedMSAState.

Gli stati supportati sono:

  • 0: Non utilizzato (questo stato è quello predefinito quando non è definito)
  • 1: Uso della migrazione avviato
  • 2: Utilizzo della migrazione completato
  • 3: Uso dei nativi

Un dMSA può essere utilizzato come un gMSA. In questo caso, lo stato del dMSA sarà 3, ovvero viene utilizzato in modo nativo.

Il dMSA è stato progettato per supportare la migrazione di un account di servizio legacy a un dMSA per una gestione delle credenziali migliore e potenziata, senza impattare sulla funzionalità di un servizio, un'applicazione o un'attività pianificata che utilizza l'account di servizio legacy. Una gestione delle credenziali migliore e migliorata significa tecnicamente una rotazione delle password più frequente e automatizzata, utilizzando una password più forte e molto complessa.

La migrazione dall'account di servizio legacy al dMSA viene avviata da un amministratore. Lo stato dell'account di servizio legacy e del dMSA cambia in 1-migrazione avviata. Una volta che l'amministratore ha completato la migrazione e lo stato sia dell'account di servizio legacy che del dMSA è cambiato in 2-migrazione completata: la configurazione specifica dell'account di servizio legacy viene migrata al dMSA. Tuttavia, le appartenenze ai gruppi dell'account di servizio legacy non vengono migrate al dMSA e rimangono con l'account di servizio legacy.

Durante il primo stato di migrazione, il sistema scopre automaticamente dove viene utilizzato l'account di servizio legacy e configura il dMSA di conseguenza. Nel secondo stato di migrazione, quando il sistema tenta di autenticarsi utilizzando l'account di servizio legacy (disattivato), il dMSA si occupa dell'autenticazione.

Quando il dMSA subentra nell'autenticazione, il controller di dominio Windows Server 2025 fonde il Certificato di attributo privilegiato (PAC) dell'account di servizio legacy e il PAC del dMSA in un unico PAC contenente tutte le appartenenze ai gruppi combinate e altri objectSID applicabili. Il dMSA eredita quindi tutti i diritti, le autorizzazioni e l'accesso dell'utente, in modo da poter sostituire l'account di servizio legacy senza alcun impatto sul servizio, sull'applicazione o sull'attività pianificata.

L'aspetto positivo: la successione di dMSA come previsto

Per la migrazione di un account di servizio legacy a un dMSA sono disponibili i seguenti cmdlet PowerShell.

CMDlet PowerShellAzione
Start-ADServiceAccountMigrationAvviare la migrazione dell'account di servizio legacy al dMSA. Questo stato passa da iniziale a avviato. Può essere eseguito solo quando lo stato è 0.
Complete-ADServiceAccountMigrationCompletare la migrazione dell'account di servizio legacy al dMSA. Passa da iniziato a completato. Può essere eseguito solo quando lo stato è 1.
Undo-ADServiceAccountMigrationAnnulla l'ultima fase della migrazione e torna alla fase precedente. Transizione da completato a iniziato o da iniziato a iniziale. Possono essere eseguite solo quando lo stato è 1 o 2.
Reset-ADServiceAccountMigrationRipristina la migrazione allo stato iniziale, annullando tutto. Transizione da completato o iniziato a iniziale. Può essere eseguita solo quando lo stato è 1 o 2.

A seconda del cmdlet PowerShell utilizzato, un attributo operativo con dati di input viene utilizzato contro il RootDSE di un DC scrivibile. In questo caso, vengono eseguite più azioni simultanee sia contro l'account del servizio legacy di destinazione che contro il dMSA di destinazione. I cmdlet PowerShell o l'attributo operativo possono essere utilizzati solo dai membri del gruppo Domain Admins.

Per una migliore comprensione delle funzioni di ciascun cmdlet PowerShell, ecco una descrizione più dettagliata delle azioni.

Quando si utilizza Start-ADServiceAccountMigrationIl sistema sta eseguendo le seguenti azioni:

  • Sull'account del servizio legacy:
    • Set msDS-SupersededServiceAccountState a 1
    • Set msDS-SupersededManagedAccountLink al DN del dMSA di destinazione
  • Sulla dMSA:
    • Set msDS-DelegatedMSAState a 1
    • Set msDS-ManagedAccountPrecededByLink al DN dell'account del servizio legacy mirato
    • Assegnare all'account del servizio legacy mirato le autorizzazioni di lettura su tutti gli attributi del dMSA mirato.
    • Assegnare le autorizzazioni di scrittura all'account del servizio legacy mirato sull'attributo msDS-GroupMSAMembership della dMSA mirata

Quando si utilizza Complete-ADServiceAccountMigrationIl sistema sta eseguendo le seguenti azioni:

  • Sull'account del servizio legacy:
    • Set msDS-SupersededServiceAccountState a 2
    • Disattivare l'account
  • Sulla dMSA:
    • Set msDS-DelegatedMSAState a 2
    • Rimuovere le autorizzazioni di lettura precedentemente assegnate all'account del servizio legacy in questione da tutti gli attributi del dMSA.
    • Rimuovere le autorizzazioni di scrittura precedentemente assegnate all'account del servizio legacy mirato dall'attributo msDS-GroupMSAMembership del dMSA
  • Dall'account di servizio legacy al dMSA, spostare le seguenti configurazioni:
    • Nomi principali di servizio (SPN)
    • Permesso di delegare all'elenco
    • Delegazione vincolata basata sulle risorse
    • Criterio di autenticazione assegnato
    • Silo di autenticazione assegnato
    • Autenticazione attendibile per la delega Bit UAC

Quando si utilizza Reset-ADServiceAccountMigration, tutte le azioni eseguite da Start-ADServiceAccountMigration o Complete-ADServiceAccountMigration vengono annullati e sia l'account di servizio legacy che il dMSA tornano allo stato iniziale.

Quando si utilizza Undo-ADServiceAccountMigration, tutte le azioni eseguite da Start-ADServiceAccountMigration o Complete-ADServiceAccountMigration vengono annullati e sia l'account del servizio legacy che il dMSA tornano allo stato precedente all'esecuzione di, rispettivamente, Start-ADServiceAccountMigration o Complete-ADServiceAccountMigration. Tecnicamente si tratta di una delle seguenti transizioni:

  • Da completato a iniziato
  • Da iniziato a iniziale

Il brutto e il cattivo: l'abuso di dMSA

Come hanno scoperto i ricercatori di Akamai, gli attributi dell'account del servizio legacy e del dMSA coinvolti nella migrazione non sono protetti dalle normali scritture LDAP. Chiunque abbia almeno il permesso di scrittura sugli attributi del dMSA, o qualsiasi altro permesso che possa portare a tale permesso, può scrivere i dati. Purtroppo, questa scappatoia invalida le protezioni implementate attraverso il cmdlet PowerShell e l'attributo operativo sotto il cofano.

Inoltre, in termini di convalida, l'autenticazione del DC scrivibile di Windows Server 2025 sembra considerare solo due attributi del dMSA e nulla dell'account di servizio legacy. Se il msDS-DelegatedMSAState della dMSA è impostato su 2 (e non importa nemmeno come sia arrivato a questo stato), il DC controllerà quale conto è specificato nel file msDS-ManagedAccountPrecededByLink attributo.

Con queste informazioni e supponendo che l'account richiedente (di solito un account del computer, ma può essere qualsiasi cosa) abbia le autorizzazioni per richiedere la password o le chiavi dal dMSA, il DC che autentica Windows Server 2025 scrivibile fonde il certificato di attributo privilegiato (PAC) dell'account di servizio legacy e del dMSA in un unico PAC. Il DC rilascia quindi il PAC unito in un TGS-REP all'account richiedente.

Il Distinguished Name (DN) dell'account nel file msDS-ManagedAccountPrecededByLink può essere qualsiasi cosa e BadSuccessor sfrutta appieno questa vulnerabilità..

L'uso del tiering amministrativo aiuta a nascondere e proteggere gli account ad alto privilegio (utenti, servizi, computer, sMSA, gMSA, dMSA). L'obiettivo è quello di "nascondere" gli account ad alto privilegio in modo che il loro DN non sia visibile a nessun account a basso privilegio. È anche importante notare che il DN degli account ad alto privilegio non deve essere facilmente indovinabile.

Questo attacco può diventare rapidamente un successo molto brutto.

If an attacker knows the DN of the default domain Administrator account (CN=administrator,CN=Users, DC=<DOMAIN>,DC=<TLD>) or the KRBTGT account (CN=krbtgt,CN=Users,DC=<DOMAIN>,DC=<TLD>), they can misuse the controlled dMSA to completely take over the AD domain, and ultimately the AD forest.

NOTA: L'account KRBTGT può essere spostato in un modello di tiering protetto e nascosto, ma Microsoft non consiglia di spostarlo.3

NOTA: L'account Amministratore può essere spostato in un modello di tiering protetto e nascosto. È anche possibile rinominarlo.4

Se si decide di spostare l'account Amministratore di dominio predefinito o l'account KRBTGT nella struttura di livellamento amministrativo, assicurarsi di inserire entrambi in una OU separata (cioè non combinata con altri account) e di garantire l'accesso a tale OU solo agli account di amministrazione di livello 0.

Come bloccare i successori

Osservando l'attuale funzionamento interno di un dMSA da parte di un "successore buono" e di un "successore brutto e cattivo", gli obiettivi della mia ricerca erano i seguenti:

  • R: Supporta tutti i casi d'uso descritti
  • B: Consentire e sostenere il buon successore
  • C: Bloccare il successore brutto e cattivo

Le normali scritture LDAP, come descritto per il successore brutto e cattivo, richiedono che l'attore abbia autorizzazioni specifiche su un dMSA. L'uso dei cmdlet PowerShell richiede che l'attore sia membro di Domain Admins.

Come ho notato in precedenza, i cmdlet PowerShell eseguono azioni diverse contro l'account di servizio legacy e il dMSA, sfruttando un attributo operativo con i dati di input.

Con queste premesse, ho rivisto lo schema di AD, in particolare la definizione dello schema del file msDS-ManagedAccountPrecededByLink perché controlla quale account viene migrato (ufficialmente) o attaccato (Figura 1).

Anche se l'attributo msDS-DelegatedMSAState gioca un ruolo importante, deve comunque essere gestito eseguendo una normale scrittura LDAP per poter impostare lo stato del dMSA su 3 quando lo si usa in modo nativo piuttosto che per scopi di migrazione.

Figura 1: La definizione dello schema AD originale dell'attributo msDS-ManagedAccountPrecededByLink con systemOnly impostato su FALSE

Osservando la definizione dell'attributo visualizzato, la mia intenzione era quella di bloccare le normali scritture LDAP e di supportare le scritture operative degli attributi. In quest'ottica, la proprietà systemOnly si è distinta, perché speravo che raggiungesse l'obiettivo della ricerca. Questo attributo non può essere modificato come qualsiasi altro attributo regolare. Una funzione del DC deve essere prima abilitata per supportare un'azione di scrittura speciale e poi nuovamente disabilitata. L'intento del blocco è quello di impedire la normale scrittura, pur consentendo la lettura.

Procediamo passo dopo passo.

Figura 2 mostra la verifica della configurazione di dMSA dMSA.weak.5 Il dMSA ha il suo stato iniziale e non è collegato a nessun conto (cioè non è visualizzato).

Figura 2: Visualizzazione della configurazione del dMSA: dMSA.weak

L'attaccante imposta lo stato di dMSA.weak a 2, configura un account collegato (l'amministratore di dominio predefinito, che è stato rinominato in questo AD in ADM.TEC) e si aggiunge come account autorizzato a recuperare le password/chiavi del dMSA6 (Figura 3). In questo caso, l'azione è possibile perché l'attaccante dispone di un account che è membro del gruppo legacy Account Operators.

Figura 3: Riconfigurazione dMSA.weak per uso improprio

Successivamente, si controlla la configurazione di dMSA.weak5 (Figura 4).

Figura 4: Visualizzazione della configurazione di dMSA.weak

Il dMSA ha ora lo stato di migrazione completata 2ha un account collegato e l'attaccante può recuperare le password/chiavi del dMSA. Utilizzando RUBEUS, ad esempio, l'attacco può essere avviato contro il dMSA e soprattutto contro l'account collegato.

Quindi, rimuoviamo la configurazione precedente6 e convalidiamo che sia stata effettivamente rimossa5(Figura 5 e Figura 6).

Figura 5: Rimozione della configurazione precedentemente impostata da dMSA.weak
Figura 6: Visualizzazione della configurazione di dMSA.weak

Ora è possibile visualizzare lo stato del blocco7(Figura 7).

Figura 7: Revisione dello stato del blocco sull'attributo (False indica che non è bloccato)

Successivamente, abilitiamo il blocco per lo scenario di migrazione8(Figura 8).

Figura 8: Abilitazione del blocco sull'attributo (True indica il blocco)

Anche in questo caso, la conferma si ottiene visualizzando lo stato del blocco7(Figura 9).

Figura 9: Revisione dello stato del blocco sull'attributo (True indica il blocco)

L'attaccante ora tenta nuovamente6 di:

  • Impostare lo stato di dMSA.weak a 2
  • Configurare un account collegato (ancora una volta l'amministratore di dominio predefinito rinominato)
  • Aggiungersi come account autorizzato a recuperare le password/chiavi del dMSA(Figura 10).

Ora, la transazione non viene completata perché l'attaccante non è autorizzato a scrivere il DN del conto collegato.
Obiettivo C raggiunto!

Figura 10: Tentativo di riconfigurazione dMSA.weak per uso improprio

Ora, controlliamo nuovamente la configurazione di dMSA.weak5 (Figura11).

Figura 11: Visualizzazione della configurazione di dMSA.weak

Poiché la transazione completa non è riuscita, non è stato modificato nulla. Se gli attributi fossero stati scritti singolarmente, tutti avrebbero avuto successo, tranne la scrittura sul file msDS-ManagedAccountPrecededByLink attributo. Non viene visualizzato nulla perché non ha un valore.

Con il blocco abilitato, anche l'utilizzo del metodo ufficiale per migrare un account di servizio legacy in un dMSA fallisce(Figura 12). Questo è un peccato. C'è comunque una luce alla fine del tunnel!

Il blocco serve a prevenire le scritture contro il file msDS-ManagedAccountPrecededByLink attributo. Se si esaminano i cmdlet PowerShell ufficiali per la migrazione, solo i cmdlet Start-ADServiceAccountMigration e Reset-ADServiceAccountMigration scrivere su quell'attributo. Il cmdlet Undo-ADServiceAccountMigration scrive su questo attributo anche quando annulla il passaggio da iniziato a iniziale. Nelle altre transizioni, non c'è alcuna scrittura necessaria o eseguita su questo attributo.

Obiettivi A e B: parzialmente raggiunti.

Figura 12: Avvio della migrazione ufficiale di un account di servizio legacy sVC.SQL ad un dMSA chiamato dMSA.SQL$

Successivamente, disabilitiamo il blocco per lo scenario di migrazione9(Figura 13).

Figura 13: Disabilitazione del blocco sull'attributo (False indica che non è bloccato)

Ora visualizziamo nuovamente lo stato del blocco7(Figura 14).

Figura 14: Revisione dello stato del blocco sull'attributo (False indica che non è bloccato)

Ora, quando l'attaccante tenta6 di:

  • Impostare lo stato di dMSA.weak a 2
  • Configurare un account collegato (ancora una volta l'amministratore di dominio predefinito rinominato)
  • Aggiungersi come account autorizzato a recuperare la password/le chiavi del dMSA

-sono riusciti perché ancora una volta il blocco è scomparso(Figura 15).

Figura 15: Riconfigurazione dMSA.weak per uso improprio

Ora, quando si controlla la configurazione di dMSA.weak5 (Figura 16), vediamo che l'attaccante ha lo stato di migrazione completata 2ha un account collegato al dMSA ed è autorizzato a recuperare le password/chiavi del dMSA.

Figura 16: Visualizzazione della configurazione di dMSA.weak

Con il blocco disattivato, è possibile utilizzare il metodo ufficiale per avviare, completare e ripristinare con successo la migrazione di un account di servizio legacy a un dMSA(Figura 17). In questo esempio, è stato utilizzato un altro account di servizio legacy e un dMSA e la migrazione è stata eseguita da un account Domain Admin.

Figura 17: Avvio, completamento e ripristino della migrazione dell'account di servizio legacy sVC.SQL a una dMSA denominata dMSA.SQL$

Il blocco di BadSuccessor richiede una gestione pratica

Con questa soluzione è possibile bloccare lo scenario di migrazione dMSA e quindi qualsiasi uso improprio.

Incoraggiamo comunque le organizzazioni a rivedere proattivamente il proprio modello di delega2 e ad agire di conseguenza per mitigare qualsiasi rischio. In questo contesto, la revisione si concentra sulla creazione e sulla gestione dei dMSA in qualsiasi dominio AD.

Le organizzazioni che desiderano effettuare l'aggiornamento a Windows Server 2025 AD o installare un nuovo Windows Server 2025 AD possono implementare questa soluzione per mitigare i rischi di un attacco fino a quando Microsoft non avrà rilasciato una patch.

L'implementazione del blocco nello scenario di migrazione avviene nello schema AD e la modifica è reversibile: È possibile impostare il blocco8 e, in una fase successiva, sbloccare il blocco7. Ciò significa che sono possibili più approcci di gestione.

L'organizzazione potrebbe implementare questo blocco perché non desidera utilizzare i dMSA per lo scenario di migrazione.

Se l'organizzazione desidera utilizzare i dMSA per lo scenario di migrazione, è comunque possibile implementare il blocco per proteggere AD. Ogni volta che si desidera avviare la migrazione di un account, è possibile rimuovere il blocco in anticipo e implementarlo nuovamente in seguito. È possibile completare la migrazione di un account con o senza il blocco.

Utilizzando questo approccio, è possibile raggiungere gli obiettivi A, B e C.

Anche se si implementa un blocco, gli IOE e gli IOC di Semperis DSP consentono di monitorare da vicino gli eventi di creazione, gestione e autenticazione di dMSA e le modifiche degli attributi.

Per saperne di più sui pericoli di un eccesso di privilegi in AD

Note finali

  1. BadSuccessor: Abuso di dMSA per l'escalation dei privilegi in Active Directory
  2. (2025-05-25) Rivedere il modello di delega prima di introdurre i DC W2K25 e migliorare la sicurezza (a causa di "BadSuccessor")
  3. Microsoft Learn: Attributi dell'account KRBTGT
  4. Microsoft Learn: Account amministratore
  5. Successore errato - VIEW DATA IN ATTRIBUTI "msDS-groupMSAMembership", "msDS-DelegatedMSAState", "msDS-ManagedAccountPrecededByLink".
  6. Successore errato - SCRIVERE DATI INTO ATTRIBUTI "msDS-groupMSAMembership", "msDS-DelegatedMSAState", "msDS-ManagedAccountPrecededByLink".
  7. Successore cattivo - VISUALIZZA LO STATO DEL BLOCCO
  8. Successore cattivo - BLOCCO DI AGGIUNTA/INCOLLAZIONE
  9. Successore cattivo - RIMUOVERE/DISABLICARE IL BLOCCO

DISCLAIMER

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.