Kerberoasting Detection and Defense for Active Directory Service Accounts

In enterprise Active Directory environments, kerberoasting remains one of the most reliable credential access techniques because it abuses legitimate Kerberos behavior rather than exploiting a software flaw.

Any authenticated domain user can request service tickets. When a service account has a weak password and a legacy encryption type, those tickets become an offline cracking target.

This article takes a defender’s view. It covers how the technique works at a conceptual level, how to find exposure in your environment, how to detect abuse in telemetry, and how related identity attacks (DCSync, golden ticket, silver ticket) fit into the same risk chain.

Executive Summary

• Kerberoasting is an identity hygiene problem, not a patching problem. Exposure comes from service accounts with SPNs, weak passwords, and RC4 encryption.
• Detection is feasible with existing logs. Event ID 4769, filtered for RC4 ticket encryption and unusual request volume, catches most noisy activity.
• Managed identities remove the root cause. Group Managed Service Accounts (gMSA) and AES-only enforcement make cracking impractical.
• Ticket attacks form a chain. Kerberoasting often leads to lateral movement, then to DCSync or golden ticket persistence. Break the chain early.

The practical takeaway is to inventory SPN-bearing accounts, migrate them to gMSA where possible, enforce AES, and alert on anomalous service ticket requests.

Understanding the Foundations of Kerberoasting

Kerberos is the default authentication protocol in Active Directory domains. Clients prove identity to a Key Distribution Center (KDC) running on domain controllers, then receive tickets for specific services.

Understanding this ticket flow is essential before assessing risk.

How Service Tickets Create the Exposure

When a client requests access to a service, the KDC issues a service ticket. Part of that ticket is encrypted with a key derived from the service account’s password.

The KDC does not check whether the requester is authorized for the service at ticket-issue time. That check happens at the service itself.

Kerberoasting exploits this design. An attacker with any valid domain credential requests tickets for accounts that have a Service Principal Name (SPN), then attempts to recover the password offline.

No further privileged access is required, and the domain controller sees only ordinary ticket requests.

Three factors determine how dangerous this is:

• Password strength. Short or human-chosen passwords fall quickly to offline guessing.
• Encryption type. RC4-HMAC is far cheaper to attack than AES128 or AES256.
• Account privilege. Service accounts that belong to privileged groups turn a cracked password into domain-level impact.

Where It Sits in the Wider Ticket Attack Family

Kerberoasting is often discussed alongside other ticket-based techniques. They differ in prerequisites and impact.

A silver ticket forges a service ticket using the service account’s key, so it never touches the KDC. A cracked service password can feed directly into that technique.

A golden ticket requires the krbtgt key, usually obtained after a DCSync-style replication abuse. That is why service account compromise is rarely the end of an incident.

DCSync abuses the directory replication protocol. An account holding replication permissions can ask a domain controller for credential data as if it were another domain controller.

How Kerberoasting Fits Into Modern IT Infrastructure

Hybrid estates complicate service account management. Legacy applications, database engines, middleware, and backup agents often run under domain accounts that nobody has reviewed in years.

Cloud migration rarely retires these accounts. It usually adds more.

Trust Boundaries and Attack Surface

The diagram below shows the components involved and where trust boundaries sit. Note that the domain controller trusts any authenticated user to request tickets, while the service enforces authorization.

The key insight is that step 2 is where exposure occurs. The ticket leaves the identity tier, so its cryptographic strength must hold up outside your control.

Enterprise Governance and Risk Perspective

For CISOs and IT managers, kerberoasting maps cleanly onto governance controls. It is measurable, auditable, and fixable.

Useful program metrics include:

• Number of user accounts with SPNs
• Percentage of service accounts migrated to gMSA
• Count of accounts with RC4 still permitted
• Median service account password age
• Alert mean time to triage for anomalous 4769 events

Ownership matters as much as tooling. Every service account should have a named owner, a documented purpose, and a rotation schedule.

Without ownership, rotation never happens because nobody knows what will break.

Real-World Implementation: Auditing and Detection

Defenders can gain significant visibility with built-in tooling. The examples below use placeholder identifiers only (example.com, svc-sample, 192.0.2.x).

Auditing Your Exposure

The first step is inventory. This PowerShell snippet lists user accounts that have SPNs, along with password age and supported encryption types.

It requires the ActiveDirectory module and read access to the directory.

Import-Module ActiveDirectory

Get-ADUser -Filter 'ServicePrincipalName -like "*"' `
  -Properties ServicePrincipalName, PasswordLastSet,
              MemberOf, 'msDS-SupportedEncryptionTypes' |
  Select-Object SamAccountName,
    @{n='SPNCount';e={$_.ServicePrincipalName.Count}},
    PasswordLastSet,
    @{n='EncTypes';e={$_.'msDS-SupportedEncryptionTypes'}},
    @{n='PrivilegedGroups';e={($_.MemberOf | Where-Object { $_ -match 'Admins' }).Count}} |
  Sort-Object PasswordLastSet |
  Format-Table -AutoSize

Representative sanitized output:

SamAccountName  SPNCount PasswordLastSet      EncTypes PrivilegedGroups
--------------  -------- ---------------      -------- ----------------
svc-sample-db          2 2019-03-14 09:12:41         0                1
svc-sample-bkp         1 2021-07-02 16:40:03         0                0
svc-sample-web         3 2024-11-20 08:05:27        24                0

A value of 0 for encryption types means the account relies on domain defaults, which often still allow RC4. A value of 24 indicates AES128 and AES256 are set.

Prioritize accounts that combine an old password, no explicit AES setting, and privileged group membership. In the sample above, svc-sample-db is the clear first target.

Detecting Anomalous Ticket Requests

Domain controllers log service ticket requests as Event ID 4769. Two fields matter most for this analysis: the ticket encryption type and the requested service name.

An encryption type of 0x17 indicates RC4. In an AES-enforced environment, RC4 requests are inherently suspicious.

This command retrieves recent RC4 service ticket requests from a domain controller’s Security log:

$since = (Get-Date).AddHours(-24)

Get-WinEvent -FilterHashtable @{
    LogName='Security'; Id=4769; StartTime=$since
} | ForEach-Object {
    $x = [xml]$_.ToXml()
    $d = @{}
    $x.Event.EventData.Data | ForEach-Object { $d[$_.Name] = $_.'#text' }
    [pscustomobject]@{
        Time       = $_.TimeCreated
        Account    = $d.TargetUserName
        Service    = $d.ServiceName
        EncType    = $d.TicketEncryptionType
        ClientAddr = $d.IpAddress
    }
} | Where-Object { $_.EncType -eq '0x17' -and $_.Service -notlike '*$' } |
  Format-Table -AutoSize

Excluding service names ending in $ removes computer account noise. Sanitized sample output:

Time                 Account                 Service         EncType ClientAddr
----                 -------                 -------         ------- ----------
2026-10-02 14:03:11  [email protected]      svc-sample-db   0x17    ::ffff:192.0.2.41
2026-10-02 14:03:11  [email protected]      svc-sample-bkp  0x17    ::ffff:192.0.2.41
2026-10-02 14:03:12  [email protected]      svc-sample-web  0x17    ::ffff:192.0.2.41

Several RC4 requests from one client within seconds, spanning multiple distinct services, is the classic pattern. Legitimate users rarely touch several unrelated service accounts in one burst.

For scale, export events to CSV and score them with a small script. This Python example flags clients that request many distinct services in a short window:

import csv
from collections import defaultdict
from datetime import datetime, timedelta

WINDOW = timedelta(minutes=5)
THRESHOLD = 3  # distinct services per window

events = defaultdict(list)
with open("events_4769_sanitized.csv", newline="") as f:
    for row in csv.DictReader(f):
        ts = datetime.fromisoformat(row["Time"])
        events[row["ClientAddr"]].append((ts, row["Service"], row["EncType"]))

for client, items in events.items():
    items.sort()
    for i, (start, _, _) in enumerate(items):
        window = [e for e in items[i:] if e[0] - start <= WINDOW]
        services = {s for _, s, _ in window}
        rc4 = sum(1 for _, _, t in window if t == "0x17")
        if len(services) >= THRESHOLD and rc4 >= THRESHOLD:
            print(f"ALERT client={client} services={len(services)} rc4={rc4}")
            break

This is a triage aid, not a replacement for SIEM correlation. In production, baseline normal behavior per client and tune the threshold.

The workflow below shows how this detection fits an automated pipeline.

flowchart TD
    A[Domain Controller Event 4769] --> B[Log Forwarder]
    B --> C[SIEM Ingestion]
    C --> D{RC4 Encryption?}
    D -->|No| E[Archive]
    D -->|Yes| F{Multiple Services in Short Window?}
    F -->|No| G[Low Priority Review]
    F -->|Yes| H[Create Alert]
    H --> I[Enrich with Asset and Owner Data]
    I --> J[Analyst Triage]
    J --> K[Contain and Rotate Credentials]

A complementary technique is the honeypot service account. Create an SPN-bearing account with a long random password, no real function, and no legitimate ticket requests.

Any 4769 event for that service name is a high-confidence alert with near-zero false positives.

Challenges and Best Practices

Detection reduces dwell time, but prevention removes the exposure. Mitigation should combine account redesign, cryptographic hardening, and monitoring of adjacent techniques.

Hardening Service Accounts

The strongest control is replacing user-based service accounts with Group Managed Service Accounts. gMSA passwords are 240 characters of random data rotated automatically by the domain.

At that length and entropy, offline cracking is not practical.

Where gMSA is not supported by the application, apply these compensating controls:

• Set passwords of 25+ random characters, stored in a vault
• Remove RC4 by setting AES-only encryption types on the account
• Remove accounts from privileged groups
• Restrict logon rights to the specific servers that need them
• Remove unnecessary SPNs

This example enforces AES on a service account and reviews the result. Run it in a change window, since services that depend on RC4 will fail afterward.

# 24 = AES128 + AES256
Set-ADUser -Identity "svc-sample-db" `
  -Replace @{'msDS-SupportedEncryptionTypes'=24}

Get-ADUser "svc-sample-db" -Properties 'msDS-SupportedEncryptionTypes' |
  Select-Object SamAccountName, 'msDS-SupportedEncryptionTypes'

Note that the password must be reset after this change so AES keys exist for the account. Test in a staging environment first.

Containing DCSync, Golden Ticket, and Silver Ticket Risk

A kerberoasted credential matters most when it opens a path to higher privilege. Controls against the downstream techniques should therefore be part of the same program.

For DCSync:

• Audit who holds replication rights on the domain object
• Alert on Event ID 4662 where replication access is requested by non-domain-controller accounts
• Keep Tier 0 groups small and reviewed

For golden ticket:

• Protect domain controllers as Tier 0 assets
• Rotate the krbtgt password twice, with a replication interval between resets, on a regular schedule and after any suspected compromise
• Monitor for tickets with abnormal lifetimes or accounts that do not exist

For silver ticket:

• Use gMSA so service keys are never guessable
• Enable PAC validation where supported
• Monitor service-side logons that lack a matching KDC ticket request

The lifecycle below shows how these controls form a continuous improvement loop rather than a one-time project.

flowchart TD
    A[Inventory SPN Accounts] --> B[Risk Rank by Privilege and Age]
    B --> C[Migrate to gMSA or Harden]
    C --> D[Enforce AES and Rotate Secrets]
    D --> E[Deploy Detections and Honeypots]
    E --> F[Review Alerts and Tune]
    F --> G[Validate with Purple Team Exercise]
    G --> A

Common failure modes include forgetting accounts used by scheduled tasks, leaving old SPNs on decommissioned servers, and disabling RC4 without testing legacy dependencies.

Plan a phased rollout with application owners.

Future Trends and Emerging Technologies

Identity attacks continue to move toward techniques that look like normal behavior. Kerberoasting is a good example because it generates no malware and few unusual network flows.

Defensive investment is shifting accordingly toward identity-centric detection.

Several trends are worth tracking:

• Microsoft’s phased removal of RC4 defaults. Domain controller defaults are moving toward AES, reducing legacy exposure over time.
• Identity threat detection and response (ITDR). Dedicated tooling correlates Kerberos telemetry with behavioral baselines.
• Passwordless and certificate-based service authentication. These reduce reliance on shared secrets.
• Authentication tiering and privileged access models. These limit what a single cracked credential can reach.

Organizations should not wait for defaults to change. Legacy compatibility settings tend to persist for years in real environments, particularly in estates with older applications.

Treat the audit and detection steps in this article as a baseline today, and revisit them as platform defaults evolve.

Advanced FAQ

Does disabling RC4 fully prevent kerberoasting?
No. It raises the cost of cracking considerably, but AES tickets can still be requested and attacked offline. Password length and randomness remain the deciding factor, which is why gMSA is the preferred fix.

Which accounts are most at risk?
User accounts with SPNs, old passwords, human-chosen secrets, and privileged group membership. Computer accounts and gMSA accounts have long random passwords and are not practical targets.

How can I tell kerberoasting apart from legitimate service access in Event 4769?
Look for bursts of requests across many distinct services from one client, RC4 encryption where AES is the norm, and requests for services the account has never used. Baselining per client improves accuracy.

What is the relationship between a cracked service password and a silver ticket?
A recovered service password lets an attacker derive the service key and forge tickets for that service without contacting the KDC. This is why service-side monitoring and PAC validation complement KDC-side detection.

How often should the krbtgt password be rotated?
Many organizations rotate it on a defined schedule, commonly every 180 days, and immediately after suspected domain compromise. Always reset it twice with replication time between resets, and follow Microsoft’s guidance to avoid ticket validation failures.

Kerberoasting persists because it exploits long-standing design choices combined with weak service account hygiene. The fix is largely within defenders’ control.

Inventory SPN accounts, migrate to gMSA, enforce AES, monitor Event 4769, and extend your controls to DCSync, golden ticket, and silver ticket scenarios. Treated as a continuous program, kerberoasting becomes a manageable and measurable risk.