SecCore Essentials - Kerberos Security

Summary

This entry highlights common attack vectors and special features of the Kerberos protocol that have to be kept in mind in order to create a secure environment. This SecCore Essential is considered implemented if the following conditions are met:

• There are no highly privileged users with a Service Principal Name (SPN) set
• All service users have strong and randomly generated passwords
• Pre-Authentication is required for all users
• There are no systems where Unconstrained Delegation is configured (besides of Domain Controllers)

Introduction

Kerberos is the successor to NTLM in Microsoft Active Directory environments. It is a modern and robust protocol that fixes security problems like NTLM Relaying (described in our SMB Security and LDAP Security post).

Kerberos uses a ticketing system instead of the challenge-response procedure used by NTLM, making it more robust against attacks:

• The user first requests a Ticket Granting Ticket (TGT) from the Key Distribution Center (KDC). The Domain Controller acts as an authentication server (AS) and verifies the login credentials from the request.
• The user receives a TGT from the authentication server. This ticket allows the user to request Service Tickets (ST) for a target service.
• The user provides the TGT to a Ticket Granting Server (TGS) and receives a ST for the target service.
• The user can now use this ST on the target service to authenticate. The target service never gets a (hashed) password.

Common Attack Vectors

This section describes some security problems that may arise when using Kerberos authentication.

Kerberoasting

Any valid domain user account can obtain a TGT from the KDC. The TGT proves the user’s identity and is used to request Service Tickets for accounts that have a Service Principal Name registered, such as SQL, Exchange or custom application services. The KDC encrypts the Service Ticket with a key derived from the service account’s password hash.

An attacker can use this feature to request Service Tickets for all users with an SPN, but since the ticket is encrypted, they can not be used for authentication to a target system. However, the fact that the ticket is encrypted can be exploited, since an attacker can attempt to crack the encryption password offline and recover credentials for the service account.

AS-REP Roasting

AS-REP roasting is functionally identical to Kerberoasting. There is a special flag (do not require pre-authentication) that can be set for service users which makes it possible to request a Service Ticket without presenting a TGT.

To request a Service Ticket, an attacker only needs to know the username of the target user. Since possible usernames can be enumerated, this attack is very dangerous as it does not require any domain user credentials.

After receiving a Service Ticket, it can also be cracked offline like in the Kerberoasting attack.

Kerberos Delegations

Delegations are a powerful mechanism in the Kerberos protocol, since they allow services to act on the behalf of another user or computer. For example, a web server may need to get a user's documents from a file share. It can use delegations to connect to the file share as the logged on user and retrieve their documents. There are multiple ways to set up delegations, each with different security considerations:

Unconstrained Delegation

Systems or services with unconstrained delegation enabled will cache Kerberos tickets in memory. If they are compromised by an attacker, the stored tickets can be used to authenticate to other systems with the permissions of this user or system. Tools like Coercer¹ can also be used to force a target system to connect to an unconstrained delegation system, leaving its ticket in memory where it can be stolen.

Constrained Delegation

Constrained delegation was implemented with Windows Server 2003 and was meant to improve security for Kerberos delegations. Constrained delegation allows a service account to impersonate users only when connecting to specific services (SPNs) listed in its msDS-AllowedToDelegateTo attribute.

If the service account configured for constrained delegation is compromised, an attacker can request Service Tickets on behalf of any user to the delegated target services, without needing to extract tickets from memory.

An attacker who gains administrative permissions on such a system or compromises such an account can automatically compromise all other systems that it is allowed to delegate to.

Resource Based Constrained Delegation (RBCD)

RBCD is a different form of Constrained Delegation. It was introduced with Windows Server 2012 and works in the opposite direction. Instead of the service account listing which services it can delegate to, the resource account (a computer or service) stores this information in its msDS-AllowedToActOnBehalfOfOtherIdentity attribute.

This attribute contains an Access Control List (ACL) that specifies which accounts are permitted to act on behalf of users to the resource.

An attacker who compromises an account listed in this attribute can impersonate any user to the specific resource, but cannot extend that access to other systems unless they are also explicitly configured for RBCD.

Attack Scenario

This section should demonstrate how attackers may exploit different Kerberos configurations to fully compromise the Active Directory. The setup of this attack scenario is as follows:

• Network segmentation is not properly configured
• The attacker has a foothold in the internal network without user credentials
• The attacker has no considerations regarding OPSEC, the most straightforward approach is used

Additionally this attack scenario consists of three different systems and one vulnerable user:

Since the attacker has already access to the internal network, they can use this access to crack AS-REP-Roastable accounts using a brute-force attack. For this, the tool NetExec² can be used, with the following arguments:

nxc ldap <DC> -u users.txt -p '' --asreproast output.txt

For probable usernames, a list of common usernames is used. The password field is left empty, since no password is required for AS-REP roasting. The output file contains all roastable accounts and their hashes.

This approach reveals the password hash of the roastable account serviceUser@lab.local:

This hash can afterwards be used to perform an offline brute-force attack against it:

If, like in this case, the brute-force attack is successful, the attack retrieves the cleartext password of the vulnerable account:

Afterwards the attacker can use the password to enumerate the permissions of the account, which reveals, that they have administrative access on the system srv1.lab.local:

Additionally, ADSearch³ can be used with the following arguments to search for systems that have unconstrained delegation configured:

ADSearch.exe --search "(&(objectCategory=computer)(userAccountControl:1.2.840.113556.1.4.803:=524288))" --attributes samaccountname,dnshostname

Luckily for the attacker, the compromised system srv1.lab.local is one of those systems:

Since the system is configured with unconstrained delegation, it caches Kerberos tickets in memory. This can be abused by coercing¹ a user or an additional system to login into srv1.lab.local, which then stores the ticket. All cached tickets can be viewed by the triage command of Rubeus⁴:

Rubeus.exe triage

This reveals that a ticket of the domain controller is stored in memory, after it was coerced:

With administrative permissions, this ticket can be dumped with Rubeus by providing the current session ID (LUID) and service:

Rubeus.exe dump /luid:0x651230 /service:krbtgt

Afterwards the ticket gets printed into the commandline, or it can be injected directly in the current session with the /ptt argument of Rubeus:

Now that an attacker has obtained a Service Ticket for a domain controller (a computer account), they will attempt to access the system in order to perform a DCSync attack. A DCSync means that all domain data such as users, groups, password-hashes etc. get replicated to other domain controllers. If an attacker gains access to this data, all accounts on the target domain are compromised, including users like krbtgt.

In order to accomplish this, the S4U2Self⁵ technique can be used:

Rubeus.exe s4u /impersonateuser:administrator /self /altservice:ldap/WIN-4SAHM65HN1H.lab.local /user:WIN-4SAHM65HN1H$ /ticket:[TICKET FROM DUMP] /ptt

This command impersonates the administrator account, requests access to the LDAP service on the domain controller in order to perform a DCSync and provides the previously dumped ticket of the computer account of WIN-4SAHM65HN1H$ (the domain controller):

Since machines do not get remote local admin access to themselves, the Service Ticket cannot be used to get access. However, Rubeus provides a /self flag that can be used to abuse S4U2Self to obtain a usable Service Ticket. With this injected ticket, an attacker can use mimikatz⁶ to perform a DCSync:

Mitigation

To protect against AS-REP roasting, Kerberos pre-authentication should be required: When this is enforced, it is no longer possible to retrieve the password hash of a user account through AS-REP roasting: Additionally, to remove the Unconstrained Delegation permission of srv1.lab.local the setting Do not trust this computer for delegation should be enabled if possible:

Other methods for delegation should be used.