Understanding and Mitigating Kerberos Delegation Attacks

Kerberos delegation, a feature integral to Microsoft’s Active Directory (AD) since its inception in Windows 2000, is designed to facilitate seamless and secure communication between services in a networked environment. However, if not managed correctly, this feature can become a gateway for attackers, leading to potentially devastating breaches.

What is Kerberos Delegation?

At its core, Kerberos delegation allows one service to impersonate a user to access another service on their behalf. Imagine a web server needing to fetch data from a backend database for a user. Instead of the user directly accessing the database, the web server does so on their behalf, ensuring a streamlined user experience.

The Three Faces of Kerberos Delegation:

1. Unconstrained Delegation: The oldest and most vulnerable type. It grants a service the ability to impersonate users and access any network-based service. This broad scope makes it a prime target for attackers. For instance, an attacker with access to a server configured for this type of delegation can steal a user’s Ticket Granting Ticket (TGT), granting them access to any service across the domain.
2. Constrained Delegation: Introduced in Windows Server 2003, this type narrows down the services a delegated computer can access. It uses Kerberos extensions, namely S4U2Self and S4U2Proxy, to manage this restricted access. While more secure than its unconstrained counterpart, it’s not impervious to attacks. Misconfigurations can allow attackers to impersonate users without needing their passwords.
3. Resource-Based Constrained Delegation: A feature since Windows Server 2012, this type is set up on the resource a user wishes to access, not on the requesting servers. It offers administrators more granular control over impersonation rights, making it the most secure of the three. However, attackers can still exploit it if they gain the ability to modify specific Active Directory attributes.

Potential Attack Vectors:

• 1. Kerberoasting:
  • Technical Details:
    • SPN Enumeration: Every service account in AD has an associated Service Principal Name (SPN). Using tools like PowerShell or ldapsearch, attackers can enumerate all SPNs, identifying potential service accounts.
    • Ticket Extraction: Once SPNs are identified, attackers can request their respective service tickets using the GetUserSPNs function in tools like Impacket. These tickets are encrypted using the NTLM hash of the service account’s password.
    • Offline Cracking: The extracted tickets can be cracked offline using tools like John the Ripper or Hashcat. Given that service accounts often have long-lived passwords, attackers might use powerful GPU rigs to speed up the cracking process.
• 2. Golden Ticket Attack:
  • Technical Details:
    • Domain Admin Compromise: This attack requires domain admin rights, often obtained via other attack vectors like phishing or exploiting vulnerabilities.
    • TGT Forgery: Using tools like Mimikatz, attackers can forge a TGT. They have control over the ticket’s lifespan, associated user, and privileges.
    • Stealth and Persistence: The forged TGT can be used for up to 10 years by default, allowing attackers to maintain persistence in the environment without re-engaging in the initial compromise.
• 3. Silver Ticket Attack:
  • Technical Details:
    • Service Compromise: Attackers need the NTLM hash of the service account, which can be obtained from a compromised machine or through methods like Kerberoasting.
    • Service Ticket Forgery: Using the acquired hash, attackers can forge a service ticket for a specific service using tools like Mimikatz or TicketConverter.
    • Localized Impact: Unlike the golden ticket, the silver ticket is specific to a service, but it’s not verified by the domain controller, making it stealthy and hard to detect.
• 4. Unconstrained Delegation Exploitation:
  • Technical Details:
    • Memory Dumping: Tools like Mimikatz can be used to dump the memory of a server with unconstrained delegation enabled. This memory dump contains the TGTs of users who’ve recently authenticated to the server.
    • TGT Theft: Extracted TGTs can be injected into the attacker’s session, allowing them to impersonate users and access services as those users.
• 5. Constrained Delegation Exploitation:
  • Technical Details:
    • Account Compromise: Attackers need to compromise an account with constrained delegation rights. This can be done through various means, including phishing or exploiting vulnerabilities.
    • Forced Authentication: Attackers can force a service to authenticate to a machine they control, capturing the service’s TGT.
    • Ticket Request: Using the S4U2Self extension, attackers can request a service ticket for any user, and then with the S4U2Proxy extension, they can request a ticket to access a service on behalf of that user.
• 6. Resource-Based Constrained Delegation Exploitation:
  • Technical Details:
    • Attribute Manipulation: Attackers need to modify the msDS-AllowedToActOnBehalfOfOtherIdentity attribute in AD, which controls resource-based constrained delegation.
    • Service Impersonation: After modifying the attribute, attackers can impersonate services and request tickets on behalf of users, similar to constrained delegation exploitation.

Securing Your Environment:

1. Review and Restrict Delegation: Regularly check which accounts have delegation enabled. Only essential accounts should have this privilege, and always prefer resource-based constrained delegation.
2. Protect Service Account Credentials: Ensure service accounts have complex passwords that are changed regularly.
3. Monitor for Suspicious Activity: Keep an eye out for unusual service ticket requests or unexpected renewals.
4. Limit Privileges: Service accounts should only have the minimum required privileges.
5. Active Directory Hygiene: Avoid unconstrained delegation, assign privileged accounts to the “Protected Users” security group, and ensure regular patching.
6. Educate and Train: Ensure that your team is aware of the risks associated with Kerberos delegation and that they can recognize potential phishing or social engineering attempts.
7. Regular Audits: Use tools like BloodHound to visualize AD permissions and identify potential delegation misconfigurations.
8. Limit Delegation: Prefer resource-based constrained delegation and ensure that only necessary accounts have delegation rights.
9. Monitor for Anomalies: Implement solutions like Microsoft Advanced Threat Analytics to detect abnormal Kerberos activities.
10. Educate Staff: Regular training sessions to keep IT staff updated on the latest threats and best practices.

In conclusion, while Kerberos delegation is a powerful feature that can streamline service interactions in a networked environment, it’s not without its risks. By understanding its intricacies and potential vulnerabilities, organizations can take steps to secure their environments and protect their assets.