Service Account Attack #4: Golden Tickets
In this blog series, we’ve focused on ways to find and compromise Active Directory service accounts. So far, this has led us to compromise accounts which grant us limited access to the services they secure. In this final post, we are going to explore the most powerful service account in any Active Directory environment: the KRBTGT account. By obtaining the password hash for this account, an attacker is able to compromise every account within Active Directory, giving them unlimited and virtually undetectable access to any system connected to AD.
The KRBTGT Account
Every Active Directory domain controller is responsible for handling Kerberos ticket requests, which are used to authenticate users and grant them access to computers and applications. The KRBTGT account is used to encrypt and sign all Kerberos tickets within a domain, and domain controllers use the account password to decrypt Kerberos tickets for validation. This account password never changes, and the account name is the same in every domain, so it is a well-known target for attackers.
Using Mimikatz, it is possible to leverage the password information for the KRBTGT account to create forged Kerberos tickets (TGTs) which can be used to request TGS tickets for any service on any computer in the domain.
To create golden tickets, the following information will be needed:
- KRBTGT account password hash – This is the most important piece of information needed to create golden tickets. This will only be available by gaining elevated rights to a domain controller.
- Domain name and SID – The name and SID of the domain to which the KRBTGT account belongs.
That’s really about it. Let’s take a look at how to gather this information and create golden tickets step-by-step.
Step 1 – Gather KRBTGT Password Information
This is the hardest part of the attack and it requires gaining privileged access to a domain controller. Once you are able to log on interactively or remotely to a domain controller, you can use Mimikatz to extract the password hash. The simplest command to issue to gather this information with Mimikatz is:
lsadump::lsa /inject /name:krbtgt
This will output the necessary password hash, as well as the domain SID information.
Step 2 – Create Golden Tickets
Now that the necessary information has been obtained, you can create golden tickets using Mimikatz. Golden tickets can be created for valid domain accounts, or for accounts that do not exist. Some of the parameters you may want to leverage when creating golden tickets include:
- User – The name of the user account the ticket will be created for. This can be a real account name but it doesn’t have to be.
- ID – The RID of the account you will be impersonating. This could be a real account ID, such as the default administrator ID of 500, or a fake ID.
- Groups – A list of groups to which the account in the ticket will belong. This will include Domain Admins by default so the ticket will be created with the maximum privileges.
- SIDs – This will insert a SID into the SIDHistory attribute of the account in the ticket. This is useful to authenticate across domains
In this example, I am creating a ticket for a fake user, but providing the default administrator ID. We will see later when I use this ticket how the User and ID come into play. I also issue use “ptT” to inject the created ticket into the current session.
Step 3 – Pass the Ticket
Now that you have generated a golden ticket, it is time to use it. In the previous Mimikatz command I used the ptT trigger to load the golden ticket into the current session. Next, I will launch a command prompt under the context of that ticket using the misc::cmd command.
You can see in the command prompt I am still operating as a regular domain user with no domain group membership, which also means I should have no rights to any other domain computers.
However, because the Kerberos ticket is in memory, I can connect to a domain controller and gain access to all of the files stored there.
You can also see if I use PSExec I can open a session on the target domain controller, and according to that session I am logged in as the Administrative user now.
It believes I am the administrator due to the RID of 500 I used to generate my golden ticket. Also, when looking at the event logs of the domain controller, I will see that it believes I am the Administrator but my account name is the one I spoofed during the golden ticket creation:
This can be particularly useful if you are looking to evade detection or create deceptive audit logs.
Protecting Yourself from Golden Tickets
Golden tickets are very difficult to detect, because they are perfectly valid TGTs. However, in most cases they are created with lifespans of 10 years or more, which far exceeds the default values in Active Directory for ticket duration. Unfortunately, event logs do not log the TGT timestamps in the authentication logs but other AD monitoring products are capable of doing so. If you do see that golden tickets are in use within your organization, you must reset the KRBTGT account twice, which may have other far-reaching consequences.
The most important protection against golden tickets is to restrict domain controller logon rights. There should be the absolute minimum number of Domain Admins, as well as members of other groups that provide logon rights to DCs such as Print and Server Operators. In addition, a tiered logon protocol should be used to prevent Domain Admins from logging on to servers and workstations where their password hashes can be dumped from memory and used to access a DC to extract the KRBTGT account hash.
To register for today’s webinar on the Service Account Attacks Blog Series, please click here.
Here are the first three installments in the blog series:
Service Account Attack #1 – Discovering Service Accounts without using Privileges
Service Account Attack #2 – Extracting Service Account Passwords with Kerberoasting
Service Account Attack #3 – Impersonating Service Accounts with Silver Tickets