CQURE Hacks #64: S4U2self in Pieces – Attacking Active Directory by Abusing Kerberos Delegation

During the demonstration, you will see how to use PowerShell to gather more information about a user, generate a Ticket Granting Service (TGS) ticket using the S4U2proxy protocol with Rubeus, and perform a DCSync attack using Mimikatz.

This attack will show you how an account with constrained delegation rights, when compromised, can be leveraged to impersonate high-privilege users and gain elevated access to domain resources, making proper configuration and monitoring of these privileges critical for domain security.

After watching this, you can make sure to keep your kerberos delegations secure!

And if you’re hungry for more cybersecurity knowledge, we’ve opened the registration for our 6-weeks Advanced Windows Security Course 2026, ensuring you’re prepared for the threat landscape of the next year!

Check out the course offer >>

Transcript of the video:

So, let’s start by running PowerShell.

After using the whoami command, we see that we are JamesJ. Let’s import the PowerView module into PowerShell and get more information about user James using the Get-DomainUser command.

The user James has the value TRUSTED_TO_AUTH_FOR_DELEGATION (T2A4D) in userAccountControl; that means he can get a TGS for himself on behalf of any other user. An account can get a TGS on behalf of any user to the service set in msDS-AllowedToDelegateTo.

To do so, it first needs a TGS from that user to itself, but it can use the S4U2self to get that TGS before requesting the other.

Let’s check the next command for what it specifically owns. We see that we have the ability to delegate to LDAP and CIFS services on DC01.cqure.lab. Close PowerShell and open the command prompt. After using klist, we can see our current tickets.

Try to open the c$ directory on the domain controller. Access denied. Let’s now prepare for the attack.

The first step will be using Rubeus to change the password of our user, in this case James, to hashes/keys.

We copy the AES256 key and use Rubeus again with the s4u function.

We authenticate as the Administrator user, so in the impersonateuser we type Administrator, and in msdsspn we now use the CIFS service to get the ticket. As you can see, the ticket was imported successfully. Let’s try opening the DC01 directory again. We have successfully got the permissions to do so.

Now let’s try to connect using PsExec to DC01. We have also succeeded, let’s make sure with the hostname command that this is indeed the correct machine.

You can use whoami /all to check our privileges. We see that we are the Domain Admin. Ok, now exit this host, fire up a new command prompt, and clear our tickets with the klist purge command.

The next step is to reopen the c$ directory on DC01 after clearing the Kerberos tickets. We don’t have the permission to do it. We will now use the LDAP service instead of CIFS to show what the difference is.

We use the same command, only in msdsspn we specify LDAP instead of CIFS, and this time we’ll save the file to dc. kirbi to import it later into Mimikatz. Now let’s turn on Mimikatz and import this ticket. As you can see, importing is successful. Let’s try to use DCsync.

DCsync has been executed, and now let’s exit Mimikatz and try to reopen the c$ directory to dc01 only with the LDAP ticket.

As you can see, we can’t do this because SMB uses the CIFS service, not LDAP. And vice versa, it also works the same way the other way around. If we wanted to do a DCsync with a CIFS ticket, we can’t do it until we get the appropriate ticket.