Golden ticket attacks: How they work - and how to defend against them
Kerbrute works by sending a single UDP packet to the authentication service to begin the authentication process, but then doesn’t complete the transaction as to avoid an actual login failure (and the associated logging). While this doesn’t grant access to anything, it does allow domain users to be enumerated using a wordlist.
NOTE: To use kerbrute you need to already be on the domain you are attacking, or alternately need to have mapped the domain controller (which normally hosts the KDC) IP address properly in your /etc/hosts file.
Rubeus is a Windows-only post-exploitation tool for attacking Kerberos. No compiled binaries are available (either through the GitHub repo or Kali Linux’s windows-binaries
package).
NOTE: To use Rebueus you need to already be on the domain you are attacking, or alternately need to have mapped the domain controller (which normally hosts the KDC) IP address properly in C:/Windows/System32/drivers/etc/hosts.
# Harvest ticket granting tickets observed by the current machine.
# Probably works best when run on a domain controller.
#
Rubeus.exe harvest /interval:30
# Spray the specified password across all known users and generate a
# ticket giving ticket for successful authentications. (Can trigger
# account lockouts!)
#
Rubeus.exe brute /password:ThePasswordToSpray /noticket
Kerberoasting is where a service ticket is used to brute force a service password. This password can then be used to either move laterally or (if the service runs with elevated privileges) to elevate your privileges.
Note that not every account is kerberoastable, though it’s not 100% obvious from this walk-through why that is. The Kali Linux tool bloodhound
can be used to identify potentially kerberoastable accounts.
The main defenses against kerberoasting are (1) strong passwords and (2) making sure you’re not running any services as domain admin (which you shouldn’t need to do in this day and age anyway).
# Extract password hashes for all known kerberoastable accounts using
# Rubeus.
#
Rubeus.exe kerberoast
The password hashes output here can then be cracked with Hashcat (use the 13100 hash mode).
Impacket can identify kerberoastable accounts and dump packets remotely. It comes standard with Kali Linux.
sudo python3 \
/usr/share/doc/python3-impacket/examples/GetUserSPNs.py \
${DOMAIN}/${USER}:${PASSWORD} \
-dc-ip $DOMAIN_CONTROLLER_IP -request
The password hashes output here can then be cracked with Hashcat (use the 13100 hash mode).
AS-REP roasting is basically kerberoasting for regular user accounts. The only requirement to roast a user account is that Kerberos pre-authentication is disable.
(When pre-authentication is disabled, the authentication server will supply a ticket granting ticket and a session key automatically when requested, without first verifying the user. This data is then stored offline by the Windows machine for later decryption when the user with pre-authentication disabled logs in. But this means that all we need to do is to break the user’s NT hash!)
Both Rubeus and Impacket (via GetNPUsers.py) support AS-REP roasting; however, Rubeus can auto-discover roastable users, while GetNPUsers.py requires that user accounts already be enumerated and roastable accounts identified.
# AS-REP roasting with Rubeus.
#
Rubeus.exe asreproast
To use Hashcat to crack the hashes obtained in this fashin, first insert 23$
after the leading $kerb5asrep$
(so $kerb5asrep$
→ $kerb5asrep$23$
) and then use mode 18200.
Basically the only mitigation for this attack is to keep pre-authentication enabled, though strong password policies can help.
Mimikatz can dump ticket granting tickets (and session keys?) from the memory of Windows’ Local Security Authority Subsystem Service (LSASS); these can then be used to for privilege elevation or lateral movement (depending on which users are active on that machine).
NOTE: There’s a bit of terminology creep in these discussions. Mimikatz and Rubeus are actually dumping Kerberos data structures (as .kirbi files), which contain both a ticket and the corresponding session key. People tend to call these .kirbi files “tickets”, but it’s worth keeping in mind that they contain both pieces of data (as a “ticket” in the Kerberos sense, not the hacker’s sense, isn’t useful without the corresponding session key). See “Rubeus - Now With More Kekeo” for a good discussion of this.
Mimikatz needs to be run with administrative privileges (on the local machine), and provides its own command prompt.
privilege::debug
- See if you’re running with the right privileges.sekurlsa::tickets /export
- Dump any Kerberos “tickets” (really ticket + session key data structures) from LSASS’s memory as .kirbi files. Tickets are named like ID-USER-SERVICE-DOMAIN.kirbi; ticket granting tickets have a krbtgt
SERVICE name. If you can find a krbtgt
ticket belonging to an administrator account, then you’ve struck gold (literally - see the next section).kerberos::ptt TICKET_FILE
- Load the data structure in the specified .kirbi file into memory (allowing the account you’re logged in as to “pass the ticket” and impersonate the user whose ticket you’ve harvested).The built-in Windows command klist
will show you the current Kerberos tickets in memory.
The only real way to defend against this attack is to only allow domain admins to log into domain controllers, not lower privileged machines!
The idea with gold and silver tickets is that, since the KDC and service long term secret keys are just the NT hashes of the corresponding service account’s passwords, then if you can dump the password (or even its hash), you can forge a kerberos ticket without ever needing to contact the KDC. (See “Silver & Golden Tickets”.)
Silver tickets are forged using a service account’s NT hash, and can be used to grant any user access to that service. This works because Kerberos implicitly assumes that only the KDC and the service account know the service account’s long term secret key.
Golden tickets take things a step further - if you can get the krbtgt
user’s NT hash, then you can forge a ticket granting ticket for any user, and then use that to get the KDC to provide a valid service ticket for any service that user has access to. This works because Kerberos trusts the encrypted ticket granting ticket blob and doesn’t reauthenticate the user before granting further access.
Golden tickets are powerful (since you can be anyone, it’s trivial to gain control of the domain), but also noisier - because you’re running through the KDC infrastructure, golden ticket still generate (almost) all of the normal logging, while silver tickets allow you to bypass the KDC completely and only generate logs on the service server (if that).
To generate a gold or silver ticket using Mimikatz, begin by running the lsadump::lsa /inject /name:SERVICE
command to retrieve the service SID and NTLM password hash for that service. If SERVICE is krbtgt
then this will allow the creation of a golden ticket, otherwise you’ll be creating a silver ticket.
(You can also use a user name instead of SERVICE, in which case it appears that Mimikatz will just request a ticket granting ticket from the KDC as that user in the next step; this is theoretically just as noisy as a golden ticket, but looks more “normal”.)
To actually create and cache the ticket, use Kerberos::golden /user:USER /domain:DOMAIN /sid:SID /krbtgt:HASH /id:TYPE
, where:
USER
is the user to create the ticket for (probably the one you’ve compromised).DOMAIN
is the domain to create the ticket for.SID
is the SID of the service from the previous step.HASH
is the NT hash of the service password from the previous step.TYPE
is the type of Kerberos ticket to create; use 500 for a golden (ticket granting) ticket, and 1103 for a service ticket.Once the ticket has been created, use misc::cmd
to open a command prompt using the newly forged ticket.
If Mimikatz is run on a domain controller, it can modify the authentication service’s memory using the misc::skeleton
command to cause it to attempt to decrypt the AS-REQ using both the user’s NT hash and an NT hash of your choosing (by default 60BA4FCADC466C7A033C178194C03DF6
, which is just mimikatz
). This means that you can send an AS-REQ as any user using the “skeleton key” hash to gain access as that user, similar to a golden ticket attack.
Obviously this isn’t very persistent itself, as the skeleton key will be lost if the server is rebooted or the authentication service restarted.