Just in time for our DEF CON workshop “Constructing Kerberos Attacks with Delegation Primitives”, Microsoft failed to meet the disclosure deadline, and so we publish another primitive that can be abused to achieve Windows Local Privilege Escalation (LPE). It affects all domain-joined Windows 10 hosts by default, as well as Windows Server 2016 and Windows Server 2019 that have the WebDAV Redirector feature installed.

This attack is very similar to the LPE attack chain that we disclosed in “Wagging the Dog”. Actually, it is identical except for the primitive used to initiate the attack chain.

If you are not up-to-speed with the intricacies of Resource-Based Constrained Delegation and NTLM Relay, I highly recommend reading Wagging the Dog before proceeding. All the information in the reminders below is explained in details in Wagging the Dog.


  1. An attacker can personalize the lock screen image and set it to a UNC path pointing at a rogue WebDAV NTLM relay server.
  2. At the end of the picture change process, SYSTEM will attempt to access the file and authenticate to the rogue server using the host’s computer account.
  3. Because a WebDAV path is provided, the WebClient negotiates authentication, and so the NetNTLM Negotiate Sign flag is not set. This allows NTLM relay attacks to LDAP.
  4. Once an LDAP session is established with the identity of the computer account, the attacker can configure Resource-Based Constrained Delegation to the target host.
  5. The attacker can now invoke S4U2Self and S4U2Proxy to impersonate a privileged user to the target host and elevate their privileges.

Reminder #1: Resource-Based Constrained Delegation

I’ll open with a very short reminder for those who are too busy to read Wagging the Dog. We found that Resource-Based Constrained Delegation suffers from the following insecurities:

  1. Any user with write access to the msDS-AllowedToActOnBehalfOfOtherIdentity attribute of an object can configure Resource-Based Constrained Delegation for that object without any special privileges, including the SeEnableDelegation privilege that is required for any other Kerberos delegation flavor.
  2. “Protocol Transition” is always permitted for Resource-Based Constrained Delegation, even when the TrustedToAuthForDelegation flag is not set, allowing the service to magically impersonate users out of thin air.
  3. By default, every resource is given the right to configure Resource-Based Constrained Delegation for itself, including computer accounts.
  4. In order to invoke S4U2Self and initiate the “Protocol Transition” process, an account with at least one Service Principal Name (SPN) is required. However, by default, any domain user (or computer) can abuse the MachineAccountQuota and create a new computer account. The owner of the new computer account can assign an SPN to it, which makes it trivial to obtain an account that can invoke S4U2Self.

If any of the above is not clear, please read Wagging the Dog before you proceed.

Reminder #2: NTLM Relay is Hard

When performing an NTLM relay attack to LDAP, if the Negotiate Sign flag was set during the NetNTLM exchange the target server will ignore messages that are not signed, making the session useless. Luckily, not all clients set the Negotiate Sign flag. The most notorious one is the WebClient, which includes the WebDAV client as well.

By default, the WebClient will authenticate using “default credentials” (whatever credentials are in LSASS for that logon session) for targets in the Trusted Zone or the Local Intranet Zone. However, this is not an obstacle because Active Directory Integrated DNS (ADIDNS) allows all domain users to add new DNS entries, which enables getting a rogue WebDAV relay server into the Local Intranet Zone.

Once again, if any of the above is not clear, please read Wagging the Dog before you proceed.

The New Attack Primitive

Very similaly to the account profile picture primitive, when a user personalizes their lock screen, SYSTEM attempts to access the file specified by the user, which means that the host’s computer account will be used to authenticate to network resources.

It is a small and meaningless operation; not an arbitrary file write/delete. But that is all we need.

The Attack Chain

The attack chain works as follows:

  1. The attacker compromises credentials or a TGT for an account that has an SPN or creates one by abusing the MachineAccountQuota (“Service A”). LPE1.png
  2. The attacker gains low-privileged access to a host running Windows 10 or Windows Server 2016/2019 with the WebDAV Redirector feature installed (“Service B”).
  3. If required, the attacker adds a DNS record for the WebDAV relay server using ADIDNS. LPE2.png
  4. The attacker changes the lock screen picture to a path on a rogue WebDAV NTLM relay server. Lock-Screen.png
  5. The attacker relays the computer account NTLM authentication to the LDAP service on the domain controller, and configures resource-based constrained delegation from Service A to Service B. LPE4.png
  6. The attacker uses Rubeus to perform a full S4U attack to obtain a TGS to Service B for a user that has local administrator privileges on it. LPE5.png
  7. The attacker can pass-the-ticket to compromise Service B. LPE6.png

The following diagram illustrates this scenario: Lock-Screen-LPE-Diagram.png

Video demonstration of this attack chain:


Preconditions for Exploitation

The following conditions must be met for this attack:

  • The attacker must gain low-privileged access to the target host.
  • The target host must be domain-joined.
  • The domain environment must have at least one domain controller that is Windows Server 2012 or later.
  • The target host must have a WebDAV client installed, which is present by default on Windows 10 but requires the “WebDAV Redirector” feature on Windows Server 2016 and Windows Server 2019.

In addition, the attacker needs only one of the following:

  • Control of an account with an SPN (either credentials or a TGT).
  • Control of a domain user whose “MachineAccountQuota” attribute is greater than zero (default value is “10”).
  • The domain controller has LDAPS enabled, which allows creating a new computer account when establishing an LDAP session through NTLM relay.

Affected Versions

The following versions of Windows are affected:

  • All domain-joined Windows 10 versions, including the latest Insider Preview.
  • All domain-joined Windows Server 2019 versions, including the latest Insider Preview, that have the “WebDAV Relay” feature installed.
  • All domain-joined Windows Server 2016 versions that have the “WebDAV Relay” feature installed.

Mitigating Factors

The following factors may mitigate this attack chain:

  • LDAP signing with channel binding is enforced
  • NTLM authentication is restricted
  • Computer accounts are denied write access to their own msDS-AllowedToActOnBehalfOfOtherIdentity attribute
  • Personalization is blocked for low-privileged users


This attack chain is very easy to detect:

  1. If an appropriate SACL was configured, “A directory service object was modified” event (5136) will be generated showing that the computer account changed its own msDS-AllowedToActOnBehalfOfOtherIdentity attribute. RBCD_Event.png
  2. A “Kerberos service ticket was requested” event (4769) showing S4U2Self will be generated, in which the account and the service have the same identity. S4U2Self_Event.png
  3. A “Kerberos service ticket was requested” event (4769) showing S4U2Proxy will be generated, showing transition from the account in the previous event the account of the targeted host. S4U2Proxy_Event.png

Please refer to the Detection section of Wagging the Dog for more details.


Elad Shamir (@elad_shamir) from The Missing Link Security.


  • Matt Bush (@3xocyte), and Danyal Drew (@danyaldrew) for bouncing off ideas and helping me figure this out.

Disclosure Timeline

  • 10/07/2019 - Sent initial report to MSRC, advising the following disclosure schedule: “This bug is subject to a 90-day disclosure deadline. After 90 days elapse or a patch has been made available (the earlier of the two), the vulnerability will be publicly disclosed. If MSRC fails to confirm that the vulnerability was successfully reproduced within 30 days, by August 8 2019, the vulnerability will be publicly disclosed. If MSRC fails to confirm within 60 days, by September 7 2019, that the vulnerability will be serviced, the vulnerability will be publicly disclosed.”
  • 11/07/2019 - MSRC Case 52927 was opened and a case manager was assigned.
  • 29 days of silence
  • 08/08/2018 - Public disclosure as MSRC fails to communicate further.

Help Enlighten Microsoft

There are many similar primitives out there that lead to RCE or LPE. Until Microsoft decides to address this issue, countless environments remain vulnerable to this class of attacks by default, as explained in detail in Wagging the Dog. I encourage everyone to keep hunting for these primitives to help Microsoft understand the gravity of the issue and finally address it.

This post was also published on shenaniganslabs.io.