Security, et al

Randy's Blog on Infosec and Other Stuff

«  Extracting Password Hashe... | Persistence Using AdminSD... »

Complete Domain Compromise with Golden Tickets

Wed, 18 Oct 2017 15:47:09 GMT

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. KRBTGT account targeted by attackers who want to use the KRBTGT password to forge Kerberos tickets (TGTs)

Golden Tickets

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:

privilege::debug

lsadump::lsa /inject /name:krbtgt

This will output the necessary password hash, as well as the domain SID information. Using Mimikatz to extract the password hash of the KRBTGT account and the Domain SID with the command lsadump::lsa

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. Using Mimikatz to create a Golden Ticket for a fake user while providing the default administrator ID and using ptt to inject the ticket into the 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. Displaying the group membership and user information for the current user, showing that the user has no Active Directory domain privileges

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. Using Mimikatz ptt to load the golden ticket into the session, impersonate an admin user, and use pushd to access a DC since the Kerberos ticket is in memory

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. Using Mimikatz pass-the-ticket to load the ticket and PSExec to open a session on the DC where the user will be logged on as an admin due to the RID of 500

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: Logon event 4624 shows the golden ticket account data with the SID as administrator due to RID spoofing and the fake user account name

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.

This is the final installment in our blog series, 4 Service Account Attacks and How to Protect Against Them. To view the previous blogs, please click on the links below.

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

Watch this video and sign up for the complete Active Directory Attacks Video Training Series here (CPE Credits offered).

email this digg reddit dzone
comments (0)references (0)

Related:
Complete Domain Compromise with Golden Tickets
Extracting Service Account Passwords with Kerberoasting
Severing the Horizontal Kill Chain: The Role of Micro-Segmentation in Your Virtualization Infrastructure
Auditing Privileged Operations and Mailbox Access in Office 365 Exchange Online

Comments disabled

powered by Bloget™

Search


Categories
Recent Blogs
Archive


 

Additional Resources