Kerberoasting Detection and Response Guide

Understand what the domain controller can and cannot see

Kerberoasting detection and response begins with a valid Kerberos identity requesting a ticket-granting service ticket for an account that has a service principal name. The requester can extract material from the ticket and test password guesses offline; the domain controller does not observe those guesses.

MITRE ATT&CK T1558.003 describes the path and recommends combining anomalous TGS activity with encryption and endpoint context. A service-ticket request is normal Windows authentication evidence, so event 4769 is a starting fact, not a verdict.

Risk rises when a service account has a guessable password, RC4 tickets, broad privilege, interactive logon, or access across many systems. AES raises cracking cost but does not repair weak credentials.

Build a service-ticket baseline before alerting

Collect successful 4769 events from every domain controller with event time, requester account, client address, service name or SPN, service account, ticket encryption type, status, domain controller, and ticket options. Join identity inventory: managed-service-account status, privilege, password age, allowed logon, owner, and expected clients.

Keep a daily profile of distinct SPNs per requester, requests per minute, normal client hosts, usual encryption types, and first-seen requester-to-service pairs. Microsoft RC4 auditing guidance explains relevant 4768 and 4769 fields; verify field availability for each supported Windows version.

Normalize IPv4, IPv6, loopback, machine accounts, and service-name aliases before baselining. Missing domain-controller coverage can turn an apparent spike into an ingestion artifact.

Combine burst, novelty, encryption, and privilege signals

Alert when one non-service identity requests many distinct SPNs in a short interval, targets unusual service accounts, or makes requests from a new endpoint. Increase confidence for RC4 ticket encryption, high-value service accounts, weak-password indicators, suspicious tooling on the endpoint, or follow-on logons using the targeted account.

Do not hard-code “RC4 equals attack.” Legacy services may legitimately require it. Start with a baseline query, then test thresholds against administration, monitoring, vulnerability scanning, application start-up, and backup jobs. Record the complete feature set that caused the decision.

Validate with an authorized simulation account and disposable SPNs. Label the generated telemetry as simulation; it is evidence that collection and analytics work, not evidence of a live intrusion.

Contain the requester and recover every targeted account

Follow security alert triage: preserve 4769 events, endpoint process and network evidence, identity changes, and subsequent logons. Confirm whether the requester, source host, and targeted services are expected before disabling production identities.

If malicious, isolate the source, revoke sessions and tickets where supported, disable or constrain the compromised requester, and rotate every service credential plausibly recovered. A normal reset may break dependent services; inventory SPNs, scheduled tasks, application pools, services, and secrets before coordinated rotation.

Hunt for use of targeted accounts from new hosts, privilege changes, remote administration, and persistence. Recovery is incomplete until dependencies use the new secret and old credentials no longer authenticate.

Remove crackable and overprivileged service identities

Migrate eligible services to group managed service accounts or equivalent managed identities with long, automatically rotated secrets. Enable AES where every dependency supports it, remove unnecessary SPNs, prohibit interactive logon, and minimize local and domain privilege.

Treat RC4 removal as a compatibility migration: audit use, identify account and client support, test, remediate, then enforce. Do not disable a protocol blindly on critical services. Maintain owners and dependency maps for every service identity.

Build one explainable baseline and exercise it safely

Next step: select one week of complete domain-controller 4769 data. Rank requesters by distinct SPNs, annotate legitimate scanners and service workflows, identify RC4-dependent accounts, and review the highest-risk service accounts with their owners.

In an isolated test domain, generate a small authorized burst against disposable SPNs and verify collection, enrichment, alerting, triage, and credential rotation. Keep the lab outcome separate from production findings.