ralfhacker/kerbeus-bofBOF per l'abuso di Kerberos (un'implementazione di alcune importanti caratteristiche di Rubeus).
Beacon Object Files per abuso di Kerberos. Questa è un'implementazione di alcune importanti caratteristiche del progetto Rubeus, scritta in C. Il progetto include l'integrazione con i framework C2 Cobalt Strike, Havoc, AdaptixC2 e Outflank C2.
L'azione asktgt costruirà traffico AS-REQ (richiesta TGT) grezzo per l'utente e la chiave di crittografia specificati (/rc4 o /aes256). È possibile usare anche il flag /password invece di un hash – in questo caso /enctype:X sarà predefinito su RC4. Se non viene specificato /domain, viene estratto il dominio corrente del computer; se non viene specificato /dc, si fa lo stesso per il controller di dominio corrente del sistema. Se l'autenticazione ha successo, l'AS-REP risultante viene analizzato e il KRB-CRED (un .kirbi, che include il TGT dell'utente) viene emesso come blob in base64. Il flag /ptt esegue un "pass-the-ticket" e applica la credenziale Kerberos risultante alla sessione di logon corrente. Nota opsec: solo un TGT può essere applicato per volta alla sessione di logon corrente, quindi il TGT precedente viene cancellato quando viene applicato il nuovo ticket usando l'opzione /ptt.
Per formulare richieste AS-REQ più conformi a quelle genuine, è possibile usare il flag /opsec. Questo invierà prima una AS-REQ iniziale senza pre-autenticazione; se ha successo, l'AS-REP risultante viene decifrato e viene restituito il TGT, altrimenti viene quindi inviata una AS-REQ con pre-autenticazione.
Richiedere un TGT senza PAC può essere fatto usando l'opzione /nopac. Il flag /nopreauth può essere usato per inviare una AS-REQ senza pre-autenticazione.
krb_asktgt /user:USER /password:PASSWORD [/domain:DOMAIN] [/dc:DC] [/enctype:{rc4|aes256}] [/ptt] [/nopac] [/opsec]
krb_asktgt /user:USER /aes256:HASH [/domain:DOMAIN] [/dc:DC] [/ptt] [/nopac] [/opsec]
krb_asktgt /user:USER /rc4:HASH [/domain:DOMAIN] [/dc:DC] [/ptt] [/nopac]
krb_asktgt /user:USER /nopreauth [/domain:DOMAIN] [/dc:DC] [/ptt]
L'azione asktgs costruirà/analizzerà una richiesta di ticket di servizio TGS-REQ/TGS-REP grezza usando il TGT fornito /ticket:X. Questo valore deve essere una codifica base64 di un file .kirbi. Se non viene specificato /dc, viene estratto il controller di dominio corrente del computer e utilizzato come destinazione per il traffico della richiesta. Il flag /ptt esegue un "pass-the-ticket" e applica il ticket di servizio risultante alla sessione di logon corrente. È obbligatorio specificare uno o più SPN /service:X, separati da virgola.
I tipi di crittografia supportati nella TGS-REQ costruita sono RC4_HMAC e AES256_CTS_HMAC_SHA1. In questo caso, la crittografia mutuamente supportata più elevata sarà utilizzata dal KDC per costruire il ticket di servizio restituito. Se si desidera forzare le chiavi RC4 o AES256, usare /enctype:[rc4 o aes256].
Per formulare richieste TGS-REQ più conformi a quelle genuine, è possibile usare il flag /opsec. Questo farà sì che venga inviata automaticamente anche una TGS-REQ aggiuntiva quando viene richiesto un ticket di servizio per un account configurato per la delega senza vincoli.
Il flag /u2u è stato implementato per richiedere ticket User-to-User. Insieme all'argomento /tgs:X (usato per fornire il TGT dell'account di destinazione), l'argomento /service:X può essere il nome utente dell'account per il quale è stato fornito il TGT (con l'argomento /tgs:X). L'argomento /targetuser:X richiederà un PAC di qualsiasi altro account inserendo una sezione dati PA-FOR-USER con il nome utente dell'utente di destinazione.
Il flag /keyList è stato implementato per le richieste di elenco chiavi Kerberos. Queste richieste devono utilizzare un TGT parziale falsificato proveniente da un controller di dominio di sola lettura nel parametro /ticket:BASE64. Inoltre, il campo /spn:x deve essere impostato sull'SPN KRBTGT all'interno del dominio, ad es. KRBTBT/domain.local.
krb_asktgs /ticket:BASE64 /service:SPN1,SPN2,... [/domain:DOMAIN] [/dc:DC] [/tgs:BASE64] [/targetdomain:DOMAIN] [/targetuser:USER] [/enctype:{rc4|aes256}] [/ptt] [/keylist] [/u2u] [/opsec]
L'azione renew costruirà/analizzerà uno scambio di rinnovo TGT TGS-REQ/TGS-REP grezzo usando il ticket fornito /ticket:X. Questo valore deve essere una codifica base64 di un file .kirbi. Se non viene specificato /dc, viene estratto il controller di dominio corrente del computer e utilizzato come destinazione per il traffico di rinnovo. Il flag /ptt esegue un "pass-the-ticket" e applica la credenziale Kerberos risultante alla sessione di logon corrente.
krb_renew /ticket:BASE64 [/dc:DC] [/ptt]
Se un account utente (o computer) è configurato per la delega vincolata (cioè ha un valore SPN nel campo msds-allowedtodelegato), questa azione può essere utilizzata per abusare dell'accesso all'SPN/server di destinazione.
Una spiegazione TL;DR è che un account con delega vincolata abilitata è autorizzato a richiedere ticket a se stesso come qualsiasi utente, in un processo noto come S4U2self. Affinché un account possa farlo, deve avere TrustedToAuthForDelegation abilitato nella sua proprietà useraccountcontrol, qualcosa che solo utenti con privilegi elevati possono modificare per impostazione predefinita. Questo ticket ha il flag FORWARDABLE impostato per impostazione predefinita. Il servizio può quindi utilizzare questo ticket appositamente richiesto per richiedere un ticket di servizio per qualsiasi nome principale del servizio (SPN) specificato nel campo msds-allowedtodelegato dell'account. In breve, se hai il controllo di un account con TrustedToAuthForDelegation impostato e un valore in msds-allowedtodelegato, puoi impersonare qualsiasi utente del dominio per gli SPN impostati nel campo msds-allowedtodelegato dell'account.
Il ticket S4U2self può quindi essere utilizzato come parametro /tgs:Y (blob base64) per eseguire il processo S4U2proxy. Deve essere fornito un valore msds-allowedtodelegato valido per l'account (/service:X).
Il parametro /altservice ci consente di sostituire qualsiasi nome di servizio desiderato nel file KRB-CRED risultante. Possono essere forniti uno o più nomi di servizio alternativi, separati da virgola (/altservice:cifs,HOST,...).
Per formulare le TGS-REQ più conformi a quelle genuine, è possibile usare il flag /opsec.
In determinate circostanze, è possibile utilizzare un ticket S4U2Self per impersonare utenti protetti al fine di scalare i privilegi sul sistema richiedente, come discusso qui. A questo scopo, è possibile usare il flag /self e l'argomento /altservice:X per generare un ticket di servizio utilizzabile.
Per falsificare un rinvio S4U2Self, è richiesta solo la chiave di trust. Usando l'argomento /targetdomain:X con il flag /self e senza l'argomento /targetdc, il ticket fornito con /ticket:X viene trattato come un rinvio S4U2Self e viene richiesto solo il ticket di servizio S4U2Self finale. È possibile usare anche /altservice:X per riscrivere lo sname nel ticket risultante.
krb_s4u /ticket:BASE64 /service:SPN {/impersonateuser:USER | /tgs:BASE64} [/domain:DOMAIN] [/dc:DC] [/altservice:SERVICE] [/ptt] [/nopac] [/opsec] [/self]
krb_cross_s4u /ticket:BASE64 /service:SPN /targetdomain:DOMAIN /targetdc:DC {/impersonateuser:USER | /tgs:BASE64} [/domain:DOMAIN] [/dc:DC] [/altservice:SERVICE] [/nopac] [/self]
L'azione ptt invierà un /ticket:X (TGT o ticket di servizio) per la sessione di logon corrente tramite l'API LsaCallAuthenticationPackage() con un messaggio KERB_SUBMIT_TKT_REQUEST, oppure (se eseguita con privilegi elevati) per la sessione di logon specificata da /luid:ea4... Come per altri parametri /ticket:X, il valore può essere una codifica base64 di un file .kirbi.
krb_ptt /ticket:BASE64 [/luid:LOGONID]
L'azione purge eliminerà tutti i ticket Kerberos dalla sessione di logon corrente, o (se eseguita con privilegi elevati) dalla sessione di logon specificata da /luid:0xA...
krb_purge [/luid:LOGONID]
L'azione describe prende un valore /ticket:X (TGT o ticket di servizio), lo analizza e descrive i valori del ticket. Come per altri parametri /ticket:X, il valore può essere una codifica base64 di un file .kirbi.
krb_describe /ticket:BASE64
klist elenca informazioni dettagliate sulla sessione di logon dell'utente corrente e sui ticket Kerberos, se non eseguito con privilegi elevati. Se eseguito da un contesto elevato (SYSTEM), vengono visualizzate informazioni su tutte le sessioni di logon e i ticket Kerberos associati. Le informazioni di logon e ticket possono essere visualizzate per uno specifico LogonID con /luid:3ea.. (se eseguito con privilegi elevati).
krb_klist [/luid:LOGINID] [/user:USER] [/service:SERVICE] [/client:CLIENT]
L'azione dump estrarrà i TGT e i ticket di servizio correnti se eseguita in un contesto elevato (SYSTEM). Se non è elevata, vengono estratti i ticket di servizio per l'utente corrente.
krb_dump [/luid:LOGINID] [/user:USER] [/service:SERVICE] [/client:CLIENT]
L'azione triage emetterà una tabella dei ticket Kerberos dell'utente corrente, se non eseguita con privilegi elevati. Se eseguita da un contesto elevato (SYSTEM), viene visualizzata una tabella che descrive tutti i ticket Kerberos sul sistema.
krb_triage [/luid:LOGINID] [/user:USER] [/service:SERVICE] [/client:CLIENT]
Per klist, triage e dump, i ticket possono essere filtrati per /luid, /service e /client.
È necessario il contesto SYSTEM.
L'azione tgtdeleg abusa della GSS-API di Kerberos per recuperare un TGT utilizzabile per l'utente corrente senza necessità di elevazione sull'host. Viene utilizzata AcquireCredentialsHandle() per ottenere un handle alle credenziali di sicurezza Kerberos dell'utente corrente e InitializeSecurityContext() con il flag ISC_REQ_DELEGATE e un SPN di destinazione CIFS/DC.domain.com per preparare un contesto di delega fittizio da inviare al DC. Ciò produce un AP-REQ nell'output GSS-API che contiene un KRB_CRED nel checksum dell'authenticator. La chiave di sessione del ticket di servizio viene estratta dalla cache Kerberos locale e utilizzata per decifrare il KRB_CRED nell'authenticator, ottenendo un TGT .kirbi utilizzabile.
Se l'estrazione automatica di destinazione/dominio fallisce, è possibile specificare un SPN noto di un servizio configurato con delega senza vincoli con /target:SPN.
krb_tgtdeleg [/target:SPN]
L'azione kerberoasting viene utilizzata per richiedere il ticket di servizio appropriato. L'argomento /ticket:X specifica il ticket TGT dell'utente del dominio. L'argomento /spn:X specifica l'SPN di destinazione. Gli argomenti /domain e /dc sono opzionali e recuperano le impostazioni predefinite del sistema come per le altre azioni.
L'argomento /nopreauth:USER tenterà di inviare una AS-REQ con il servizio passato a /spn:Y per richiedere ticket di servizio.
krb_kerberoasting /spn:SPN [/nopreauth:USER] [/dc:DC] [/domain:DOMAIN]
krb_kerberoasting /spn:SPN /ticket:BASE64 [/dc:DC]
Se un utente del dominio non ha la preautenticazione Kerberos abilitata, è possibile richiedere con successo un AS-REP per l'utente, e una componente della struttura può essere craccata offline a la kerberoasting. L'argomento /user:X specifica l'utente di destinazione. Gli argomenti /domain e /dc sono opzionali e recuperano le impostazioni predefinite del sistema come per le altre azioni.
krb_asreproasting /user:USER [/dc:DC] [/domain:DOMAIN]
L'azione hash prende un /password:X e opzionalmente /user:USER e/o /domain:DOMAIN. Genererà la rappresentazione rc4_hmac (NTLM) della password. Se vengono specificati nome utente e dominio, vengono generate le forme hash aes128_cts_hmac_sha1 e aes256_cts_hmac_sha1. I nomi utente e dominio vengono utilizzati come salt per le implementazioni AES.
krb_hash /password:PASSWORD [/user:USER] [/domain:DOMAIN]
L'azione changepw prende un blob TGT .kirbi di un utente ed esegue un cambio password MS kpasswd con il valore /new:PASSWORD specificato. Se non viene specificato /dc, viene estratto il controller di dominio corrente del computer e utilizzato come destinazione per il traffico di reset della password.
Gli argomenti /targetuser e /targetdomain possono essere utilizzati per cambiare la password di altri utenti, a condizione che l'utente il cui TGT viene utilizzato abbia privilegi sufficienti.
Nota che può essere utilizzato sia un TGT utente che un ticket di servizio per kadmin/changepw per cambiare la password
krb_changepw /ticket:BASE64 /new:PASSWORD [/dc:DC] [/targetuser:USER] [/targetdomain:DOMAIN]
asktgt /cert:...describe