Protecting Against the Bronze Bit Vulnerability with Cortex XDR

This post is also available in: 日本語 (Japanese)

Executive Summary

A recent vulnerability, CVE-2020-17049 (dubbed Bronze Bit), has been disclosed by Microsoft. This vulnerability occurs in the way the Key Distribution Center (KDC) handles service tickets and validates if delegation is allowed. In this attack, as detailed in NetSPI Blog CVE-2020-17049: Kerberos Bronze Bit Attack, the attacker tampers with the Kerberos service ticket, allowing the attacker to authenticate to the target as any user, including sensitive accounts and members of the “Protected Users” group.

The vulnerability was patched by Microsoft and will be gradually deployed with upcoming Windows updates. Microsoft aims to enforce using the patch only on or after May 11, 2021. Though the patch is available, many organizations do not patch servers immediately, specifically the Active Directory Domain Controller server, which is an important server in an organization's infrastructure.

In this blog, we’ll cover the vulnerability in detail and explain how customers using Cortex XDR can observe and detect the attack.

Kerberos Delegation

A common use case for Kerberos delegation is a web server fetching user data from a database server. The database server can grant access to the user data only for the user. In this scenario, the web server will need to impersonate the user. This impersonation is called Kerberos delegation.

There are 3 known types of Kerberos delegation:

Unconstrained Delegation: When a user authenticates to a service that holds unconstrained delegation permission, the KDC adds the user’s ticket-granting ticket (TGT) to the ticket-granting service (TGS) so the service will be able to extract the TGT. The service account will use this TGT to obtain TGS tickets on behalf of the user. In this case, any user which is not part of the Protected Users group or set as “Account is sensitive and cannot be delegated” can be impersonated by the service account that holds this type of delegation, and the service account can obtain TGS to any resource wanted.

Unconstrained delegation poses a major security risk, as the TGT of each user authenticated to the service is stored in memory. Once an attacker compromises this type of service account, it can extract the user’s TGT and authenticate to any resource in the domain.

Constrained Delegation: Microsoft introduced Constrained delegation to tighten the security and control the exact resources the delegating service can access. This information can be found under the msDS-AllowedToDelegateTo attribute in Active Directory. Moreover, Microsoft has implemented Kerberos extensions in order to avoid holding the user’s TGT in memory. This extension is called S4U (Service for User), and it consists of S4U2Self and S4U2Proxy. S4U2Self allows the service to ask for a ticket to itself on behalf of any user. This ticket has a forwardable bit set. Next, to authenticate to another service, it uses the extension S4U2Proxy. In this extension, the service can ask TGS on behalf of the user to any service mentioned in the msDS-AllowedToDelegateTo.

Resource-Based Constrained Delegation: This last delegation method differs from the previous methods as the security controls are defined on the resource and not on the impersonating service. The access control information can be found under the object msDS-AllowedToActOnBehalfOfOtherIdentity attribute.

The Vulnerability

As noted above, the delegation is only allowed for users that are not part of the Protected Users group or marked as sensitive accounts. For those users, even if the TGS request will be with a forwardable bit, the KDC will return the ticket with the forwardable bit unset. CVE-2020-17049 arises from a Kerberos design flaw. While the Privileged Attribute Certificate (PAC) validates the user privileges, there’s no integrity mechanism to determine if any of the KDC-options flags have been forged. As the KDC-options flags are protected only by the service ticket password hash, once the attacker compromises the service hash, they can decrypt the ticket, flip the forwardable bit, and re-encrypt the ticket.

(Credits to https://blog.netspi.com/author/jkarnes/)

Behavioral Activities Observed

As the beginning of the Kerberos transaction is standard and the TGS reply is encrypted, we can only observe the activities that happen after the forwardable bit flip. As Cortex XDR has the ability to correlate data from the Cortex XDR Agent, Palo Alto Networks NGFW, and Active Directory data, we can provide very detailed observations. Since the attacker must manipulate the ticket and flip the forwardable bit, the Kerberos session will be initiated from the attacker process and not from lsass.exe.

You can use this hunting query to find such cases:

Next, if we look at the Kerberos data being transmitted on the wire, we can see the S4U2Proxy request by noticing the forwardable and constrained delegation flags.

In this case, since we have the Kerberos flags and Active Directory data, we can check whether the user is sensitive for delegation or part of the protected groups.

In a second scenario, the attacker might try to avoid Resource-Based Constrained Delegation as they are limited to a machine that does not have delegation permissions.

In this scenario, the attacker creates a machine account with a known password and adds it to the trusted principles of the target service. During this exploitation, the attacker asks a TGT for a newly generated machine account to use it as the delegating service. In this case, we leverage the correlation between the Cortex Agent and Palo Alto Networks NGFW, as we can see that the actual computer name is different from the machine account in the TGT.

Lastly, after the attacker receives the TGS for the requested user to the Kerberos cache to be able to work flawlessly. In the case of a Kerberos ticket cache manipulation, the malicious process calls “LsaCallAuthenticationPackage” with a flag message type named “KerbSubmitTicketMessage”. “LsaCallAuthenticationPackage” is an RPC-based function that triggers an RPC server handler in lsass.exe. This function handles a variety of requests and routes each request to the proper handler based on the “AuthenticationPackage” and the “ProtocolSubmitBuffer” parameters.

Stack trace of the RPC server handler function

For this activity, Cortex XDR has an RPC tracking capability which allows us to track relevant events that were generated on the system and identify the source process that requested the RPC operation. We can detect the ticket injection by observing the flag message type which was sent to the server. The flag message type is part of the ProtocolSubmitBuffer parameter, and lsass.exe reads it from the injector process by calling the “NtReadVirtuaMemory” function.

Cortex XDR correlates between the RPC function context and the flag message type that was copied from the injector. Based on this advanced correlation, the agent can block this attack and any Kerberos ticket injections.

Cortex XDR Alerts

Cortex XDR will trigger multiple alerts on this activity, beginning first with static analysis. WildFire and Behavioral Threat Prevention will trigger on Mimikatz and other tools that implement this technique.

In the later stages of the attack, an Analytics BIOC will trigger on the uncommon implementation of Kerberos within a non-standard process, and the usage of a machine account from an uncommon source.

Following these detection techniques, a Cortex XDR Analytics BIOC focused on the Bronze Bit delegation itself will trigger.

Lastly, when the attacker performs a pass-the-ticket (PTT) technique to abuse the new credentials, Cortex XDR will trigger a Behavioral Threat Protection on the PTT activity.

Full Attack Chain

Summarizing Alerts that are raised during the execution of CVE-2020-17049

Conclusion

The CVE-2020-17049 vulnerability occurs because of a small modification of the Kerberos forwardable flag. Since the Kerberos response is encrypted, it is impossible to detect this modification without holding all users’ secrets. To detect the behavior, Cortex XDR leverages the capability of correlating different data sources and detecting the malicious activity on different attacker execution steps.

Read the Unit 42 Bronze Bit Threat Brief here.