Note: Attacks discussed in this series have already been publicly disclosed on different forums. This series is for educational purposes only.
Assumption
We will assume that the target domain is already breached and now the attacker is 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 Silver 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).
Silver Ticket
Looking into step 5, when the user presents the TGS to the service, the only validation done at the service level on the authenticity of the TGS ticket is if it can decrypt the TGS presented by the user. If we somehow grab the NTLM hash of the service, we can forge TGS.
Simulation
Idea: If we somehow elevate our privileges to domain admin and then grab the NTLM hash of service, then it is possible to exploit the trust.
We are using the amazing PowerShell utility PowerView to do some initial enumeration. On a breached machine, we check to see if we have local admin access. We do. [CLICK IMAGES TO ENLARGE]
Now we need to check if there is 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.
It’s always best to cross-check if we have local admin access on the remote machine.
Once we confirm all that, we will use PowerShell remoting to set up a session with the remote server and load Mimikatz there. As we can see, we have 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 of user “chotu.”
Once we grab NTLM hash of “chotu,” we can use “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. Under the newly-spawned PowerShell terminal, we can create a session with a domain controller. (Why? Because the terminal is of DA privileges.) We’re repeating the process, as is done earlier, to grab the credentials of the machine account of DC.
Below is the NTLM hash of the machine account of the DC.
Now, since we have the NTLM hash of the DC’s machine account, we can create a forged TGS. Below, we have created a forged TGS for CIFS service on DC.
We confirm that the ticket is generated and injected into the session.
We can now access the CIFS service in DC.
Similarly, we can create a forged ticket for the HOST service also. (Notice the change in /service:HOST.)
We confirm that we have TGS generated for the HOST service.
As an example, we can run commands to list the scheduled tasks on the DC.
This is how persistence can be achieved in the AD environment with Silver Ticket once a machine has been breached in the environment and privileges have been escalated to Domain Admin. We will continue this series with more examples of possible attacks on AD environments.
