WebClientRelayUp – an universal no-fix local privilege escalation in domain-joined windows workstations

by ddos · February 20, 2026

WebClientRelayUp

This is basically an universal no-fix local privilege escalation in domain-joined windows workstations in default configuration.

Tested on Windows 10 and 11

This project is based on DavRelayUp. The main difference is that I implemente Shadow Credentials + S4U2Self, which were not available with DavRelayUp (only RBCD is supported, which relies on creating a new computer account (MAQ!=0) or having compromised a service account).

How does it work ?

Force-start the WebClient service (if not already running) (No admin account needed! :))
Start a HTTP relay server (by default on port 8080)
Force SYSTEM to connect to our relay server using MS-EFSR functions (SharpEfsTrigger)
Relay the connection to the LDAP service of a domain controller (relaying a machine account)
Generate and add a KeyCredential blob into ms-DSKeyCredentialLink attribute of relayed machine account.
Use PKINIT to authenticate as the machine account and obtain a TGT for the machine account.
Use the TGT to exploit S4U2Self technique to obtain a Service Ticket (ST) on behalf of a domain administrator for SPN HOST.
Use the Service Ticket to authenticate to local Service Control Manager and create a new service as NT AUTHORITY/SYSTEM. (SCMUACBypass)

Prerequisites

Be in in a domain that supports PKINIT (Domain Controller has to run Windows Server 2016 or above)
Be in a domain where the Domain Controller(s) has its own key pair (When ADCS is in place or a custom CA is set up)
WebClient service installed and enabled or in state “Manual Trigger” on the targeted machine.

Mitigation

The best way to protect yourself against this kind of technique is to enforce LDAP Signing and LDAP Channel Binding. This mitigates relay-based attacks. This can be configured via the “Domain Controller: LDAP server signing requirements” GPO.

You may disable WebClient service on workstations, but make sure that it is not necessary for some application running on your system.

Detection

To detect this attack, one approach can be based on Windows event 5136 (A directory service object was modified).

https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-10/security/threat-protection/auditing/event-5136

The idea to detect a Shadow Credential attack is to identify the operation “Value Added – new value added” on msDS-KeyCredentialLink attribute.

The following “pseudo-code” can be used:

[pastacode lang=”markup” manual=”WHEN%20eventID%20IS%20%225136%22%0A%20%20AND%20%60AttributeLDAPDisplayName%60%20IS%20%22msDS-KeyCredentialLink%22%0A%20%20AND%20%60OperationType%60%20IS%20%22%25%2514674%22″ message=”” highlight=”” provider=”manual”/]

An SACL has to be configured to get the correct event ID on GUID 5b47d60f-6090-40b2-9f37-2a4de88f3063 https://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-ada2/45916e5b-d66f-444e-b1e5-5b0666ed4d66