SOP-95: Kerberoasting (Service Ticket Roasting) Response | CyberHawk Threat Intel

The stolen ticket is already off the wire by the time you triage the 4769 alert. You cannot "un-steal" it — the encrypted hash is on the attacker's cracking rig. Containment for Kerberoasting is therefore RESET THE ROASTED SERVICE ACCOUNT PASSWORD, not just isolate a host. Assume every roasted account with a weak password is compromised.

Highest-value targets are user accounts with an SPN that are ALSO members of privileged groups — a single crack there is a direct domain-privilege win. Hunt your own directory for these before an attacker does: they should have 25+ char passwords or be gMSA.

Kerberoasting fires as either a Sentinel scheduled-rule hit on 4769 or a Microsoft Defender for Identity "Suspected Kerberoasting" alert. Answer these five before opening a full investigation — they decide whether this queues or pages.

If Microsoft Defender for Identity raised the alert, open it first — MDI already correlates the source account, source host and the list of requested SPNs, saving you the initial 4769 join.

The defining footprint of Kerberoasting is one principal requesting RC4-encrypted service tickets for many distinct user SPNs in a short window. Normal clients request a ticket for the one or two services they actually use — not a sweep of every SPN in the directory.

• 1Open Microsoft Sentinel → Logs (or Defender XDR → Advanced Hunting if 4769 is ingested there).
• 2Paste the KQL below. Set the time range to Last 6 hours, expand to 7 days when hunting.
• 3Read the DistinctSPNs and SPNs columns — a single Account/IpAddress pulling many SPNs is the primary tell.
• 4Note the IpAddress (source host) and the requesting Account — these feed Containment C3 and the tooling hunt I4.

Do NOT dismiss a hit just because the count is low. A targeted attacker (A2) roasts only the two or three accounts they already know are privileged. A single RC4 TGS for a Domain-Admin service account with no matching business reason is more serious than a 40-SPN sweep of low-value accounts.

Severity is decided by which account was roasted. A roasted account that is a member of a privileged group is a domain-compromise-in-waiting the moment its password cracks. Also confirm whether RC4 was forced while the domain supports AES — that downgrade is a deliberate cracking-speed optimisation, not accidental.

• 1For every ServiceName from I1, check group membership in ADUC → account → Member Of, or run Get-ADUser <svc> -Properties MemberOf,servicePrincipalName,msDS-SupportedEncryptionTypes.
• 2Flag any roasted account in Domain Admins, Enterprise Admins, Administrators, Account Operators, or a Tier-0 group — that is an automatic SEV1.
• 3Check msDS-SupportedEncryptionTypes on the account and the domain policy — if AES is supported but the ticket came back RC4 (0x17), the requester downgraded on purpose.

No watchlist yet? Build one now: Get-ADUser -LDAPFilter "(servicePrincipalName=*)" -Properties MemberOf | where MemberOf -match "Admin" gives you every SPN account in a privileged group. These are your crown-jewel roast targets — protect them first.

Before roasting, an attacker must discover which accounts have SPNs. That discovery is an LDAP query for the servicePrincipalName attribute, or a setspn -q run. Finding the enumeration immediately before the 4769 burst confirms intent and pins the source host.

• 1Run the DeviceProcessEvents query below on the source host identified in I1.
• 2Correlate timing: SPN enumeration a few seconds/minutes before the ticket burst is a confirmed roast chain.
• 3If SecurityEvent 4662 (directory object access) is collected, look for the requester reading servicePrincipalName across many user objects.

The 4769 tells you a ticket was requested; the source host tells you what did the requesting. Rubeus, Impacket GetUserSPNs, Invoke-Kerberoast and mimikatz leave recognisable command lines. Confirming the tool converts "suspicious volume" into "confirmed attacker tooling".

• 1Run the query below scoped to the source DeviceName from I1 across the last 7 days.
• 2Open the Device Timeline for any hit to reconstruct the full session — download, execution, and any follow-on credential-dumping.
• 3Capture file hashes for the tool binaries and add them to the IOC list (I5) and MDE custom indicators (Containment).

Impacket GetUserSPNs runs from a REMOTE (often Linux) attacker host, so there may be NO process telemetry on any managed Windows endpoint. In that case I1's 4769 IpAddress is your only source pointer — pivot to network / NAC to identify the device before it disappears.

If the password cracked, the attacker's next move is to authenticate as the service account. A service account — normally used only by a service on a fixed host — suddenly performing an interactive/network logon from a new host is the strongest possible confirmation that the roast succeeded. This flips the incident from "attempted" to "confirmed compromise".

"It's probably the vulnerability scanner" is a hypothesis, not a verdict. Confirm it against the scanner's asset IP AND its documented scan schedule before closing. Attackers deliberately run roasts during scan windows to hide in the noise.

The clock started when the ticket left the DC. Every hour a weak-password service account stays un-reset is an hour the attacker has to finish cracking. Treat password reset of confirmed roasted accounts as the first, not the last, containment action.

• 1For EVERY roasted ServiceName from I1, reset the password to a 25+ character random secret (attackers cannot dictionary-crack a long random key). Coordinate with the app owner to update the service config in the same change.
• 2Prioritise any privileged roasted account — reset it first, then revoke its Kerberos tickets by resetting twice if it is highly sensitive.
• 3Where the account only serves one host and supports it, plan migration to a Group Managed Service Account (gMSA) — the OS rotates a 120+ char key automatically and it cannot be roasted usefully (covered in Eradication).
• 4Confirm msDS-SupportedEncryptionTypes is set to AES-only on the reset account so the next ticket is no longer RC4.

Do NOT reset the krbtgt account as a reflex here — Kerberoasting does not compromise krbtgt (that is Golden Ticket, SOP-12). Resetting krbtgt is only warranted if you have separate evidence of DC/DA compromise. Reset the ROASTED accounts, not krbtgt.

• 1Isolate the source host (MDE Actions → Isolate Device) to stop further enumeration, dumping, or lateral movement from the foothold.
• 2Disable / force-reset the requesting account (TargetUserName from I1) and revoke its sessions — it is the attacker's foothold identity: Entra Users → [user] → Revoke sessions and on-prem reset.
• 3If the source was a remote/Linux host (Impacket), block its IP at the firewall/NAC and quarantine the device before it detaches.
• 4Add roasting-tool file hashes (I4) to MDE custom indicators: Settings → Endpoints → Indicators → File → Add.

Kerberoasting is almost never the attacker's first action — it follows an initial foothold. Once contained, pivot to how the requesting account was obtained (phishing SOP-01, infostealer SOP-83, or lateral movement SOP-06).

• All roasted (and all roastable) service-account passwords reset to 25+ char / migrated to gMSA
• AES enforced and RC4 disabled on service accounts where compatible
• Requesting/foothold account reset, source host reimaged or cleared of tooling and persistence
• I1 + I4 re-run return 0 hits; I5 shows no post-reset anomalous logon
• Standing Sentinel rule + MDI Kerberoasting alert active; unnecessary SPNs and privileged-group memberships removed

Do not close on "we reset the one account in the alert." If tickets were roasted, assume the attacker holds hashes for every SPN they enumerated. Rotate the whole roastable set or you will re-open this incident when a second account cracks.

A single confirmed crack of a privileged, SPN-bearing account is a domain-privilege escalation — route straight to IR + CISO regardless of how few tickets were requested. Ticket count measures noise, not impact; the identity of the roasted account measures impact.