Come recuperare da un attacco Golden gMSA

Questo articolo descrive un approccio per ripristinare le credenziali di un account del servizio gestito di gruppo interessato da un evento imprevisto di esposizione al database del controller di dominio.

              Si applica a: Windows Server 2022, Windows Server 2019, Windows Server 2016, Windows Server 2012 R2, Windows Server 2012

Sintomi

Per una descrizione di un attacco Golden gMSA, vedere l'articolo Semperis seguente:

Introduzione all'attacco Golden GMSA

La descrizione nell'articolo precedente è accurata. L'approccio per risolvere il problema consiste nel sostituire l'oggetto chiave radice del servizio di distribuzione delle chiavi microsoft (kdssvc.dll, noto anche come KDS) e tutti i GMSA che usano l'oggetto chiave radice KDS compromesso.

Ulteriori informazioni

In un attacco riuscito a un gMSA, l'utente malintenzionato ottiene tutti gli attributi importanti dell'oggetto Chiave radice KDS e gli Sid attributi e msds-ManagedPasswordID di un oggetto gMSA.

L'attributo msds-ManagedPasswordID è presente solo in una copia scrivibile del dominio. Pertanto, se il database di un controller di dominio è esposto, solo il dominio ospitato dal controller di dominio è aperto all'attacco Golden gMSA. Tuttavia, se l'utente malintenzionato può eseguire l'autenticazione a un controller di dominio di un dominio diverso nella foresta, l'utente malintenzionato potrebbe avere autorizzazioni sufficienti per ottenere il contenuto di msds-ManagedPasswordID. L'utente malintenzionato potrebbe quindi usare queste informazioni per creare un attacco contro gMSA in domini aggiuntivi.

Per proteggere altri domini della foresta dopo l'esposizione di un dominio, è necessario sostituire tutti i GMSA nel dominio esposto prima che l'utente malintenzionato possa usare le informazioni. In genere, non si conoscono i dettagli di ciò che è stato esposto. Di conseguenza, è consigliabile applicare la risoluzione a tutti i domini della foresta.

Come misura proattiva, il controllo può essere usato per tenere traccia dell'esposizione dell'oggetto Chiave radice KDS. Un elenco di controllo di accesso di sistema (SACL) con letture riuscite può essere inserito nel contenitore Chiavi radice master, che consente il controllo delle letture riuscite sull'attributo msKds-RootKeyData della msKds-ProvRootKey classe. Questa azione determina il panorama di esposizione dell'oggetto per quanto riguarda un attacco Golden gMSA.

Nota

Il controllo consente solo di rilevare un attacco online ai dati della chiave radice KDS.

È possibile impostare il ManagedPasswordIntervalInDays parametro su 15 giorni o scegliere un valore appropriato durante la creazione di un account del servizio gestito di gruppo, in quanto il ManagedPasswordIntervalInDays valore diventa di sola lettura dopo la creazione di un account del servizio gestito del gruppo.

In caso di compromissione, questa impostazione può ridurre il tempo di rotazione successivo.

Ridurrà il numero teorico di gMSA da ricreare tra la data del backup ripristinato e la fine dell'esposizione del database o, almeno, la durata della finestra di rischio fino al rollback di questi GMSA, se si usa lo scenario 1.

Ecco uno scenario di esempio:

1. Dopo l'esposizione di un database, si esegue il ripristino in "Giorno D".

2. Il backup ripristinato è da D-15.

   Nota

   D-15 indica il giorno che è 15 giorni prima di "Giorno D".

3. Il valore gMSA ManagedPasswordIntervalInDays è 15.

4. Esistono gMSA e hanno eseguito il rollback di D-1.

5. Sono stati creati gMSA più recenti da D-10.

6. La compromissione si verifica in D-5 e alcuni GMSA sono stati creati in questa data.

Ecco i risultati:

1. GMSA creati tra D e D-5 non sono interessati^*.

2. È necessario ricreare gMSA creati tra D-15 (backup ripristinato) e D-5 (compromissione)^* o le finestre di rischio devono essere considerate se è possibile attendere da D+5 fino a D+10. Ad esempio:

   • In D+5 è necessario ricreare gMSA creati in D-10.
   • In D+10 è necessario ricreare gMSA creati in D-5.

   ^*Dipende dall'ora esatta di compromissione o backup.

Ecco una sequenza temporale di esempio:

Per il debug, è possibile esaminare gli ID evento per il registro eventi System, Security, Directory Services e Security-Netlogon.

Per altre informazioni su una compromissione, vedere Usare le risorse di sicurezza di Microsoft e Azure per consentire il ripristino da una compromissione dell'identità sistemica.

Risoluzione

Per risolvere questo problema, usare uno degli approcci seguenti, a seconda della situazione. Gli approcci prevedono la creazione di un nuovo oggetto Chiave radice KDS e il riavvio del servizio di distribuzione delle chiavi Microsoft in tutti i controller di dominio del dominio.

Scenario 1: si dispone di informazioni affidabili su quali informazioni sono state esposte e quando

Se si sa che l'esposizione si è verificata prima di una determinata data e questa data è precedente alla password gMSA meno recente disponibile, è possibile risolvere il problema senza ricreare gli account del servizio gestito del gruppo, come illustrato nella procedura seguente.

L'approccio consiste nel creare un nuovo oggetto chiave radice KDS sconosciuto all'utente malintenzionato. Quando gli account del servizio gestito di gruppo eseguono il rollback della password, passeranno all'uso del nuovo oggetto Chiave radice KDS. Per correggere gli account del servizio gestito che hanno recentemente eseguito il rollback della password usando la chiave radice KDS precedente, è necessario un ripristino autorevole per forzare un aggiornamento della password immediatamente dopo il ripristino.

Nota

• Non è necessario ripristinare manualmente gli account del servizio gestito creati dopo la fine dell'esposizione del database Active Directory Domain Services (AD DS). L'utente malintenzionato non conosce i dettagli di questi account e le password per questi account verranno rigenerate in base al nuovo oggetto Chiave radice KDS.
• È consigliabile considerare l'oggetto gMSA in "modalità di manutenzione" fino al completamento della procedura e ignorare i possibili errori segnalati con gli account nel registro eventi System, Security, Directory Services e Security-Netlogon.
• La guida presuppone che gli account del servizio gestito siano oggetti figlio del contenitore Account del servizio gestito . Se gli account sono stati spostati in contenitori padre personalizzati, è necessario eseguire i passaggi correlati al contenitore Account del servizio gestito in gMSA in questi contenitori.
• Un ripristino autorevole esegue il rollback di tutti gli attributi allo stato in cui si trovava al momento del backup, inclusi gli account autorizzati a recuperare le credenziali gMSA (PrincipalsAllowedToRetrieveManagedPassword).

Nel dominio che contiene gli account del servizio gestito di gruppo che si desidera ripristinare, seguire questa procedura:

1. Portare offline un controller di dominio e isolarlo dalla rete.

2. Ripristinare il controller di dominio da un backup creato prima dell'esposizione del database di Active Directory Domain Services.

   Se l'intervallo di password per gli account del servizio gestito del servizio gestito è più lungo dell'età del backup, è possibile decidere di tollerare la finestra in cui funziona ancora il materiale della chiave precedente. Se non è possibile attendere così a lungo e il backup precedente corrispondente non è presente un numero eccessivo di GMSA, è necessario passare allo scenario 2.

3. Eseguire un'operazione di ripristino autorevole nel contenitore Account del servizio gestito del dominio. Assicurarsi che l'operazione di ripristino includa tutti gli oggetti figlio dei contenitori che potrebbero essere associati a questo controller di dominio. Questo passaggio esegue il rollback dello stato dell'ultimo aggiornamento della password. La volta successiva in cui un servizio recupera la password, la password verrà aggiornata a una nuova in base al nuovo oggetto Chiave radice KDS.

4. Arrestare e disabilitare il servizio di distribuzione delle chiavi Microsoft nel controller di dominio ripristinato.

5. In un controller di dominio diverso seguire la procedura descritta in Creare la chiave radice KDS di Servizi di distribuzione chiavi per creare un nuovo oggetto Chiave radice KDS.

   Nota

   Nell'ambiente di produzione è necessario attendere 10 ore per assicurarsi che sia disponibile la nuova chiave radice KDS. Controllare l'attributo EffectiveTime per sapere quando la nuova chiave radice KDS sarà utilizzabile.

6. Riavviare il servizio di distribuzione delle chiavi Microsoft in tutti i controller di dominio.

7. Creare un nuovo gMSA. Assicurarsi che il nuovo gMSA usi il nuovo oggetto Chiave radice KDS per creare il valore per l'attributo msds-ManagedPasswordID .

   Nota

   Questo passaggio è facoltativo, ma consente di verificare che la nuova chiave radice KDS sia attualmente in uso e usata nel servizio di distribuzione chiavi Microsoft.

8. Controllare il msds-ManagedPasswordID valore del primo gMSA creato. Il valore di questo attributo è costituito da dati binari che includono il GUID dell'oggetto chiave radice KDS corrispondente.

   Si supponga, ad esempio, che l'oggetto Chiave radice KDS abbia il codice seguente CN.

   

   Un account del servizio gestito di gruppo creato usando questo oggetto ha un msds-ManagedPasswordID valore simile al seguente.

   

   In questo valore, i dati GUID iniziano dall'offset 24. Le parti del GUID si trovano in una sequenza diversa. In questa immagine le sezioni rosso, verde e blu identificano le parti riordinate. La sezione arancione identifica la parte della sequenza che corrisponde al GUID originale.

   Se il primo gMSA creato usa la nuova chiave radice KDS, anche tutti gli account del servizio gestito successivi usano la nuova chiave.

9. Disabilitare e arrestare il servizio di distribuzione delle chiavi Microsoft in tutti i controller di dominio.

10. Riconnettersi e riportare online il controller di dominio ripristinato. Assicurarsi che la replica funzioni.

    A questo momento, vengono replicati il ripristino autorevole e tutte le altre modifiche,inclusi gli account del servizio gestito ripristinati.

11. Riabilitare e avviare il servizio di distribuzione delle chiavi Microsoft in tutti i controller di dominio. I segreti dei GMSA ripristinati verranno rollforati e le nuove password verranno create in base al nuovo oggetto Chiave radice KDS su richiesta.

    Nota

    Se gli account del servizio gestito di gruppo vengono ripristinati ma non usati e il PrincipalsAllowedToRetrieveManagedPassword parametro è popolato, è possibile eseguire il Test-ADServiceAccount cmdlet nell'account del servizio gestito del gruppo ripristinato usando un'entità che può recuperare la password. Se è necessaria una modifica della password, questo cmdlet eseguirà il rollback degli account del servizio gestito di gruppo nella nuova chiave radice KDS.

12. Verificare che sia stato eseguito il rollback di tutti i GMSA.

    Nota

    L'account del servizio gestito di gruppo senza il parametro popolato non eseguirà mai il PrincipalsAllowedToRetrieveManagedPassword rollback.

13. Eliminare l'oggetto chiave radice KDS precedente e verificare le repliche.

14. Riavviare il servizio di distribuzione delle chiavi Microsoft in tutti i controller di dominio.

Scenario 2: non si conoscono i dettagli dell'esposizione dell'oggetto chiave radice KDS e non è possibile attendere il rollback delle password

Se non si sa quali informazioni sono state esposte o quando sono state esposte, tale esposizione potrebbe far parte di un'esposizione completa della foresta di Active Directory. Ciò può creare una situazione in cui l'utente malintenzionato può eseguire attacchi offline su tutte le password. In questo caso, è consigliabile eseguire un ripristino della foresta o reimpostare tutte le password dell'account. Il ripristino degli account del servizio gestito di gruppo in uno stato pulito fa parte di questa attività.

Durante il processo seguente, è necessario creare un nuovo oggetto Chiave radice KDS. Usare quindi questo oggetto per sostituire tutti i GMSA nei domini della foresta che usano l'oggetto chiave radice KDS esposto.

Nota

I passaggi seguenti sono simili alla procedura descritta in Introduzione con account del servizio gestito del gruppo. Tuttavia, ci sono alcune modifiche importanti.

attenersi alla seguente procedura:

1. Disabilitare tutti gli account del servizio gestito esistenti e contrassegnarli come account da rimuovere. A tale scopo, per ogni account impostare l'attributo userAccountControl su 4098 (questo valore combina i flag WORKSTATION_TRUST_ACCOUNT e ACCOUNTDISABLE (disabilitato ).

   È possibile usare uno script di PowerShell simile al seguente per impostare gli account:

    $Domain = (Get-ADDomain).DistinguishedName
    $DomainGMSAs = (Get-ADObject -Searchbase "$Domain" -LdapFilter 'objectclass=msDS-GroupManagedServiceAccount').DistinguishedName
    ForEach ($GMSA In $DomainGMSAs)
    {
        Set-ADObject "$GMSA" -Add @{ adminDescription='cleanup-gsma' } -Replace @{ userAccountControl=4098 }
    }
   

2. Usare un singolo controller di dominio e seguire questa procedura:

   1. Seguire la procedura descritta in Creare la chiave radice KDS dei servizi di distribuzione delle chiavi per creare un nuovo oggetto Chiave radice KDS.

   2. Riavviare il servizio di distribuzione delle chiavi Microsoft. Dopo il riavvio, il servizio preleva il nuovo oggetto.

   3. Eseguire il backup dei nomi host DNS e dei nomi di entità servizio (SPN) associati a ogni account del servizio gestito del servizio gestito contrassegnato per la rimozione.

   4. Modificare gli account del servizio gestito esistenti per rimuovere i nomi spn e host DNS.

   5. Creare nuovi gMSA per sostituire gli account del servizio gestito esistenti. Devono anche essere configurati con i nomi host DNS e i nomi SPN appena rimossi.

      Nota

      È anche necessario esaminare tutte le voci di autorizzazione usando i SID gMSA rimossi direttamente, in quanto non sono più risolvibili. Quando si sostituisce una voce di controllo di accesso, è consigliabile usare i gruppi per gestire le voci di autorizzazione gMSA.

3. Controllare i nuovi GMSA per assicurarsi che usino il nuovo oggetto Chiave radice KDS. A tal fine, attenersi alla seguente procedura:

   1. Si noti il CN valore (GUID) dell'oggetto Chiave radice KDS.

   2. Controllare il msds-ManagedPasswordID valore del primo gMSA creato. Il valore di questo attributo è costituito da dati binari che includono il GUID dell'oggetto chiave radice KDS corrispondente.

      Si supponga, ad esempio, che l'oggetto Chiave radice KDS abbia il codice seguente CN.

      

      Un account del servizio gestito di gruppo creato usando questo oggetto ha un msds-ManagedPasswordID valore simile all'immagine.

      

      In questo valore, i dati GUID iniziano dall'offset 24. Le parti del GUID si trovano in una sequenza diversa. In questa immagine le sezioni rosso, verde e blu identificano le parti riordinate. La sezione arancione identifica la parte della sequenza che corrisponde al GUID originale.

      Se il primo gMSA creato usa la nuova chiave radice KDS, anche tutti gli account del servizio gestito successivi usano la nuova chiave.

4. Aggiornare i servizi appropriati per usare i nuovi GMSA.

5. Eliminare i vecchi GMSA che usavano l'oggetto chiave radice KDS precedente usando il cmdlet seguente:

   $Domain = (Get-ADDomain).DistinguishedName
   $DomainGMSAs = (Get-ADObject -Searchbase "$Domain" -LdapFilter '(&(objectClass=msDS-GroupManagedServiceAccount)(adminDescription=cleanup-gsma))').DistinguishedName
   ForEach ($GMSA In $DomainGMSAs)
   {
       Remove-ADObject "$GMSA" -Confirm:$False
   }
   

6. Eliminare l'oggetto chiave radice KDS precedente e verificare le repliche.

7. Riavviare il servizio di distribuzione delle chiavi Microsoft in tutti i controller di dominio.

Scenario 3: Dimissioni di un amministratore di dominio, nessuna informazione rubata al momento ed è possibile attendere il rollback delle password

Se un membro con privilegi elevati con amministratori di dominio o diritti equivalenti si dimette, non esiste alcuna prova dell'esposizione della chiave radice KDS al momento ed è possibile permettersi un intervallo di tempo per il rollback delle password. Non è necessario ricreare i GMSA.

Come misura preventiva, è necessario eseguire il rollback della chiave radice KDS per evitare attacchi post-sfruttamento. Ad esempio, un ex amministratore di dominio si è rivelato non autorizzato e ha mantenuto alcuni backup.

Viene creato un nuovo oggetto Chiave radice KDS e i GMSA verranno rollforati in modo naturale.

Nota

Per una compromissione correlata a un amministratore di dominio, fare riferimento allo scenario 1 o scenario 2 in base a quanto esposto e seguire le attività di correzione locali in "Usare le risorse di sicurezza di Microsoft e Azure per consentire il ripristino da compromissione dell'identità sistemica".

Nel dominio che contiene gli account del servizio gestito di gruppo che si desidera eseguire il rollback, seguire questa procedura:

1. In un controller di dominio seguire la procedura descritta in Creare la chiave radice KDS di Servizi di distribuzione chiavi per creare un nuovo oggetto Chiave radice KDS.

   Nota

   Nell'ambiente di produzione è necessario attendere 10 ore per assicurarsi che sia disponibile la nuova chiave radice KDS. Controllare l'attributo EffectiveTime per sapere quando la nuova chiave radice KDS sarà utilizzabile.

2. Riavviare il servizio di distribuzione delle chiavi Microsoft in tutti i controller di dominio.

3. Creare un nuovo gMSA. Assicurarsi che il nuovo gMSA usi il nuovo oggetto Chiave radice KDS per creare il valore per l'attributo msds-ManagedPasswordID .

   Nota

   Questo passaggio è facoltativo, ma consente di verificare che la nuova chiave radice KDS sia attualmente in uso e usata nel servizio di distribuzione chiavi Microsoft.

4. Controllare il msds-ManagedPasswordID valore del primo gMSA creato. Il valore di questo attributo è costituito da dati binari che includono il GUID dell'oggetto chiave radice KDS corrispondente.

   Si supponga, ad esempio, che l'oggetto Chiave radice KDS abbia il codice seguente CN.

   

   Un account del servizio gestito di gruppo creato usando questo oggetto ha un msds-ManagedPasswordID valore simile all'immagine seguente.

   

   In questo valore, i dati GUID iniziano dall'offset 24. Le parti del GUID si trovano in una sequenza diversa. In questa immagine le sezioni rosso, verde e blu identificano le parti riordinate. La sezione arancione identifica la parte della sequenza che corrisponde al GUID originale.

   Se il primo gMSA creato usa la nuova chiave radice KDS, anche tutti gli account del servizio gestito successivi usano la nuova chiave.

5. A seconda del successivo rollback delle password, i segreti degli account del servizio gestito di gruppo verranno naturalmente rollforati e le nuove password verranno create in base al nuovo oggetto Chiave radice KDS su richiesta.

   Nota

   Se gli account del servizio gestito usati hanno eseguito il rollback, ma gli account del servizio gestito inutilizzati con lo stesso intervallo di rolling non sono stati inseriti e il PrincipalsAllowedToRetrieveManagedPassword parametro è popolato, è possibile eseguire il Test-ADServiceAccount cmdlet. Usa un'entità a cui è consentito recuperare la password gMSA e questo passaggio sposta quindi l'account del servizio gestito di gruppo nella nuova chiave radice KDS.

6. Verificare che sia stato eseguito il rollback di tutti i GMSA.

   Nota

   L'account del servizio gestito di gruppo senza il parametro non eseguirà mai il PrincipalsAllowedToRetrieveManagedPassword rollback.

7. Dopo il rollback di tutti i GMSA nel nuovo oggetto Chiave radice KDS, eliminare l'oggetto Chiave radice KDS precedente e verificare le repliche.

8. Riavviare il servizio di distribuzione delle chiavi Microsoft in tutti i controller di dominio.

Riferimenti

Panoramica degli account del servizio gestito del gruppo

Dichiarazione di non responsabilità di contatti di terze parti

Microsoft fornisce informazioni di contatto di terze parti per aiutarti a trovare ulteriori informazioni su questo argomento. Queste informazioni di contatto sono soggette a modifica senza preavviso. Microsoft non garantisce l'accuratezza delle informazioni di contatto di terze parti.