What Is Kerberoasting? Security Definition

Imagine you work in an office building that uses electronic key cards to open doors. Each employee gets a card that grants access to the areas they need. Now, imagine a thief finds a way to request a temporary visitor pass from the security desk for any employee, including those with high-level access.

The temporary pass has a scrambled code written on it that is based on that employee's password. The thief cannot use the pass directly because the scrambled code is unreadable, but he can take it home and spend hours trying different combinations to unscramble it. If he cracks the code, he can now get into the building as that high-level employee.

This is exactly how Kerberoasting works. In the digital world, the building is a company's network, the security desk is the Active Directory domain controller, and the temporary visitor pass is a special ticket called a service ticket. The attacker asks the domain controller for a service ticket for a particular service account, without needing any special permissions.

This ticket is encrypted using the service account's password hash. The attacker copies the ticket from his own computer and uses password-cracking tools offline. Once the password is cracked, the attacker can use that service account to access any resource that account can reach, often including databases, file servers, or even other domain controllers.

The real danger is that many organizations use weak or default passwords for service accounts, making them easy targets. Kerberoasting does not rely on any exploit or software vulnerability; it simply abuses the way Kerberos authentication works by design. This makes it a favorite technique for penetration testers and attackers alike, because it is stealthy and difficult to detect with standard security tools.

The attack leaves a log entry of a service ticket request, but in large environments with thousands of legitimate requests, a few extra ones often go unnoticed.

Kerberoasting is a post-exploitation attack targeting the Kerberos authentication protocol in Microsoft Active Directory environments. It specifically exploits the service ticket (TGS) request process to obtain password hashes of user accounts that have Service Principal Names (SPNs) registered. These accounts are typically service accounts that run applications, databases, or other services, and they often have elevated privileges.

The attack does not require any authentication as a privileged user; any domain user can initiate a TGS request for any SPN. The resulting TGS ticket is encrypted using the service account's password hash derived from the NTLM hash of the account. An attacker captures this encrypted ticket from the Kerberos traffic or from a memory dump on a compromised machine.

The encryption algorithm used in the TGS ticket is typically RC4-HMAC (based on the NTLM hash) or AES, depending on the domain functional level and encryption type support. The RC4-HMAC variant is particularly vulnerable because the encryption key is derived directly from the NTLM hash, which can be cracked offline using brute-force or dictionary attacks. Attackers use tools like Rubeus, Impacket's GetUserSPNs.

py, or Mimikatz to query Active Directory for all accounts with SPNs and request service tickets for them. Once the tickets are obtained, they are saved to a file and processed with password-cracking tools such as Hashcat or John the Ripper. The cracking process attempts to reverse the encryption and recover the plaintext password.

If the service account password is weak, common, or defaults to a known value (e.g., 'P@ssw0rd' or 'service123'), the attacker can recover it within minutes or hours. With the plaintext password, the attacker can authenticate as that service account and gain whatever privileges the account holds.

This often includes access to databases, file shares, remote administration tools, and sometimes even domain admin privileges if the service account has been granted excessive rights. Mitigations include using strong, complex passwords for service accounts (at least 25 characters), enabling AES encryption for Kerberos tickets (which makes cracking significantly harder), implementing managed service accounts (gMSA) that rotate passwords automatically, and monitoring for unusual TGS request patterns. Security Information and Event Management (SIEM) systems can detect Kerberoasting by flagging a single user requesting many TGS tickets for different SPNs in a short time window, or by detecting service ticket requests made from non-standard workstations.

Kerberoasting matters because it is one of the most common and effective attacks against Windows-based enterprise networks. It does not rely on any software vulnerability or unpatched system, which means that even fully updated environments are vulnerable. The attack is stealthy: it generates logs that look similar to routine Kerberos authentication traffic, making it hard for security teams to detect without advanced monitoring.

Once an attacker cracks a service account password, they can move laterally across the network and escalate privileges. Many organizations use service accounts with weak passwords because they are rarely changed due to the fear of breaking applications. This creates a persistent security gap that attackers know how to exploit.

For IT professionals, understanding Kerberoasting is critical for designing secure Active Directory environments. It directly impacts how you configure service accounts, set password policies, and implement monitoring. The principle of least privilege becomes even more important because if a service account is compromised through Kerberoasting, the blast radius is limited to the permissions that account has.

Using Group Managed Service Accounts (gMSA) or ensuring service accounts have passwords that are cryptographically random and at least 25 characters long can make cracking attempts infeasible. Security professionals must also know how to configure Kerberos encryption types to prefer AES over RC4, since RC4-hashed tickets are much easier to crack. Kerberoasting is not just an attack technique; it is a test of an organization's fundamental identity and access management hygiene.

For anyone pursuing IT security certifications, it is a core concept that bridges theoretical authentication protocols with practical offensive and defensive security.

Multiple-choice scenario questions are the most common format. A typical question might describe a situation where an attacker with a standard domain user account runs a tool that queries Active Directory for all service principal names, then requests service tickets for those accounts. The attacker downloads the tickets and uses a password-cracking tool offline.

The question then asks you to identify the attack (Kerberoasting) or the best mitigation (use strong service account passwords and enable AES encryption). Another common question type involves log analysis. You are given excerpts from Windows Security Event Log showing multiple Event ID 4769 entries for different service names, all requested from the same workstation within a few minutes.

The question asks what type of attack this log pattern suggests. This tests your ability to recognize the behavioral indicator of Kerberoasting. In simulation questions, you might be asked to configure a Group Policy setting to mitigate Kerberoasting, such as enabling AES128 and AES256 encryption for Kerberos tickets, or configuring an audit policy to log Kerberos ticket requests.

Some exams use drag-and-drop questions where you need to order the steps of a Kerberoasting attack: enumerate SPNs, request TGS tickets, capture encrypted tickets, crack passwords offline, and authenticate as the service account. For advanced certifications, there may be performance-based questions where you are given a command output from a tool like GetUserSPNs.py and asked to interpret the results.

For example, the output might list several accounts with SPNs, and you need to identify which account is most vulnerable based on its password age or encryption type. You may also see troubleshooting questions: a company has implemented strong passwords for service accounts, but Kerberoasting is still successful. The question asks why.

The answer is that the domain still supports RC4 encryption, and the attacker is requesting tickets using RC4 instead of AES. The fix is to disable RC4 encryption for Kerberos or use group Managed Service Accounts. Another troubleshooting scenario might involve a security analyst who captures network traffic and notices many Kerberos AS-REQ and TGS-REQ packets.

They need to determine if it is a Kerberoasting attack or legitimate traffic. The answer involves checking if the requests are for a large number of different SPNs within a short time from a single source. These question types require you to not only recall definitions but also apply the concept to realistic IT situations.

Kerberoasting is a primary method attackers use to move from a standard user compromise to more privileged access. As a security professional, you need to understand both the offensive and defensive aspects. When testing your own environment, you can use tools like Rubeus with the command 'Rubeus kerberoast' to simulate the attack and identify weak service accounts.

However, ensure you have written authorization before performing any security testing. On the defensive side, your first priority is service account hygiene. Every service account should have a password that is at least 25 characters long, randomly generated, and changed regularly.

Group Managed Service Accounts (gMSA) are the gold standard because they automatically rotate complex passwords without manual intervention. Next, you must configure Kerberos encryption to use AES128 and AES256 and disable RC4-HMAC. This can be done via Group Policy under Computer Configuration -> Windows Settings -> Security Settings -> Local Policies -> Security Options -> Network security: Configure encryption types allowed for Kerberos.

Select 'AES128_HMAC_SHA1' and 'AES256_HMAC_SHA1', and uncheck 'RC4_HMAC_MD5'. Be aware that disabling RC4 may affect older applications that do not support AES. Testing is essential before broad deployment.

Monitoring is also crucial. Enable auditing for Kerberos service ticket operations (Audit Kerberos Authentication Service) and monitor Event ID 4769. A single user generating many 4769 events for multiple SPNs in a short time is a red flag.

You can also look for Event ID 4776 (credential validation) for service accounts being used from unusual workstations. In a Security Operations Center (SOC) context, you might use a SIEM to create a correlation rule: 'If more than 10 Event ID 4769 from same Source IP within 5 minutes, then trigger alert for possible Kerberoasting.' consider implementing User and Entity Behavior Analytics (UEBA) tools that learn normal Kerberos traffic patterns and flag anomalies.

For incident response, if Kerberoasting is detected, immediately isolate the affected workstation, reset the password for any service accounts that were targeted, and investigate for lateral movement. Finally, remember that Kerberoasting is often a post-exploitation technique. The attacker already had a foothold in the environment, so you need to investigate the initial compromise vector as well.

This layered approach-hardening service accounts, encryption settings, monitoring, and incident response-forms a comprehensive defense against Kerberoasting.

Kerberoasting is a post-exploitation attack that targets service accounts in a Microsoft Active Directory environment. The attack uses the Kerberos authentication protocol to obtain service account credentials without needing to send any network traffic that is obviously malicious. An attacker who has already gained a foothold on a domain-joined machine, usually with a standard user account, can request Kerberos service tickets for any service principal name (SPN) in the domain. The Domain Controller (DC) encrypts these tickets using the password hash of the service account that owns the SPN. Specifically, the ticket-granting service (TGS) ticket is encrypted with the service account's NTLM hash derived from its password.

The attacker then extracts these encrypted TGS tickets from memory or from the local LSASS process using tools like Mimikatz, Rubeus, or Impacket. Once the ticket is obtained offline, the attacker can attempt to crack the encryption offline using brute-force or dictionary attacks. Because service account passwords are often complex but still shorter than 15 characters, and because administrators sometimes set them to never expire or use weak passwords, the cracking phase can be highly successful. The encryption used is typically RC4-HMAC (with a key derived from the NTLM hash) or, in newer environments, AES128 or AES256. However, RC4-HMAC is still common and is especially vulnerable because it is fast to crack with tools like Hashcat or John the Ripper. The goal is to recover the service account's plaintext password, which often has high privileges, such as domain admin rights or access to critical servers.

A crucial aspect of the mechanism is that the attacker does not need administrative privileges to request TGS tickets. Any authenticated domain user can request a service ticket for any SPN. This makes the attack a low-privilege escalation vector. The only prerequisite is that the attacker must have valid domain credentials (even low-privileged ones). This is why Kerberoasting is often performed after initial compromise via phishing or other exploitation. The attack is stealthy because it mimics legitimate Kerberos authentication traffic. Security teams must therefore rely on anomaly detection, such as unusual volume of TGS requests from a single account, or the use of decoy service accounts (honeytokens) to detect the activity. Understanding this mechanism is essential for any IT professional preparing for security-related certification exams, as it tests knowledge of Kerberos internals, privilege escalation, and password security.

From an exam perspective, candidates must know that Kerberoasting does not exploit a vulnerability in Kerberos itself, but rather abuses the protocol's design. It is a password cracking attack, not a memory exploit. The mitigation involves using strong, randomly generated passwords for service accounts (preferably 25+ characters), implementing Managed Service Accounts (MSAs) or Group Managed Service Accounts (gMSAs), and monitoring for anomalous TGS requests. In certifications like CompTIA Security+ or CISSP, questions often focus on the attack's reliance on weak passwords and the need for service account hardening. In Microsoft-specific exams, the correct answer might involve enabling AES encryption to slow down cracking, or using conditional access policies to flag unusual TGS requests.

the Kerberoasting mechanism can be broken into three steps: Request, Extract, Crack. The request phase is performed by an authenticated user, the extraction phase uses tools to capture the encrypted ticket, and the cracking phase attempts to recover the password offline. This process highlights why service accounts are a high-value target and why exam questions emphasize the importance of service account management and monitoring.

For certification preparation, remember that the key defense is to ensure service account passwords are long, complex, and changed frequently. The use of AES encryption makes cracking much slower than RC4, but does not prevent the attack entirely. Finally, the best detection method is to look for an unusual number of TGS requests from a single user, especially service tickets that are not needed for that user's role.

Defending against Kerberoasting requires a multi-layered approach that combines technical controls, policy enforcement, and proactive monitoring. Because the attack does not exploit a software vulnerability but instead abuses the Kerberos protocol's normal behavior, traditional patching is not a complete solution. The primary mitigation focuses on making service account passwords resistant to offline cracking and on detecting the anomalous TGS requests that are the precursor to credential theft.

First and foremost, service account passwords should be strong, unique, and randomly generated. The National Institute of Standards and Technology (NIST) recommends using complex passwords that are at least 15 characters long, but for service accounts, 25 characters or more is advisable. Even better is to use Managed Service Accounts (MSAs) or Group Managed Service Accounts (gMSAs) introduced in Windows Server 2008 R2 and later. These are computer accounts that have automatically rotated, complex passwords managed by the domain. They do not require manual password changes and are much harder to crack because the password is a 240-character random value. However, not all applications support MSAs, so legacy service accounts may still exist. In such cases, administrators should enforce strong password policies and schedule regular password rotations, ideally every 30 to 90 days.

Second, encryption type matters. Kerberos supports multiple encryption types, including RC4-HMAC (which is fast and weak), AES128, and AES256. By default, many environments still offer RC4 because of compatibility with older applications. To mitigate Kerberoasting, administrators should disable RC4 encryption for service accounts and enforce the use of AES encryption. This can be done via Group Policy by setting the "Network security: Configure encryption types allowed for Kerberos" to include only AES128 and AES256. Cracking AES-encrypted tickets is computationally much more expensive than RC4, though with enough resources it is still possible. Certification exams often test this: disabling RC4 is a strong mitigation but not a complete prevention.

Third, monitoring and detection are critical. Security Information and Event Management (SIEM) systems can be configured to alert on high volumes of TGS requests from a single user, especially for service accounts that the user does not normally access. For example, if a regular user suddenly requests a dozen service tickets for SQL Server service accounts, that is suspicious. Windows Event ID 4769 (A Kerberos service ticket was requested) can be logged and analyzed. Deploying decoy service accounts (honeytokens) with weak passwords can be an effective early warning system. When an attacker attempts to crack the honeytoken's password and uses it, an alert is triggered. This technique is covered in advanced security exams and blue team training.

Fourth, the principle of least privilege applies. Service accounts should have only the permissions necessary to perform their tasks. A SQL Server service account, for example, should not be a domain administrator. If an attacker cracks a service account password, the blast radius is limited if the account has minimal privileges. This is often a key point in exam questions about privilege escalation and lateral movement.

Finally, user awareness and credential hygiene are important. Because Kerberoasting often follows a successful initial compromise via phishing, training users to recognize phishing attempts reduces the attack surface. Multi-factor authentication (MFA) does not directly prevent Kerberoasting because the attack uses cached credentials, but MFA can prevent the initial compromise that provides the attacker with a foothold.

From an exam perspective, candidates should be prepared to answer questions about the relative effectiveness of different mitigations. For instance, the most effective mitigation is using gMSAs or long, complex passwords. The next is disabling RC4 encryption. Monitoring and least privilege are complementary controls. Understanding that no single control is perfect is important for comprehensive security. In certifications like CompTIA Pentest+ or OSCP, candidates may need to describe both the attack and the mitigations. In CISSP, the focus might be on the principle of defense in depth.

a successful defense against Kerberoasting combines account management (MSAs/gMSAs), encryption hardening (disable RC4), strong password policies, vigilant monitoring (Event ID 4769 and honeytokens), and least privilege. This layered approach significantly reduces the risk and impact of this common attack.