The Digital Brick Wall: Breaking Through AD with Kerberos

Deep inside, somewhere on the domain, an attacker has come to a point where privilege escalation opportunities have stopped. A digital brick wall. They don't have admin rights yet. Dumping LSASS with Mimikatz proves futile. Only the PC user's credentials.

But there is always an option of abusing Kerberos tickets. Having a legitimate ticket from the KDC is like having the key to a door.

What type of tickets do we want? More than any other ticket, an attacker wants a TGT. A TGT essentially says, "I authenticated. I proved I am who I say I am." This was legitimized through a process called authentication between the user and the Domain Controller's Kerberos service. It verified the user's authentication and issued the ticket.

How does this process work? There are various steps within the ticket process that attackers also abuse and many might find familiar, such as the AS-REQ stage, preauthentication stage, etc. But basically, the most essential part is the initial request. The user enters their password and the password is used to derive a key that can be used to prove knowledge of the user's secret to the DC. The DC is able to verify this using the corresponding key stored for the account.

If successful, the DC issues the TGT.

This ticket is not always easily achievable through modern circumstances on a locked-down network, however. In an enterprise environment, no matter what, there are just some situations that everyone knows are vulnerable, but it's just the way it is. Engineers and sysadmins do what they can to keep their environment secure despite these holes in security.

Example: A CNC machine was purchased by the company five years ago. It is running an outdated OS and is critical to business production. No matter what, the company doesn't want to spend millions of dollars to remedy this for a "what if" scenario. Especially when the machine is working fine and has many years of life left.

So they air gap it. They isolate it. They do what they can to keep these situations under control.

This is an example of why attackers with a knowledge of Windows, Kerberos, etc. can move through a network quite quickly.

An example more closely related to what we are looking into is the example of a machine having unconstrained delegation rights or some form of constrained delegation. A PC can be configured in Active Directory with delegation rights based on whether they want that PC or service to act on behalf of a user when requesting a service ticket, rather than a TGT.

With tools like Rubeus, an attacker can abuse an attack path involving RBCD and S4U2Proxy. This is where an attacker can take advantage of a delegation relationship configured in Active Directory and have the Kerberos service issue a service ticket representing another user to a target service.

Using this method, an attacker can potentially obtain a service ticket that allows them to authenticate to another machine or service as a different identity.

The important thing to understand is that the attacker isn't simply "fooling" Kerberos into believing something that isn't true. Kerberos is doing what it was designed to do based on the delegation relationships and permissions configured in Active Directory.

A simple example of the S4U process would look something like this:

Attacker controls a computer account called ATTACKER$.

That computer account has been given permission to perform delegation to a target service.

The attacker uses S4U2Self to request a service ticket representing another user.

That ticket can then be used with S4U2Proxy to request a service ticket to the target service. The resulting service ticket can potentially allow the attacker-controlled computer account to authenticate to the target service as the represented user.

It is essentially asking the KDC to issue a service ticket to a particular service while using the delegated identity.

For example, conceptually:

User → Attacker-controlled computer → Target service

The attacker isn't necessarily becoming the user everywhere. The ticket is tied to the particular service being requested.

This is where commands such as Rubeus s4u come into play.

Another important part when working with Kerberos tickets is understanding the logon session the ticket belongs to.

If we look through the tickets on a Windows machine, we may see multiple logon sessions. Each session can have its own collection of Kerberos tickets.

This is where the LUID becomes important.

A LUID, or Locally Unique Identifier, identifies a particular logon session. When looking at Kerberos tickets, Rubeus can display the LUID associated with the session holding those tickets.

So instead of just seeing:

Administrator User Service Account

you may see something more like:

LUID: 0x3e7 LUID: 0x4a123 LUID: 0x52abc

The LUID essentially tells us, "these tickets belong to this particular logon session."

If an attacker has access to multiple sessions or tickets, they can use the LUID to identify which session they are interested in rather than blindly working with every ticket on the machine.

For example, Rubeus can be used to enumerate tickets and their associated LUIDs:

Rubeus.exe triage

This gives a view of the Kerberos tickets and the logon sessions associated with them.

Then, when working with a particular session, the LUID can be specified so the operation targets that specific logon session instead of everything available.

The important part here is understanding what the LUID actually represents.

It isn't the ticket itself.

It is the identifier for the Windows logon session that the ticket belongs to.

Thanks for reading

~Mal3vant~