Backup Account Lights Up the Finance VLAN
Meridian Health's SOC receives a correlation alert at 09:42: service account svc_backup generated 14 successful 4624 events with Logon Type 3 to hosts FIN-WS-11 through FIN-WS-23, all sourced from FIN-WS-07, within 88 seconds. The authentication package is NTLM, not Kerberos. In the same window, 7045 events on nine of those hosts install a service named PSEXESVC with binary path C:\Windows\PSEXESVC.exe. The CMDB documents svc_backup as a backup agent account restricted to two servers, and its scheduled job ran at 02:00. The SIEM rule that fired is medium severity and produced six false positives in 90 days, all traced to an admin tool inventory sweep from one host inside a change window. The user on FIN-WS-07 called the helpdesk at 09:50 saying the machine keeps locking up. EDR covers servers but not workstations, and endpoint logs are not forwarded; domain controller security logs arrive with a four-hour delay.
1. Decide whether this is a true positive and explain what separates it from the earlier false positives.
Read the worked answer
It is a true positive. The prior six alerts were dismissed for concrete reasons that do not apply here:
- Fan-out versus fixed target list. Fourteen hosts in 88 seconds is discovery-and-execute behaviour; the inventory tool swept from one source against a documented, ticketed set. svc_backup is scoped to two servers in the CMDB, so contacting twelve workstations is out of policy by definition.
- Timing. The legitimate job completed at 02:00. A 09:42 burst cannot be the backup.
- Service name. PSEXESVC is the service PsExec creates. A backup account deploying PsExec to workstations maps to remote service execution for lateral movement, not backup operations.
- Auth package. NTLM rather than Kerberos is consistent with pass-the-hash or a credential used outside a normal logon context, and backups normally authenticate with Kerberos.
- Host symptom. The user's lock-up report is consistent with service creation and process injection on FIN-WS-07.
What would downgrade it is a change ticket from the server team authorising PsExec at that exact minute. None exists.
2. State the order in which you collect evidence and explain why that order, given the telemetry gaps.
Read the worked answer
Order follows volatility, and the gaps drive it:
- Memory of FIN-WS-07 first. It is the source of all 14 logons and the only place holding the injected code, the parent process, network sockets, and possibly plaintext credentials or hashes in LSASS. Since workstations have no EDR and no log forwarding, memory is the only live telemetry that exists - once the machine reboots or the user logs off, it is gone.
- Volatile network state from FIN-WS-07: net sessions, net use, ARP cache, DNS cache, and the SMB client connections to the 14 targets.
- The PSEXESVC binary from one or two targets, with hashes, before any cleanup removes it.
- Local Security and System event logs from the workstations (4624, 7045, 4688 where enabled) pulled directly, because forwarding to the SIEM does not exist.
- Domain controller logs last, since they arrive with a four-hour delay anyway; pull them on demand rather than waiting for the pipeline.
Collecting DC logs first would waste the window in which FIN-WS-07 memory is still intact.
3. Design the containment sequence so the intrusion stops spreading without destroying evidence or alerting the operator prematurely.
Read the worked answer
- Capture, then isolate FIN-WS-07 at the switch port or via NAC. Do not shut it down; a live capture of memory precedes network isolation so the SMB session table is preserved. Port isolation stops further fan-out without wiping RAM.
- Block workstation-to-workstation SMB (445/135/139) by GPO or firewall policy on the finance VLAN. Legitimate backup traffic flows server-to-server, so this costs little and severs the lateral path the attacker is using.
- Do not simply disable svc_backup yet. A disabled account mid-operation often triggers the operator to switch tooling or detonate. Instead, first push the SMB block, snapshot the logs you need, then reset the password twice and disable the account in a single coordinated step.
- Rotate any credential that was on FIN-WS-07 - the user's domain password and any cached admin credentials - because the account may have been harvested from that host rather than guessed.
- Hunt before notifying broadly. Query 7045 across all hosts for PSEXESVC and compare service creation times; the attacker may already be on hosts outside the original twelve.
The sequence keeps the adversary's channel quiet until the SMB path is closed and the account is useless to them.