Account di Server (Un)Trust

Persistenza in Active Directory tramite manipolazione di userAccountControl

Ultimamente ho fatto delle ricerche sugli account di servizio gestiti di gruppo (gMSAs) e ho letto la specifica del protocollo MS-SAMR per alcune informazioni. Mi sono imbattuto in alcune informazioni interessanti nella sezione userAccountControl che ci hanno fatto interrompere quello che stavamo facendo per testarle:

Effettivamente, quando il bit UF_SERVER_TRUST_ACCOUNT è impostato nell'attributo userAccountControl di un oggetto computer, allora Active Directory deve impostare lo stesso oggetto primaryGroupId al RID del gruppo Domain Controllers. Pertanto, semplicemente cambiando userAccountControl si possono concedere a un oggetto computer i privilegi di un domain controller.

Indagando il comportamento

Abbiamo iniziato i test utilizzando un account Domain Admin nel nostro laboratorio e abbiamo prima tentato di usare il valore predefinito di userAccountControl per un domain controller di 0x82000 (decimale 532480), che è la somma dei bit flag per SERVER_TRUST_ACCOUNT (0x2000, decimale 8192) e TRUSTED_FOR_DELEGATION (0x80000, decimale 524288).

Dopo aver modificato il valore di userAccountControl, notiamo che il primaryGroupId viene aggiornato a 516 (l'RID per il gruppo dei Domain Controllers) e siamo partiti alla grande! Successivamente, volevamo sapere se è necessario solo il bit SERVER_TRUST_ACCOUNT, quindi abbiamo tentato nuovamente impostando l'attributo userAccountControl a 8192.

Abbiamo quindi confermato l'accuratezza della specifica del protocollo e che è solo il bit SERVER_TRUST_ACCOUNT a causare il cambiamento del primaryGroupId.

Ricerca dei privilegi necessari

Iniziamo a considerare possibili vettori di abuso. Se è richiesta solo la capacità di modificare l'attributo userAccountControl, allora potremmo essere di fronte a una interessante tecnica di privilege escalation. Abbiamo iniziato a testare con un account non privilegiato con solo i permessi per modificare l'attributo userAccountControl e ci siamo rapidamente imbattuti in errori di accesso negato.

Si è scoperto che avremmo dovuto leggere solo qualche riga in più nella documentazione MS-SAMR. La sezione 5 dell'attributo userAccountControl delinea ulteriori permessi richiesti per impostare determinati bit di userAccountControl. Per poter impostare il bit userAccountControl UF_SERVER_TRUST_ACCOUNT, l'attore deve avere il permesso DS-Install-Replica (“Aggiungere/rimuovere replica nel dominio”) concesso sull'oggetto dominio.

Abbiamo concesso al nostro utente non privilegiato questo permesso e abbiamo tentato nuovamente il nostro test.

Dopo aver concesso il privilegio di scrittura userAccountControl sul computer e il privilegio DS-Install-Replica sull'oggetto dominio al nostro utente non privilegiato, il nostro test è stato un successo.

Per impostazione predefinita, il permesso DS-Install-Replica è concesso ai gruppi “Domain Admins” e “Enterprise Admins”. Pertanto, in tutti gli ambienti tranne quelli configurati male, questo approccio non rappresenta un vettore di escalation dei privilegi. Tuttavia, date le limitate autorizzazioni richieste, abbiamo iniziato a pensare a applicazioni per la persistenza del dominio.

Applicazioni per la persistenza del dominio

Nella valutazione se questo presenta un metodo interessante per la persistenza, abbiamo considerato diversi fattori: che è richiesto un set limitato di privilegi, che questi privilegi non sono comunemente esaminati, che gli account (objectClass=computer) sono facili da creare, che i computer sono raramente controllati (molte organizzazioni hanno difficoltà con oggetti computer obsoleti), e che lo sfruttamento del meccanismo è facile e i segni sono di breve durata.

Configurare questo meccanismo richiede solo alcuni piccoli passaggi:

1. Creare un account fittizio di computer, MSA o gMSA. È possibile utilizzare anche un account esistente, ma l'efficacia del meccanismo di persistenza sarà limitata dalla frequenza dei cambiamenti di password. Tuttavia, un account di computer esistente ma inutilizzato (non più usato) potrebbe essere un obiettivo attraente.
2. Concedi il privilegio “Add/remove replica in domain” a un utente regolare compromesso, a un gruppo o a un'entità ben nota. Abbiamo usato “Authenticated Users” in modo che un avversario potesse compromettere qualsiasi account utente regolare e riacquistare il dominio della dominanza.
3. Concedi il privilegio “Write userAccountControl” sull'oggetto computer alla stessa entità del passaggio precedente.

Creazione di un account computer con una password nota

Potrebbe sembrare ovvio, ma non tutti potrebbero essere a conoscenza della possibilità di creare un account computer con una password nota utilizzando i cmdlet New-ADComputer o New-ADServiceAccount, ad esempio:

New-ADComputer “ComputerName” -AccountPassword (ConvertTo-SecureString -AsPlainText -Force “Password”)

Conoscere la password in chiaro è vantaggioso per diversi motivi. Principalmente, possiamo calcolare gli hash NTLM, AES-128 e AES-256 utilizzando i cmdlet ConvertTo-NTHash e ConvertTo-KerberosKey del modulo PowerShell DSInternals di Michael Grafnetter. Quando l'avversario decide di sfruttare la backdoor, dovrà autenticarsi come account computer per utilizzare i suoi privilegi e lo farà con la tecnica overpass-the-hash. Specificare gli hash NTLM e AES elude la maggior parte dei rilevamenti di overpass-the-hash.

Riconquistare il dominio

Dopo aver preparato l'account e i permessi, se l'avversario perde l'accesso alle proprie credenziali amministrative o viene espulso dalla rete, gli basta compromettere un qualsiasi utente regolare per riacquistare il dominio sulla rete.

Con qualsiasi account utente, l'avversario deve solo modificare l'attributo userAccountControl del loro computer preparato a 0x2000 (8192). Questa modifica provoca anche una replica immediata, il che significa che l'avversario non ha bisogno di prendere di mira specifici controller di dominio. Una volta che il userAccountControl è completo, l'avversario può utilizzare i suoi privilegi di controller di dominio per compromettere il dominio.

Ad esempio, l'aggressore potrebbe utilizzare l'account del computer per eseguire DCSync e compromettere l'hash della password di krbtgt. Poiché la replica sembra provenire da un controller di dominio, la maggior parte dei rilevamenti di minacce DCSync non rileva l'attività. Una volta replicato il segreto di krbtgt, possono semplicemente reimpostare userAccountControl su 0x1000 (4096) e l'account del computer apparirà come un normale account computer.

Automatizzare la tecnica

Per dimostrare la potenziale efficacia di questo metodo, ho creato due nuove funzioni PowerShell che sono available on GitHub.

La prima funzione, Add-ServerUntrustAccount, automatizza i tre passaggi di configurazione – creando un account computer fasullo con una password nota e concedendo agli “Authenticated Users” i privilegi di “Add/remove replica in domain” e “Write userAccountControl”.

La seconda funzione, Invoke-ServerUntrustAccount, automatizza lo sfruttamento del backdoor ed è destinata ad essere eseguita come un utente non privilegiato. La funzione imposta l'attributo userAccountControl a 0x2000 (8192), poi utilizza pass-the-hash per autenticarsi come falso account computer, esegue un DCSync degli hash di krbtgt, e infine reimposta userAccountControl a 0x1000 (4096).

Scoperta dei meccanismi e rilevamento dell'exploit

Per trovare questo e altri meccanismi simili, le organizzazioni dovrebbero eseguire periodicamente l'audit dei permessi sensibili di Active Directory. Monitorare (o addirittura bloccare) le modifiche ai permessi sensibili (come l'“Aggiungi/rimuovi replica nel dominio”) in tempo reale è altresì vantaggioso. Abbiamo testato diversi popolari strumenti open-source per l'audit dei permessi di Active Directory e solo AD ACL Scanner ha correttamente evidenziato i permessi del nostro avversario come preoccupanti.

I log degli eventi di Active Directory – ovvero gli ID evento 5136 e 4662 – consentono un monitoraggio di base in tempo reale delle modifiche delle ACL e possono essere utilizzati per rilevare il privilegio a livello di dominio “Add/remove replica in domain”. Tuttavia, il processo di analisi di questi eventi non è semplice.

Inoltre, è importante trovare e rimuovere gli account computer (e MSA e gMSA) obsoleti o che non corrispondono a una macchina reale nella rete. Ad esempio, puoi trovare rapidamente account computer inutilizzati o obsoleti con PowerShell (sostituendo “-90” con l'età massima dell'account computer del tuo dominio):

$Date = [DateTime]::Today.AddDays(-90); Get-ADComputer -Filter ‘(Enabled -eq $true) -and (PasswordLastSet -le $Date)’ | Select Name

Rilevamento dell'exploitation

Rilevare l'uso di questa tecnica da parte di un avversario si basa sul monitoraggio delle modifiche all'attributo userAccountControl. L'Id evento 4742 – Computer Account Management può essere utilizzato per monitorare le modifiche ai valori di userAccountControl. Qualsiasi modifica di userAccountControl con il bit 0x2000 impostato al di fuori di una promozione del controller di dominio prevista è preoccupante.

Concludendo

Sebbene ovviamente non sia grave come una vulnerabilità critica, queste tecniche vengono spesso non rilevate nelle imprese e possono rendere il lavoro di un addetto alla risposta agli incidenti ancora più difficile. Data la bassa frequenza di rilevamento negli strumenti di auditing di Active Directory che abbiamo testato, riteniamo che questa sia una tecnica interessante che sfrutta un comportamento meno noto che potrebbe facilmente essere trascurato. Accogliamo i vostri commenti e domande, e saremmo negligenti se non vi indirizzassimo al nostro Attack Catalog, dove potete scoprire di più su come funzionano certi attacchi.