Kerberoasting Alert During Payroll
Tailspin has 1,200 employees, on-premises Active Directory, Entra Connect, and a 90-day password policy. MFA is enforced only on VPN and Microsoft 365; internal apps use Kerberos. Fourteen service accounts have PasswordNeverExpires, and six have service principal names. svc_sql is used interactively by four DBAs and has RC4 enabled. At 02:14 on Tuesday, the SIEM reports 120 Kerberos service ticket requests (event 4769) for svc_sql with encryption type 0x17 from workstation 10.20.5.77 in three minutes. The workstation belongs to a help-desk technician who is on leave. There are no 4625 failures and no 4624 type 10 logons. The SOC analyst wants to disable svc_sql immediately, but the payroll batch runs at 03:00 and depends on it.
1. What activity does the alert most likely represent, and which specific log fields support or weaken that conclusion?
Read the worked answer
Most likely Kerberoasting: an authenticated user requests service tickets for accounts with SPNs, then cracks the ticket offline. The 4769 events for svc_sql, encryption type 0x17 (RC4-HMAC), 120 requests in three minutes, and a workstation belonging to an absent help-desk technician all fit. The requesting account matters: if 10.20.5.77 was logged in as the technician, the ticket requests may be from a scheduled task or a compromised session; if the account is a normal user with no reason to touch svc_sql, that strengthens the malicious interpretation.
The absence of 4625 and 4624 type 10 does not weaken it, because Kerberoasting uses existing credentials and does not require interactive logon. What would weaken it: a known inventory or monitoring tool on that workstation that enumerates SPNs, a change window, or the same pattern from many hosts. Check 4769 fields for service name, client address, and ticket options; check 4688/Sysmon for PowerShell, Rubeus, or setspn; check whether the RC4 ticket was followed by a 4624 type 3 to another host.
2. Give a 60-minute containment plan that keeps the 03:00 payroll batch running. Order the actions and state the trade-off for each.
Read the worked answer
0-10 min: confirm the alert with raw 4769 events, identify the client account and host, and check whether payroll has started. Do not disable svc_sql yet. 10-20 min: reset svc_sql's password to a 30+ character random value in a controlled change, update the payroll job's credential store, and restart the batch; this invalidates any cracked or soon-to-be-cracked ticket without downtime if done before 03:00. 20-35 min: isolate 10.20.5.77 from the network but preserve memory, collect EDR triage, and revoke the technician's sessions and refresh tokens. 35-50 min: search for other 4769 RC4 bursts and for 4624 type 3 to servers from that host; block the host's account and check for scheduled tasks. 50-60 min: brief the payroll owner and SOC lead; keep svc_sql enabled but restrict logon to the batch server.
Trade-offs: resetting the password may break the batch if the credential is cached; test the job's service-account configuration first. Isolating the host may destroy remote-access evidence, so capture memory and EDR telemetry before containment. Disabling svc_sql is the safest security move but the highest business risk; use it only if payroll cannot be moved or if you see active use of the cracked ticket.
3. Design the durable fix for service accounts and Kerberos exposure. Include at least three controls and one sequencing risk.
Read the worked answer
Controls: (1) convert service accounts with SPNs to group Managed Service Accounts (gMSA), or at least 64-character random passwords rotated every 30-60 days; (2) remove interactive logon rights from service accounts and restrict logon to specific servers; (3) disable RC4 where the application supports AES, but sequence it: audit 4769 encryption types first, because payroll or legacy apps may require RC4; (4) inventory SPNs quarterly and alert on new SPNs; (5) deploy a honeypot service account with an SPN and no privileges, and alert on any 4769 for it; (6) tier admins so DBA workstations cannot reach domain controllers.
Sequencing risk: disabling RC4 before confirming AES support will break Kerberos authentication at 03:00 and may cause a payroll outage; do it in a pilot with one service account and a rollback. Also avoid a mass password reset without a credential-store update plan. Measure success by zero RC4 4769 for privileged service accounts, no interactive logons, and a tested gMSA migration.