Kerberoasting is a common attack in Active Directory environments. It is based on a weakness in the Kerberos protocol, but its exploitation requires specific configurations.
In this article, we will explain how a kerberoasting attack works. We will also look at how to identify and exploit a vulnerable environment, as well as methods for protecting against it.
Comprehensive Guide to Kerberoasting
How does a Kerberoasting Attack Work?
What is kerberoasting?
A Kerberoasting attack targets Active Directory environments using the Kerberos protocol for authentication. Kerberoasting enables an attacker with a valid account on the network to retrieve Kerberos tickets called Service Tickets. These tickets contain information encrypted using the password of the account linked to the service.
The attacker’s objective is to retrieve these tickets and perform an offline cryptanalysis in an attempt to guess the password of the associated account. If the password is weak or poorly protected, it can be cracked, giving the attacker additional access into the network.
Process of a Kerberoasting Attack
To understand the principle behind the Kerberoasting attack, we need to look back at the concept of a service ticket (ST).
Role of the Service Ticket (ST) in Kerberos
The service ticket (ST) is the ticket obtained at the Ticket Granting Service (TGS) stage. This stage is when the client requests access to a service from the Key Distribution Center (KDC).
The special feature of the service ticket (ST) is that part of it is encrypted. This part is encrypted using a symmetric encryption algorithm and a derivative of the service account password.
Ticket encryption
In the logic of the Kerberos protocol, ticket encryption does not have the same objective depending on the adversary.
- If the adversary is not one of the entities in the Kerberos protocol, but simply an attacker listening in on the network, then encryption is used to guarantee the confidentiality of certain fields in the ticket, in particular the session key.
- In the case where the adversary is the client, encryption is essentially used to guarantee the integrity of the ticket against arbitrary modification of its content.
This difference is explained by the fact that, although the client is unable to decrypt the ticket, it is still able to deduce some of its content. This is because the encrypted part contains information known to the client (SPN, session key, etc.).
Cryptanalysis using Known-Plaintext Attacks (KPA)
With even partial knowledge of the content of the encrypted part of the ticket, it is possible to perform a cryptanalysis operation using a ‘known-plaintext attack’. If successful, the secret of the service will be discovered.
The success of this cryptanalysis operation will depend on the complexity of the service account password, as well as the complexity of the algorithm used to derive the password (RC4, DES, AES, etc.).
This observation has a rather interesting consequence in an Active Directory context. Since the client can initiate a TGS request to access any service, this implies that :
- Any active account in the domain can attempt this cryptanalysis operation.
- Any account with a Service Principal Name (SPN) can be targeted by this cryptanalysis operation.
Thus, any authenticated user can attempt to deduce the password of a service account using this cryptanalysis operation.
Limits of a Kerberoasting attack on machine accounts
In reality, this cryptanalysis operation has its limits. Machine accounts are managed directly by the domain controller. This different management introduces security mechanisms regarding the passwords for these accounts. By default, machine account passwords are :
- Randomly generated with a length of 120 characters,
- Renewed periodically every 30 days.
Under these conditions, a cryptanalysis operation targeting a machine account cannot succeed because of the complexity of the password. In an Active directory environment, it is very common for services to be associated with machine accounts.
User accounts as prime targets for Kerberoasting
On the other hand, it sometimes happens that a user account is used as a service for specific needs. Since this type of account does not have the same security mechanisms as machine accounts, the cryptanalysis operation is likely to be successful.
This is because user accounts do not generally have the same constraints on the complexity and rotation of their passwords. Another element that makes these types of account interesting is the algorithm used to derive the password for these accounts. By default, user accounts are not configured to impose the AES algorithm for this derivation. The use of the RC4 algorithm by the KDC when obtaining the service ticket further facilitates the cryptanalysis operation.
In conclusion, the kerberoasting attack consists of targeting services using user accounts, obtaining a service ticket (ST) for these accounts and then performing a cryptanalysis operation to deduce their password.
How to Identify Accounts Vulnerable to a Kerberoasting Attack?
In an Active Directory environment, an account is considered vulnerable to a kerberoasting attack if it is a user account with a non-empty Service Principal Name (SPN) attribute.
A simple user authenticated on the domain is able to identify this type of account by querying the LDAP directory.
Here is the type of LDAP query that can be used to obtain the required information:
(&(&(objectCategory=person)(objectClass=user))(servicePrincipalName=*))Several tools are available to detect these vulnerable accounts. All these tools perform more or less the same search.
Here’s how to transcribe this search from a machine not associated with the domain. The ldeep tool offers a dedicated command for listing this type of account:
ldeep ldap -u <user> -p <password> -d <domain> -s ldap://<DC_ip> users spnFrom a Windows workstation associated with the domain, it is possible to use the tool AD-Module:
get-ADUser -Filter 'ServicePrincipalName -like "*"'
In the screenshot above, the value of the msDS-SupportedEncryptionTypes attribute has been explicitly displayed. This attribute is used to identify the accounts for which the RC4 algorithm will be used to obtain the service ticket (ST). By default, this attribute is empty for user accounts, which corresponds to the use of the RC4 algorithm.
By default, the krbtgt account will appear in the output of these tools. Although this is an account with the desired properties, it is not an account considered vulnerable to a kerberoasting attack.
Exploitation of Active Directory Accounts Vulnerable to Kerberoasting
Once the vulnerable accounts have been identified, there are several steps involved in actually exploiting the cryptanalysis operation.
Identifying and retrieving the Service Ticket (ST)
The first step is to request a Service Ticket (ST) from the KDC in order to access one of the services declared by the vulnerable user.
This service ticket can then be converted into a format that password cracking programs can understand.
Using exploitation tools
Exploitation can be carried out using the Rubeus tool or the GetUserSPNs.py script from the Impacket suite.
These tools enable vulnerable accounts to be detected, a service ticket to be retrieved and this ticket to be presented in a format suitable for password cracking tools.
Here’s how to perform these actions using Rubeus:
Rubeus.exe kerberoast /nowrap /simple
The resulting output will have a format similar to this:
$krb5tgs$XX$*serviceaccount$domain.local$USSvc/[email protected]*$D35..The value entered in XX is used to differentiate the algorithm used by the KDC to generate the service ticket (ST). If the value observed is 23, then the algorithm used to derive the service account password is RC4.
This algorithm is the easiest to break. If the value observed is 18, then the algorithm used by the KDC is AES. Although password recovery is not impossible, using this algorithm makes the password cracking operation more difficult.
Password cracking
Cracking tools such as john or hashcat will be used to calculate the account password from the text obtained in the step above.
Here’s how to do it with hashcat and a list of potential passwords:
hashcat -m 13100 -a 0 hashfile wordilst.txt # for $krb5tgs$23$*…
hashcat -m 19700 -a 0 hashfile wordlist.txt # for $krb5tgs$18$*…If the password for the service account is one of those in the password list provided, then the tool will identify it.
This is how a domain user is able to exploit an account that is vulnerable to a kerberoasting attack. The consequence is that the password of the vulnerable account is obtained in clear text.
How to Protect an Active Directory Against Kerberoasting?
Having explained how Kerberoasting works, let’s look at how to protect yourself against it.
Since only user accounts are affected, a simple solution is to limit their use for implementing services. This approach is effective, but it does not cover all use cases. Sometimes, machine accounts are not enough to meet certain specific needs.
In these situations, it is essential to reinforce the elements that facilitate cryptanalysis. A strong password policy applied to user accounts is an effective method. However, managing this policy manually requires a great deal of rigour.
To simplify management, the use of managed service accounts (gMSA) is recommended. These accounts, designed specifically for services, benefit from a password policy managed automatically by the domain, just like machine accounts.
Replacing vulnerable user accounts with managed service accounts is therefore an excellent solution for protecting against Kerberoasting attacks.
Author: Benoit PHILIPPE – Pentester @Vaadata