Skip to main content

Kerberoasting (Not the usual Sunday Roast)


dips
Forum|alt.badge.img+7
  • Veeam Legend
  • 808 comments

Here is a quick post on a Active Directory attack Vector called Kerberoasting which seems to have started gaining more and more prominence recently. 

It is a technique used mostly to steal credentials and move laterally through the network. 

What is Kerberoasting?

This is a technique that is carried out once a malicious actor gained access to a domain user account within a AD environment. User objects configured with a Service Principal Name (SPN), i.e. service accounts, can be exploited by malicious actors by requesting its Ticket Granting Service (TGS) ticket from a Domain Controller. This TGS ticket is encrypted with the hash of the service account's password. 

Service accounts in particular can sometimes have additional privileges such as being a member of the Domain Admins Security Group. 

Once the malicious actor has the TGS, it is then exfiltrated and with the enormous power of GPUs these days, will attempt to crack the password hash using brute force techniques. Once cracked, they can essentially use it to move through the network by authenticating as the account.  

Actions such as attempts can be made to exfiltrate data, escalate or set back doors. 

Mitigating Kerberoasting

  • Minimise the number of user objects with SPNs
  • Use Group Managed Service Accounts (gMSA) or Delegated Managed Service Accounts (dMSA) in Server 2025
  • Service Accounts should use AES (128 and 256 bit) for Kerberos service ticket encryption
  • If it is not possible to use gMSA accounts, set a unique, randomly generated password with at least 30 characters and rotate often

Detecting Kerberoasting
As this is legitimate Active Directory Activity, this type of activity can be quite hard to detect. 
On Domain Controllers, check for Event ID's: 4738, 5136 & 4769

  • 4738 & 5136 - These are generated when a user account is changed.
  • 4769 - This is generated when a TGS ticket is requested. When executed maliciously this event is generated for each TGS ticket requested for a user object. Additionally, RC4 encryption is requested by the malicious actor as this is easier to crack.

14 comments

lukas.k
Forum|alt.badge.img+10
  • Veeam Vanguard
  • 198 comments
  • October 13, 2024

Nice work @dips and thank you for summarizing!

Some thoughts / questions:

  1. Do you know my any chance how to monitor these events and send alarms e.g. with PRTG or other tools?
  2. How often do you recommend rotating passwords when not using gMSA?
  3. Does the password length affect the hash so that maybe it takes longer to brute force (don’t think so, right)?

dips
Forum|alt.badge.img+7
  • Author
  • Veeam Legend
  • 808 comments
  • October 13, 2024

Hey @lukas.k 

Thank you.

In answer to your questions:

  1. The best option would be to monitor these events generated on Domain Controllers. I am not sure if PRTG would be able to detect this as it comes under normal Active Directory activity and hence the difficulty in trying to detect this type of attack. I would probably export logs from your DC’s to a SIEM and setup rules there to flag for those events. 
  2. Not always possible depending on the environment, but every 30 days is recommended. This would mitigate the scenario when the hash was exfiltrated and was in the process of being brute forced. However, if it has already been brute-forced, look for and monitor user and service account creation. Has an account just appeared out of no-where? Also, use the ‘Log On to’ option in AD to restrict access only to certain workstations. 
  3. Yes, that is correct. The longer the password and as long as its utilising AES 128 or 256, the longer it will take to brute force. Ideally, identify if RC4 encryption is in use and if possible disable in the environment. Monitor Event Id 4768 on DCs, and look for ‘Ticket Encryption Type’ set to 0x17 which shows that RC4 is in use. 

Hope that helps!


dips
Forum|alt.badge.img+7
  • Author
  • Veeam Legend
  • 808 comments
  • October 13, 2024

lukas.k
Forum|alt.badge.img+10
  • Veeam Vanguard
  • 198 comments
  • October 13, 2024

Thank you!

I will add this to our internal to-do lists and share the info within my team.

The “log on to” option could be interesting but comes with some administrative effort but this could be handled by tools, maybe GPOs (?) or some scripts.

Maybe I can get some experience reports from our internal AD team, I will keep you posted!


dips
Forum|alt.badge.img+7
  • Author
  • Veeam Legend
  • 808 comments
  • October 13, 2024

Your mileage may vary with the “Log On To” option. I’ve not yet tried but setting with PowerShell is definitely worth a go. 


vAdmin
Forum|alt.badge.img+2
  • Influencer
  • 168 comments
  • October 14, 2024

Thank you @dips for the sharing.

Therefore, it is better to disable and restrict the insecure Ciphers like:

'RC4 40/128', 'RC4 56/128', 'RC4 64/128', 'RC4 128/128', 'RC2 40/128', 'RC2 56/128', 'RC2 128/128', 'DES 56/56', 'Triple DES 168'


Iams3le
Forum|alt.badge.img+11
  • Veeam Legend
  • 1393 comments
  • October 14, 2024

In addition to the above, I would recommend implementing policies that will mitigate the risks posed by these tools “Impacket, Rubeus, Mimikatz, Hashcat, and CrackMapExec”. These are some of the tools employed for kerberoasting. By implementing Attack Surface Reduction (ASR) rules, these tools etc can be prevented from running. AppLocker or Windows Defender Application Control (WDAC) policies can also help a lot here. I have written an article on this but a different use case was targeted. Lastly, I will recommend configuring Credential Guard or LSA Protection to prevent access to the LSASS process.


vAdmin
Forum|alt.badge.img+2
  • Influencer
  • 168 comments
  • October 14, 2024

@Iams3le ,


Do you recommend placing the Veeam service account into the Protected Users builtin group?

Protected Users Security Group | Microsoft Learn


Iams3le
Forum|alt.badge.img+11
  • Veeam Legend
  • 1393 comments
  • October 14, 2024
vAdmin wrote:

@Iams3le ,


Do you recommend placing the Veeam service account into the Protected Users builtin group?

Protected Users Security Group | Microsoft Learn

Hi, I would recommend using gMSAs as discussed above due to some potential bottlenecks that might arise when you do this. Please see “https://helpcenter.veeam.com/docs/backup/vsphere/required_permissions.html?ver=120”. Fabian also answered this question here: https://forums.veeam.com/veeam-backup-replication-f2/service-accounts-hardening-t82416.html


dloseke
Forum|alt.badge.img+8
  • Veeam Vanguard
  • 1447 comments
  • October 14, 2024

I’m just starting to look around at gMSA, and now you’re telling me there will be dMSA?  Hard to keep up sometimes….  Great post though….glad someone is keeping on top of this.


dips
Forum|alt.badge.img+7
  • Author
  • Veeam Legend
  • 808 comments
  • October 14, 2024
dloseke wrote:

I’m just starting to look around at gMSA, and now you’re telling me there will be dMSA?  Hard to keep up sometimes….  Great post though….glad someone is keeping on top of this.

dMSA is quite interesting as it can be used just for specific servers. I need to give it a test once I fix my broken lab.


dips
Forum|alt.badge.img+7
  • Author
  • Veeam Legend
  • 808 comments
  • October 14, 2024
vAdmin wrote:

@Iams3le ,


Do you recommend placing the Veeam service account into the Protected Users builtin group?

Protected Users Security Group | Microsoft Learn

Definitely not. The article also says the following:

  • Never add accounts for services and computers to the Protected Users group. For those accounts, membership doesn't provide local protections because the password and certificate is always available on the host.

 

Also, remember, the malicious actor is going to request a TGS for accounts with SPNs so it would not make much difference. Once they have the hash and exfiltrate, and manage to derive the password value, then its already too late. Additionally, since they are already in the environment to be able to perform these actions, hopefully something will flag unauthorised access. 


vAdmin
Forum|alt.badge.img+2
  • Influencer
  • 168 comments
  • October 15, 2024
Iams3le wrote:
vAdmin wrote:

@Iams3le ,


Do you recommend placing the Veeam service account into the Protected Users builtin group?

Protected Users Security Group | Microsoft Learn

Hi, I would recommend using gMSAs as discussed above due to some potential bottlenecks that might arise when you do this. Please see “https://helpcenter.veeam.com/docs/backup/vsphere/required_permissions.html?ver=120”. Fabian also answered this question here: https://forums.veeam.com/veeam-backup-replication-f2/service-accounts-hardening-t82416.html

That’s great, thank you @Iams3le for sharing.


vAdmin
Forum|alt.badge.img+2
  • Influencer
  • 168 comments
  • October 15, 2024
dips wrote:
vAdmin wrote:

@Iams3le ,


Do you recommend placing the Veeam service account into the Protected Users builtin group?

Protected Users Security Group | Microsoft Learn

Definitely not. The article also says the following:

  • Never add accounts for services and computers to the Protected Users group. For those accounts, membership doesn't provide local protections because the password and certificate is always available on the host.

 

Also, remember, the malicious actor is going to request a TGS for accounts with SPNs so it would not make much difference. Once they have the hash and exfiltrate, and manage to derive the password value, then its already too late. Additionally, since they are already in the environment to be able to perform these actions, hopefully something will flag unauthorised access. 

@dips ,
Yes, that would’ve been too late when the attacker is lay low or undetected.

Thank you for the clarification.