kerberoasting

What is kerberoasting?📖

Within Active Directory, some service accounts are set up to use Kerberos authentication and these accounts have a Service Principal Name (SPN) associated with them. Kerberoasting is an attack that can be performed on service accounts in Active directory environment by requesting TGS and use offline cracking methods thereafter.

Any malicious user/attacker with access to the Active Directory environment can request TGS of any service accounts presenting the TGT to KDC (Key Distribution Center).

Assumption: You have already compromised a domain machine and you have local admin rights on the machine.

If you don’t have an idea about how Kerberos authentication works, I would recommend you to go through the article given below.

We will undertake a structured exploration of the Kerberoasting process, by going through the following sections given below.

1. Identifying SPN(Service Principal Name) enabled users
2. Requesting service ticket (TGS) using Rubeus
3. Saving service ticket (TGS) locally in the system
4. Offline cracking using John the Ripper
5. Targeted Kerberoasting
6. OpSec safe practice to perform kerberoasting attack
7. Mitigations against kerberoasting attack

Identifying SPN(Service Principal Name) enabled users👤

The PowerView module facilitates the identification of users associated with Service Principal Names (SPNs).

. PowerView.ps1
Get-DomainUser -SPN

The user krbtgt (shown above) is a default user that is used for kerberos operations. The “krbtgt” account in Active Directory is a built-in account that serves a key role in the Kerberos authentication process and is responsible for encrypting and signing all Kerberos tickets within the domain.

We would skip this account and try to have a look on the output to find out other user than krbtgt that has SPN enabled.

Based on the provided screenshot above, it is apparent that there exists an account named “serviceaccount” that we can used for keberoasting.

Requesting TGS using Rubeus 🎫

Lets verify how many kerberoastable accounts are there in current Active Directory environment. We already know that there is only one account which is serviceaccount, lets verify the same using Rubeus.

Rubeus.exe kerberoast /stats

Let’s now request TGS with /rc4opsec flag. We will discuss it later why we used this flag.

Rubeus.exe kerberoast /user:serviceaccount /simple /rc4opsec

Saving service ticket hash (TGS) locally in the system 💻

We already have got the TGS for serviceaccount. Lets save it using /outfile flag locally as shown below.

Rubeus.exe kerberoast /user:serviceaccount /simple /rc4opsec /outfile:hash.txt

The ‘type’ command can be utilized to display the contents of ‘hash.txt’ file.

type hash.txt

Offline cracking using John the Ripper 🧑‍💻

We can use john the ripper tool to crack this hash.

john.exe --wordlist=passwords.txt hash.txt

The error we got in above screenshot is most likely because of the inclusion of the port number in TGS ticket hash of the service account. To resolve this issue, the port after the domain needs to be removed from the ‘hash.txt’ file, as indicated in the highlighted section of the screenshot. This should solve our problem.

Lets now try cracking it.

Great:) We successfully have cracked the password of the service account.

Targeted Kerberoasting🎯

Setting up the the SPN (Service Principal Name) for a user account inside active directory environment and then kerberoast it is called targeted kerberoasting. We require some rights on the user account to setup SPN such as GenericAll or GenericWrite, if we do have these rights on the user account then we can set the SPN using PowerView module and later on kerberoast it. Lets find out the interesting permission using PowerView module assigned to our already compromised domain user that is mayank.prajapati

Find-InterestingDomainAcl -ResolveGUIDs | ?{$_.IdentityReferenceName -match "mayank.prajapati"}

The trick to read above output is: IdentityReferenceName (mayank.prajapati) has ActiveDirectoryRights (WriteProperty) on ObjectDN (Client-PC1). We already knew that as we took an assumption that we already have compromised a machine and we have logged in into using a user account credentials. Lets go through the output to find out interesting ACLs.

From the above screenshot we can see that the current user (mayank.prajapati) has GenericAll rights on “aniket prajapati”. It was the canonical name but we require UserPrincipalName, lets find out it.

Get-DomainUser | ?{$_.cn -match "aniket prajapati"}

As we have the UserPrincipalName, lets verify if the user already has SPN.

Get-DomainUser -Identity "aniket.prajapati"| select serviceprincipalname

We didn’t get anything in the output that indicates SPN has not still been set for this account. Let’s setup the SPN now and verify it again.

Set-DomainObject -Identity aniket.prajapati -Set @{serviceprincipalname='testdomain.local/myspnX'}

We can now request TGS for this account using Rubeus and use john the ripper to crack account’s password.

OpSec safe practice to perform kerberoasting attack

Did you notice we supplied /rc4opsec flag while getting TGS ticket for service account “serviceaccount” using Rubeus in the above section.

Rubeus.exe kerberoast /user:serviceaccount /simple /rc4opsec

The flag “/rc4opsec” is used to avoid detection triggered by MDI (Microsoft Defender for Identity) for encryption degradation. To illustrate this, consider the options available for the “serviceaccount” within the Domain Controller settings for users as shown in below screenshot.

• This account supports Kerberos AES 128 bit encryption
• This account supports Kerberos AES 256 bit encryption

Now, if we try to collect TGS ticket for the account “serviceaccount” with rc4opsec flag, it will not get us any result because the AES encryption has explicitly been enabled for this account.

However, we can still get the rc4 ticket by downgrading the encryption as shown in below screenshot, however there would be higher chances of detection by MDI.

Rubeus.exe kerberoast /user:serviceaccount /simple

Mitigations against kerberoasting🔐

1. Utilizing Group Managed Service Accounts (gMSAs) is recommended for automatic password management within Active Directory environments.
2. Use complex password while setting up service account to prevent guessing the password using brute-force attack.