Kerberoasting
Background
The Kerberoasting attack is a lateral movement technique used in Active Directory environment. To better understand this attack, a basic knowledge of how Kerberoasting authentication protocol works is necessary. The Kerberoasting authentication protocol is covered here. But to summarize, users are granted access to domain services by requesting a ticket for this specific service to the KDC (Key Distribution Center).
Here is a schema summarizing how Kerberoasting works.
In Active Directory, each service run under a domain account (host-based or user account). A domain account that is mapped with a service is named a service account. Each service account has a unique identifier representing the instance of a service, which corresponds to the Service Principal Name. The Service Principal Name (SPN) can be found within the attributes of the account and is unique within the domain. The first step to perform a Kerberoasting attack is to enumerate all domain accounts with the SPN attributes set.
In Active Directory, any user from the domain is allowed to request a ticket to access a service. The ticket to get access to a specific services is encrypted with the service account NTLM hash. By conducting a brute force attack against the ticket, an attacker may possibly retrieve the clear text password of the service account and extend its access to the network.
In Kerberoasting attack, SPN from user domain accounts are mostly targeted compare to host-based account. In the first case, the password of a user account is set manually by an administrator and so more subjected to human errors. On the contrary, in host-based account, the password is randomly determined by the system and much more complex. By default, the password rotates every 30 days. Therefore, hashes from an host-based account is less likely to be cracked offline even using a powerful GPU cracking rig.
The success of the Kerberoasting attack rely on the ability to crack the ticket offline and to gain credentials for a domain account that permits to give additional access to services or parts of the network. As instance it is common to observe high privilege user account tied to a service.
It could be note worthy for a company to be aware of the danger surrounding SPN within the environment even if we were not able to crack the TGS in the time allocated for the engagement. Lowering the severity of the finding can be an option in such case.
Pre-requisites
Prerequisites to perform a Kerberoasting attack are the follow:
Credentials for a domain user account
A SYSTEM shell on domain-joined host
A shell in the context of a domain user account
It is possible to conduct the Kerberoasting attack from different perspectives:
From a non-domain joined Linux host with domain user credentials
From a domain joined Linux host as root after retrieving the keytab file
From a domain-joined Windows host authenticated as a domain user.
From a domain-joined Windows host with a shell in the context of a domain account.
From a domain-joined Windows host with a shell in the SYSTEM context
From a non-domain joined Windows host using the runas /netonly.
From a Linux Host
Impacket - GetUserSPN.py
Listing all SPN Accounts
Check for the group membership of all the listed accounts to see if some SPN accounts are members of high privileged groups.
Requesting TGS Tickets for all SPN users
This command is to request TGS tickets for all listed SPN accounts from a Linux remote host. Only a domain user account credential is needed.
Requesting specific TGS Tickets
It is possible to request a TGS ticket for a specific service only.
OR
We can also use the Kerberos authentication mechanism (ptt) to get the krb5tgs hash of SPN users. The command below shows that having the .ccache
ticket from the KRBTGT service, I could dump the krb5tgs without the need of valid credentials.
Cracking the ticket
We can use Hashcat to crack the ticket offline.
From Windows Host
Semi Manual Approach
Manual approach requires more steps than with automated tools or scripts. However, knowing how to perform Kerberoasting in different manners can be useful in case that we are restricted in the use of some tools.
We can enumerate all SPN users account with the Windows command-line tool setspn.exe. The command will output both computer and user accounts.
Requesting the TGS for a specific SPN account
Then we can request a TGS for a specific service and load the ticket into memory using Powershell.
The first command is to load a .Net
class within the Powershell session that can be instantiated. The -AssemblyName
parameters specify the type of data we will be using. The System.IdentityModel
is a namespace containing class to create security tokens objects.
The second command is to request a TGS for the service specified in argument. The System.IdentityModel.Tokens
corresponds to a name space and the KerberosRequestorSecurityToken
represents a class.
Requesting TGS for all SPN accounts
It is also possible to request TGS for all SPN accounts. However, tickets from both user and computer SPN accounts will be retrieved which is not the ideal.
Extract the TGS file using Mimikatz
The next step is to extract the TGS loaded into memory using Mimikatz.
The base64 /out:true
is to format the output in base64. Otherwise, the TGS will be retrieved in .kirbi
file and written to disk.
Conversion of the TGS file from b64 to .kirbi
We can perform some manipulation to the b64
TGS file to be able to crack it using Hashcat. The command below removed white spaces and new lines. This will output the TGS in a single line.
We can easily switch back from the base64 to the .kirbi format if needed.
Extracting the ticket from the TGS file using kirbi2john.py and put it in Hashcat format
The kirbi2john.py
script can be used to extract the ticket service from the TGS file. This will output a crack_file.
To crack the ticket using Hashcat, we can do the following modification on crack_file:
Crack the ticket using Hashcat.
See details here.
Powerview
The Kerberoasting attack can be simplified a lot by using the Powerview script instead of the manual approach.
Listing all SPN accounts
Retrieving the TGS file for a specific user
The following command output the TGS file for the sqldev
SPN account. We can specify to format the TGS output to be crackable by Hashcat.
Retrieving TGS for all SPN users
It is possible to use the Export-Csv command to output the TGS files into a .csv file that we can upload offline.
Rubeus
Rubeus offers a way more options than the previous tools covered to perform Kerberoasting attacks. We can download a pre-compiled binary of Rubeus on this repo. All the commands below are run from a domain-joined Windows system.
Amongst others capabilities listed by Hack The Box Academy:
Performing Kerberoasting and outputting hashes to a file.
Using alternate credentials.
Performing Kerberoasting combined with a pass-the-ticket attack.
Performing "opsec" Kerberoasting to filter out AES-enabled accounts.
Requesting tickets for accounts passwords set between a specific date range.
Placing a limit on the number of tickets requested.
Performing AES Kerberoasting.
Statistics
Rubeus offers the capability to collect statistics about the kerberoastable users. It is possible to retrieve information such as what types of algorithm is used to encrypt the ticket and the last time the password of the domain account was set.
/nowrap flag
In the command below we are requesting the TGS for every SPN with the adminCount flag set to 1. The /nowrap
flag is to format the b64 TGS to be crackable by Hashcat.
It is possible to retrieve Kerberoast TGS tickets with different encryption types.
Notes on encryption
$krb5tgs$23$*: RC4 (type 23)
$krb5tgs$18$*: AES-256 (type 18)
Tickets being encrypted using the RC4 encryption type are a way more easier to crack offline than tickets being encrypted with the AES algorithm which takes longer.
It is possible to use Powerview to determine if a specific type of encryption is set for the SPN account. The testers must check the msds-supportedencryptiontypes
attribute. If set to 0
, this means that the SPN used the encryption algorithm by default (RC4_HMAC_MD5
). If set to 24 this means that the SPN user supports only the AES 128/256
encryption. The use of the /tgtdeleg flag can be used to send only TGS request with the RC4 encryption.
Use 19700
in Hashcat to crack tickets encrypted with the AES 128/256 encryption file
Listing all SPN users tickets
In the following command:
/tgtdeleg:
to only retrieve the encrypted ticket using the RC4 algorithm. Will downgrade the ticket encrypted with AES to RC4.
/nowrap:
to avoid b64 tickets blob to be column wrapped
/format:
to output the tickets in a format readable by Hashcat.
/consoleoutfile:
to output the ticket into a file
In Windows server 2019, only ticket with the highest level of encryption can be requested
Invoke-Kerberoast Powershell script
The script can be downloaded from this GitHub repo.
In a Powershell session:
Mitigation and Detection
Modification of the encryption algorithm
It is possible to modify the algorithm supported by Kerberos in Windows in the Computer configuration.
Computer Configuration
> Policies
> Windows Settings
> Security Settings
> Local Policies
> Security Options
, then double-clicking on Network security: Configure encryption types allowed for Kerberos.
Recommandation 1: The use of the RC4 encryption algorithm should be avoid. However Administrator should always test the impact of removing the support for a specific encryption type before applying the policy to all domain hosts.
Recommandation 2: Service accounts should be part of the Group Managed Service Account (gMSA) group. Accounts members of the gMSA group have a complex password set by Active Directory that rotate every 3 days.
Recommandation 3: The monitoring of TGS-REQ and TGS-REP can indicate the use of an automated tool to perform kerberoasting. Kerberoasting activities can be monitored. See here.
The log events to look for are:
IDs: 4769: A Kerberos service ticket was requested;
IDs: 4770: A Kerberos service ticket was renewed;
Resources
Metcalf, Sean. (2017). Detecting Kerberoasting Activity. Here
Last updated