Attaccare la Delega Vincolata per Elevare l'Accesso

Questo articolo completa una serie di articoli su Kerberos delegation. Prima di leggerlo, suggeriamo di assicurarsi di essere familiari sia con la Active Directory delegation che con la Kerberos delegation, e di aver letto i post precedenti della serie che forniscono una panoramica di come la resource-based constrained delegation e la unconstrained delegation siano configurate e come possano essere abusate.

Questo articolo spiega come un attacco di constrained delegation consente a un avversario di ottenere un accesso elevato a servizi vitali.

Delega vincolata

La delega vincolata consente agli amministratori di configurare a quali servizi un utente o un account computer di Active Directory può delegare e quali protocolli di autenticazione possono essere utilizzati. Viene configurata nella scheda Delega per l'oggetto AD:

Quando la delega vincolata è impostata su un account, si verificano due cose dietro le quinte:

• L'attributo userAccountControl per l'oggetto viene aggiornato con il flag “TRUSTED_TO_AUTHENTICATE_FOR_DELEGATION”.
• L'attributo msDS-AllowedToDelegateTo è popolato con l'SPN specificato.

Attacco di delega vincolata

In teoria, la delega vincolata limita i danni che potrebbero derivare se un account AD viene compromesso. Tuttavia, la delega vincolata può essere abusata: un avversario che compromette la password in chiaro o l'hash della password di un account configurato con delega vincolata a un servizio può poi impersonare qualsiasi utente nell'ambiente per accedere a quel servizio. Ad esempio, se la delega vincolata è configurata per uno SPN di Microsoft SQL, un attaccante potrebbe ottenere l'accesso privilegiato a quel database.

Come si sviluppa un attacco

Supponiamo quanto segue:

• Abbiamo guadagnato una posizione di rilievo in un ambiente IT.
• Abbiamo compromesso un account con privilegi di amministratore locale su una postazione di lavoro.
• Abbiamo usato Mimikatz per ottenere un hash della password lasciato in memoria dopo un accesso, e l'account associato (l'account 'notadmin') ha la delega vincolata configurata.

Quindi, tutto ciò che abbiamo finora è l'accesso alla singola macchina su cui siamo atterrati e l'hash della password di un account configurato per la delega vincolata.

Passo 1. Recon

Per sfruttare la delega vincolata, abbiamo bisogno di tre cose fondamentali:

• Un account compromesso configurato con delega vincolata
• Un account privilegiato di destinazione da impersonare quando si richiede l'accesso al servizio
• Informazioni sulla macchina che ospita il servizio a cui otterremo l'accesso

Abbiamo il primo, quindi prendiamo gli altri due.

1.1: Innanzitutto, vediamo per cosa è configurata la delega vincolata dell'account 'notadmin':

1.2: Ora sappiamo che la delega vincolata è configurata per gli SPN CIFS e LDAP sull'host SBPMLAB-DC2. Quindi cerchiamo di capire esattamente cosa sia l'host SBPMLAB-DC2 (anche se il nome in qualche modo lo rivela!). Forse l'appartenenza al gruppo del computer ci dirà qualcosa.

1.3: Siamo fortunati: La macchina a cui questo utente può delegare l'accesso è un domain controller (DC). Ora troviamo un buon utente da impersonare quando accediamo a questo servizio. Il seguente comando PowerShell elencherà i membri del gruppo Domain Admins:

Get-ADGroup ‘Domain Admins’ | Get-ADGroupMember

Possiamo vedere che l'account 'KevinJ' è membro dei Domain Admins, quindi ora abbiamo tutti gli elementi necessari per sfruttare la delega vincolata.

Passaggio 2. Ottenere l'Accesso

Utilizzando uno strumento come Kekeo, possiamo richiedere il ticket granting ticket (TGT) per l'account con delega vincolata configurata, eseguire la richiesta di servizio di emissione del ticket per l'account che vogliamo impersonare e poi accedere al servizio target.

Ricorda che non abbiamo ancora accesso alla condivisione amministrativa C$ sul host di destinazione:

2.1. Utilizzando Kekeo, richiediamo il TGT per l'account 'notadmin' utilizzando il suo hash della password:

2.2. Ora che abbiamo il TGT, eseguiamo la richiesta TGS per l'account che vogliamo impersonare per il servizio di destinazione a cui l'account 'notadmin' è vincolato:

2.3. Ritornando a Mimikatz, siamo in grado di utilizzare Pass the Ticket per ottenere l'accesso al servizio CIFS sull'host di destinazione:

Come puoi vedere, dopo che il ticket è stato importato, possiamo navigare nella condivisione di amministrazione C$ sul controller di dominio. Ciò significa che potremmo potenzialmente rubare una copia del file NTDS.dit e provare a decifrare le password degli utenti offline.

Protezione contro gli attacchi basati sulla delega

Una tecnica critica per difendersi dagli attacchi legati alla delega è quella di inserire gli account sensibili che non dovrebbero essere delegati nel gruppo degli Utenti Protetti, oppure selezionare la casella 'L'account è sensibile e non può essere delegato' in Active Directory Users and Computers nella scheda Account:

Per una protezione più ampia, prendi in considerazione la Netwrix Active Directory Security Solution. Fornisce report completi che offrono una chiara comprensione di dove sono configurati la delega senza restrizioni e quella con restrizioni, così come gli specifici account di servizio che sono vincolati. Utilizzando queste informazioni, puoi ridurre il rischio e proteggere il tuo ambiente in modo più efficace. In aggiunta, puoi facilmente rilevare e automatizzare la tua risposta a minacce sofisticate e mitigarne l'impatto.

FAQ

Cos'è un attacco di delega vincolata?

Un attacco di delega vincolata è un tipo di cyberattacco in cui un avversario ottiene accesso non autorizzato a un sistema o servizio target sfruttando i permessi concessi a un account di servizio. Compromettendo l'account di servizio o intercettando e manipolando il traffico Kerberos tra i servizi, l'attaccante può impersonare un utente e ottenere accesso non autorizzato ad altri servizi ai quali l'account di servizio ha il permesso di accedere. Questo tipo di attacco può essere più difficile da eseguire rispetto a un attacco di delega non vincolata, ma rappresenta comunque una seria minaccia per la sicurezza della rete.

Cosa sono la delega vincolata e non vincolata?

La delega vincolata e la delega non vincolata sono due modi in cui il protocollo di autenticazione Kerberos può essere configurato per consentire a un servizio di impersonare un utente per accedere ad altri servizi. La delega non vincolata consente a un servizio di impersonare un utente per accedere a qualsiasi altro servizio all'interno di un dominio Active Directory. La delega vincolata, d'altra parte, limita l'ambito della delega specificando quali servizi un servizio può accedere per conto di un utente.

Cosa significa delega senza vincoli?

La delega senza vincoli è una configurazione di delega Kerberos che consente a un servizio di impersonare un utente per accedere a qualsiasi altro servizio all'interno di un dominio Active Directory. Questo tipo di delega può essere sfruttato dagli aggressori per muoversi lateralmente all'interno di una rete e ottenere l'accesso a dati o sistemi sensibili.

Perché la delega senza vincoli è negativa?

La delega senza vincoli è considerata pericolosa perché può permettere agli aggressori di muoversi lateralmente all'interno di una rete e ottenere accesso a dati sensibili o sistemi. Si raccomanda di utilizzare la delega vincolata, che limita l'ambito della delega e riduce il rischio di attacchi riusciti.