Attacchi di Delega Kerberos: Rilevamento e Rimedio

Cosa Sono Gli Attacchi di Delega Kerberos?

Gli attacchi di delega Kerberos sfruttano funzionalita di delega legittime di Active Directory che permettono a un servizio di accedere a un altro servizio per conto di un utente. La delega esiste per flussi applicativi reali, come un livello web che si connette a un livello database con l'identita dell'utente. Il problema di sicurezza inizia quando l'ambito della delega e piu ampio di quanto l'applicazione richieda realmente, o quando un attaccante puo modificare la relazione di delega.

I tre modelli di delega che i difensori devono generalmente esaminare sono:

Delega non vincolata, in cui un servizio attendibile puo ricevere materiale Kerberos delegabile e usarlo oltre un singolo servizio backend.
Delega vincolata, in cui il servizio frontend e limitato a nomi principal di servizio specifici elencati in Active Directory.
Delega vincolata basata sulle risorse (RBCD), in cui la risorsa di destinazione controlla quali principal sono autorizzati ad agire per conto degli utenti verso quella risorsa.

Questi modelli non devono essere trattati come rischio equivalente. La delega non vincolata e di solito la priorita piu alta, perche la compromissione dell'host delegato puo esporre credenziali delegate riutilizzabili. La delega vincolata e RBCD possono comunque essere pericolose, in particolare quando i servizi consentiti sono troppo ampi o quando i permessi di scrittura permettono a un attaccante di modificare gli attributi di delega.

Come Funziona la Delega Kerberos

La delega Kerberos estende la normale autenticazione di servizio Kerberos. In un flusso Kerberos standard, un utente ottiene un ticket-granting ticket dal Key Distribution Center (KDC) e poi richiede ticket di servizio per servizi specifici. La delega aggiunge la possibilita che un servizio ottenga o usi ticket per conto dell'utente verso un altro servizio.

Con la delega non vincolata, l'account o il computer e contrassegnato come attendibile per la delega. Se un utente si autentica presso quel servizio con la delega abilitata, il servizio puo ricevere materiale Kerberos delegabile. Se l'host viene compromesso, l'attaccante potrebbe riutilizzare quell'accesso delegato. Per questo Microsoft Defender for Identity tratta la delega Kerberos non vincolata come una voce di valutazione della sicurezza: l'impostazione puo esporre credenziali privilegiate quando utenti sensibili si autenticano presso servizi delegati.

La delega vincolata restringe l'ambito. Invece di consentire la delega verso qualsiasi servizio, l'account puo delegare solo verso servizi configurati, rappresentati da valori come msDS-AllowedToDelegateTo. Il protocol transition cambia di nuovo il rischio, perche il servizio puo ottenere un ticket delegato per un utente senza che quest'ultimo si sia autenticato in precedenza via Kerberos presso quel servizio frontend, quando configurato per usare qualsiasi protocollo di autenticazione.

RBCD inverte parte del modello amministrativo. La risorsa stessa memorizza l'elenco dei principal autorizzati ad agire per conto degli utenti verso quella risorsa in msDS-AllowedToActOnBehalfOfOtherIdentity. Questo rende RBCD utile per alcuni scenari applicativi, ma significa anche che il controllo in scrittura su un oggetto computer puo diventare un percorso di delega.

Precondizioni Che Rendono Possibile l'Abuso di Delega

Le impostazioni di delega non sono automaticamente sfruttabili da sole. I casi pericolosi combinano di solito piu condizioni:

un server o account di servizio e configurato per la delega non vincolata ed e piu facile da compromettere degli utenti che vi si autenticano
utenti privilegiati o Domain Controller si autenticano presso sistemi che possono ricevere credenziali delegate
gli oggetti computer hanno ACL deboli che permettono a principal non amministrativi di modificare attributi legati alla delega
gli account di servizio hanno target di delega vincolata troppo ampi che non corrispondono piu al reale bisogno applicativo
esistono voci RBCD senza un owner documentato, una dipendenza applicativa o un processo di scadenza
i Domain Controller espongono percorsi di coercizione che portano l'autenticazione di account macchina verso sistemi dove il materiale delegato puo essere catturato o riutilizzato

La conclusione difensiva e pratica: una revisione della delega non e solo un elenco di attributi. Deve includere hardening degli host, percorsi di logon degli account privilegiati, ACL degli oggetti e ownership applicativo.

La Catena di Attacco

Un attacco di delega segue normalmente una sequenza piuttosto che un evento singolo.

L'attaccante identifica computer o account di servizio configurati per la delega.
L'attaccante compromette un host delegato, un account di servizio, o un'identita con accesso in scrittura su un oggetto computer.
L'attaccante attende o induce l'autenticazione di un account di valore, oppure modifica RBCD in modo che un principal controllato dall'attaccante possa impersonare gli utenti verso una risorsa di destinazione.
L'attaccante riutilizza l'accesso delegato risultante per raggiungere un servizio piu sensibile.
Se il percorso raggiunge i diritti di replica del Domain Controller, sistemi Tier-0 o servizi amministrativi privilegiati, l'attacco puo diventare una compromissione completa del dominio.

Per la delega non vincolata, i casi piu gravi coinvolgono account privilegiati o account macchina di Domain Controller che si autenticano presso un server delegato compromesso. Per RBCD, la domanda chiave e diversa: chi puo scrivere l'attributo di delega dell'oggetto computer di destinazione, e la relazione di fiducia risultante corrisponde a una dipendenza applicativa legittima?

Rilevamento

Nessun singolo evento Windows dimostra da solo un attacco di delega Kerberos. Il rilevamento nasce dalla correlazione tra inventario di delega, modifiche agli oggetti, attivita dei ticket di servizio Kerberos, eventi di logon e telemetria degli host.

Segnali dall'Inventario di Delega

Iniziate dai dati di configurazione:

account o computer con delega non vincolata abilitata
account con TrustedToAuthForDelegation abilitato
valori msDS-AllowedToDelegateTo popolati
valori msDS-AllowedToActOnBehalfOfOtherIdentity popolati
account privilegiati non contrassegnati come sensibili e quindi ancora idonei a percorsi di delega
ACL deboli su oggetti computer che permettono a principal inattesi di scrivere attributi legati alla delega

L'inventario da solo non basta, ma fornisce alle rilevazioni il contesto di cui hanno bisogno. Un evento 4769 di ticket di servizio e piu significativo quando si sa che l'account di servizio e configurato per una delega rischiosa.

Eventi Windows da Correlare

Event ID	Perche E Importante
4769	E stato richiesto un ticket di servizio Kerberos. Verificate servizio, client, cifratura e contesto di delega, quando disponibile.
4624	Logon riusciti su host o destinazioni delegate. I logon di rete da account macchina insoliti meritano un esame.
4672	Privilegi speciali sono stati assegnati a un nuovo logon, utile quando utenti privilegiati si autenticano presso sistemi delegati.
5136	Un oggetto del servizio directory e stato modificato. Monitorate gli attributi di delega e le modifiche alle ACL degli oggetti.
4738	Le modifiche a un account utente possono rivelare cambi di controllo account legati alla delega.
5145	L'accesso a condivisioni SMB puo aiutare a indagare coercizione o movimento laterale, ma non va trattato come prova da solo.

L'evento 5136 richiede la corretta policy di audit e copertura SACL. Microsoft documenta che viene generato quando un oggetto Active Directory viene modificato, ma un rilevamento utile dipende dal conservare i dettagli di oggetto, attributo e operazione.

Pattern di Rilevamento ad Alto Segnale

Date priorita a queste rilevazioni prima di scrivere regole di anomalia ampie:

un valore msDS-AllowedToActOnBehalfOfOtherIdentity nuovo o modificato su un oggetto computer
delega non vincolata abilitata su un sistema non-DC
un account privilegiato che si autentica presso un sistema configurato per la delega non vincolata
attivita di logon di account macchina di Domain Controller verso server membro inattesi
modifiche di attributi legati alla delega effettuate da account che non possiedono l'applicazione
voci RBCD in cui il principal agente e stato creato di recente, usato raramente, o non correlato al servizio di destinazione

L'alert dovrebbe includere entrambi i lati della relazione: l'account o il computer autorizzato a delegare, e il servizio o la risorsa verso cui avviene la delega.

Rimedio

Trattate la delega non vincolata su sistemi non-DC come un rilievo ad alta priorita. Se un'applicazione richiede ancora la delega, migrate verso un modello piu ristretto e dimostrate che l'elenco delle destinazioni e corretto.

1. Rimuovere la Delega Non Vincolata Dove Possibile

Identificate computer e account attendibili per la delega non vincolata, confermate l'ownership applicativo e rimuovete l'impostazione dai sistemi privi di un requisito di business attuale.

Get-ADComputer -Filter {TrustedForDelegation -eq $true} -Properties TrustedForDelegation |
  Select-Object Name, DistinguishedName, TrustedForDelegation

Non disabilitate la delega alla cieca sui server applicativi di produzione senza testare. Alcune applicazioni legacy possono dipendere dalla delega per l'autenticazione utente verso il backend. Il percorso di rimedio sicuro e: inventario, conferma del proprietario, staging, modifica e validazione.

2. Restringere la Delega Vincolata

Per i servizi che richiedono ancora la delega, restringete i servizi di destinazione consentiti al set minimo praticabile. Rivedete i valori msDS-AllowedToDelegateTo e rimuovete gli SPN obsoleti. Se il protocol transition e abilitato, verificate che l'applicazione ne abbia davvero bisogno e che l'account di servizio sia protetto come un'identita privilegiata.

3. Rivedere e Ripulire RBCD

Per RBCD, rivedete ogni valore msDS-AllowedToActOnBehalfOfOtherIdentity popolato. Ogni voce dovrebbe corrispondere a una dipendenza applicativa documentata. Se la voce esiste solo perche un troubleshooting la richiedeva mesi fa, rimuovetela. Rivedete anche chi puo scrivere sull'oggetto computer di destinazione, perche il controllo in scrittura e spesso la vera vulnerabilita.

4. Proteggere gli Account Privilegiati dall'Esposizione da Delega

Gli utenti privilegiati non dovrebbero autenticarsi in modo interattivo su server a fiducia inferiore. Usate amministrazione a livelli, workstation di amministrazione dedicate e restrizioni di logon in modo che le credenziali Tier 0 non finiscano su host delegati. Per gli account sensibili, rivedete le impostazioni dell'account e il modello operativo che previene l'esposizione da delega.

5. Ridurre l'Esposizione alla Coercizione sui Domain Controller

Se il servizio Print Spooler non e necessario sui Domain Controller, disabilitarlo rimuove un noto vettore di autenticazione tramite account macchina usato nelle catene di abuso della delega. Trattatelo come un livello di protezione, non come l'unico rimedio. Il problema di fondo resta la delega non sicura e l'esposizione delle credenziali.

Validazione Dopo il Rimedio

Il rimedio della delega non e completo finche non validate sia la sicurezza sia il comportamento applicativo:

confermate che i sistemi non-DC non abbiano piu delega non vincolata, salvo approvazione esplicita
confermate che gli SPN di destinazione rimanenti della delega vincolata corrispondano al design applicativo
confermate che le voci RBCD abbiano owner documentati e nessun principal agente inatteso
testate il flusso applicativo che in precedenza richiedeva la delega
monitorate l'evento 5136 per rilevare nuove scritture di attributi di delega dopo la pulizia
monitorate i logon privilegiati verso host delegati per almeno una finestra di change dopo il rimedio
rivedete le ACL degli oggetti computer per assicurarvi che gli attaccanti non possano ricostruire il percorso di delega

La domanda finale di validazione e semplice: se un attaccante compromette lo stesso server applicativo domani, potrebbe ancora raccogliere o creare accesso delegato verso una risorsa piu attendibile?

Come EtcSec Rileva Questo

EtcSec verifica le impostazioni di delega su computer e account di servizio a ogni scansione AD.

UNCONSTRAINED_DELEGATION identifica sistemi e account configurati per la delega non vincolata.

CONSTRAINED_DELEGATION evidenzia impostazioni di delega vincolata rischiose o troppo ampie.

RBCD_ABUSE rivela relazioni di delega vincolata basata sulle risorse che meritano una revisione perche possono offrire un percorso di impersonificazione inatteso.

Controlli Correlati

La revisione della delega andrebbe fatta insieme a Rilevamento prevenzione kerberoasting: come individuare e proteggere gli account di servizio esposti al cracking offline, Abuso ACL e DCSync: Percorsi verso Domain Admin, Monitoraggio Sicurezza AD: Event ID e SIEM, Configurazioni Errate GPO come Vettore di Attacco e Golden Ticket: Le Chiavi del Tuo Dominio. Negli ambienti reali questi percorsi vengono di solito concatenati piuttosto che sfruttati in isolamento.

Attacchi di Delega Kerberos: da Non Vincolata all'Abuso RBCD