← Home
AS-REP Roasting

Theory — Pre-Authentication Disabled

Normally, a Kerberos AS-REQ includes a timestamp encrypted with the user's key. This pre-authentication step proves to the KDC that the requesting party actually knows the password before issuing a TGT. Without it, anyone can request a TGT for any user.

The DONT_REQ_PREAUTH flag (userAccountControl bit 0x400000) disables pre-authentication for a specific account. When set, the KDC responds to an AS-REQ with an AS-REP that contains data encrypted with the user's NTLM hash — without verifying who is asking. The attacker can then attempt to crack that encrypted blob offline to recover the password.

This is AS-REP Roasting: enumerate accounts with pre-auth disabled, request their AS-REP, extract the encrypted portion, crack it with Hashcat.

# Find AS-REP Roastable users with Impacket (no creds needed) kali@kali:~$ impacket-GetNPUsers meridianfg.local/ -dc-ip 192.168.1.10 -no-pass -usersfile users.txt # Or with a valid credential to enumerate automatically kali@kali:~$ impacket-GetNPUsers meridianfg.local/jsmith:Password123 -dc-ip 192.168.1.10 -request # From Windows with Rubeus PS> .\Rubeus.exe asreproast /format:hashcat /outfile:asrep.txt

Crack the AS-REP hash with Hashcat mode 18200:

kali@kali:~$ hashcat -m 18200 asrep.txt /usr/share/wordlists/rockyou.txt -r /usr/share/hashcat/rules/best64.rule
AS-REP Roasting does not require any domain credentials. It is often one of the first things to try against an AD environment with only the domain name and DC IP address. BloodHound's "Find AS-REP Roastable Users" query identifies targets automatically.
Kerberoasting

Theory — Attacking Service Account Passwords

Any authenticated domain user can request a service ticket (TGS) for any service registered with an SPN in AD. The service ticket is encrypted with the service account's NTLM hash. The attacker requests the ticket, extracts the encrypted blob, and cracks it offline — recovering the service account's password.

The attack is particularly effective against service accounts that:

# Kerberoast all SPNs with Impacket kali@kali:~$ impacket-GetUserSPNs meridianfg.local/jsmith:Password123 \ -dc-ip 192.168.1.10 -request -outputfile kerberoast.txt # From Windows with Rubeus PS> .\Rubeus.exe kerberoast /format:hashcat /outfile:kerb.txt # PowerView — enumerate SPNs first PS> Get-DomainUser -SPN | Select SamAccountName, ServicePrincipalName

Crack with Hashcat mode 13100 (Kerberos 5 TGS-REP etype 23):

kali@kali:~$ hashcat -m 13100 kerberoast.txt /usr/share/wordlists/rockyou.txt -r /usr/share/hashcat/rules/best64.rule
Kerberoasting generates TGS requests in the DC event log (Event ID 4769). The requests look legitimate but can be detected by filtering for RC4 encryption (etype 0x17) in TGS requests — modern environments prefer AES 256 (etype 0x12). Request AES tickets if stealth is required: Rubeus kerberoast /rc4opsec only roasts RC4-compatible SPNs to reduce AES-only detection.
Service accounts with Domain Admin membership or local admin rights on many machines are high-value Kerberoasting targets. Even a service account with read access to sensitive shares is worth cracking — it may reuse a password that unlocks other accounts.
Pass the Ticket

Using Stolen Kerberos Tickets

If you have code execution on a Windows machine where a privileged user is logged in, you can extract their Kerberos tickets from memory and inject them into your own session — authenticating as that user without needing their password. This is Pass the Ticket (PTT).

Tickets live in the LSASS process memory in Kerberos ticket caches. Mimikatz and Rubeus can export them:

# Export all tickets from memory (requires admin/SYSTEM) PS> .\Rubeus.exe dump /luid:0x3e4 /service:krbtgt /nowrap # Or with Mimikatz PS> sekurlsa::tickets /export # Inject a ticket file into current session PS> .\Rubeus.exe ptt /ticket:<base64-blob-or-.kirbi-file> # Verify the ticket is in your session PS> klist

Once a ticket is injected, any Kerberos-authenticated command you run uses the stolen identity. You can access SMB shares, run PsExec, or request further service tickets — all as the ticket's original owner.

TGTs are the most valuable tickets to steal — they allow requesting any service ticket. TGS (service) tickets are limited to the specific service they were issued for. A stolen DA TGT allows requesting tickets for any service in the domain.
Silver and Golden Tickets

Forged Tickets — When You Have the Hash

Pass the Ticket steals existing tickets. Silver and Golden Ticket attacks forge tickets from scratch using a compromised account hash — no interaction with the KDC required during the forge step.

Silver Ticket — Forged using a service account's NTLM hash. The ticket grants access only to the specific service tied to that account (e.g. CIFS on a specific server). Does not require KDC interaction after forging. Less detectable than Golden Ticket because it never touches the DC. Impact: full access to that service as any user (typically DA).

Golden Ticket — Forged using the krbtgt account's NTLM hash. The krbtgt account's hash is the domain's master secret — it is used to encrypt all TGTs. With it, you can forge a TGT for any user (including a non-existent user), valid for any duration, with any group memberships. The resulting ticket bypasses all normal authentication checks. Impact: complete, long-term domain compromise. Effective until the krbtgt password is rotated twice.

# Golden Ticket with Mimikatz (requires krbtgt hash + domain SID) mimikatz# kerberos::golden /user:FakeAdmin /domain:meridianfg.local \ /sid:S-1-5-21-... /krbtgt:<krbtgt-hash> /ptt # Silver Ticket — CIFS service on a target server mimikatz# kerberos::golden /user:Administrator /domain:meridianfg.local \ /sid:S-1-5-21-... /target:DC01.meridianfg.local /service:cifs \ /rc4:<service-account-hash> /ptt
Golden Ticket attacks require the krbtgt hash, which is only obtainable via DCSync (requires Domain Admin or equivalent) or physical DC access. They are a post-exploitation persistence mechanism, not a standalone attack. Obtaining the krbtgt hash is covered in Module 08 — Persistence.
When a Golden Ticket is detected (usually by Security Event ID 4769 with abnormal ticket parameters), defenders must rotate the krbtgt password twice to invalidate all outstanding forged tickets. The second rotation invalidates tickets forged before the first rotation. This is a significant operational disruption — which is why Golden Tickets are sometimes used as a pressure point in adversary simulations.