Kerberoasting Retrospective: How to Investigate an Attack That Happened Weeks Ago When Your SIEM Was Not Logging It

If your SIEM has a 30-day retention window and the Kerberoasting occurred 45 days ago, the Event ID 4769 logs are gone. What survives:

1. Active Directory account attributes: PasswordLastSet, PasswordNeverExpires, and BadPwdCount are current AD state and do not roll back. If a service account's PasswordLastSet date changed unexpectedly between your last AD snapshot and today, that is a post-attack indicator that the attacker used the cracked credential and triggered a forced reset, or that the account was reset by an administrator who detected the threat.

2. SPN registration history: SPNs are registered on the account and persist unless explicitly removed. The current SPN list shows which accounts were attackable. If SPNs were recently removed from service accounts without a corresponding change management ticket, someone may have conducted cleanup after an unauthorized access event.

3. Kerberos audit policy state: check whether KDC auditing was actually enabled at the time of the suspected attack. Run auditpol /get /subcategory:"Kerberos Service Ticket Operations" on a Domain Controller. If the result shows No Auditing, Event ID 4769 was never generated and the SIEM silence means nothing: the events did not exist to forward.

4. Short-lived log sources that may have longer retention: Windows Forwarding Event Log on the DC (check the Security event log on the DC itself, not just the SIEM), network flow logs (Kerberos TGS requests appear as UDP/TCP 88 traffic), and any EDR process execution logs on workstations where the Kerberoasting tool was run.

For each SPN-bearing service account, build a crack probability assessment based on four factors.

Factor 1: encryption type. RC4-HMAC (0x17) tickets are significantly faster to crack than AES-256-CTS-HMAC-SHA1 (0x12) tickets. If the service account has Use Kerberos DES encryption types for this account or the account has no AES keys registered (check with Get-ADUser [name] -Properties KerberosEncryptionType), attackers received RC4 tickets by default. RC4 = high crack probability.

Factor 2: password age. PasswordLastSet older than 2 years combined with RC4 encryption = assume cracked. PasswordLastSet within the past 6 months = lower probability but not zero.

Factor 3: password complexity policy. If the service account is in an OU with a Fine-Grained Password Policy that allows shorter passwords, the keyspace is smaller. Check Get-ADFineGrainedPasswordPolicy -Filter * to see if any FGPPs apply to the service account's OU.

Factor 4: account privilege level. A cracked service account password is only useful if the account has privileges worth using. Assess each account's group memberships and ACL rights in AD. A service account that is a member of Domain Admins (unfortunately common) represents full domain compromise if cracked.

Output: a prioritized list of accounts ranked High, Medium, or Low by crack probability combined with privilege impact.

For accounts assessed as High crack probability combined with high privilege, hunt for evidence that the cracked credential was used.

Event ID 4624 (successful logon): filter by the service account's SamAccountName as the Account Name field and look for interactive or network logon types (Type 2 or Type 3) from unexpected workstations. Service accounts typically authenticate from specific servers; a logon from an engineer's workstation is anomalous.

Event ID 4648 (explicit credential logon): records when credentials are explicitly passed using RunAs or equivalent. A service account appearing in 4648 logs on a workstation it has no reason to be on suggests the cracked password was used manually.

Event ID 4625 (failed logon): look for failed logons with the service account name from multiple workstations in a short time window. This pattern suggests automated lateral movement tools attempting to reuse the credential.

In environments with Sysmon deployed, process creation events (Event ID 1) showing the service account's credentials in command-line parameters (particularly psexec, wmic, or net use commands) are definitive post-crack usage indicators.

For accounts with no surviving SIEM data, the absence of post-crack evidence does not confirm no lateral movement. It means the investigation is inconclusive and the account should be treated as potentially compromised.

Containment actions for Kerberoasting are account-level operations that reduce the value of any cracked credentials and prevent future Kerberoasting against the same accounts.

Immediate (within 24 hours, for High priority accounts): force reset the service account password using a randomly generated value of at least 25 characters. Update all services, scheduled tasks, and application configurations that use the account. If the account is a member of Domain Admins or other highly privileged groups and there is no legitimate business reason for that membership, remove it immediately.

Short-term (within 72 hours, for Medium priority accounts): force reset passwords, document all password storage locations, and test rotation before cutting over to new credentials. Enable AES encryption on service accounts by setting Use AES 128 and 256 bit encryption types in the account properties. This ensures future ticket requests use AES rather than RC4.

Structural (within 30 days, for all SPN-bearing accounts): migrate eligible service accounts to Group Managed Service Accounts (gMSAs). gMSA passwords are 240-character random values managed automatically by AD, rotated every 30 days, and never exposed to administrators. gMSA passwords cannot be Kerberoasted in a useful way because offline cracking a 240-character password is not feasible. Accounts that cannot use gMSA (vendor restrictions, application compatibility) should have PAM vault-managed rotation with at least 25-character random passwords and 30-day rotation.