Overview

Kerberoasting is a credential theft technique in which an attacker with any valid domain account requests Kerberos Ticket-Granting Service (TGS) tickets for accounts that have Service Principal Names (SPNs) registered. Because portions of these tickets are encrypted with the service account’s password hash (RC4/etype 23 by default), the attacker can export them and crack them offline without ever touching a domain controller again — ultimately recovering the service account’s plaintext password.

Service accounts targeted by Kerberoasting are frequently over-privileged, long-lived, and protected by weak passwords, making a successful crack highly impactful. Every security team needs reliable detection for this technique because it is nearly invisible on the wire, requires no exploits, uses only built-in Kerberos functionality, and directly enables privilege escalation, persistence, and lateral movement through valid account access.

Attacker Perspective

Once an attacker has any foothold on a domain — even a low-privileged user account — Kerberoasting lets them escalate toward high-value service accounts entirely through legitimate Kerberos protocol operations.

• Automated SPN enumeration and ticket request via Impacket: GetUserSPNs.py DOMAIN/lowprivuser:Password1 -request -outputfile hashes.txt — enumerates all SPNs and requests TGS tickets in a single command from a Linux attack host.
• PowerShell in-memory execution via Invoke-Kerberoast (PowerSploit/Empire): Invoke-Kerberoast -OutputFormat Hashcat | Select-Object -ExpandProperty Hash — requests tickets and formats hashes for Hashcat directly in memory, avoiding disk writes.
• Rubeus targeted ticket request: Rubeus.exe kerberoast /user:svc_sql /rc4opsec /outfile:hash.txt — targets a specific high-value account and can request RC4-downgraded tickets even when AES is preferred, to improve offline crackability.
• Offline cracking with Hashcat: hashcat -m 13100 hashes.txt rockyou.txt --rules-file best64.rule — cracks Kerberos 5 TGS-REP etype 23 hashes completely offline with no further domain interaction needed.

Kerberoasting is attractive because it requires no elevated privileges to execute, generates no explicit authentication failures, and the core activity — requesting a service ticket — is indistinguishable from normal Windows behavior without purpose-built monitoring.

Detection Strategy

Required Telemetry

• Windows Security Event Log — Event ID 4769 (Kerberos Service Ticket Request): This is your primary detection source. Enable via GPO: Computer Configuration → Windows Settings → Security Settings → Advanced Audit Policy Configuration → Account Logon → Audit Kerberos Service Ticket Operations → Success and Failure. This must be configured on all Domain Controllers. Without it, Kerberoasting is completely undetectable from a SIEM perspective.
• Windows Security Event Log — Event ID 4768 (Kerberos TGT Request): Provides context on the requesting account, source IP, and encryption type at TGT issuance. Enable under the same GPO node: Audit Kerberos Authentication Service → Success and Failure on Domain Controllers.
• Windows Security Event Log — Event ID 4688 (Process Creation with command-line logging): Required to catch tool execution on the attacking host. Enable via GPO: Computer Configuration → Windows Settings → Security Settings → Advanced Audit Policy Configuration → Detailed Tracking → Audit Process Creation → Success. Also enable command-line capture: HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\Audit → ProcessCreationIncludeCmdLine_Enabled = 1.
• PowerShell Script Block Logging — Event ID 4104: Captures PowerShell commands including obfuscated or in-memory scripts. Enable via GPO: HKLM\SOFTWARE\Policies\Microsoft\Windows\PowerShell\ScriptBlockLogging → EnableScriptBlockLogging = 1. Critical for catching Invoke-Kerberoast and similar PowerShell-based tooling.
• PowerShell Module Logging — Event ID 4103: Captures pipeline input/output from PowerShell modules. Enable via GPO: HKLM\SOFTWARE\Policies\Microsoft\Windows\PowerShell\ModuleLogging → EnableModuleLogging = 1, with all module names under ModuleNames set to *.
• Sysmon — Event ID 1 (Process Create): Provides richer process metadata than Event ID 4688, including parent process GUID, full command line, and hash. Deploy using a community baseline config (e.g., SwiftOnSecurity or Olaf Hartong configs). Essential for correlating tool execution with Kerberos ticket requests.
• Sysmon — Event ID 3 (Network Connection): Captures outbound connections, useful for identifying Impacket-based attacks originating from non-Windows hosts connecting to DC port 88 (Kerberos).
• Network traffic (IDS/NDR) — Kerberos port 88/TCP and 88/UDP: If you have a network detection platform (Zeek, Suricata, ExtraHop, Darktrace), enable Kerberos protocol parsing to capture etype values in TGS-REQ and TGS-REP messages. RC4 (etype 23) in TGS-REP for accounts configured for AES is a strong indicator.

Key Indicators

• Event ID 4769 with RC4 encryption type: In the Security event log on domain controllers, check Ticket Encryption Type = 0x17 (decimal 23, which is RC4-HMAC). Modern environments should predominantly see AES-256 (0x12) or AES-128 (0x11). A single account generating multiple 0x17 TGS requests in a short window is the canonical Kerberoasting signal. Also check Ticket Options = 0x40810000, which is the default flag set used by many Kerberoasting tools.
• Event ID 4769 — high volume of TGS requests from one account: In the Account Name field, a single user requesting TGS tickets for many different Service Name values within a short time window (e.g., more than 5 unique SPNs in 10 minutes) indicates automated SPN enumeration and bulk ticket requesting, as produced by Impacket’s GetUserSPNs.py or Rubeus kerberoast without a /user target.
• Event ID 4769 — requests targeting sensitive service accounts: Cross-reference Service Name values against a known list of high-value service accounts (e.g., accounts with names matching svc_*, sql*, backup*, admin*). Flag any RC4 TGS request for these accounts regardless of volume.
• Event ID 4104 / 4103 — Invoke-Kerberoast keywords: In PowerShell script block or module logs, look for strings including Invoke-Kerberoast, KerberosRequestorSecurityToken, GetRequest, System.IdentityModel.Tokens, and OutputFormat Hashcat or OutputFormat John. These are the .NET classes and parameters used by PowerShell-based Kerberoasting tools.
• Event ID 4688 / Sysmon Event ID 1 — Rubeus execution: Look for Image or CommandLine containing Rubeus, kerberoast, /rc4opsec, /tgtdeleg, or the Rubeus binary hash. Also flag ParentImage anomalies such as Rubeus launched from cmd.exe, powershell.exe, or a scripting engine.
• Event ID 4688 / Sysmon Event ID 1 — Impacket GetUserSPNs indicators: On Windows hosts, look for python.exe or python3.exe executing with GetUserSPNs in the command line. On network sensors, look for Linux source IPs making TCP/88 connections to domain controllers followed by rapid TGS-REP responses.
• Sysmon Event ID 3 — anomalous port 88 connections: Flag connections to DestinationPort = 88 from non-Windows hosts or from workstations where Kerberos traffic to the DC is unusual. Impacket attacks frequently originate from Linux or macOS attacker machines.

Detection Logic

Rule 1: High-volume RC4 TGS requests from a single account (broad, high sensitivity)
IF EventID = 4769
AND TicketEncryptionType = "0x17"
AND ServiceName NOT ENDS_WITH "$"
AND Count(ServiceName DISTINCT) >= 5 WITHIN 10 minutes
GROUP BY AccountName, ClientAddress
AND NOT AccountName IN [known_service_accounts_whitelist]
THEN alert HIGH

This catches bulk Kerberoasting runs using tools like Impacket or Rubeus without a specific target, where the attacker enumerates and requests tickets for all SPNs. Expected volume is low in well-tuned environments — fewer than 5 alerts per week. The exclusion of accounts ending in $ removes machine account TGS requests, which are noisy and legitimate.

Rule 2: Any RC4 TGS request for a sensitive or privileged service account (narrow, high precision)
IF EventID = 4769
AND TicketEncryptionType = "0x17"
AND ServiceName MATCHES_REGEX "(svc_|sql|backup|admin|oracle|exchange|sharepoint|sap)"
AND ServiceName NOT ENDS_WITH "$"
AND AccountName NOT = ServiceName
THEN alert CRITICAL

This rule fires on any single RC4 ticket request targeting a known high-value service account pattern, regardless of volume. Expected volume is very low — any true positive here should be treated as a priority incident. Tune the regex to match your environment’s service account naming conventions.

Rule 3: PowerShell Kerberoasting keywords in script block logs (targeted, medium precision)
IF EventID = 4104
AND ScriptBlockText CONTAINS_ANY ["Invoke-Kerberoast", "KerberosRequestorSecurityToken", "GetRequest", "OutputFormat Hashcat", "OutputFormat John", "System.IdentityModel.Tokens.KerberosRequestorSecurityToken"]
THEN alert HIGH

This catches PowerShell-based Kerberoasting tools including Invoke-Kerberoast from PowerSploit and Empire. False positive rate is near zero — these .NET classes are not used in legitimate administrative scripts. Expected volume is very low; treat every hit as requiring investigation.

Rule 4: Known Kerberoasting tool execution via process command line (targeted, high precision)
IF (EventID = 4688 OR SysmonEventID = 1)
AND (
CommandLine CONTAINS "Rubeus" AND CommandLine CONTAINS "kerberoast"
OR CommandLine CONTAINS "GetUserSPNs"
OR CommandLine CONTAINS "Invoke-Kerberoast"
OR CommandLine CONTAINS "rc4opsec"
OR CommandLine CONTAINS "tgtdeleg"
)
THEN alert CRITICAL

This catches explicit tool execution on Windows endpoints. Rubeus and Impacket command patterns are highly specific and have essentially zero legitimate use in production environments. Expected volume is extremely low — a single hit warrants immediate escalation.

Tuning Guidance

• Legacy applications using RC4: Some older applications (pre-Windows Server 2008, certain SAP, Oracle, or Java Kerberos implementations) still request RC4 tickets legitimately. Identify these by correlating ClientAddress and ServiceName combinations that appear consistently over weeks. Add exclusions as ClientAddress IN [legacy_app_servers] AND ServiceName IN [legacy_spn_list] — document each exclusion with a ticket reference.
• SQL Server and IIS service accounts with RC4 configured: If service accounts are not configured with Use Kerberos AES 256 bit encryption, they will generate RC4 tickets on every legitimate authentication. Remediate by setting AES flags on the account in Active Directory (msDS-SupportedEncryptionTypes), and use that as your long-term fix rather than a blanket exclusion.
• Scheduled tasks and automated scripts performing LDAP/SPN enumeration: Some monitoring or inventory tools (e.g., certain configurations of ManageEngine, SolarWinds, or custom PowerShell scripts) enumerate SPNs via LDAP. These will not generate Event ID 4769 entries, but they may trigger process-based rules. Exclude by ParentImage IN [known_monitoring_tool_paths] after confirming the process is legitimate.
• Privileged Access Workstations (PAWs) and jump servers: Administrators on PAWs legitimately request TGS tickets for multiple services during normal operations. Correlate by username and source IP — if the ClientAddress belongs to a known PAW subnet and the user is a known admin, suppress Rule 1 volume alerts but retain Rule 2 (sensitive account RC4) regardless.
• Security tooling and red team exercises: Your own red team or vulnerability scanners may generate Kerberoasting activity. Maintain a documented exclusion for known red team source IPs during authorized engagements — but ensure these exclusions are time-bounded and automatically expire.

When the Alert Fires: Investigation Steps

1. Verify the alert against the raw event on the domain controller: Pull the raw Event ID 4769 directly from the Security event log on the DC identified in the alert — confirm that Ticket Encryption Type = 0x17, note the exact Account Name, Service Name, Client Address, and timestamp. Do not rely solely on the SIEM-normalized event; check the raw XML to ensure no field parsing errors have occurred.
2. Identify and profile the requesting account and source host: Query Active Directory for the Account Name from the event — check group memberships, last password change, whether it is a service account or user account, and whether it has administrative rights. Query your asset inventory for the Client Address to determine whether it is a known workstation, server, jump host, or an unrecognized/foreign IP.
3. Pull all TGS requests from this account in the preceding 24 hours: In your SIEM, search Event ID 4769 filtered to the same Account Name and Client Address over the past 24 hours, and list every unique Service Name requested. More than 3–5 distinct SPNs, especially if they span different systems or service types, strongly indicates automated enumeration rather than normal user behavior.
4. Retrieve the full process execution chain on the source host: Using Sysmon Event ID 1 or Event ID 4688 logs from the source host (identified by Client Address), search for processes created within ±5 minutes of the Kerberoasting event. Look for Rubeus.exe, powershell.exe with suspicious arguments, python.exe, or any unsigned or newly written executable. Trace the parent process chain to determine what launched the tool.
5. Check for files written to disk around the time of the attack: Using Sysmon Event ID 11 (File Create) on the source host, look for output files (e.g., .txt, .kirbi, .hash files) written in the same time window. Also check for Rubeus, Mimikatz, or Impacket binaries dropped to common staging paths such as C:\Users\Public\, C:\Windows\Temp\, or C:\ProgramData\.
6. Search for lateral movement originating from the source host and the targeted service account: In your SIEM, query Event ID 4624 (logon) and Event ID 4648 (explicit credentials logon) for the attacking user account and for any service accounts whose SPN tickets were requested — look for new logon events appearing after the Kerberoasting timestamp. Check Windows Event Forwarding or EDR telemetry on downstream hosts for remote service creation (Event ID 7045), scheduled task creation (Event ID 4698), or new admin sessions.
7. Determine escalation threshold — confirmed incident vs. false positive: Escalate to a confirmed incident if any of the following are true: the source IP is unrecognized or non-Windows, more than 5 distinct SPNs were requested, a high-value or privileged service account SPN was targeted, PowerShell or known tool keywords appear in script block logs, or lateral movement evidence exists post-event. Treat it as a likely false positive only if the source IP belongs to a known legacy application server with a documented RC4 requirement, the SPN requested matches a single known service, and no other suspicious activity correlates — document the decision either way.

Response Playbook

Containment

• Isolate the source host — keep it powered on: Use your EDR console (CrowdStrike Network Containment, Defender for Endpoint Isolate, Carbon Black Quarantine) to cut the host from the network while preserving its state for memory forensics. Do not power it off — volatile artifacts including process memory and network connections may contain cracked credentials or C2 artifacts needed for the investigation.
• Disable the attacking user account immediately: In Active Directory Users and Computers or via PowerShell (Disable-ADAccount -Identity username), disable the account that generated the Kerberoasting requests. If the account is a shared or service account, coordinate with the application owner before disabling, but prioritize containment over availability in a confirmed incident.
• Reset the password on all targeted service accounts: For every Service Name (SPN) that had an RC4 TGS ticket requested, immediately reset the password of the associated service account using Set-ADAccountPassword. Use a randomly generated password of at least 25 characters. This is critical — the attacker may already be cracking the hash offline and could gain access at any moment, so speed matters here.
• Invalidate all active Kerberos tickets for affected accounts: Run klist purge on any known hosts where the service account is logged in, and increment the msDS-KeyVersionNumber by performing a second password reset after the first to ensure previously issued tickets are invalidated. For domain-wide purge in critical cases, consult your AD team about a krbtgt reset process.
• Block the source IP at the perimeter and on domain controllers: If the Client Address in Event ID 4769 is an external or unrecognized IP, block it at the firewall and in your DC’s Windows Firewall via GPO. If it is an internal host already isolated by EDR, ensure lateral movement paths from that subnet to domain controllers are monitored or temporarily restricted.

Eradication

• Remove attacker tools from the source host: Using your EDR or by mounting the isolated host’s drive, locate and delete any identified Kerberoasting tools (Rubeus, Invoke-Kerberoast scripts, Impacket files, output hash files). Search the paths identified in your investigation: C:\Users\Public\, C:\Windows\Temp\, C:\ProgramData\, and user profile temp directories.
• Audit and remove any persistence mechanisms added on the source host and any lateral movement targets: Check for scheduled tasks (Event ID 4698, schtasks /query), new services (Event ID 7045, sc query), registry Run keys (HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Run), and WMI subscriptions. If the service account password was already cracked, treat any system it had access to as potentially compromised and audit those hosts as well.
• Audit all accounts with SPNs for password strength and encryption type: Run Get-ADUser -Filter {ServicePrincipalName -ne "$null"} -Properties ServicePrincipalName, msDS-SupportedEncryptionTypes to enumerate all Kerberoastable accounts. Any account not configured for AES-256 (msDS-SupportedEncryptionTypes = 24) should have its encryption type updated and password reset to a high-entropy value immediately.
• Search lateral movement targets for additional backdoors: For each system the compromised service account had access to, run your EDR’s threat hunt for the same IOCs (Rubeus hashes, PowerShell keywords, unusual parent-child process relationships). Check for newly created local admin accounts (Event ID 4720 + 4732) on those hosts.
• Rotate any additional secrets potentially exposed: If the compromised service account had access to credential stores, connection strings, vaults (CyberArk, HashiCorp Vault, Azure Key Vault), or API keys, rotate those secrets immediately and audit access logs to determine if they were accessed post-compromise.

Recovery

• Re-image the source host if confidence in its integrity is low: If the attacker had interactive access, ran additional tooling beyond Kerberoasting, or if the host was compromised for more than a short window before detection, re-image from a known-good baseline rather than attempting to clean it in place. Reconnect to the network only after reimaging and verifying endpoint agent health.
• Re-enable affected user and service accounts only after full eradication: Before re-enabling the attacking user account, confirm with HR and the user’s manager whether the account was used by a malicious insider or was itself compromised. Re-enable service accounts only after password resets are complete, encryption types are updated, and all targeted systems have been audited.
• Monitor previously affected hosts, accounts, and SPNs for 72 hours post-remediation: Create temporary, high-sensitivity detection rules in your SIEM scoped to the affected Account Name, Client Address, and targeted Service Names — alert on any new TGS requests, logon events, or process executions from these entities for a minimum of 72 hours. This catches re-entry attempts if the attacker successfully cracked hashes before containment.
• Implement long-term hardening based on findings: Use Managed Service Accounts (gMSA) for service accounts where possible — gMSA passwords are 240-character randomly generated values rotated automatically, making Kerberoasting practically useless. For accounts that cannot use gMSA, enforce 25+ character random passwords and set msDS-SupportedEncryptionTypes = 24 (AES-256 only) to eliminate RC4 ticket requests.
• Document the full timeline and update detection content: Write an incident report covering the full attack timeline, affected accounts and systems, attacker tools identified, and gaps in detection that delayed alerting. Update your Kerberoasting detection rules with any new tool hashes, command-line patterns, or SPN naming patterns discovered during the investigation, and share IOCs with your threat intelligence platform.