Proteggere i tuoi account di servizio gestiti di gruppo

Panoramica degli Account di Servizio Gestiti di Gruppo

La pratica tradizionale di utilizzare account utente regolari come account di servizio scarica il peso della gestione delle password sugli utenti. Di conseguenza, le password degli account spesso rimangono invariate per anni, il che le rende altamente vulnerabili ad attacchi di forza bruta e abusi. Gli account di servizio gestiti in gruppo (gMSAs) offrono un modo più sicuro per eseguire compiti automatizzati, servizi e applicazioni.

I gMSA sono stati introdotti in Windows Server 2016 e possono essere utilizzati su Windows Server 2012 e versioni successive. Le password dei gMSA sono completamente gestite da Windows: vengono generate casualmente e ruotate automaticamente. Inoltre, le password non devono essere note a nessun utente, poiché gli account di servizio vengono 'installati' sul server che deve interrogare le informazioni della password da Active Directory al momento dell'esecuzione. Di conseguenza, i gMSA sono molto meno soggetti a uso improprio e compromissione rispetto agli account utente utilizzati come account di servizio.

Sicurezza degli account di servizio gestiti dal gruppo

I gMSA sono un tipo specifico di oggetto in Active Directory: msDS-GroupManagedServiceAccount. Questi oggetti hanno attributi speciali associati a loro relativi alla loro password e alla sua rotazione. Similmente a LAPS, vorrai assicurarti che gli attributi gMSA siano bloccati per l'accesso solo agli oggetti di Active Directory che ne hanno bisogno.

Attributi e permessi gMSA

I gMSA possiedono i seguenti attributi:

• msDS-ManagedPassword— Un BLOB con la password del gMSA
• msDS-ManagedPasswordID— L'ID chiave utilizzato per generare la password corrente gMSA
• msDS-ManagedPasswordPreviousID— L'ID chiave utilizzato per generare la password gMSA precedente
• msDS-GroupMSAMembership— Un elenco degli oggetti che hanno il permesso di interrogare la password per il gMSA
• msDS-ManagedPasswordInterval— L'intervallo (giorni) in cui la password viene ruotata

Poiché le informazioni sulla password sono memorizzate nell'attributo msDS-ManagedPassword, vorrai sicuramente sapere chi nel tuo ambiente è in grado di interrogare la password. Quelle informazioni sono impostate nell'attributo msDS-GroupMSAMembership.

Tuttavia, è un po' più complicato di così, poiché entrano in gioco i permessi di Active Directory. Se per qualsiasi motivo un utente o un oggetto è configurato per avere i permessi di interrogare la password tramite l'account msDS-GroupMSAMembership, deve comunque avere i permessi di 'Lettura' per l'attributo msDS-ManagedPassword del gMSA.

Ciò significa che ci sono due modi per proteggere le password gMSA:

• Assicurati che solo gli oggetti necessari abbiano il permesso di interrogare la password e che esistano nell'msDS-GroupMSAMembership
• Assicurati che solo gli utenti amministrativi che necessitano dell'accesso e gli account computer dove sono installati i gMSA abbiano il permesso di leggere l'attributo. Inoltre, assicurati che solo gli amministratori abbiano la capacità di modificare il gMSA e i suoi attributi, così nessuno può aggiungersi all'attributo msDS-GroupMSAMembership.

Idealmente, si dovrebbero bloccare i gMSA attraverso entrambe le vie per impedire a un attaccante di avere l'opzione di sfruttare uno degli scenari sopra descritti. Qui sotto mostreremo come permessi o configurazioni mal gestite su un gMSA possono portare al compromesso dell'account e privilege escalation o movimento laterale.

Abusare della password gMSA

Abusare di un gMSA è un concetto relativamente semplice. Prima, ottieni la sua password utilizzando uno strumento come Mimikatz o interrogandolo direttamente a causa di configurazioni insicure in Active Directory. Poiché i gMSA sono account di servizio, di solito sono piuttosto privilegiati, quindi di solito sarai in grado di muoverti lateralmente o scalare.

Facciamo un esempio pratico.

1. Prima compromettiamo l'account utente Windows ordinario 'notadmin' attraverso una tecnica come il phishing. Questo account ha privilegi minimi in Active Directory, ma è un amministratore locale sulla macchina su cui siamo atterrati.

2. Successivamente, cercheremo di scoprire se esistono gMSA. Questo è molto semplice da realizzare se si ha accesso al cmdlet di Windows PowerShell. Eseguendo uno script semplice otteniamo tutti gli account di servizio gestiti in Active Directory:

      Get-ADServiceAccount -Filter *
      

3. Con alcune piccole modifiche allo script, possiamo identificare chi ha l'accesso per interrogare le password gMSA:

      Get-ADServiceAccount -Filter * -Properties PrincipalsAllowedToRetrieveManagedPassword
      

Come possiamo vedere, solo l'account Kevin Joyce è in grado di interrogare le password per questi account di servizio:

4. Possiamo restringere l'ambito degli obiettivi che vogliamo controllando se questi account di servizio sono membri di gruppi privilegiati e, da lì, possiamo approfondire ulteriormente i permessi impostati su uno degli oggetti:

      Get-ADServiceAccount -Filter * -Properties memberof
      

Osservando i risultati qui, possiamo vedere che l'account di servizio gMSA è membro dei Domain Admins, quindi sarà questo che cercheremo di sfruttare.

5. Modificando uno script fornito in un post su Microsoft LAPS, siamo stati in grado di ottenere un elenco di tutti gli oggetti che hanno permessi su un account di servizi gestiti che includevano Controllo completo, Scrittura di tutte le proprietà o Scrittura proprietà per l'attributo gMSA specifico. Di seguito è riportato l'output, e lo script è collegato in fondo.

6. Come potete vedere, l'account notadmin ha il controllo completo sull'account gMSA. Questo ci dà la capacità di modificare l'attributo msDS-GroupMSAMembership, che ci permetterà di recuperare la password per l'account del servizio gestito:

      Set-ADServiceAccount -Identity gmsa -PrincipalsAllowedToRetrieveManagedPassword notadmin
      

7. Ora che siamo effettivamente in grado di interrogare la password, vediamo cosa possiamo farne:

      Get-ADServiceAccount -Identity gmsa -properties msds-ManagedPassword
      

      $pwd = Get-ADServiceAccount -identity gMSA -Properties msds-ManagedPassword
      

8. Il valore memorizzato nell'attributo è un BLOB che contiene i dati per la password, non la password stessa, quindi dovremo decodificare la password utilizzando uno strumento come DSInternals:

      $pw = ConvertFrom-ADManagedPasswordBlob $pwd.’msds-managedpassword’
ConvertTo-NTHash $pw.securecurrentpassword
      

Questo ci permette di ottenere il SecureCurrentPassword e il CurrentPassword. Il CurrentPassword sembra inutile ma è perché tutti i caratteri sono in UTF-16. Il SecureCurrentPassword può essere convertito in un hash NTLM e utilizzato in un attacco pass-the-hash con mimikatz per elevare i nostri privilegi.

9. Per pass the hash dobbiamo semplicemente eseguire mimikatz e usare questo comando:

      sekurlsa::pth /user:gmsa /domain:sbpmlab.net /ntlm:a99afa608b79a3c539a969212c505ea9
      

10. Ora che abbiamo una shell eseguita come account del servizio gMSA che era membro degli Admin di Dominio, possiamo fare ciò che vogliamo per compromettere Active Directory. Uno dei modi più rapidi, ma probabilmente più rumorosi per farlo, è eseguire un DCSync attack e rubare l'hash dell'account krbtgt:

      lsadump::dcsync /user:krbtgt /domain:sbpmlab.net
      

Protezione e monitoraggio gMSA

Ci sono strategie che puoi utilizzare per prevenire e rilevare l'abuso di gMSA.

Permessi

La protezione più evidente e probabilmente la più importante che puoi implementare è assicurarti che siano impostati i permessi appropriati sui tuoi account di servizio gestiti dal gruppo. Comprendere chi ha l'accesso in scrittura a questi oggetti è pertinente per proteggerli; qualcuno che può aggiungersi all'attributo che controlla chi può interrogare la password in teoria ha già l'accesso per prendere il controllo di questo account e abusare dei suoi privilegi.

La cosa successiva sarebbe capire chi ha la capacità di interrogare le password di questi account e chi ha esattamente bisogno di tale accesso. In realtà, l'unico account che dovrebbe essere in grado di ottenere la password di un gMSA è l'account del computer su cui il gMSA è installato.

Registri degli eventi

C'è un evento che puoi cercare nei log degli eventi nativi che ti aiuterà a identificare chi sta interrogando le password degli account gMSA. Se abiliti la policy 'Audit directory service access' per il tuo dominio e configuri una SACL sugli gMSA che vuoi monitorare, puoi generare log degli eventi quando le persone interrogano l'attributo msDS-ManagedPassword:

Attivando questa impostazione e creando un nuovo SACL verrà generato un registro eventi con ID evento 4662; apparirà così:

Come puoi vedere, è stato registrato che l'account 'notadmin' ha letto una proprietà sull'account gMSA. Le proprietà lette sono i GUID memorizzati nello schema per Active Directory, ma utilizzando ADSI edit possiamo vedere che il GUID evidenziato corrisponde all'attributo msDS-ManagedPassword.

Assumendo che tu possa avere qualche tipo di inoltro del registro eventi o una soluzione SIEM, questi log sarebbero inestimabili per determinare chi sta accedendo a questi attributi.

Netwrix StealthDEFEND

Un'altra opzione è uno strumento come Netwrix StealthDEFEND. Netwrix StealthDEFEND non si basa sui log degli eventi nativi e può rilevare l'accesso alla password gMSA e l'assegnazione di permessi ad alto rischio direttamente out of the box. Ad esempio, lo scenario mostrato sopra genererebbe la seguente minaccia quando l'account 'notadmin' ha interrogato la password:

Inoltre, con Netwrix StealthDEFEND, è possibile creare facilmente un playbook da eseguire quando viene rilevato un abuso di gMSA. Il playbook può prevedere più passaggi, come richiedere all'account utente colpevole di rispondere a una richiesta MFA, disabilitare l'account o creare un incidente ServiceNow.

Appendice

Codice dei permessi gMSA:

      <#
Author: Kevin Joyce
Requirements: Active Directory PowerShell module, Domain Administrator privileges (to ensure the capability to get attribute GUIDs and view all permissions on all gMSA objects)
Description: Looks up permissions within Active Directory on a gMSA to determine access to modify the gMSA attribute (ms-ds-GroupMSAMembership).
Usage: populate the $target variable with the samaccountname of a gMSA.
To output the results to a text file run the following .gMSA_Permissions_Collection.ps1 > output.txt
#>
Import-Module ActiveDirectory
##Get the GUID of the extended attribute ms-ds-GroupMSAMembership from Schema
$schemaIDGUID = @{}
Get-ADObject -SearchBase (Get-ADRootDSE).schemaNamingContext -LDAPFilter '(name=ms-ds-GroupMSAMembership)' -Properties name, schemaIDGUID |
ForEach-Object {$schemaIDGUID.add([System.GUID]$_.schemaIDGUID,$_.name)}

<# **REPLACE DN VARIABLE BELOW**
Declare the samaccountname of the gMSA to search for#>
$target = 'gmsa'

##Get distinguished name of all gMSAs objects from the OU
$gMSAs = Get-ADServiceAccount -identity $target


<#Get objects that have specific permissions on the target(s): 
Full Control(GenericAll) 
Write all Properties (WriteProperty where ObjectType = 00000000-0000-0000-0000-000000000000 
#>
Set-Location ad:
foreach ($gmsa in $gMSAs){
(Get-Acl $gmsa.distinguishedname).access | 
Where-Object { (($_.AccessControlType -eq 'Allow') -and ($_.activedirectoryrights -in ('GenericAll') -and $_.inheritancetype -in ('All', 'None')) -or (($_.activedirectoryrights -like '*WriteProperty*') -and ($_.objecttype -eq '00000000-0000-0000-0000-000000000000')))} |
ft ([string]$gmsa.name),identityreference, activedirectoryrights, objecttype, isinherited -autosize 
}
<#Get objects that have specific permissions on the target(s) and specifically the gMSA attribute:
WriteProperty 
#>
Set-Location ad:
foreach ($gmsa in $gMSAs){
(Get-Acl $gmsa.distinguishedname).access | 
Where-Object {(($_.AccessControlType -eq 'Allow') -and (($_.activedirectoryrights -like '*WriteProperty*') -and ($_.objecttype -in $schemaIDGUID.Keys)))} |
ft ([string]$gmsa.name),identityreference, activedirectoryrights, objecttype, isinherited -AutoSize
}
      

visualizza grezzogMSA_Permissions_Collection.ps1 ospitato con da GitHub

FAQ

Cos'è un gMSA?

Simili agli account di servizio gestiti (MSA), gli account di servizio gestiti di gruppo (gMSA) sono account di dominio gestiti utilizzati per aiutare a proteggere i servizi e la gestione degli accessi. La funzionalità gMSA fornisce una gestione automatica delle password da parte del controller di dominio (DC), una gestione semplificata del nome del servizio principale (SPN) e la possibilità di delegare la gestione ad altri amministratori, il che migliora la sicurezza di Active Directory e riduce al minimo gli account con accesso privilegiato.

Qual è la differenza tra MSAs e gMSAs?

A differenza di un MSA, un gMSA può essere associato a più computer.

Come trovare un account servizio gestito da un gruppo?

Per ottenere un elenco di gMSAs sul controller di dominio, apri Server Manager > Strumenti > Active Directory Users and Computers > Account di servizio gestiti.

Un gMSA può essere un Domain Admin?

Sì, un account gMSA può essere membro di Domain Admins, anche se questa pratica può essere pericolosa per la sicurezza delle informazioni.

Come posso creare un gMSA?

Gli account di servizio gestiti dal gruppo vengono creati con il cmdlet New-ADServiceAccount.

I permessi dell'oggetto di un gMSA decidono se quell'automazione rimane sicura. Quando un account ordinario ha accesso in scrittura all'attributo che controlla il recupero della password, può concedersi il permesso di leggere la credenziale e quindi agire con i diritti esistenti dell'identità del servizio, inclusa qualsiasi appartenenza a gruppi privilegiati che l'account possiede.

Quell'unico permesso è spesso l'unica cosa che separa un deployment sicuro da una compromissione a livello di dominio.

Gli account di servizio sono identità non umane e il 76% delle organizzazioni non li governa o monitora completamente, secondo il Netwrix 2026 Data and Identity Security Report. Un account di servizio gestito di gruppo rimuove la password dalle mani umane, ma chiunque possa riscrivere quali principali possono recuperarla può comunque prendere il controllo dell'identità.

Cos'è un account di servizio gestito di gruppo (gMSA)?

Come funziona un gMSA

La password di un gMSA segue la stessa sequenza su ogni host che la utilizza.

1. Il Key Distribution Service (KDS) su ogni controller di dominio detiene il segreto usato per calcolare le password di ogni gMSA nel dominio.

Un account di servizio gestito di gruppo è un account gestito di Active Directory domain utilizzato per eseguire servizi, applicazioni e attività pianificate. Windows genera una password casuale e la ruota automaticamente, e gli host autorizzati recuperano le credenziali da Active Directory durante l'esecuzione, quindi gli amministratori non devono mai conoscere la password o memorizzarla in file.

1. L'host recupera anche la password precedente, mantenendo l'autenticazione attiva durante la breve finestra in cui la rotazione si propaga.

I gMSA non sono applicabili ai sistemi operativi Windows precedenti a Windows Server 2012, quindi ogni host che li esegue necessita di Windows Server 2012 o versioni successive. Un gMSA supporta un’identità di servizio su più computer, mentre un account di servizio gestito autonomo supporta un solo computer, e un account utente normale lascia la gestione delle password agli amministratori.

1. Poiché ogni host autorizzato si autentica come lo stesso principal di dominio, un gMSA semplifica anche la gestione del Service Principal Name (SPN) per i servizi che condividono un’identità tra host.
2. Windows ruota automaticamente la password, ogni 30 giorni per impostazione predefinita, senza che alcun host necessiti di preavviso o intervento manuale.
3. Un host autorizzato contatta un controller di dominio e recupera la password corrente in fase di esecuzione, calcolata da quel segreto, invece di memorizzarla localmente.

gMSA rispetto ad altri tipi di account di servizio

Insieme, questi attributi indicano a un host come recuperare la password, e msDS-GroupMSAMembershipExpand è ciò che un attaccante deve riscrivere, la configurazione errata che lo walkthrough più avanti sfrutta.

Active Directory rappresenta un gMSA con la classe di oggetto msDS-GroupManagedServiceAccountExpand, e questi attributi dello schema memorizzano la password e i controlli di recupero.

Windows offre diversi principali per l'esecuzione dei servizi, e ognuno supporta servizi diversi e gestisce la propria password in modo differente. Scegli il tipo di account in base ai requisiti di autenticazione e al modello di distribuzione dell'applicazione.

A differenza di un sMSA, un gMSA può essere condiviso tra più computer, rendendolo adatto per farm di server e servizi bilanciati. Entrambi sono account di servizio gestiti che consentono a Windows e Active Directory di gestire le password.

Perché le gMSA sono importanti

Microsoft osserva che le password gMSA sono generate automaticamente dalla macchina e ruotate automaticamente, ma non sono vincolate alla macchina, quindi possono ancora essere lette da un host compromesso, e una gMSA non può essere migrata direttamente a una dMSA.

Windows Server 2025 aggiunge la delegated managed service account (dMSA), che migra un account di servizio tradizionale a un account macchina con chiavi gestite e casuali e lega l'autenticazione all'identità del dispositivo.

Password robuste che nessuno deve gestire

Utilizzare un account utente normale come account di servizio mette la generazione, distribuzione e rotazione delle password nelle mani degli amministratori, e la password rimane invariata finché qualcuno non la ruota. Un gMSA sostituisce questo ciclo manuale con una generazione e recupero gestiti dal dominio.

La password deve comunque raggiungere ogni host, quindi l'autorizzazione e la sicurezza dell'host diventano parte della protezione delle credenziali.

Un'identità unica in un server farm

I protocolli di autenticazione che supportano l'autenticazione reciproca, come Kerberos, richiedono che ogni istanza di un servizio ospitato in farm utilizzi lo stesso principal. Un gMSA fornisce a tutti gli host membri un unico principal di dominio, e gli amministratori gestiscono le sue autorizzazioni centralmente senza sincronizzare una password tra gli host.

Minore esposizione a forza bruta e uso improprio

Un gMSA utilizza una password di 240 byte generata casualmente che Windows cambia ogni 30 giorni, riducendo al minimo il rischio di compromissione tramite attacchi brute-force o dizionario. Gli amministratori configurano l’account e gli host autorizzati e non gestiscono mai la password, quindi i servizi ottengono credenziali forti senza che nessuno le copi in script, note di distribuzione o file di configurazione.

I servizi Windows, i pool di applicazioni IIS e le attività pianificate possono essere eseguiti come gMSA, e la guida Kerberoasting di Microsoft cita anche SQL Server. Il supporto applicativo rimane un requisito di distribuzione, quindi testa ogni servizio sotto il gMSA prima di passare alla produzione.

Un'impostazione predefinita più sicura contro il Kerberoasting

La generazione automatica elimina la selezione delle password da parte degli utenti, e la rotazione automatica elimina il compito ricorrente di aggiornare una credenziale statica su ogni host di servizio. Microsoft consiglia gMSA per i servizi on-premises a meno che un servizio non possa usarli.

La responsabilità rimanente è la governance degli accessi, perché chi può modificare l'autorizzazione al recupero della password può ottenere la credenziale senza mai partecipare alla generazione della password.

Kerberoasting consente a un attaccante con qualsiasi account di dominio di richiedere ticket di servizio e decifrare offline la password di un account di servizio, quindi la forza della password determina se l'attacco ha successo.

Le linee guida Kerberoasting di Microsoft indicano gli account con password deboli come i più vulnerabili e raccomandano gMSA o dMSA quando possibile, perché una password generata elimina la debolezza scelta dall’utente su cui si basa la tecnica.

Come configurare in modo sicuro un gMSA

Netwrix Threat Manager rileva il furto di credenziali, movimenti laterali e escalation di privilegi in ambienti ibridi. Richiedi una demo.

1. Verifica i requisiti

Conferma i requisiti di dominio, host, amministrazione e applicazione prima di distribuire il gMSA.

Crea l’account con un elenco esplicito di host autorizzati, quindi installalo e convalidalo su ogni host.

• Livelli funzionali di dominio e foresta impostati su Windows Server 2012 o versioni successive, che Microsoft afferma supportare le funzionalità gMSA per tutti i dispositivi.
• Host che eseguono Windows Server 2012 o versioni successive.
• Il modulo PowerShell di Active Directory sul sistema di amministrazione, che necessita di un’architettura a 64 bit per eseguire i cmdlet gMSA.
• Una chiave root KDS disponibile per i controller di dominio.
• Appartenenza a Domain Admins o Enterprise Admins, o permesso delegato per creare msDS-GroupManagedServiceAccountExpand oggetti.
• Un servizio che supporta gMSA, come un servizio Windows, un pool di applicazioni IIS o un'attività pianificata.

Delega la creazione di gMSA a un gruppo amministrativo dedicato e mantieni l’identità del servizio fuori dai gruppi amministrativi.

2. Crea la chiave root KDS

3. Creare il gMSA con New-ADServiceAccount

I cluster di failover non supportano gMSA, ma i servizi che girano sul servizio Cluster possono usarne uno se sono un servizio Windows, un pool di applicazioni o un'attività pianificata, o se supportano nativamente gMSA. Kerberos deve funzionare end-to-end, quindi registra gli SPN per ogni servizio, mantieni accurati i record DNS e gli orologi, e consenti il traffico Kerberos tra i sistemi coinvolti.

Nonostante il nome del parametro, -EffectiveImmediatelyExpand non salta la replica. Altri controller di dominio non possono usare la chiave finché non viene replicata, e la procedura di creazione chiavi di Microsoft fa attendere i controller di dominio fino a 10 ore prima di consentire la creazione di un gMSA, quindi prevedi questa finestra in produzione.

4. Installare e testare il gMSA su ogni host

Crea un gruppo di sicurezza dedicato per gli account computer host del servizio, quindi crea il gMSA con New-ADServiceAccountExpand, nominando il suo nome host DNS e il gruppo di sicurezza in PrincipalsAllowedToRetrieveManagedPasswordExpand. Microsoft richiede che i nomi gMSA siano unici in tutta la foresta, non solo nel dominio.

Verifica se la foresta ha già una chiave radice KDS prima di crearne una, poiché la chiave è un prerequisito unico a livello di foresta. Creala su un controller di dominio Windows Server 2012 o successivo con Add-KdsRootKey -EffectiveImmediatelyExpand, quindi conferma l'ID evento 4004Expand nel registro eventi KDS.

5. Configurare il servizio per l'esecuzione come gMSA

Imposta un intervallo di password personalizzato con -ManagedPasswordIntervalInDaysExpand durante la creazione se il deployment ne ha bisogno, poiché l'intervallo può essere impostato solo alla creazione. Registra il proprietario dell'applicazione dell'account e gli host previsti insieme alla configurazione del deployment, ed escludi i gruppi generali di amministrazione server e i gruppi che contengono utenti ordinari dal parametro di recupero, come spiegato in "Limit who can retrieve the password".

Testa ogni server membro singolarmente, perché un risultato positivo su un server non garantisce la membership di gruppo o la connettività su un altro server. Risolvi la validazione fallita prima di modificare l'identità di accesso di un servizio in produzione.

Imposta l'identità di accesso del servizio tramite Service Control Manager, le impostazioni dell'identità del pool applicazioni IIS o la configurazione delle attività pianificate, e lascia la password vuota. Windows recupera la credenziale gestita.

Come gli aggressori abusano di una password gMSA

Concedi all'account le autorizzazioni applicative necessarie, quindi conferma sia l'avvio del servizio sia l'accesso alle risorse dipendenti. Un test dell'account superato dimostra solo la prontezza delle credenziali, quindi il carico di lavoro necessita ancora delle proprie autorizzazioni per file, database e altre risorse.

Aggiungi l'account computer di ogni host al gruppo di sicurezza, quindi esegui Install-ADServiceAccountExpand seguito da Test-ADServiceAccountExpand su ogni host autorizzato. Test-ADServiceAccountExpand verifica che l'host possa recuperare la password.

Il laboratorio sottostante utilizza un account ordinario chiamato notadminExpand e un gMSA privilegiato configurato in modo errato. I nomi di dominio e account appartengono a quell'ambiente di esempio.

Trova i gMSA e chi può leggerli

Un attaccante può recuperare una password gMSA tramite un percorso autorizzato o tramite permessi insicuri di Active Directory, quindi autenticarsi come l’account con i diritti esistenti.Sfruttamento gMSA copre una classe di attacchi più ampia, inclusi gli attacchi Golden gMSA, che seguono una via diversa verso le credenziali gestite.

1. Con il modulo PowerShell di Active Directory disponibile, l'attaccante elenca gli account di servizio gestiti con Get-ADServiceAccount -Filter *Expand.

Trova un gMSA privilegiato e un modo per entrare

1. La richiesta della proprietà PrincipalsAllowedToRetrieveManagedPasswordExpand mostra quali principali possono leggere la password di ogni account.

Nei risultati del laboratorio, solo un account amministrativo può interrogare le password, quindi notadminExpand non può ancora leggerle. Questa configurazione è importante quando l'attaccante verifica chi può modificare l'oggetto gMSA.

1. L'attaccante verifica se un account di servizio appartiene a gruppi privilegiati interrogando la proprietà memberOfExpand.

Il gMSA del laboratorio appartiene a Domain Admins, quindi l'attaccante lo seleziona. La sua appartenenza esistente fornisce i privilegi necessari per i passaggi successivi.

Recupera e decodifica la password

1. La revisione delle autorizzazioni degli oggetti identifica i principali con Controllo completo, Scrivi tutte le proprietà o Scrivi proprietà sull’attributo di autorizzazione per il recupero della password, utilizzando uno script adattato da un approccio descritto in un post su Microsoft LAPS. Lo script dei permessi in "Find and audit every gMSA" qui sotto esegue lo stesso controllo.
2. Nel laboratorio, notadminExpand ha il Controllo completo sull'oggetto gMSA, che gli consente di usare Set-ADServiceAccountExpand per aggiungersi a PrincipalsAllowedToRetrieveManagedPasswordExpand.

Usa la password per scalare

1. L'attributo contiene un BLOB con i dati della password anziché la password stessa, quindi l'attaccante lo decodifica con DSInternals, che espone i valori della password attuale e precedente e può convertire la password attuale in un hash NT.
2. L'attaccante compromette notadminExpand tramite una tecnica come il phishing. L'account ha privilegi minimi di Active Directory ma possiede local administrator rights sulla macchina compromessa.
3. Dopo la modifica, notadminExpand può interrogare l'attributo msDS-ManagedPasswordExpand e memorizzare l'oggetto restituito.

Come proteggere i tuoi gMSA

Un singolo permesso troppo ampio, Full Control su un oggetto gMSA, ha permesso all’attacco di passare da un account compromesso ordinario alla falsificazione delle credenziali a livello di dominio.

Gli attacchi Golden gMSA raggiungono la password di un gMSA attraverso una via diversa e sono trattati nella pagina di sfruttamento gMSA.

Proteggi insieme l'autorizzazione di recupero di un gMSA, le autorizzazioni degli oggetti e i privilegi di servizio.

1. Con la credenziale recuperata, l'attaccante si autentica come gMSA tramite pass-the-hash e avvia un processo sotto l'identità del servizio, ereditando tutti i diritti che tale identità possiede.

Limitare chi può recuperare la password

Limitare chi può modificare il gMSA

1. Poiché il gMSA del laboratorio appartiene a Domain Admins, l'attaccante può usare i suoi diritti di replica per eseguire un attacco DCSync contro l'account krbtgtExpand. Il materiale delle credenziali di quell'account firma ogni ticket Kerberos nel dominio, quindi recuperarlo consente all'attaccante di falsificare ticket per qualsiasi utente successivamente.

Tieni i gMSA fuori dai gruppi privilegiati

Solo gli account computer che eseguono il servizio dovrebbero normalmente recuperare la sua password gMSA. Per un deployment multi-server, usa un gruppo di sicurezza dedicato contenente quegli account computer, configurandolo tramite PrincipalsAllowedToRetrieveManagedPasswordExpand, e controlla la sua appartenenza ogni volta che cambia la lista degli host del servizio.

Concedi l'accesso in scrittura solo agli amministratori che devono gestire l'account e verifica i permessi di Controllo completo, Scrittura di tutte le proprietà e Scrittura di proprietà specifiche per ogni gMSA. Un soggetto con il permesso di modificare msDS-GroupMSAMembershipExpand può autorizzare il recupero della propria password, che è esattamente la configurazione errata sfruttata dalla procedura sopra.

Concedi a ogni gMSA solo i diritti necessari per il suo servizio. Un gMSA può appartenere a Domain Admins, ma tale appartenenza conferisce a chiunque ottenga le sue credenziali privilegi amministrativi a livello di dominio, e le linee guida di mitigazione di Microsoft raccomandano di rivedere le autorizzazioni degli account di servizio e rimuovere gli accessi eccessivi.

Applicare la crittografia AES

Proteggi l'account tramite entrambi i percorsi di autorizzazione. Limita quali principali rappresenta l'attributo msDS-GroupMSAMembershipExpand e limita l'accesso alla directory all'oggetto gMSA stesso, in particolare il permesso di modificare l'account o la sua autorizzazione di recupero.

Verifica l'appartenenza diretta al gruppo e i permessi effettivi conferiti dai gruppi nidificati, e documenta l'accesso richiesto dall'applicazione prima di rimuovere i permessi, così che il proprietario del servizio possa convalidare la configurazione rivista.

I controller di dominio che eseguono Windows Server 2025 non emettono più ticket di concessione RC4, quindi un dispositivo legacy che dipende da RC4 non può autenticarsi con essi.

Trova e verifica ogni gMSA

Microsoft sta eliminando la crittografia RC4 Kerberos per impostazione predefinita, non solo sconsigliandola. Un aggiornamento del 2022 ha già cambiato il tipo di crittografia predefinito in Advanced Encryption Standard (AES)-SHA1 per qualsiasi account senza un tipo di crittografia esplicito configurato.

Controlla l'attributo msDS-SupportedEncryptionTypesExpand di ogni gMSA e conferma che includa AES invece di fare affidamento sul valore predefinito di fallback del dominio, poiché proprio quel fallback è ciò che Microsoft sta rimuovendo.

Reimpostare la password dell'account dopo aver abilitato il supporto AES per generare nuove chiavi, quindi testare l'autenticazione, perché un gMSA lasciato solo su RC4 può perdere completamente l'autenticazione Kerberos invece di funzionare semplicemente con una cifratura più debole.

Monitorare le letture delle password

Script originale: gMSA_Permissions_Collection.ps1.

L'evento risultante identifica l'account soggetto, l'oggetto directory di destinazione e le proprietà accessibili.

Lo script dei permessi sottostante segnala quali account hanno accesso Full Control o Write Property all'attributo msDS-GroupMSAMembershipExpand di un gMSA, il controllo che il passaggio 5 della guida sopra esegue dal lato dell'attaccante. Gli amministratori devono comunque esaminare ereditarietà, appartenenza ai gruppi e accesso effettivo quando decidono chi deve mantenere tali diritti.

Elenca gli account di servizio gestiti con Get-ADServiceAccount -Filter *Expand, quindi filtra gli oggetti il cui ObjectClassExpand è msDS-GroupManagedServiceAccountExpand per distinguere gMSA dagli account di servizio gestiti autonomi.

Rimuovi i gMSA che non usi più

Abilita la policy di accesso al servizio directory di Audit e configura una lista di controllo accessi di sistema (SACL) sui gMSA per monitorare, che genera l'ID evento 4662Expand ogni volta che un principale legge msDS-ManagedPasswordExpand.

Gli identificatori delle proprietà appaiono come GUID dello schema nell’evento, e ADSI Edit può risolvere il GUID pertinente per confermare che corrisponde a msDS-ManagedPasswordExpand.

Inoltra i log del controller di dominio a un sistema di gestione delle informazioni e degli eventi di sicurezza (SIEM), confronta le letture delle password con gli host di servizio approvati dell'account e indaga il recupero da parte di utenti o computer inattesi.

Come Netwrix aiuta a proteggere i gMSA

Proteggi l'amministrazione di gMSA

La revisione manuale delle autorizzazioni di recupero e dei log di controllo non è scalabile una volta che un ambiente ha più di qualche gMSA. Questi tre prodotti Netwrix coprono l'accesso amministrativo all'account, rilevano l'uso improprio delle credenziali e forniscono visibilità continua su quali account detengono ancora permessi eccessivi.

Rimuovi un gMSA inutilizzato dai suoi host precedenti con Uninstall-ADServiceAccountExpand. La disinstallazione dell’host e la rimozione dell’account della directory sono azioni di ciclo di vita separate. Conferma che ogni carico di lavoro dipendente sia stato migrato o ritirato prima di eliminare l’oggetto AD e rimuovi le autorizzazioni obsolete dell’host e i permessi delle risorse associati come parte della stessa modifica.

Rilevare comportamenti anomali degli account di servizio

Con Netwrix Privilege Secure, il distretto concede l’accesso al volo tramite account temporanei che vengono rimossi una volta completato il compito, e ha implementato Privileged Access Management per i suoi sistemi critici in giorni anziché mesi.

Netwrix Privilege Secure sostituisce l'accesso permanente a oggetti privilegiati come gMSA con account temporanei limitati al compito. Eastern Carver County Schools ha visto i Red Teams ottenere ripetutamente accesso a sistemi critici tramite accessi privilegiati eccessivi e non necessari.

Individua account di servizio con permessi eccessivi e obsolete

Netwrix Threat Manager rileva il furto di credenziali, i movimenti laterali e l’escalation dei privilegi negli ambienti ibridi. Indaga queste rilevazioni per abusi di identità di servizio come gMSA, dove un attaccante che si autentica con una password gestita rubata esercita i diritti esistenti dell’identità.

Abbina la rotazione automatica a permessi rigorosi di recupero

Netwrix Access Analyzer risolve l’appartenenza a gruppi nidificati e analizza i permessi effettivi sugli oggetti di Active Directory, e i suoi report segnalano anche gli account trustee obsoleti. Usa questi risultati per rivedere il recupero di gMSA e i permessi degli oggetti e identificare i candidati per la pulizia.

La rotazione automatica delle password e i permessi rigorosi di recupero sono due controlli separati, e un gMSA rimane sicuro solo quando entrambi sono attivi. La spiegazione sopra mostra cosa succede quando solo un permesso viene meno: un account compromesso ordinario eredita una credenziale di Domain Admin e falsifica ticket per l'intero dominio, senza che alcuna password venga mai decifrata o indovinata.

Considera le revisioni dei permessi come un lavoro ricorrente, non come un passaggio di configurazione una tantum, perché ogni nuovo host, ogni modifica dell'appartenenza a un gruppo e ogni migrazione di servizio possono riaprire lo stesso percorso.

Richiedi una demo per vedere come Netwrix Privilege Secure rimuove l'accesso permanente agli account privilegiati, Netwrix Threat Manager rileva l'abuso degli account di servizio e Netwrix Access Analyzer identifica gli account con permessi eccessivi.