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.