Active directory walkthrough series: GOLDEN TICKET

In this article series, we will look at the most famous ways that can be used to attack Active Directory and achieve persistence. This article will focus on Golden Ticket.

Note: Attacks discussed in this series have already been publicly disclosed on different forum. This series is for educational purposes only.

What should you learn next?

From SOC Analyst to Secure Coder to Security Manager — our team of experts has 12 free training plans to help you hit your goals. Get your free copy now.

Get Your Plan

Assumption

We will assume that the target domain is already breached and that the attacker is now trying to pivot from the breached machine/host to gain higher privileges.

Lab setup

Domain controller: kidulala-dc.kidulala.local

Domain user: KIDULALA/lala

Domain admin: KIDULALA/chotu

Kerberos authentication

To understand Golden Ticket, it is very important for us to understand how Kerberos authentication works. Let’s take a look.

Step 1: A user’s password is converted to an NTLM hash, and the timestamp is encrypted with this hash and sent to KDC. This step is often called AS-REQ (authentication server — request). Basically, the user is proving its identity to the ticket-granting server.

Step 2: Since the KDC has the NTLM hash of all users, it was able to decrypt the message retrieved in Step 1. After this, KDC grants a TGT (ticket-granting ticket) back to the user. This ticket is encrypted with a special user on the Domain Controller, known as krbtgt. This means that when the user receives the ticket, he cannot decrypt it, since the krbtgt hash is only on DC. This step is often called AS-REP (authentication server — response).

Step 3: In this step, the user asks for TGS (ticket-granting service); a ticket to access the actual service user is interested in. In this step, the user sends the TGT back to the KDC along with the requested TGS. This step is often called TGS-REQ (TGS request).

Step 4: In this step, KDC sends back the requested TGS, which is encrypted with the NTLM hash of the service. This step is often called TGS-REP.

Step 5: Once the user receives the TGS for the requested service, the user presents the TGS to the service. The service will evaluate whether the user is authorized or not and grant access if possible. This step is often called AP-REQ (application server request).

Golden ticket

Looking into step 3, the only validation for a TGS-REQ from the user done at the KDC level is whether the request can be decrypted by KDC. That’s it. Which account was it encrypted with? It was krbtgt. So, if we can extract the krbtgt hash from the environment, we can forge a ticket by impersonating any user.

Simulation

Idea: If we somehow elevate our privileges to domain admin and then grab the hash of the krbtgt account, then it is possible to exploit the trust of KDC, as explained above. [CLICK IMAGES TO ENLARGE]

1. We are using the amazing PowerShell utility PowerView to do some initial enumeration.
2. On a breached machine, we check to see if we have local admin access. We have it.
3. Now we need to check if there’s any machine where our current user has admin access and a domain session is active. We will use Invoke-Hunter for that. We got the server “kidu.kidulala.local” where the domain admin “chotu“ has a session.
4. It’s always best to cross-check if we have local admin access on the remote machine.
5. Once we confirm all of this, we will use PowerShell remoting to set up a session with the remote server and load Mimikatz there. As you can see, we’ve used New-PSSession to set up a session with “kidu.kidulala.local”, followed by loading Mimikatz and entering the session. As soon as we are in the remote context, we execute Mimikatz, which will default dump the creds. We are interested in the creds for “chotu.”
6. Once we grab the NTLM hash of user “chotu,” we can use the “over pass the hash” attack to grab the TGT and inject it into the session. Below, we have used the Mimikatz functionality for the same, where we have supplied parameters such as username, hash, domain, etc. Once we run the command, we will get a new PowerShell terminal with domain admin privileges.
7. Under the newly spawned PowerShell terminal, we can create a session with a domain controller. (Why? Because the terminal is of DA privileges.) Now we’re repeating the process as done earlier to grab the credentials of the krbtgt user. (Why? Read step 2 of Kerberos authentication workflow. Who signs the TGT?)
8. Once we grab the NTLM hash of the krbtgt user, then we can create a forged TGT ticket (called a Golden Ticket), as shown below.
9. Below, we can see that the TGT is created and present in the session.
10. We can access the CIFS service on DC in the current session and we successfully do that.

This is how persistence can be achieved in the AD environment with a Golden Ticket. You can do this once a machine has been breached in the environment and privileges have been escalated to domain admin.

What should you learn next?

From SOC Analyst to Secure Coder to Security Manager — our team of experts has 12 free training plans to help you hit your goals. Get your free copy now.

Get Your Plan

We will continue this series with more such possible attacks on AD environments.