[Un giorno, navigando su YouTube, ci siamo imbattuti in una presentazione del Black Hat 2015 di Tal Be'ery e Michael Cherny. Nel loro intervento e nel successivo brief, Watching the Watchdog: Protecting Kerberos Authentication with Network Monitoring, Be'ery e Cherny hanno descritto qualcosa di cui non avevamo mai sentito parlare... l'attacco Diamond Privilege Attribute Certificate (PAC). Nell'ultimo anno ci siamo entrambi interessati alla falsificazione dei ticket, quindi questa tecnica ha immediatamente attirato la nostra attenzione e ci ha fatto intraprendere un viaggio di approfondimento e di armamento PoC. Il risultato? Il Diamond Ticket.
Lettura correlata
Golden Ticket vs Diamond Ticket
Sia gli attacchi Golden che quelli Diamond Ticket richiedono l'accesso alla chiave KRBTGT. Tuttavia, gli attacchi Diamond Ticket richiedono quasi certamente anche l'accesso alla chiave AES256. Mentre gli attacchi Golden Ticket sfruttano la capacità di falsificare da zero un ticket di concessione dei biglietti (TGT), gli attacchi Diamond Ticket sfruttano la capacità di decifrare e ricifrare TGT autentici richiesti da un controller di dominio (DC).
Diamond PAC vs Diamond Ticket
L'attacco Diamond PAC originale:
- Richiede un TGT senza PAC
- Assicura che l'account di servizio per il servizio a cui si deve accedere non abbia il bit NA nel suo attributo UserAccountControl (UAC).
- Falsifica un PAC e lo firma con la chiave KRBTGT
- Inietta il PAC nel ticket di servizio risultante includendo il PAC nel file enc_authorization_data della sezione TGS-REQ
Il bit NA dell'attributo UAC ha il valore 33554432 (vedere Figura 1).
Dopo aver impostato il bit NA nell'attributo UAC di un account di servizio, le richieste di ticket di servizio a quell'account di servizio non hanno PAC (vedere Figura 2).
Ogni volta che i dati di autorizzazione sono inclusi nel campo enc_authorization_data di un TGS-REQ (vedere Figura 3), vengono copiati nella sezione dati_autorizzazione della parte criptata del ticket di servizio risultante.
Diamond PAC ha sfruttato questo comportamento per iniettare un PAC nel ticket di servizio risultante quando l'account di servizio di destinazione non aveva il bit NA (vedi Figura 4).
Si noti la differenza di dimensioni dell'output del biglietto tra la Figura 2 e la Figura 4.
Come mostra la Figura 5, il biglietto appartiene a Loki ma il PAC ha informazioni diverse sull'utente (cioè Thor).
Grazie allepatch Kerberos/AD del novembre 2021 , l'utilizzo di un TGT senza PAC non è più possibile sui DC completamente aggiornati. Quindi, abbiamo capito subito che questa versione dell'attacco non avrebbe più funzionato. Tuttavia, dopo averlo letto, ci siamo chiesti perché l'attacco dovesse essere così complesso. Nel processo di semplificazione dell'attacco, abbiamo eliminato la maggior parte dei suoi requisiti, rendendolo possibile su DC completamente aggiornati.
La chiave KRBTGT era un requisito, e l'attacco utilizzava qualsiasi altro account valido per richiedere un TGT. Perché non decriptare il TGT, modificarlo a nostro piacimento, ricalcolare le firme PAC e crittografarlo nuovamente? Abbiamo ribattezzato questo approccio come attacco Diamond Ticket.
Armamento di Rubeus
Abbiamo implementato il nostro Biglietto Diamante in Rubeus con un nuovo comando, il diamante.
-all'interno di questa PR. Nella dimostrazione che segue, utilizziamo questo nuovo comando per creare e utilizzare un Diamond Ticket.
Si inizia l'attacco tentando di accedere al file C$ (CIFS) su un DC, utilizzando il nostro utente con privilegi bassi (Loki). Come mostra la Figura 6, otteniamo una risposta Access is denied .
Supponendo di aver compromesso in precedenza la chiave KRBTGT, possiamo utilizzare il nuovo comando diamante
in Rubeus per creare un Diamond Ticket. Questo comando richiede innanzitutto un normale TGT per l'utente a basso privilegio Loki (vedere Figura 7). Il comando decifra quindi il TGT, modifica le parti rilevanti, ricalcola le firme e cripta nuovamente il TGT (cfr. Figura 8).
Il ticket risultante può essere utilizzato come qualsiasi altro TGT, ma ora con delle modifiche. Come mostra la Figura 9, abbiamo richiesto un ticket di servizio al servizio CIFS sul nostro DC di destinazione(Earth-DC).
Infine, nello stesso terminale, possiamo ora accedere al file C$ sul DC, autenticandoci come utente diverso dall'account che ha richiesto il TGT (vedi Figura 10).
Vantaggi OPSEC
Esistono molti modi potenziali per rilevare l'uso del Golden Ticket o le azioni necessarie per ottenere l'accesso alla chiave KRBTGT (come DCSync). Una tecnica: Monitorare le richieste di ticket di servizio (TGS-REQ) che non hanno una richiesta TGT corrispondente (AS-REQ). Tuttavia, è bene tenere presente che la tecnica Diamond Ticket ha maggiori probabilità di aggirare questo tipo di rilevamento richiedendo un TGT valido prima di utilizzare il ticket risultante. Inoltre, poiché il ticket viene creato prima da un DC, è più probabile che alcuni valori (ad esempio, i tempi del ticket) siano corretti per impostazione predefinita, anziché richiedere il calcolo dei tempi corretti per la creazione del Golden Ticket OPSEC.
Guida al rilevamento
La ricerca originale del Diamond PAC elencava le seguenti indicazioni per il rilevamento basato sulla rete:
- Un AS-REQ con un PA-PAC-REQUEST impostato su falso
- L'aggiunta di dati di autorizzazione in un successivo messaggio TGS
- Il servizio di destinazione bit NA impostato su false, richiede il PAC per l'autorizzazione
Data la nostra tecnica migliorata, questa guida non è applicabile. L'attacco Diamond Ticket non richiede la richiesta di un TGT senza PAC, né l'invio di un PAC contraffatto all'interno di un file enc_authorization_data di un TGS-REQ, né di impostare il bit NA su qualsiasi account di servizio.
Tuttavia, alcune logiche di rilevamento per gli attacchi Golden Ticket (ad esempio, le azioni necessarie per ottenere l'accesso alla chiave KRBTGT ) potrebbero essere applicate anche al rilevamento di un attacco Diamond Ticket. Molte altre tecniche che possono essere utilizzate per rilevare qualsiasi tipo di biglietto contraffatto (Golden, Silver o Diamond) dipendono in larga misura dal livello di attenzione prestato durante la creazione del biglietto, ad esempio l'impostazione di orari diversi da quelli previsti.
Nessuno di questi metodi garantisce l'individuazione di questo attacco, così come non esistono proiettili d'argento per individuare i Golden Ticket.
Un nuovo approccio ai biglietti
Questo post ha cercato di dimostrare una minima arma PoC dei Diamond Ticket, sebbene un'implementazione in stile Mimikatz. Questa ricerca può essere facilmente estesa per fornire il pieno controllo e la manipolazione di qualsiasi biglietto, date le chiavi giuste.
Al termine della nostra ricerca e della creazione di un'arma PoC, Elad Shamir ci ha inviato l ' intervento di Tim Medin al DerbyCon 2014, Attaccare Microsoft Kerberos dando un calcio al cane da guardia dell'Ade. In questo intervento, Tim discute la stessa tecnica nel contesto dei ticket di servizio.
Sebbene la nostra tecnica sia una versione leggermente diversa dei biglietti d'oro e d'argento, potrebbe rappresentare un'alternativa utile e preferibile in determinati ambienti.
