As cyberthreats continue to evolve, it’s essential for security professionals to stay informed about the latest attack vectors and defense mechanisms. Kerberoasting is a well-known Active Directory (AD) attack vector whose effectiveness is growing because of the use of GPUs to accelerate password cracking techniques.
Because Kerberoasting enables cyberthreat actors to steal credentials and quickly navigate through devices and networks, it’s essential for administrators to take steps to reduce potential cyberattack surfaces. This blog explains Kerberoasting risks and provides recommended actions administrators can take now to help prevent successful Kerberoasting cyberattacks.
What is Kerberoasting?
Kerberoasting is a cyberattack that targets the Kerberos authentication protocol with the intent to steal AD credentials. The Kerberos protocol conveys user authentication state in a type of message called a service ticket which is encrypted using a key derived from an account password. Users with AD credentials can request tickets to any service account in AD.
In a Kerberoasting cyberattack, a threat actor that has taken over an AD user account will request tickets to other accounts and then perform offline brute-force attacks to guess and steal account passwords. Once the cyberthreat actor has credentials to the service account, they potentially gain more privileges within the environment.
AD only issues and encrypts service tickets for accounts that have Service Principal Names (SPNs) registered. An SPN signifies that an account is a service account, not a normal user account, and that it should be used to host or run services, such as SQL Server. Since Kerberoasting requires access to encrypted service tickets, it can only target accounts that have an SPN in AD.
SPNs are not typically assigned to normal user accounts which means they are better protected against Kerberoasting. Services that run as AD machine accounts instead of as standalone service accounts are better protected against compromise using Kerberoasting. AD machine account credentials are long and randomly generated so they contain sufficient entropy to render brute-force cyberattacks impractical.
The accounts most vulnerable to Kerberoasting are those with weak passwords and those that use weaker encryption algorithms, especially RC4. RC4 is more susceptible to the cyberattack because it uses no salt or iterated hash when converting a password to an encryption key, allowing the cyberthreat actor to guess more passwords quickly. However, other encryption algorithms are still vulnerable when weak passwords are used. While AD will not try to use RC4 by default, RC4 is currently enabled by default, meaning a cyberthreat actor can attempt to request tickets encrypted using RC4. RC4 will be deprecated, and we intend to disable it by default in a future update to Windows 11 24H2 and Windows Server 2025.
What are the risks associated with Kerberoasting?
Kerberoasting is a low-tech, high-impact attack. There are many open-source tools which can be used to query potential target accounts, get service tickets to those accounts, and then use brute force cracking techniques to obtain the account password offline.
This type of password theft helps threat actors pose as legitimate service accounts and continue to move vertically and laterally through the network and machines. Kerberoasting typically targets high privilege accounts which can be used for a variety of attacks such as rapidly distributing malicious payloads like ransomware to other end user devices and services within a network.
Accounts without SPNs, such as standard user or administrator accounts, are susceptible to similar brute-force password guessing attacks and the recommendations below can be applied to them as well to mitigate risks.
How to detect Kerberoasting?
Administrators can use the techniques described below to detect Kerberoasting cyberattacks in their network.
- Check for ticket requests with unusual Kerberos encryption types. Cyberthreat actors can downgrade Kerberos ticket encryption to RC4 since cracking it is significantly faster. Admins can check the events in the Microsoft Defender XDR and filter the results based on the ticket encryption type to check for weaker encryption type usage.
- Check for repeated service ticket requests. Check if a single user is requesting multiple service tickets for Kerberoasting-vulnerable accounts in a short time period.
Recommendations to help prevent Kerberoasting from succeeding
Microsoft recommends that IT administrators take the following steps to help harden their environments against Kerberoasting:
- Use Group Managed Service Accounts (gMSA) or Delegated Managed Service Accounts (dMSA) wherever possible:
- These accounts are ideal for multi-server applications that require centralized credential management and enhanced security against credential-based attacks, such as IIS, SQL Server, or other Windows services running in a domain-joined environment.
- Group Managed Service Account (gMSA) is an Active Directory account type that allows multiple servers or services to use the same account with automatic password management and simplified SPN handling. Passwords for gMSAs are 120 characters long, complex, and randomly generated, making them highly resistant to brute-force cyberattacks using currently known methods.
- Delegated Managed Service Accounts (dMSA) are the newest iteration of managed service accounts available on Windows Server 2025. Like gMSAs, they restrict which machines can make use of the accounts and they provide the same password mitigations against Keberoasting. However, unlike gMSAs, dMSAs have the added benefit of supporting seamless migration of standalone service accounts with passwords to the dMSA account type. They can also be optionally integrated with Credential Guard so that even if the server using dMSA is compromised, the service account credentials remain protected.
- If customers cannot use gMSA or dMSA, then manually set randomly generated, long passwords for service accounts:
- Service account administrators should maintain at least a 14-character minimum password. If possible, we recommend setting even longer passwords and randomly generating them for service accounts which will provide better protection against Kerberoasting. This recommendation also applies to normal user accounts.
- Ban commonly used passwords and audit the passwords for service accounts so that there is an inventory of accounts with weak passwords and can be remediated.
- Make sure all service accounts are configured to use AES (128 and 256 bit) for Kerberos service ticket encryption:
- Audit the user accounts with SPNs:
- User accounts with SPNs should be audited. SPNs should be removed from accounts where they are not needed to reduce the cyberattack surface.
Conclusion
Kerberoasting is a threat to Active Directory environments due to its ability to exploit weak passwords and gain unauthorized access to service accounts. By understanding how Kerberoasting works and implementing the recommended guidance shared in this blog, organizations can significantly reduce their exposure to Kerberoasting.
We truly believe that security is a team effort. By partnering with Original Equipment Manufacturers (OEMs), app developers, and others in the ecosystem, along with helping people to be better at protecting themselves, we are delivering a Windows experience that is more secure by design and secure by default. The Windows Security Book is available to help you learn more about what makes it easy for users to stay secure with Windows.
Next steps with Microsoft Security
To learn more about Microsoft Security solutions, visit our website. Bookmark the Security blog to keep up with our expert coverage on security matters. Also, follow us on LinkedIn (Microsoft Security) and X (@MSFTSecurity) for the latest news and updates on cybersecurity.
References
Directory Hardening Series – Part 4 – Enforcing AES for Kerberos – Microsoft Community Hub
Network security Configure encryption types allowed for Kerberos – Windows 10 | Microsoft Learn,
Decrypting the Selection of Supported Kerberos Encryption Types – Microsoft Community Hub