Last updated
Was this helpful?
Last updated
Was this helpful?
Kerberos delegation in Active Directory refers to the ability of an object, such as a user or computer, to reuse end-user credentials for accessing resources hosted on a different server.
Unconstrained Delegation occurs when a computer, such as a File Server, has the "Trust this computer for delegation to any service" option enabled, and a Domain Administrator logs into the File Server. This enables us to grab a copy of the Domain Administrator's TGT, which can be used to authenticate anywhere in the Domain.
Elevated privileges on the host that is configured for Unconstrained Delegation.
When a system is not configured for unconstrained delegation, typically only a Ticket Granting Service (TGS) ticket for the relevant service is stored on the system when a user authenticates through Kerberos. This ticket can only be used to authenticate to the same service on that same system and cannot be used to authenticate to other services or systems within the domain.
If we were to extract the TGS ticket for the Domain Administrator from the system below, we could only use that ticket to authenticate through the HTTP service on that same system. This is not really useful since the Domain Administrator already has elevated privileges on the system.
When a system is configured for Unconstrained Delegation and a user, such as the Domain Administrator, connects to the system through a protocol like WinRM or CIFS, the TGT for the user account may be stored on the system.
If an attacker can gain access to this TGT, either by compromising the system or using other techniques, they can potentially use it to impersonate the user and access resources anywhere in the domain. This is known as a Pass-the-Ticket (PtT) attack.
In the image below, the Domain Administrator connected to the system through WinRM, and a TGT for this account can now be extracted from the system.
With effective Domain Administrator permissions from the imported TGT we can now proceed with lateral movement, such as using WinRM:
When a system has Unconstrained Delegation enabled, a potential attack vector is to force other users or systems to authenticate against the host which is configured for unconstrained delegation.
By doing so we can force the victim user / computer account to store a copy of their TGT into the compromised system.
Firstly, obtain a list of computers or servers within the domain to test.
After using one of the above methods to force authentication we soon collect a TGT for the Domain Controller DC01. We can then impersonate this using Pass the Ticket.
Disable Unconstrained Delegation: Organizations should identify all computers and services that have Unconstrained Delegation enabled and disable it whenever possible. Instead, organizations can use Constrained Delegation or Resource-Based Constrained Delegation to limit the scope of delegation.
Use Constrained Delegation: Constrained Delegation allows users and services to delegate authentication to specific services on specific computers. This ensures that the user or service only has access to the specific resources required to perform their tasks.
Use Resource-Based Constrained Delegation: Resource-Based Constrained Delegation allows services to delegate authentication to other services without requiring the use of a domain account. This allows organizations to limit the scope of delegation and reduce the risk of credential theft.
Use Protected Users group: Protected Users group is a security group that enforces stronger authentication and reduces the risk of credential theft. Members of the Protected Users group cannot be delegated to other computers or services. (Note: a TGT ticket for a protected user will still exist in memory from an interactive logon session. This means if as a user in the protected users group connects through RDP or physical logon, the TGT can be extracted and impersonated still.)
Regularly review and monitor delegation settings: Organizations should regularly review and monitor delegation settings to ensure that they are configured correctly and that there are no unintended consequences.
By implementing these mitigation's, organizations can reduce the risk of credential theft and unauthorized access to sensitive resources in their environment.
can then be used to iterate through and check for vulnerable servers.
GitHub:
