By Jackson Godwin | Cybersecurity Analyst & Penetration Tester, Jackson Technology

Kerberoasting remains one of the most reliable credential access techniques used by attackers operating inside Windows Active Directory environments. It requires no exploits, no malware payloads, and often no elevated privileges to begin with — just a valid domain user account and the ability to request Kerberos service tickets. Because the technique abuses legitimate protocol behavior, it frequently slips past traditional antivirus and endpoint detection tools, making it a favorite for both red teamers and real-world threat actors during post-compromise lateral movement.

For Security Operations Center (SOC) teams across Nigeria, the wider African region, and international enterprises alike, building dedicated detection logic for Kerberoasting is no longer optional. Whether your organization runs a banking infrastructure, a fintech platform, or a government network, an unmonitored Active Directory environment is an open invitation for credential theft and privilege escalation.

In this guide, I'll walk through what Kerberoasting is, how it works at the protocol level, and provide custom, production-ready Splunk SPL queries and Sigma rules you can deploy directly into your SIEM to detect this activity early — before attackers move from a single compromised account to full domain takeover.

What Is Kerberoasting?

Kerberoasting is a credential access technique catalogued under MITRE ATT&CK as T1558.003. It targets the Kerberos authentication protocol used by Active Directory, specifically the way Ticket Granting Service (TGS) tickets are issued for services associated with a Service Principal Name (SPN).

In a standard Kerberos exchange, when a user wants to access a service — such as a SQL Server database or a web application running under a domain service account — the Key Distribution Center (KDC) issues a TGS ticket. Part of this ticket is encrypted using a hash derived from the service account's password. Critically, any authenticated domain user can request a TGS ticket for any service that has a registered SPN, regardless of whether they actually have permission to use that service.

An attacker who has compromised even a low-privilege domain account can request TGS tickets for every SPN-registered account in the domain, extract the encrypted portion of those tickets, and take them offline for password cracking. If the targeted service account uses a weak or guessable password — and many legacy service accounts do — the attacker can recover the plaintext password without ever triggering a failed logon or lockout event.

Why Kerberoasting Is So Dangerous

• It uses fully legitimate Kerberos protocol functionality — no exploit code is involved
• Ticket requests are normal, everyday AD traffic, making detection difficult without tuned rules
• Service accounts often hold elevated privileges (database admin, backup operator, domain admin) and rarely have password rotation enforced
• Password cracking happens offline, away from any monitored network segment
• Popular offensive tools such as Rubeus, Impacket's GetUserSPNs.py, and PowerView make the attack trivial to execute

How Kerberoasting Attacks Unfold

A typical Kerberoasting attack chain follows a predictable sequence, which is exactly what gives defenders the opportunity to build detection logic around it.

1. Initial Access — The attacker obtains valid domain credentials, often through phishing, password spraying, or exploiting an unrelated vulnerability
2. SPN Enumeration — Using LDAP queries, the attacker enumerates all accounts in the domain that have a registered Service Principal Name, typically service accounts
3. TGS Ticket Requests — The attacker requests Kerberos service tickets (Event ID 4769) for each discovered SPN, often requesting tickets encrypted with the legacy RC4-HMAC algorithm rather than AES
4. Offline Cracking — The encrypted portion of each ticket is extracted and brute-forced offline using tools like Hashcat
5. Privilege Escalation — Once a service account password is cracked, the attacker authenticates as that account, often gaining elevated access to databases, file shares, or in some cases domain admin rights

🔑 Key Detection Insight Most Kerberoasting tooling deliberately requests RC4-HMAC (encryption type 0x17) tickets because RC4 hashes crack significantly faster than AES-256. On a well-configured modern domain, RC4 usage for service ticket requests should be rare — making it one of the strongest single indicators of Kerberoasting activity.

Core Detection Strategy: What to Look For

Effective Kerberoasting detection in Splunk and Sigma relies on monitoring Windows Security Event ID 4769 ("A Kerberos service ticket was requested") on your Domain Controllers, combined with a few key correlation patterns.

Indicator	Event Field	Why It Matters
RC4 encryption (0x17)	TicketEncryptionType	Modern Windows clients default to AES (0x12); RC4 is a red flag for cracking-optimized requests
High volume TGS requests	ServiceName count per user	Indicates SPN enumeration sweeping the entire domain
Targeted privileged SPNs	ServiceName naming pattern	Attackers prioritize SQL, admin, and backup service accounts
Unusual TicketOptions flags	TicketOptions = 0x40810000	Common signature of Rubeus and Impacket ticket requests
Baseline deviation	User/Service combination history	Service accounts rarely request tickets for services they have never used before

Custom Sigma Rules for Kerberoasting Detection

Sigma rules provide a vendor-agnostic detection format that can be converted into Splunk, Elastic, QRadar, or Microsoft Sentinel queries using tools such as sigma-cli or Uncoder.io. Below are three custom Sigma rules covering the primary Kerberoasting indicators.

Rule 1: RC4 Encryption Downgrade on Service Ticket Requests

This rule flags any TGS request (Event 4769) using RC4-HMAC encryption (TicketEncryptionType 0x17) for non-machine accounts. Machine account tickets (ending in $) are excluded to reduce noise from legacy systems.

title: Potential Kerberoasting via RC4 Service Ticket Request id: f0a3f0e1-9d3a-4f3c-8c8d-1c2e3f4a5b6c status: stable logsource:   product: windows   service: security detection:   selection:     EventID: 4769     TicketEncryptionType: '0x17'   filter_machine_accounts:     ServiceName|endswith: '$'   condition: selection and not filter_machine_accounts level: high tags:   - attack.credential_access   - attack.t1558.003

Rule 2: High-Volume TGS Requests From a Single Account

This rule detects a single user account requesting service tickets for an unusually high number of distinct SPNs within a short time window — a strong signal of automated enumeration tooling rather than normal user behavior.

title: Kerberoasting - High Volume TGS Requests id: a1b2c3d4-5e6f-7a8b-9c0d-1e2f3a4b5c6d status: stable logsource:   product: windows   service: security detection:   selection:     EventID: 4769     TicketOptions: '0x40810000'   timeframe: 5m   condition: selection | count(ServiceName) by TargetUserName > 10 level: medium tags:   - attack.credential_access   - attack.t1558.003

Rule 3: RC4 Ticket Requests Targeting Privileged Service Accounts

This rule narrows focus to RC4-encrypted ticket requests against accounts whose SPN naming convention suggests privileged roles, such as service, SQL, admin, or backup accounts. These accounts represent the highest-value targets for an attacker.

title: Kerberoasting - RC4 Request for Privileged SPN id: b2c3d4e5-6f7a-8b9c-0d1e-2f3a4b5c6d7e status: stable logsource:   product: windows   service: security detection:   selection:     EventID: 4769     TicketEncryptionType: '0x17'     ServiceName|contains:       - 'svc_'       - 'sql'       - 'admin'   condition: selection level: critical tags:   - attack.credential_access   - attack.t1558.003

Custom Splunk SPL Queries for Kerberoasting Detection

If your organization runs Splunk natively, the following SPL queries can be deployed directly as scheduled correlation searches against your Windows Security Event Logs index.

Query 1: RC4 Encryption on Non-Machine Service Tickets

index=wineventlog EventCode=4769 | where Ticket_Encryption_Type="0x17" | where NOT match(Service_Name, ".*\$$") | stats count min(_time) as first_seen max(_time) as last_seen     values(Service_Name) as services_requested     by Account_Name, Client_Address | convert ctime(first_seen) ctime(last_seen) | eval risk_score=case(     count >= 10, "Critical",     count >= 5, "High",     count >= 1, "Medium") | sort -count

Query 2: Burst Detection — Possible SPN Enumeration

index=wineventlog EventCode=4769 Ticket_Options="0x40810000" | bucket _time span=5m | stats dc(Service_Name) as unique_services     count as ticket_requests     by _time, Account_Name, Client_Address | where unique_services > 10 | eval alert="Possible Kerberoasting - High Volume SPN Enumeration" | table _time, Account_Name, Client_Address, unique_services,     ticket_requests, alert | sort -ticket_requests

Query 3: Privileged SPN Targeting With RC4

index=wineventlog EventCode=4769 Ticket_Encryption_Type="0x17" | eval is_priv_spn=if(match(Service_Name,     "(?i)(svc_|sql|admin|backup|exch)"), "true", "false") | where is_priv_spn="true" | stats count values(Service_Name) as targeted_spns     earliest(_time) as first_request     latest(_time) as last_request     by Account_Name, src | convert ctime(first_request) ctime(last_request) | eval alert_level="Critical - Privileged SPN Targeted via RC4" | table Account_Name, src, count, targeted_spns,     first_request, last_request, alert_level

Tuning Tips to Reduce False Positives

Detection logic that generates excessive noise quickly gets ignored by analysts. Before deploying these rules into production, apply the following tuning steps to align them with your environment's baseline.

• Whitelist known legacy applications that still require RC4 encryption due to compatibility constraints, but flag them for remediation separately
• Exclude scheduled service health-check accounts that legitimately request multiple SPNs as part of monitoring tooling
• Enrich Account_Name and Service_Name fields with an LDAP lookup against your privileged groups (Domain Admins, Enterprise Admins, Server Operators) to prioritize alerts
• Correlate Event 4769 with Event 4768 (TGT requests) and Event 4624 (logon events) to build a fuller picture of the attack chain
• Run a 30-day baseline period in 'monitor only' mode before enabling automated alerting to calibrate thresholds for your domain's normal ticket request volume

Beyond Detection: Reducing Kerberoasting Risk at the Source

Detection rules are essential, but they work best as part of a layered defense strategy. Organizations should also focus on reducing the attack surface that makes Kerberoasting effective in the first place.

• Enforce long, randomly generated passwords (25+ characters) for all service accounts, ideally managed through Group Managed Service Accounts (gMSA)
• Disable RC4 encryption support domain-wide where compatible, forcing AES-256 for all Kerberos ticket exchanges
• Regularly audit and remove unnecessary SPN registrations on user accounts
• Rotate service account passwords on a defined schedule, especially for accounts with elevated AD privileges
• Apply the principle of least privilege so that even a cracked service account password yields minimal lateral movement potential

📋 Compliance Note for Nigerian and African Enterprises For organizations operating under NDPA (Nigeria Data Protection Act) or pursuing ISO/IEC 27001:2022 certification, Kerberoasting detection maps directly to Annex A controls covering access control (A.8.5), monitoring activities (A.8.16), and protection against malware and exploitation techniques (A.8.7). Demonstrating active SIEM monitoring for credential access techniques such as T1558.003 strengthens both your audit posture and your incident response readiness.

Final Thoughts

Kerberoasting succeeds because it hides in plain sight, exploiting normal Kerberos behavior rather than a software flaw. That's exactly why detection engineering matters more than patching here — there is no patch for legitimate protocol design. By deploying the Sigma rules and Splunk queries outlined in this guide, tuning them to your domain's baseline, and pairing detection with strong service account hygiene, your SOC can catch Kerberoasting attempts in the reconnaissance and credential theft stages — well before an attacker reaches domain admin.

If you're building out a detection engineering program for your organization's Active Directory environment, start with Event ID 4769 monitoring this week. It's one of the highest-value, lowest-effort detections you can stand up in your SIEM.

About the Author

Jackson Godwin is a Cybersecurity Analyst and Penetration Tester, and the founder of Jackson Technology, a cybersecurity and data protection consulting firm based in Abuja, Nigeria. Jackson Technology provides VAPT, cloud security, compliance advisory (ISO 27001, NDPA, GDPR), and AI governance consulting to enterprise clients across banking, fintech, oil and gas, and the public sector. Jackson is also affiliated with TechTrain Academy, where he contributes to cybersecurity capacity-building initiatives.

For consulting inquiries, security assessments, or compliance support, contact: info@jacksontechnology.com.ng