The Service Account That Runs Everything
During a quarterly access review, you find svc_sqlbackup is a member of Domain Admins, has a password set in 2016 that never expires, and is used by 12 scheduled tasks on nine servers, including payroll batch jobs. The password is also stored in plaintext in a script on a shared IT folder. The SIEM alerts on 14 RC4 TGS requests for svc_sqlbackup in two minutes from WS-227, a workstation belonging to a helpdesk technician; event 4769 shows encryption type 0x17. The technician says he ran a 'SQL backup check' script from the shared folder. The payroll batch window is 22:00-02:00, and the application owner refuses any change before month-end. The account has not logged on interactively in 90 days, but it has 3,000 network logons per day. You must reduce risk without breaking payroll.
1. What does the Kerberoasting alert imply here, and what immediate actions do you take?
Read the worked answer
The alert means an authenticated principal requested RC4 TGS tickets for an account with a service principal name. Any domain user can do this; the attacker then cracks the ticket offline. Fourteen requests in two minutes from a helpdesk workstation is not normal backup behavior and suggests a tool or a script abuse. The 2016 password and Domain Admin membership make a successful crack likely and the impact domain-wide.
Treat the account as compromised. Immediately reset the password to a long random value, update the 12 scheduled tasks, and remove Domain Admin membership. Restrict logon: deny interactive and remote desktop, allow network logon only to the nine servers. Remove the plaintext script from the share and search for copies. Check for evidence of privileged use: 4672, 4728/4732 group changes, new services, scheduled tasks, and 4769 requests from other hosts. Preserve logs from WS-227 and review the technician's activity.
If you find evidence that Domain Admin was used, plan a krbtgt reset in two stages. Do not reboot or disable payroll tasks before the password change is coordinated; a broken batch is an availability incident, but a cracked Domain Admin is a domain compromise.
2. How do you redesign the account and its permissions without breaking the payroll batch?
Read the worked answer
Move from a shared, static, over-privileged account to a Group Managed Service Account (gMSA) or, if the platform does not support it, a vaulted service account with automated rotation. A gMSA gives a 240-character machine-managed password and removes the plaintext script problem.
Steps: inventory each of the 12 tasks and the exact permissions it needs; create separate accounts per function if the tasks have different privilege needs; grant only the required file-share, SQL, and backup rights; remove Domain Admin entirely. Test the gMSA on a non-production copy of the payroll job, then update one task at a time during the 22:00-02:00 window with a rollback plan. Restrict the account to the nine servers and deny interactive logon. Enable auditing for the account and alert on TGS requests from workstations.
The application owner's refusal is about availability, so bring a tested, low-risk migration plan and a rollback. Removing Domain Admin can be done immediately if the tasks only need backup rights; verify with a permission test first. The goal is least privilege with a managed credential, not just a longer password.
3. The application owner refuses any change before month-end. What do you do, and what interim controls apply?
Read the worked answer
Escalate the decision, but do not leave the Domain Admin membership and 2016 password in place. Separate the changes that require application testing from those that do not. Removing Domain Admin and denying interactive logon are access-control changes; they can usually be tested against the tasks without changing the payroll application. Password rotation needs task updates, so coordinate a short maintenance window or use a gMSA pilot.
Interim controls: restrict the account to the nine servers by logon rights and firewall rules; remove the plaintext script; monitor all TGS requests for the account; alert on any interactive or remote-desktop logon; place the account in a privileged-access monitoring group; and require just-in-time approval for any change. If the owner still refuses, present the risk to the CISO or risk committee with a written acceptance request, an expiry date, and the evidence of Kerberoasting. Risk acceptance must be informed and time-bound.
Month-end is a valid business constraint, but it does not justify a cracked Domain Admin account. Offer a 30-minute window, a tested rollback, and a named owner for the migration. If the batch breaks, the rollback restores the old task while the investigation continues.