Active directory series: Unconstrained delegation

In this article series, we will look into the most famous ways that can be used to attack Active Directory and achieve persistence.

Note: Attacks discussed in this series have already been publicly disclosed on different forums. 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 unconstrained delegation, it is very important for us to understand how Kerberos authentication works.

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).

Delegation

With the help of delegation, user credentials can be impersonated by a service in order to access a service on the next hop.

For example, consider a three-tier application where a user accesses a web server and a web server in turn needs to impersonate the user credentials to access the back-end database. There are two types of delegation:

• Unconstrained delegation: The first hop server (let’s say the web server) can impersonate user credentials to any service in the domain. Where does it all fit in the Kerberos cycle? In step 4 mentioned above, when DC sees that the first hop service has unconstrained delegation enabled on it, along with TGS, it also sends the user’s TGT embedded, which the service will use (in step 5). This is in order to impersonate the user while making requests to other services in the domain: once the first hop service receives the TGS, it decrypts it and extract the TGT and request a TGS from the DC for the next hop service as user.
• Constrained delegation: The first hop server can only impersonate the user credentials to the specified service accounts. We will discuss more on this in greater depth in the next article.

Simulation: Unconstrained delegation

1. Let’s set up a computer object within our domain with uncontained delegation. For this exercise, we have created a new object called “zehrilla” and enrolled the kidu.kidulala.local computer object to it. As it can be seen, no delegation is currently enabled. Let’s enable it. [CLICK IMAGES TO ENLARGE]
2. Once the delegation is enabled, we can use PowerView to check for unconstrained delegation in the domain. As expected, we can see that the computer object “kidu” is listed there. Note: Ignore DC’s listed in output, as that is also expected from the DCs.
3. Now we can check if we have local admin access or not.
4. Next, we can use PowerShell remoting to enter the session on the remote object and run Mimikatz to grab all the tickets on the machine.
5. Looking into the saved tickets, we can see that the domain admin “chotu" has logged in and its ticket can be injected to gain DA privileges.
6. Grab the ticket and inject into the process, as shown below.
7. Once we do that, we can then log in to the DC and list the C share.

This is how privileges can be escalated in the AD environment with unconstrained delegation on a machine.

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 examples of possible attacks on AD environments.