Introduction
What I intend to talk about in this blog is a stream of information regarding Kerberos and Kerberoasting. Starting with a general summary and high level overview I will proceed to provide and illustrate the steps involved in the process. Following this we will dive in on conducting a SPN based Kerberoast attack with remediation and mitigation steps.
A quick summary of Kerberoasting
Kerberoasting is a computer exploit technique that involves attacking a common Windows authentication service known as Kerberos. This technique is utilized by a regular user account attempting to gain credentials of a service account, also known as an SPN or service principal name. The attack relies on the use of a deprecated encryption algorithm RC4(Arcfour) when requesting a Kerberos ticket.
To put this in perspective a domain user account uses AES256 encryption when making any Kerberos requests. However when a user account is converted into a service account (SPN) the default encryption is downgraded by Kerberos to RC4.
RC4 encryption simply uses the NT hash of the user's password as the key as per RFC 4757.
To help paint a clear picture It is important to look at and review the encryption being used by kerberos as well as the hashing algorithms used by Windows when storing passwords. Let’s take a look below.
Kerberos encryption algorithms
DES-CBC-MD5 - Data encryption standard dates back to 1974 and is a symmetric block cipher that could only handle a 56 bit key.
DES3-CBC-SHA1 - Improves upon standard DES by implementing 3 separate 56 bit keys and the sha1 algorithm.
RC4 (ARCFOUR) - is a symmetric cipher that dates back to 1987 that uses multiple key sizes. In kerberos this encryption uses the same key as the NT hash of a user's password as stated in RFC 4757.
AES256 - CTS - HMAC -SHA1 - 96 - Advanced Encryption Standard is considered modern and very secure.
Active Directory password hashing algorithms
LM - implemented in 1980 and can be found in the SAM folder on windows or the NTDS folder in a Domain Controller.
NT - is more modern and relies on an MD4 algorithm which is considered insecure and weak.
NTLMv1 - improves upon NT by using LM and NT in the encryption algorithm, but is considered weak and insecure by modern standards.
NTLMv2 - improves upon NTLMv1 but can still be cracked if the initial password is weak and found in a dictionary.
What is Kerberos?
If you do not already know, Kerberos is a computer security and authentication protocol designed to perform authentication without transmitting passwords across the network. The name Kerberos comes from the Greek mythological 3 headed dog that guards the gates of Hades. Also known as Cerberus.
Although we are not talking about a mythological creature in this case, it does allow for a simple visual analogy. Just as the Kerberos of Hades has 3 heads, the Kerberos authentication protocol involves three encryption keys, one for the client, key distribution center and the resource.
Kerberos short walk through
Starting off with an overview of those objects involved in this walk through. We have 5 total objects, 3 encryption keys, a token, and a ticket.
Green key - is used by the ticket granting server and the file server.
Blue key - is used by the authentication server.
Red key - is used by the user.
Ticket - can be exchanged for a token.
Token - provides full access to the resource.
Kerberos Tray - is the container that stores the Kerberos keys for each user or computer.
Step1
The user requests access to a file on File Server 01 (FS01) in the domain. FS01 denies the request and tells the user this is a Kerberos secured environment and a Kerberos Token is required.
Step2
The user then makes a request to the key distribution center for a token to access files on FS01 and this request by default is encrypted with AES encryption using the users key (Red Key). The authentication server then decrypts this request with the users key (Red Key) from Active Directory and will then be able to read the contents of the request. After reading the request the authentication server creates a ticket that can be exchanged for a token at the Ticket Granting Server and encrypts this ticket with its own (Blue) key sending it back to the user.
Step 3
The user takes that ticket to the ticket granting server and hands it in requesting a token. The ticket granting server then decrypts that request with the authentication server encryption (blue) key and is able to read the requests and grants a token that is encrypted with the TGT server (green) key.
Step 4
The user makes a request and submits the token to FS 01, which then decrypts the token with the green key and grants access to the User.
Kerberoast process at a really high level
The three steps to an SPN based Kerberoast attack;
Identify SPN user account.
Request Kerberos ticket for SPN user account.
Crack ticket offline.
Kerberoast - Identify SPN user account
The attacker will typically query active directory for objects with the SPN (service principal name), with the goal of finding a user account associated with a service. There are two types of user accounts tied to a service, a host and domain account. The host account cannot be attacked as the encryption is too strong. However a domain based user SPN account with a weak password is vulnerable by default. If a SPN user account is found, the attacker can make a request for a ticket in the next stage.
There are several tools available for enumerating Active directory in search of objects with the SPN attribute.
Impacket - GetUserSPN
Powershell - set-spn
LDIFDE
Powersploit
CMD Line DS Query
Powershell - setspn.exe -q */*
Kerberoast - Second Stage - Obtain the ticket
Once the attacker has identified an active spn account they are able to make a request to Kerberos as that account without the password in order to receive a ticket. The hash of the ticket is derived from whatever password was set to that SPN user account before it was converted to a Service account.
There is a common tool used to make this Kerberos request
by impacket known as GetUserSPN.
Kerberoast - Third Stage - Crack the ticket
The final stage of this Kerberos attack is to crack the ticket. We do this through brute force methods involving lengthy wordlists in which we test all possible passwords in an attempt to open the ticket.
A common tool for this is hashcat with the following flags.
Hashcat -a 3 -m 13100 /filepath/ticket.txt /usr/share/wordlists/rockyou.txt
a = mode
3 = Bruteforce mode
M = hastype
13100 = kerberos TGS type
How to prevent Kerberoasting attacks
DISABLE RC4 in the domain
Now that we have looked at Kerberos and how to perform a kerboast attack we will review mitigation and defensive measures to protect our environments against such an attack.
For starters we want to change the encryption algorithm to AES or higher for all accounts. The historical protocols used by Kerberos such as RC4 and DES are cryptographically weak and deprecated.
Secondly is our password policy around service accounts. It is common to make password policies for users in organizations but simple service accounts can be forgotten about as they are typically not accessed nearly as often as a user account. A strong password policy can prevent the ability to crack these passwords offline.
An alternative to service accounts are standalone managed service accounts or group managed service accounts which inherit strong password management from the domain, and require basic service accounts to be uninstalled which adds a layer of security.
Employing privileged account management through JEA (Just enough access) or PAM (privileged access management) to limit the abilities of users thus preventing access to tools and powershell functionality needed when querying the domain for SPN accounts is a deeper layer of security that can be added.