Overview
A security researcher from Shenanigans Labs disclosed a method of attacking the Active Directory by abusing resource-based constrained delegation. This would impose a serious threat to domain environments as an attacker could make a common domain user access services on local computers as a domain administrator, thus escalating local privileges. For details, see reference link [1].
NSFOCUS’s M01N Red Team studied and reproduced such local privilege escalation achieved through this attack, and based on this, experimented on the further obtaining of domain administrative privileges by exploiting PowerShell remoting at the same time. For details, see reference link [2].
Reference links:
[1] https://shenaniganslabs.io/2019/01/28/Wagging-the-Dog.html
[2] http://blog.nsfocus.net/analysis-attacks-entitlement-resource-constrained-delegation/
Background
Delegation is a function that allows users to entrust a server on behalf of themselves for authentication to any other service. It is mainly used in the scenario where a service needs to request access to other service resources on behalf of a user.
To understand how different kinds of delegation work, let’s assume that A is an IIS web server, B is a SQL server, and A needs to use B as the database in support of user access.
Classic constrained delegation is outgoing and works like this: A user modifies the msDS-AllowedToDelegateTo attribute of Service A by adding the service principal name (SPN) of Service B and setting a constrained delegation object (Service B). Then Service A can impersonate the user to send a request to the domain controller, asking for access to Service B, in a bid to obtain the TGS service ticket for use of resources of Service B.
In contrast, resource-based constrained delegation (incoming) is implemented by modifying the msDS-Allowed To Act On Behalf Of Other Identity attribute of Service B to add the SPN of Service A, making it possible for Service A to impersonate the user to access resources of Service B.
Attack Principle
In his report, security researcher Elad Shami pointed out that a service could invoke S4U2Self to request access to its own TGS ticket on behalf of any users whether the User Account Control attribute of the service account is set to Trusted To Auth For Delegation or not. However, if it is not set, the TGS ticket that S4U2Self produces is not forwardable.
If the TGS ticket that S4U2Self produces has the FORWARDABLE flag, it can be used in subsequent S4U2Proxy invoking; if the TGS ticket is not forwardable, it cannot be forwarded by S4U2Proxy to other services for classic constrained delegation.
However, invoking S4U2Proxy with a non-forwardable TGS ticket works with resource-based constrained delegation! S4U2Proxy will accept this non-forwardable TGS ticket, request the desired service, and return a forwardable TGS ticket.
For details, visit the following link:
http://blog.nsfocus.net/analysis-attacks-entitlement-resource-constrained-delegation/#i-2
Attack Process
Following is an attack process diagram taken from Elad Sham’s report.
If it is possible to configure resource-based constrained delegation on Service B to allow access from Service A (with the permission to modify the msDS-Allowed To Act On Behalf Of Other Identity attribute of Service B), an attacker can have Service A invoke S4U2Self to request the domain controller for a TGS ticket that allows any users to access itself before using S4U2Proxy to forward this ticket to request another TGS ticket for access to Service B. Finally, the attacker can impersonate any user to access resources of Service B.
For details, visit the following link:
http://blog.nsfocus.net/analysis-attacks-entitlement-resource-constrained-delegation/#i-4
Mitigations
- For high-privilege accounts, set the property to “sensitive for delegation.”
- Add high-privilege accounts to the Protected Users group.
- Enable LDAP signing and channel binding to mitigate local privilege escalation via NTLM relaying.
Statement
This advisory is only used to describe a potential risk. NSFOCUS does not provide any commitment or promise on this advisory. NSFOCUS and the author will not bear any liability for any direct and/or indirect consequences and losses caused by transmitting and/or using this advisory. NSFOCUS reserves all the rights to modify and interpret this advisory. Please include this statement paragraph when reproducing or transferring this advisory. Do not modify this advisory, add/delete any information to/from it, or use this advisory for commercial purposes without permission from NSFOCUS.
About NSFOCUS
NSFOCUS IB is a wholly owned subsidiary of NSFOCUS, an enterprise application and network security provider, with operations in the Americas, Europe, the Middle East, Southeast Asia and Japan. NSFOCUS IB has a proven track record of combatting the increasingly complex cyber threat landscape through the construction and implementation of multi-layered defense systems. The company’s Intelligent Hybrid Security strategy utilizes both cloud and on-premises security platforms, built on a foundation of real-time global threat intelligence, to provide unified, multi-layer protection from advanced cyber threats.
For more information about NSFOCUS, please visit:
https://www.nsfocusglobal.com.
NSFOCUS, NSFOCUS IB, and NSFOCUS, INC. are trademarks or registered trademarks of NSFOCUS, Inc. All other names and trademarks are property of their respective firms.
