What is Kerberoasting?

Before we dive in, in case you're looking for a short answer, here’s Kerberoasting—the short version.

• What it is: Kerberoasting is a post-exploitation technique where attackers request service account tickets via Kerberos and crack them offline to harvest credentials.
• MITRE ATT&CK association: It's classified under T1558.003 (Steal or Forge Kerberos Tickets > Kerberoasting) within the credential access tactic.
• How it works: Any authenticated domain user can request Ticket Granting Service (TGS) tickets for Service Principal Names (SPNs), extract the encrypted part, and crack the NTLM hash offline using tools like Hashcat or John the Ripper.
• Why it's dangerous: It’s stealthy, fast, and effective—often enabling attackers to escalate privileges to domain admin without triggering immediate alerts.
• Who uses it: It's widely used in red teaming and by threat actors like APT40 to move laterally and gain elevated access within hours.
• Kerberoasting vs. Golden Ticket attack:
  • Kerberoasting: This attack doesn’t require elevated privileges; it relies on SPN service tickets and password cracking.
  • Golden Ticket: This attack requires domain admin access; attackers forge Ticket Granting Tickets (TGTs) using the KRBTGT hash to impersonate any user or service.
• Preventing and mitigating Kerberoasting: Use strong passwords, automate rotation with gMSAs, audit SPNs, enforce least privilege access, patch vulnerabilities, enable MFA, and monitor for unusual TGS requests.
• Indicators of Compromise (IoCs): Unusual TGS requests (4769), failed pre-auth attempts (4771), RC4-HMAC use, and access to inactive or honeypot SPNs.
• How Log360 helps:
  • It detects Kerberoasting by monitoring SPN enumeration, unusual TGS patterns, and events 4769 and 4771—especially those using RC4 encryption.
  • It maps findings to MITRE T1558.003, provides forensic audit trails, automates incident response, and correlates signals to uncover stealthy lateral movements.

This short version gives you the essentials at a glance. For detailed insights and technical walk-throughs, please continue reading.

Kerberoasting attack: Explained

Imagine an attacker silently navigating your network, and their goal is not immediate disruption but to get the keys to your digital domain . Kerberoasting, also known as a Kerberoast attack, is an Active Directory (AD) attack where adversaries request service ticket hashes for SPNs and brute‑force them offline to recover plaintext service account passwords. Because every authenticated domain user can legitimately request these tickets, the technique usually flies under the radar until the cracked password is abused for lateral movement or privilege escalation.

Understanding the Kerberos authentication protocol

To truly grasp the mechanics of a Kerberoasting attack, you must first understand the key components and core principles of the Kerberos authentication protocol. It is often referred to simply as Kerberos and acts as a trusted third party, enabling secure communication between users and services without the constant transmission of passwords.

Some of the key components within this protocol include:

• KDC: The central authority for authentication and ticket issuance, comprising the Authentication Service (AS) and the TGS.
• TGT: A reusable ticket obtained after initial login, allowing users to request service tickets without re-authenticating.
• TGS: The KDC component responsible for issuing service tickets upon the validation of a TGT.
• SPN: A unique identifier registered in AD for service accounts (e.g., MSSQLSvc/sqlserver.domain.com). SPNs map service requests to the correct service account.
• TGS ticket or service ticket: The ticket used to authenticate to a specific service. This is the prime target in a Kerberoasting attack.

The typical Kerberos authentication protocol involves these key steps:

• User login and an authentication service request: A user authenticates with their credentials, and their system requests a TGT from the KDC.
• TGT issuance: The AS within the KDC verifies the credentials and issues a TGT, which is encrypted using the user's password hash. This TGT serves as proof of identity for future ticket requests.
• Requesting service access: When a user needs to access a specific service (e.g., a database or web application), their system presents the TGT to the TGS (also part of the KDC) and requests a TGS or service ticket for that particular service.
• Access granted: The TGS issues the requested service ticket, crucially encrypted with the target service account's secret—its NTLM hash. The client then uses this TGS ticket to authenticate directly to the intended service.

Kerberoasting in the MITRE ATT&CK framework

Kerberoasting is a well-defined post-exploitation technique within the MITRE ATT&CK framework under the technique ID T1558.003. Understanding its place in the framework helps security professionals contextualize the attack within a broader spectrum of adversary tactics and techniques.

MITRE ATT&CK mapping

The MITRE ATT&CK framework provides valuable insights into how attackers leverage Kerberoasting as part of their post-compromise activities, often for credential access and privilege escalation.

How does Kerberoasting work?

Understanding what Kerberoasting is and how Kerberoasting works is the first step towards identifying the crucial IoCs in a Kerberos attack. When it comes to Kerberoasting, the vulnerability lies in how the TGS ticket is encrypted. Since the service itself needs to decrypt this ticket, the encryption key is derived from the service account's password hash (NTLM hash). A Kerberoasting attack cleverly exploits this by obtaining these tickets and attempting to crack them offline.

Here's a step-by-step breakdown of a typical Kerberoast attack:

Stage 1: Initial foothold: At this stage, the attacker gains legitimate access to the domain—either by compromising a low-privileged user account or through another method of initial access.

Common techniques include:

• Phishing: Stealing user credentials via deceptive emails.
• Credential stuffing or brute force: Using leaked or weak credentials.
• Exploiting misconfigurations: Taking advantage of insecure user privileges or domain trust settings.

MITRE ATT&CK framework association

• T1078 - Valid Accounts: Use of stolen or legitimate credentials.
• T1071 - Application Layer Protocol: Leveraging standard protocols for authentication.

Stage 2: SPN enumeration: Once inside the network, the attacker enumerates service accounts with SPNs registered in AD. These accounts are usually tied to services running under user context—many of which are highly privileged.

Tools commonly used:

• setspn.exe (native tool)
• PowerShell scripts
• GetUserSPNs.py (Impacket)

MITRE ATT&CK framework association

• T1087.002 - Account Discovery: Domain Account: Querying AD to find user and service accounts.
• T1201 - Password Policy Discovery: Used to identify accounts with weak or crackable passwords.

Stage 3: TGS request and acquisition: The attacker requests TGS tickets for the identified SPNs. These tickets are encrypted with the NTLM hash of the service account’s password, making them a target for offline cracking.

Key points:

• This is a legitimate Kerberos operation, so it avoids detection.
• No elevated privileges are needed to request these tickets.

MITRE ATT&CK framework association

• T1558.003 - Steal or Forge Kerberos Tickets: Kerberoasting: Exploiting service ticket encryption to obtain hashes.

Stage 4: Ticket extraction: The attacker extracts the TGS tickets from memory or saves them to disk using tools like:

• Mimikatz
• Rubeus
• Impacket’s GetUserSPNs

The ticket is now ready for offline password cracking and saved in formats like .kirbi or .ccache.

MITRE ATT&CK framework association

• T1555 - Credentials from Password Stores: Relevant for ticket storage locations.

Stage 5 : Offline cracking: While not part of the Kerberos protocol flow, this is the critical stage where the attacker uses password cracking tools (like Hashcat or John the Ripper) to brute-force the service account password from the encrypted TGS ticket. Once successful, the attacker gains plaintext credentials of potentially privileged accounts.

MITRE ATT&CK framework association

• T1110.002 - Brute Force: Password Cracking: Used to crack the encrypted hash offline.
• T1003 Credential Dumping: This may also apply depending on tools used.

If the cracking is successful, the attacker gains the plaintext credentials of potentially highly privileged service accounts. This can grant them the ability to move laterally within the network, escalate their privileges, access sensitive data, and ultimately achieve their objectives.

Why is Kerberoasting a dangerous threat?

The effectiveness of a Kerberoast stems from several factors:

• Stealth: Requesting service tickets (TGS-REQs) is a normal Kerberos operation, making the initial stages of a Kerberoasting attack difficult to detect without specific monitoring.
• Offline cracking: Once the tickets are obtained, the password cracking occurs offline, generating no further network traffic or suspicious activity within the Active Directory environment.
• High-value targets: Service accounts often run with elevated privileges necessary for the services they manage, like databases, web servers, or backups, making them prime targets for attackers seeking to escalate their access.
• Speed (with weak passwords): If service accounts have weak or easily guessable passwords, the cracking process can be completed very quickly.

Kerberoasting is not just a theoretical threat. Here are some of the real-world examples of Kerberoasting in action that demonstrate its effectiveness:

• APT40: This China-based group has been observed using Kerberoasting with tools like Rubeus to escalate privileges in targeted networks.
• Red team simulations: Penetration testers routinely demonstrate how easily Kerberoasting can be executed, often leading to domain admin compromise within hours by exploiting weak service account passwords.
• NotPetya or Nyetya: While not definitively attributed, analysis suggests that this destructive malware may have leveraged Kerberos abuse techniques, potentially including Kerberoasting, for lateral movement.

Kerberoasting vs. Golden Ticket attacks: Understanding the differences

While both Kerberoasting and Golden Ticket attacks are Kerberos attacks targeting AD, they differ significantly.

Here's how:

Kerberoasting is generally more accessible to attackers with lower initial privileges, often serving as a stepping stone for further compromise. Golden Ticket attacks, while more impactful, require higher-level access. A comprehensive security strategy must address both.

How to prevent and mitigate Kerberoasting

Understanding how to prevent and mitigate Kerberoasting is crucial for securing your AD environment. Here's a breakdown of strategies for Kerberoasting prevention and mitigation, as per the MITRE ATT&CK framework:

• Strong and unique passwords for service accounts (M1027): This is the first and most critical preventative measure. Ensure service accounts have complex, unique passwords that are not used for any user accounts. Rotate these passwords regularly.
• Managed service accounts (MSAs) and group managed service accounts (gMSAs) (M1027): These account types are designed for services and have automatically managed, complex passwords that are regularly changed by the system, significantly reducing the risk of successful offline cracking. Implement MSAs and gMSAs wherever possible.
• Monitor SPN registrations (M1047): Regularly review and manage registered SPNs to ensure they are legitimate and necessary. Remove any unused or suspicious SPNs. Use PowerShell cmdlets like Get-ADServiceAccount and Setspn -X for audits.
• Implement MFA wherever feasible (M1032): While it doesn't directly prevent ticket requests, MFA can add an extra layer of security if a service account password is compromised.
• Patch management (M1051): Keep your domain controllers and member servers up to date with the latest security patches to address any known Kerberos vulnerabilities.
• Network segmentation (M1030): Isolate sensitive assets and restrict lateral movement by segmenting your network using VLANs and firewall rules.
• Regular security audits (M1047): Conduct regular audits of service account configurations, permissions, and password policies.
• Principle of least privilege (M1018): Grant service accounts only the necessary permissions required for their specific function. Avoid granting domain administrator privileges to service accounts unless absolutely essential.

What are the IoCs in a Kerberoasting attack?

Early Kerberoasting detection is paramount in safeguarding your AD environment. Recognizing the subtle signs or IoCs of a Kerberoasting attack can prevent attackers from leveraging compromised service accounts for lateral movement and privilege escalation.

• Monitor for anomalous ticket requests: While requesting service tickets is normal, a sudden surge in requests for specific service accounts or from unusual source machines can be an indicator of a Kerberoasting attack.
• Analyze security logs: Examine security event logs for event ID 4769 (A Kerberos service ticket was requested.). Look for patterns like high request volumes for the same SPN from a single source or requests for unusual SPNs from compromised accounts.
• Implement network traffic analysis: Deep packet inspection tools might identify patterns associated with Kerberoasting tools, although this can be challenging as the initial requests are standard Kerberos traffic.
• Monitor legacy Kerberos setups: Legacy Kerberos setups using RC4-HMAC (EType 23) are prime targets for Kerberoasting, as these tickets are easier to crack. Look for RC4-based TGS-REQ messages and SPNs using weak encryption to spot misconfigurations or active attacks.
• Detect abnormal LDAP activity: A surge in LDAP queries using the filter servicePrincipalName=* directed at paths like ldap:///CN=Users,DC=... may indicate enumeration behavior typical of Kerberoasting reconnaissance.
• Identify high-volume AS‑REQ/TGS‑REQ from a single host: Mass authentication requests (AS‑REQ or TGS‑REQ) from a single workstation—especially in a short timeframe—could suggest automated Kerberoasting tools in use.
• Utilize specialized security tools: While tools like Kerberoast.py, Rubeus, or Invoke-Kerberoast can be used to identify vulnerable accounts and audit Kerberoasting vulnerabilities, security information and event management (SIEM) solutions, like ManageEngine Log360, and Active Directory auditing tools have built-in rules and analytics designed to identify potential Kerberoasting attacks.

How Log360 helps with Kerberoasting detection and response

ManageEngine Log360 is a unified SIEM solution with integrated DLP and CASB capabilities which provides threat detection and response, correlation, alerts, and reporting. Before we dive deep into the features of Log360 that can help with Kerberoasting, here are some common event IDs related to Kerberos in a Windows environment.

Here's how Log360 can help detect and mitigate attacks related to Kerberoasting:

• Real-time detection with Kerberos-focused alerts: Log360 enables real-time monitoring of suspicious Kerberos TGS requests by analyzing event ID 4769. Since TGS requests are common, Log360 uses advanced correlation rules to raise alerts only when certain Kerberoasting indicators are detected, such as:
  • A large volume of TGS requests in a short time span (a typical brute-force pattern).
  • TGS requests using RC4 encryption (encryption type 0x17)—a known weak cipher often exploited by attackers.
  • Requests for services with names starting with $, which is a known anomaly pattern.

  These alerts help detect attackers attempting to extract service tickets for offline cracking.

  
• Deception-based threat detection with honeypot SPNs: Security teams can configure honeypot Kerberos service accounts with fake SPNs. Log360 monitors for any access attempts to these decoy SPNs via event ID 4769, which are clear indicators of reconnaissance or Kerberoasting activity.
• Deep-dive investigation via built-in reports: Log360 offers over 1,000 built-in reports, including Kerberos-specific reports that allow analysts to:
  • Track all TGS requests and filter by encryption type, service account, and source.
  • Detect event ID 4769 with 0x17 encryption to flag suspicious RC4-based ticket requests.
  • Analyze event ID 4771 with error code 0x18, indicating authentication failures due to bad passwords—often seen in password spraying and brute-force attempts.
  • Monitor result codes like 0x8 and 0x22 that point to duplicate SPNs or ticket replays.
• Alignment with the MITRE ATT&CK framework: Log360 maps Kerberoasting indicators to MITRE ATT&CK techniques, particularly T1558.003, which has to do with stealing or forging Kerberos tickets. This helps teams understand where the attack fits in the broader kill chain and respond more strategically.

• Automated incident response: Once a Kerberoasting attempt is detected, Log360 can:
  • Automate remediation workflows.
  • Raise an incident ticket in your help desk system to assign a resolution.
  • Trigger automated responses like disabling accounts, blocking IPs, or sending escalation alerts.
• Correlation-driven threat hunting: The solution's correlation engine combines multiple data points—Kerberos logs, user behavior, encryption type, and authentication failures—to distill complex attacks into a single alert, making threat detection efficient and accurate.

ManageEngine Log360 empowers organizations to proactively detect and mitigate Kerberoasting attacks through real-time alerting, SPN honeypots, detailed Kerberos reports, MITRE ATT&CK mapping, and automated incident workflows.

Together, these features help stop attackers from stealing service tickets and cracking passwords offline, thereby strengthening your AD security posture.

Frequently asked questions

Which event IDs are useful for detecting kerberoasting?

Event ID 4769 (TGS request) in Windows Security logs is the key. Look for RC4 encryption, requests for service accounts, and high request frequencies.

How can I monitor service account usage?

Use tools like EventLog Analyzer or Log360 to track logon activity, SPN changes, and abnormal ticket request frequencies.

What encryption types are vulnerable?

RC4-HMAC is significantly weaker and more susceptible to cracking.

Can gMSAs help?

Yes, gMSAs automate strong, rotating passwords, greatly mitigating the risk.

How can I test my environment?

Conduct authorized internal assessments using tools like Rubeus or Invoke-Kerberoast to identify vulnerable accounts and configurations.