Kerberos Constrained Delegations Crossing AD Security Boundaries

A Brief History of Kerberos Delegations

Kerberos Delegations can be confusing, let’s face it. Microsoft has recently made changes to allow for Kerberos Constrained Delegation (KCD), including Resource-Based Constrained Delegation (RBCD), for authentication in Active Directory (AD)/Azure AD hybrid configurations. As you may recall, Microsoft implemented Kerberos Constrained Delegation in Windows Server 2003 to allow administrators to restrict delegations to specific resources and protocols on a host. In Windows Server 2012, Microsoft expanded on this with Resource-Based Constrained Delegation. RBCD allows for the resource owner to manage delegation directly on a host as opposed to an Active DIrectory administrator managing the delegation centrally. Changes were also implemented by Microsoft in 2019 to disable Unconstrained Delegation on incoming trusts, though this can be bypassed for backward compatibility.

With such major changes in place, it is important to understand how delegations behave when configured across trust boundaries. Over the last few years, attacks against Active Directory are becoming more frequent, with Kerberos delegations and Active Directory delegation misconfigurations as pivotal pieces of these attacks. This is because in the world of Active Directory, delegation essentially means impersonation- aka lateral movement or potentially privilege escalation.

Delegations Across Incoming Trusts

Let’s begin with delegations across incoming trusts. As of the July 2019 update, all supported Windows Server versions disable TGT delegation across incoming trusts by default. This is important because of the security risks that Unconstrained Delegations create. Unconstrained delegations allow for a Service Principal to delegate (impersonate) any other object in Active Directory when attempting to access any resource within Active Directory.

Unfortunately, there are a lot of third-party applications that require unconstrained delegation, so this configuration could cause a lot of issues in those environments. Microsoft allows for administrators to easily re-enable this delegation type on a per trust basis, which also opens the doors for potential attacks.

PrinterBug Attacks

Recently an exploit known as the PrinterBug was discovered where a computer can be coerced to connect to an attacker-controlled machine (or any other machine for that matter) in order to capture or relay the NTLMv1 (Net-NTLMv1) authentication.

Typically, Domain Controllers are targeted for this type of attack. However, this attack will work against any machine with the Print Spooler Service running. This is just one reason to ensure that Unconstrained Delegation is only configured where absolutely necessary. If an attacker successfully exploits PrinterBug against a computer in your environment with Unconstrained Delegation configured, they can potentially impersonate an account in Active Directory to any resource. If TGT Delegation is enabled across an incoming trust, the trusted domain is also compromised as the attacker can now also request TGTs from the trusted domain and delegate (impersonate) users.

Azure AD Attacks

The digital “manifest destiny” pushing us all to the cloud has opened up some interesting potential attack pathways. What were traditionally techniques used to exploit an on-premises AD environment can now potentially be used to gain a foothold into your cloud environment as well. Microsoft has recently released the ability to delegate authentication from Active Directory via Azure AD. This is possible by an on-premises proxy server used with Azure AD to request a Kerberos token on behalf of a user to be used in authentication originating from an Application Proxy URL. Essentially, this means a user can use their Azure AD credentials to access an on-premises Active Directory application via a URL.

Kerberos Constrained Delegation is used by default for the Application Proxy Connector Server, however, Resource-based KCD is often used as a way of providing Kerberos authentication for a web application that has users in multiple domains within an Active Directory forest. RBCD allows for the resource owner to decide which objects have access to the resource. It depends on the attributes of the resource service rather than the service being trusted to delegate. The msDS-AllowedToActOnBehalfOfOtherIdentity on the resource itself is used to configure access to the resource. Another thing to note is that protocol transition is always possible when using RBCD.

KrbRelayUp Attacks

This brings us to KrbRelayUp, the shiny new attack, that in its most simple implementation relies on RBCD and potentially Machine Account Quota settings. In the KrbRelayUp attack, an attacker leverages RBCD to elevate privileges to an administrator and then execute code (usually via the Service Configuration Manager) as SYSTEM of a target machine. This brings up two immediate areas of concern. The first concern is around the security of machines in your environment with RBCD currently configured. If a server configured for RBCD, such as an Application Proxy, is compromised, an attacker could create services and execute code as SYSTEM on that server. The second concern is around hybrid joined computer objects. If an attacker compromises an Azure virtual machine using a hybrid account, the attacker will have the ability to execute code as SYSTEM on the Azure virtual machine.

Preventing Unconstrained Delegation Attacks

Combining these delegation configurations could allow a compromised standard user in a domain to takeover that domain, potentially any other domain with an incoming trust to that the compromised domain, and any Azure AD objects synced with Active Directory. This can lead to more attack vectors in the cloud. Understanding how delegations are used across trust boundaries is pivotal in being successful in securing both Active Directory and Azure AD in a hybrid configuration. So now that I have touched on some of the most common delegation configuration targets in Active Directory, let’s look at how to mitigate them. So, let’s have a recap:

• Domain Controllers should not be used as print servers, and as such, should not have the Print Spooler service running.
• Domain Controllers should be the only objects in AD with Unconstrained Delegation (if possible)
• TGT should be disabled on incoming trusts, as is the default as of July 2019 (if possible)
• Enable LDAP signing- This guarantees the authenticity and integrity of the LDAP contents.
• Enable LDAP channel binding- This binds TLS with LDAP to prevent Person in the Middle attacks.
• Set Active Directory ms-DS-MachineAccountQuota to 0. This is set to 10 by default and allows for a standard user in the Active Directory to create and join 10 computers to AD. This method is the easiest way for an attacker “find” a computer with RBCD configured on it to create a computer object using default AD privileges.

Microsoft Defender 365 reports being capable of detecting the first 3 stages of KrbRelayUp, while Microsoft for Endpoints detects “suspicious LDAP and Kerberos requests to Active Directory domain controllers”. Administrators can also manually detect this type of attack. A lot of times, when pre-written tools and scripts are used for this type of attack, they leave a fingerprint. It is well known that tools like powermad and impacket  create four distinct SPNs when creating a computer object:

• Host/<hostname>
• Host/<hostname>.<domain>
• RestrictedKrbHost/<hostname>
• RestrictedKrbHost/<hostname>.<domain>

This can be correlated with Windows security event 4741 (A computer account was created) for MSADChangedAttributes when working with a SIEM. Another Windows security event to look for is 7045 (New Service was installed). The default service name for the KrbRelayUp attack tool is KrbSCM. The issue with these detection methods is that the SPNs are not always created depending on the method used to create the computer object account, and the service name can easily be changed by the attacker. A better method is to look for authentication methods indicating the privilege escalation. Windows event id 4624 (An account was successfully logged on) will show a Source Network Address of 127.0.0.1 with authentication type of Kerberos. The account name will usually (but not always be administrator). The fingerprint of authenticating to itself via Kerberos as Administrator is always an indicator relay being used for the privilege escalation.

Summary

Ok, a lot of info has been covered here on inter-forest delegation, delegation types used with hybrid AD/Azure AD environments, and how krbRelayUp relies on misconfigurations of such delegation to accomplish privilege escalation. As Microsoft delegations have now also moved into Hybrid AD authentication, I expect to see more use of krbRelayUp as a pivot into cloud breaches. In summary, when expanding your AD environment across a trust or security boundary, be sure to understand what types of delegations you have in place. The compromise of one of your environments could cause the compromise of all of them.