QOMPLX Knowledge: Kerberos Delegation Attacks Explained

This is the latest in a series of posts we’re calling “QOMPLX Knowledge.” These posts are intended to provide basic information and insights about the attack activity and trends that are driving malicious campaigns and that QOMPLX researchers encounter in our forensic work with customers.
--
The Kerberos delegation feature in Active Directory (AD) is an impersonation type present since AD was introduced in Windows 2000. Delegation allows service accounts or servers to impersonate other users and access services on different machines. A common example is a web server “impersonating” a client when it accesses a backend database and retrieves data in the security context of the client requesting it.

While delegation has a host of benefits, it also poses numerous security challenges that can expose network resources to damaging attacks. These include devastating Golden Ticket and Silver Ticket Keberos forgery attacks that grant an attacker unfettered control over an entire domain or a specific service.

Key Points

• Unconstrained delegation is perhaps the riskiest Kerberos delegation feature; computers are allowed to impersonate any user in order to access network-based resources.
• Attackers may used unconstrained delegation to steal service tickets or compromise a KRBTGT and perform Golden Ticket and Silver Ticket attacks
• Constrained delegation trusts computers for delegation only to specified services.
• Resource-based constrained delegation has been available since Windows Server 2012. It limits delegation to a targeted resource rather than the host requesting access.
• Secure Active Directory configurations blunt these attacks, as does use of the Protected Users security group

How Kerberos Delegation Attacks Work

There are three delegation types available to administrators in Active Directory: unconstrained, constrained, and resource-based constrained delegation.

Unconstrained Delegation

Unconstrained is by far the riskiest and most ripe for abuse. It pre-dates the other two delegation types, and spawned a litany of research and Black Hat presentations on Active Directory attacks and the security of the Kerberos authentication protocol.

Unconstrained delegation enables a complicated chain of trust that allows machines to impersonate users and access any network-based service. The original intent was to use Kerberos authentication to allow computers to access services and modify database records on other machines on the network on behalf of the user.

For example, attackers with a foothold on a server that is configured for unconstrained delegation, as shown below, could steal a domain administrator’s ticket granting ticket (TGT) and use it across the domain to access any service they wish.

Ticket Granting Tickets are generated by an Active Directory domain controller’s Kerberos Key Distribution Center (KDC). An encrypted TGT is given to the user and can only be decrypted by the KDC; only domain controllers within a domain share the secret that can decrypt a TGT.

When the user requests access to a service—a Ticket Granting Service (TGS)—the domain controller validates the request and creates the requested service ticket, encrypting it using the service account’s NTLM hash. Once the user connects to the server hosting the requested service and the TGS containing a Service Principal Name (SPN) is presented, the service decrypts using its hash and opens the ticket.

If unconstrained delegation is turned on, a copy of the user’s TGT is available in the service ticket; the service can then store the TGT in its Local Security Authority Subsystem Service (LSASS) and use it again to impersonate that user for the lifetime of the service ticket.

Once an attacker finds such a server configured for unconstrained delegation, they can steal the service ticket from memory, extract the TGT and use it, impersonating the user as well and making use of their privileges to move within a compromised environment.

An attacker can also make use of a host configured for unconstrained delegation to attack a domain controller TGT by exploiting what’s known as the printer bug. The Windows Print System Remote Protocol can be used by a host to query other hosts for updates on jobs. To do so, the target authenticates to the host making the request via a service ticket, which would also contain the TGT if unconstrained delegation is enabled. From there, the attacker could attempt to extract the domain controller’s TGT from memory and use that in a host of other attacks enabled by freely available tools such as Mimikatz or Rubeus, to name two.

Mitigation:

To blunt these attacks, administrators are advised:

• Not to configure servers or hosts to Kerberos unconstrained delegation; configure them instead with constrained delegation.
• Assign specific accounts such as domain administrator or enterprise administrator to the Protected Users security group, which is restrictive by default and cannot be delegated.
• Testing should also be conducted before putting all administrative accounts into the Protected Users group in order to undo the change if issues arise.
• Set Admin accounts to “Account is sensitive and cannot be delegated” within Active Directory.
• Observe basic security hygiene:  patching delegated servers; training users to spot phishing attacks and avoiding interactions with these and other suspicious messages.

Constrained Delegation

Beginning with Windows Server 2003, Microsoft has offered “constrained delegation” as a preferred option to unconstrained delegation. Using constrained delegation, systems within an Active Directory environment trust only specified services. Constrained delegation limits what services are accessible by a delegated computer.

A Windows Server 2003 feature known as “protocol transition”—a new extension within constrained delegation—enables this cross-forest trust.

Services that rely on Kerberos for authentication leverage protocol transition to obtain Kerberos service tickets for users or proxies that are not part of the Kerberos environment. Using the constrained delegation extension, once a service ticket is authenticated, a designated list of services is available to the user being impersonated.

An attacker can abuse this in a similar way, and impersonate users without the need for their password.

The constrained delegation designation relies on two Kerberos extensions known as S4U2Self and S4U2Proxy.

• The S4U2Self extension permits accounts to request service tickets to themselves for a given user. The issued ticket will be marked by the domain controller as “forwardable.”
• The S4U2Proxy extension uses the forwardable service ticket to request a ticket to a SPN in the msDS-AllowedToDelegateTo field of the requesting service.

As consultant Ryan Hausknecht explains: “If there is an SPN set in the msDS-AllowedToDelegateTo property for an account and the userAccountControl property contains the value for TRUSTED_TO_AUTH_FOR_DELEGATION, that account can impersonate any user to any service in that SPN. While it was explained that the S4U2Self extension allows a service to request a TGS to itself on behalf of any user, the additional part of the attack is that the sname (service name) field of the SPN in the (second) TGS is not protected, which allows an attacker to change that to be any service they desire.”

Mitigation:

To blunt these attacks, administrators are advised:

• Configure privileged accounts to Account is sensitive and cannot be delegated within Active Directory.
• Assign specific accounts such as domain administrator or enterprise administrator to the Protected Users security group, which is restrictive by default and cannot be delegated.
• Testing should also be conducted before putting all administrative accounts into the Protected Users group in order to undo the change if issues arise.
• Disable Protocol transition whenever feasible.

Resource-Based Constrained Delegation
Debuting with Windows Server 2012, resource-based constrained delegation is difficult to abuse compared to unconstrained and constrained delegation, with relatively few ways to target it.

Unlike unconstrained and constrained delegation, resource-based constrained delegation is configured on the resource a user is attempting to access, rather than on the servers requesting access. To quote Microsoft documentation, resource-based constrained delegation “puts control of delegation in the hands of the administrator owning the resource being accessed.”

The security benefit is that resource-based constrained delegation cannot use the TRUSTED_TO_AUTH_FOR_DELEGATION” bit that previously controlled protocol transition. “The KDC always allows protocol transition when performing resource-based constrained delegation as though the bit were set,” according to Microsoft

Instead, using Resource-Based Constrained Delegation, Active Directory accounts allowed for delegation are used by the msDS-AllowedToActOnBehalfOfOtherIdentity attribute of the target resource’s server. This gives administrators firmer control over the accounts configured for impersonation.

Successfully attacking an Active Directory environment using this type of delegation is difficult. An adversary would need to  insert an account specifying a SPN set on the target object into the msDS-AllowedToActOnBehalfOfOtherIdentity domain controller attribute.

They would then need to create an account and set the attribute to contain a security descriptor supporting the attacker’s account. From there, a tool such as Rubeus can be used to request a service ticket from the domain controller. Once the ticket is obtained, an attacker can run Active Directory attacks such as DCSync to access other domain controllers on the network and move laterally on the network.

Mitigation

To blunt these attacks, administrators are advised to:

• Deny users the ability to modify object attributes in Active Directory. This will shut down many of an attacker’s capabilities in this type of attack.
• Configure privileged accounts to Account is sensitive and cannot be delegated within Active Directory.
• Assign specific accounts such as domain administrator or enterprise administrator to the Protected Users security group, which is restrictive by default and cannot be delegated.
• Testing should also be conducted before putting all administrative accounts into the Protected Users group in order to undo the change if issues arise.

Additional Reading

Learn more about QOMPLX Cybersecurity Solutions.

Here are the previous entries in our QOMPLX Knowledge series; look for more in our QOMPLX Knowledge series in the days and weeks ahead.

QOMPLX Knowledge: Golden Ticket Attacks Explained

QOMPLX Knowledge: Silver Ticket Attacks Explained

QOMPLX Knowledge: Responding to Golden Ticket Attacks

QOMPLX Knowledge: DCSync Attacks Explained

QOMPLX Knowledge: DCShadow Attacks Explained

QOMPLX Knowledge: Pass-the-Ticket Attacks Explained

QOMPLX Knowledge: Kerberoasting Attacks Explained

Other links to consider:

Kerberosity Killed the Domain

S4U2Pwnage

Another word on delegation

AD Security: Kerberos Unconstrained Delegation

University of Washington: Kerberos Delegation in Active Directory

Microsoft documentation: Impersonation

Microsoft documentation: Kerberos delegation

Not a Security Boundary: Breaking Forests’ Trusts