The Alert That Was Almost Closed
At 02:14 on a Saturday, the EDR platform raises a high-severity alert on FIN-SRV-07: powershell.exe accessed lsass.exe memory and wrote a 42 MB file to C:/Windows/Temp. The same host shows a helpdesk ticket opened 20 minutes earlier for a password reset by user 'jdoe'. The on-call analyst sees that the process was launched by a scheduled task named 'IT_Inventory_Update', which is not in the approved task baseline. The SOC handles 1,200 alerts per day with five analysts; 92% are auto-closed by a tuning rule. The analyst's draft note says 'likely admin activity, close'. There is no specific playbook for LSASS access, and the asset owner is unreachable. The server holds payroll data and has outbound internet access.
1. Should the analyst close, escalate, or contain? Give the decision and the first three actions.
Read the worked answer
The analyst should escalate and contain, not close. The combination is not normal administrative behaviour: LSASS memory access, an unapproved scheduled task, a 42 MB file written to Temp, a password-reset ticket within 20 minutes, and 02:14 timing on a Saturday. Any one of those might be benign; together they match credential dumping and staging. The auto-close rule that suppresses 92% of alerts is also a warning sign, not a reason to trust the queue. The server holds payroll data and has outbound internet access, so the potential impact includes credential theft and data exfiltration.
First three actions: (1) isolate FIN-SRV-07 from the network using the EDR containment function rather than powering it off, so volatile memory and process state are preserved; (2) notify the incident commander and open a major incident, because the helpdesk ticket may indicate the user's credentials are already in attacker hands; (3) preserve volatile evidence before remediation, including the EDR process tree, the scheduled task definition, PowerShell operational logs, and network connections. The asset owner should be contacted, but the decision cannot wait for them. Payroll continuity should be assessed in parallel; if isolation affects a weekend batch, the incident commander should coordinate a controlled exception rather than leaving the host connected.
2. What evidence should be preserved, and in what order, before remediation?
Read the worked answer
Preserve volatile evidence first, because it disappears on reboot or process termination. Capture a memory image of FIN-SRV-07 if the tooling and authorization exist; at minimum capture the EDR process tree, the parent process, command line, user context, and the hash of the 42 MB file. Export the scheduled task XML, including the author, trigger, action, and creation time. Pull PowerShell operational logs, especially script block logging, and Security event logs for logon and process creation. Record active network connections and DNS queries from the host, and check whether the file was uploaded to an external destination.
Next, preserve the helpdesk ticket details and the timing of the password reset; determine whether 'jdoe' was the account used by the scheduled task or whether the ticket is unrelated. Collect EDR telemetry from peer servers for the same scheduled task name or the same file hash. Copy the 42 MB file to an evidence store with a hash, but do not execute it. Maintain chain of custody and a timeline.
Only after volatile capture should the team remediate: remove the scheduled task, reset credentials, and rebuild or clean the host according to policy. Running a full antivirus scan before capture can alter timestamps and delete the file, so avoid it until evidence is secured.
3. What metrics and tuning changes should follow, and what should the SOC avoid overreacting to?
Read the worked answer
The SOC should measure more than close rate. Useful metrics are true-positive rate by detection rule, median time from alert to triage, percentage of alerts with a completed playbook, and containment time for confirmed intrusions. The 92% auto-close rate is only good if it is validated by sampling; if LSASS access and unapproved scheduled tasks are inside the auto-close population, the rule is suppressing high-value signals. The team should create a specific LSASS-access playbook with mandatory escalation criteria and a scheduled-task baseline, then exclude those detections from auto-close until the baseline is mature.
The SOC should avoid two overreactions. First, do not disable auto-close entirely after one incident; with 1,200 alerts per day and five analysts, that would flood the queue and create new misses. Second, do not tune the rule to the exact file size, task name, or host, because the attacker will change them. Tune on behaviour: LSASS access by an unsigned or non-standard process, scheduled-task creation outside change control, and large writes to Temp followed by outbound connections.
The staffing gap also needs a decision: five analysts cannot both triage 1,200 alerts and investigate deeply. The CISO should present the incident and the metrics to management as evidence for either added automation or added headcount.