Ticket Kerberos dopo disabilitazione account: durata e contenimento

Ticket Kerberos dopo disabilitazione account: perché le sessioni persistono

La durata dei ticket Kerberos dopo disabilitazione account è importante perché modificare lo stato di un account non annulla automaticamente i ticket già emessi per quell'account. Microsoft documenta che i ticket di servizio validi emessi prima della disabilitazione possono ancora consentire l'accesso. Chi gestisce la risposta deve quindi raccogliere prove sull'account, sui ticket e sulle risorse che li accettano, invece di considerare la disabilitazione come prova di un contenimento completato. Microsoft Learn: durata del ticket utente

Esiste un secondo limite: una connessione autenticata può sopravvivere al ticket che l'ha stabilita. Microsoft spiega che i ticket di servizio autenticano le nuove connessioni; la scadenza non interrompe le operazioni in corso su una connessione già autenticata. Attendere l'ora di fine del ticket non è quindi una prova sufficiente che l'accesso sia cessato. Microsoft Learn: durata del ticket di servizio

In un'indagine di risposta, considerate tre domande separate. L'identità può ottenere un altro ticket? Un ticket già posseduto può autenticare un'altra connessione? Una connessione precedentemente autenticata è ancora operativa? Sono domande investigative derivate da quei limiti documentati, non tre fasi attraversate da ogni incidente. Tenetele separate nel registro dell'incidente affinché le prove relative a una non chiudano accidentalmente le altre.

Questa guida riguarda i ticket legittimi già emessi, incluso il problema del contenimento quando tale materiale è stato rubato. Per la minaccia distinta dei TGT falsificati a partire da un segreto krbtgt compromesso, consultate l'attacco Golden Ticket e il suo prerequisito krbtgt. Per distinguere la falsificazione di un ticket di servizio dal riutilizzo di un ticket rubato, consultate il confronto tra Silver Ticket e Pass-the-Ticket e il confronto tra Pass-the-Hash, Overpass-the-Hash e Pass-the-Ticket. Le relative sequenze d'attacco sono separate dalle decisioni su durata e contenimento presentate qui.

I tre orologi: TGT, ticket di servizio e connessione stabilita

Il ticket di concessione dei ticket, o TGT, serve a ottenere ulteriori ticket Kerberos. Il ticket di servizio viene presentato a un servizio specifico. La connessione stabilita ha poi una propria durata, che il criterio dei ticket di servizio non definisce. Tenete distinti i due orologi dei ticket e quello della connessione; la finestra di rinnovo è un ulteriore limite per i TGT rinnovabili. Microsoft Learn: durata del ticket di servizio, RFC 4120 §2.3

I valori seguenti sono i valori predefiniti documentati da Microsoft, non misurazioni del vostro dominio. Le chiavi e le unità sono specificate in MS-GPSB §2.2.2, Kerberos Policy.

Convertite ore e minuti prima di confrontare i valori. MS-GPSB identifica MaxTicketAge come il limite superiore correlato a MaxServiceAge; la pagina Learn sui ticket di servizio contiene un refuso che confronta il parametro con se stesso e che non deve diventare una regola operativa. Lo scarto di cinque minuti è una tolleranza, non un ritardo di contenimento garantito. MS-GPSB, Microsoft Learn: tolleranza di sincronizzazione degli orologi

Sette giorni di rinnovo non significano che ogni TGT rimanga valido ininterrottamente per sette giorni. Un ticket rinnovabile ha una scadenza individuale e un limite finale di rinnovo. Ridurre quella finestra ha anche conseguenze sulla disponibilità per gli utenti che non possono raggiungere frequentemente un controller di dominio. Microsoft Learn: rinnovo del ticket utente, RFC 4120 §2.3

I controlli dell'account limitano i nuovi ticket senza annullare automaticamente quelli già emessi

Windows esegue controlli dell'account durante le richieste di ticket. MS-KILE §5.1.3 richiede ai KDC del dominio dell'account di controllare l'account quando il TGT presentato ha più di 20 minuti. MS-KILE §3.3.5.7.1 specifica le condizioni: la convalida dei criteri dell'account deve essere abilitata e il KDC deve appartenere al dominio dell'account dell'utente. Un KDC di un altro dominio non può eseguire quel controllo. In tali condizioni, un account disabilitato viene rifiutato con KDC_ERR_CLIENT_REVOKED.

Si tratta dell'elaborazione delle richieste, non di un timer che disconnette ogni sessione al minuto 20. Limita la successiva emissione di TGS e non ritira un ticket di servizio già ottenuto. Anche le richieste di TGT hanno controlli documentati dei criteri dell'account, incluso il rifiuto degli account disabilitati quando l'opzione di convalida è abilitata. MS-KILE §3.3.5.6.3

Il protocollo descrive anche un meccanismo di revoca. RFC 4120 §3.3.3.1 specifica una hot-list controllata dal servizio di concessione dei ticket, che impedisce ai ticket annullati di ottenere ticket aggiuntivi. La distingue dai ticket ordinari già ottenuti, che restano validi fino alla loro normale scadenza. Questa specifica non stabilisce un comando universale di amministrazione Windows per revocare globalmente i ticket di un utente. RFC 4120 §3.3.3.1

Cambiare la password dell'utente non sostituisce automaticamente le chiavi di sessione e i ticket già posseduti. È una deduzione crittografica dallo scambio TGS: il TGT viene elaborato con la chiave del servizio di concessione dei ticket e la risposta utilizza una chiave di sessione invece del segreto a lungo termine del client. Non garantisce che tutte le autenticazioni future avranno successo dopo un ripristino della password. RFC 4120 §§3.3.2–3.3.3

La rimozione da un gruppo ha un altro limite. I SID dei gruppi globali e universali entrano nel PAC durante l'emissione iniziale del TGT e vengono copiati nei TGT rinnovati. Il solo rinnovo non garantisce quindi un'appartenenza aggiornata. I gruppi locali del dominio della risorsa vengono aggiunti durante l'emissione del ticket di servizio; non generalizzate affermando che tutti i gruppi rimangano congelati al primo TGT. MS-PAC §4.1.2.1, MS-KILE §3.3.5.7.3

Rilevamento

1. Costruire una cronologia dai log dell'account, del KDC e della destinazione

Utilizzate gli eventi Windows documentati di seguito come elementi di prova. La strategia di correlazione è una raccomandazione analitica basata sui loro campi e sui limiti del protocollo descritti sopra; non viene dichiarato alcun risultato di laboratorio o di rilevamento in produzione.

L'evento 4768 non copre tutti gli errori dei TGT: Microsoft documenta che i codici di risultato 0x10 e 0x18 generano invece l'evento 4771. Includete questi errori di preautenticazione quando esaminate le richieste non riuscite. Microsoft Learn: copertura di 4768

Ancorate l'incidente al destinatario di 4725, non all'amministratore che lo ha disabilitato. Associate quell'identità ai nomi normalizzati negli eventi Kerberos: 4769 non fornisce lo stesso campo SID dell'utente di destinazione presente in 4725. Conservate l'evento grezzo e la decisione di corrispondenza. Utilizzate l'host di destinazione insieme al suo identificatore di accesso quando associate 4624 e 4634; Microsoft documenta che gli identificatori di accesso sono univoci solo tra riavvii dello stesso computer. Definizioni dei campi di 4725, definizioni dei campi di 4769, limiti di correlazione di 4634

Date priorità alle richieste di ticket riuscite o ai nuovi accessi sulle destinazioni dopo la disabilitazione, agli host di origine inattesi e all'attività che continua su connessioni note. Esaminate il KDC del dominio dell'account, l'impostazione di convalida, l'età del TGT e la cronologia dell'incidente prima di interpretare una successiva richiesta TGS riuscita. Sono piste investigative derivate da KILE, non una prova automatica di furto di ticket. Gli eventi mancanti lasciano una lacuna di visibilità; non dimostrano che una connessione sia terminata. Corroborate la cronologia con l'inventario attuale delle connessioni del proprietario della risorsa e la traccia di audit dell'applicazione.

2. Misurare i criteri sui controller di dominio pertinenti

Gli esempi seguenti sono adattati dalla documentazione: non sono comandi eseguiti in un ambiente AD. Utilizzate un contesto autorizzato, gli strumenti e i moduli necessari e una directory di report esistente e scrivibile. L'esempio locale gpresult riguarda il DC su cui viene eseguito. Leggete le impostazioni Kerberos Policy nel report insieme al contesto delle GPO applicate. Microsoft Learn: gpresult

gpresult /scope computer /h C:\Temp\Kerberos-RSoP.html

Esaminate le impostazioni della Default Domain Policy con il report seguente. Il suo GUID noto è anche la chiave di ricerca dell'helper del collector in helpers/gpo_policy.go:11. Un report relativo a una sola GPO non dimostra da solo i criteri effettivi su ogni DC. Microsoft Learn: Get-GPOReport

Get-GPOReport -Guid 31B2F340-016D-11D2-945F-00C04FB984F9 -ReportType XML

Esaminate altre GPO, inclusi collegamenti e filtri, con un report separato. Selezionate il dominio e il server effettivi tramite i parametri documentati quando il contesto corrente non è adatto. Get-GPOReport

Get-GPOReport -All -ReportType XML

Get-ADDefaultDomainPasswordPolicy non legge i criteri Kerberos. Il suo output è l'oggetto dei criteri password predefiniti del dominio; non utilizzatelo per affermare che MaxTicketAge o MaxRenewAge siano stati verificati. Microsoft Learn: Get-ADDefaultDomainPasswordPolicy

3. Esaminare i ticket realmente presenti sugli host nel perimetro

I seguenti esempi separati provengono da Microsoft Learn: klist. Leggete la cache della sessione corrente:

klist

Esaminate il suo TGT, inclusi l'ora di fine e il limite di rinnovo:

klist tgt

Enumerate le sessioni di accesso locali prima di presumere che la cache dell'utente corrente copra l'host:

klist sessions

Selezionate una sessione di accesso con -li, che specifica la parte bassa del suo LUID; utilizzate anche -lh se la parte alta è diversa da zero. 0x3e7 è l'esempio documentato da Microsoft:

klist -li 0x3e7

Registrate host, sessione, ora di raccolta e orari dei ticket. Queste osservazioni coprono la cache selezionata, non le copie di ticket su un altro sistema. Mantenete quel perimetro nel registro della risposta.

Interventi correttivi (Remediation)

1. Ridurre le durate eccessive prima di un incidente

Le indicazioni Microsoft sui ticket utente propongono 4–10 ore, con richieste più frequenti che aumentano il carico del KDC. Testate il valore scelto rispetto ai flussi di lavoro legittimi. Configurate le impostazioni Kerberos del dominio in Computer Configuration > Windows Settings > Security Settings > Account Policies > Kerberos Policy. Microsoft Learn: durata del ticket utente

Per una preparazione mirata agli account privilegiati, esaminate i criteri di autenticazione e i silo per TGT Tier 0 più brevi e restrizioni sui dispositivi. Tenete questa decisione di distribuzione separata dalla pulizia d'emergenza delle cache.

Ridurre una durata in una GPO non è una cancellazione retroattiva. È una deduzione dai periodi di validità contenuti nei ticket e dalle operazioni sulla cache locale documentate sopra. Applicate la modifica e verificate i ticket appena emessi; conservate separatamente le prove relative ai ticket esistenti. RFC 4120, klist

2. Contenere l'identità e le risorse durante l'incidente

Disabilitate l'identità interessata e reimpostatene la password secondo le necessità delle autenticazioni future, quindi isolate gli host compromessi e inventariate le connessioni che coinvolgono quell'identità. L'isolamento e la chiusura dal lato della risorsa sono raccomandazioni operative dedotte dalla persistenza documentata delle connessioni autenticate, non una procedura universale di ripristino Microsoft. Assegnate un responsabile a ciascun host e servizio interessato e registrate quale percorso di accesso copre ogni azione. MS-KILE: controlli dell'account per il TGT, Microsoft Learn: durata del ticket di servizio

Su un host che controllate, eliminate i ticket della sessione corrente con questo comando documentato:

klist purge

Per una sessione selezionata, l'esempio Microsoft è un'operazione separata:

klist purge -li 0x3e7

Senza un selettore LUID, la cancellazione si applica alla sessione di accesso corrente. Non raggiunge altre cache o ticket copiati altrove. Chiudete le connessioni pertinenti e predisponete una nuova autenticazione come parte della risposta. La sola cancellazione dei ticket non dimostra che ogni connessione applicativa sia terminata. klist, limite della connessione relativo al ticket di servizio

L'operatore responsabile può scegliere di riavviare un host o un servizio per chiudere i contesti locali quando le singole sessioni non possono essere controllate. Trattatela come una decisione operativa locale, non come una revoca a livello di dominio o una prova di eradicazione. Qui non viene prescritto alcun comando universale di riavvio.

3. Riservare il ripristino di krbtgt alla compromissione di quel segreto

La disabilitazione di un utente ordinario non giustifica due rotazioni di krbtgt. Se quel segreto è compromesso, seguite la pianificazione del ripristino del dominio. La procedura Microsoft di ripristino della foresta richiede due reimpostazioni perché la cronologia conserva due password. Attendete 10 ore tra le reimpostazioni con i valori predefiniti; se le durate massime sono state modificate, l'attesa minima deve essere superiore alla durata configurata. Verificate la replica e il perimetro dei DC prima di pianificare la seconda operazione. La procedura citata si applica ai DC scrivibili, non agli account krbtgt_number dei RODC. Microsoft Learn: reimpostare la password krbtgt

Non deducete che quelle reimpostazioni distruggano tutti i ticket di servizio emessi o tutte le connessioni esistenti. Le loro chiavi di servizio e i contesti stabiliti costituiscono limiti separati. Convalidate in modo indipendente i nuovi tentativi di accesso, le cache locali e le connessioni precedentemente aperte; registrate i risultati effettivi quando il team di risposta esegue quei controlli. RFC 4120 §3.3, Microsoft Learn: durata del ticket di servizio

Come EtcSec rileva questo problema

L'etc-collector di EtcSec identifica durate configurate eccessive tramite tre identificatori reali di detector. Le affermazioni seguenti derivano dall'ispezione statica delle loro implementazioni Detect(), non da un audit eseguito sul dominio di un cliente. I percorsi seguenti sono relativi a public/internal/audit/detectors/ad/ nel codice sorgente del collector.

I confronti sono stretti: 10 ore e 7 giorni non attivano questi rilievi. Il controllo aggregato si sovrappone ai due controlli specializzati; si tratta di due controlli di durata e uno aggregato, non di tre capacità di contenimento indipendenti. Non rilevano il furto di ticket, non terminano le sessioni e non implementano la revoca dei ticket utente.

Gli input principali sono le impostazioni Kerberos estratte da GptTmpl.inf in SYSVOL, in public/internal/providers/smb/gptmpl_parser.go:221–227. L'helper public/internal/audit/helpers/gpo_policy.go:42–54 preferisce la Default Domain Policy, poi un'altra GPO disponibile con impostazioni Kerberos. Non calcola la precedenza RSoP completa. Confrontate il rilievo con i criteri effettivi del DC pertinente e con i ticket osservati prima di dichiarare completato l'intervento correttivo.

I detector specializzati selezionano valori positivi e contengono meccanismi alternativi basati su DomainInfo. MaxTicketAge=0, nonostante il significato documentato da Microsoft di assenza di scadenza, non viene segnalato dal confronto di durata. Anche input mancanti o pari a zero possono lasciare Count=0. Il controllo aggregato restituisce immediatamente Count=0 quando DomainInfo è nil, anche in presenza di dati dei criteri SYSVOL (weak-kerberos-policy.go:25–33). I suoi dettagli dipendono da IncludeDetails. Nessuno di questi tre confronti controlla la durata dei ticket di servizio, lo scarto degli orologi o il flag di convalida dell'account.

Il registro finale della risposta deve associare le durate configurate alle prove delle cache di ticket, ai risultati delle richieste KDC e ai controlli delle connessioni dal lato delle risorse. Sono le prove necessarie per distinguere criteri corretti da un accesso che è realmente terminato.