Intermediate
Lesson 32 of 38 · ~10 min

Walkthrough: a High-severity incident, start to finish

A Low plus tighter SLA, paired actions (often isolation), and the customer call. Components are the same; tempo, coordination, and stakes differ. Twenty-eight minutes, six steps, one isolate-then-call cycle.

A High is a Low plus a tighter SLA, paired actions (often isolation), and the customer call. The components are the same; the tempo, the coordination, and the stakes are different. This walkthrough makes the rhythm explicit: where the call slots in, when isolation comes (and doesn’t), how the verify step changes when remediations are paired.

The scenario

14:08 Wednesday. A High EDR Incident Report lands for example.org. Host: WS-EXAMPLE-FINANCE-07, the assistant CFO’s workstation. Summary: a scheduled task running powershell.exe -EncodedCommand <base64> discovered. The encoded payload, when decoded by the SOC, downloads and executes a script from a known-bad domain. Recommendation: isolate the host, approve the scheduled-task remediation, verify with user before closing.

That’s a meaningfully different shape from a Low: isolation in the Recommendation, a remediation, and a user-verification expectation. The MSP’s policy is a 4-hour SLA on High during business hours.

Walking it through

  1. 14:09 — Claim

    Click Claim. The clock starts.

  2. 14:10 — Review

    Header confirms: High severity, EDR surface, host WS-EXAMPLE-FINANCE-07, customer example.org. Hostname matches the customer’s pattern. Recommendation is in scope (isolation, a remediation, user verification — all helpdesk actions). The encoded PowerShell calling out to a known-bad domain makes the High tag obvious; this isn’t borderline.

  3. 14:11 — Isolate

    Don’t read the full Evidence yet. Isolate WS-EXAMPLE-FINANCE-07 via the portal. Within 30 seconds, the agent picks up the policy. The host is contained.

  4. 14:13 — Call

    Call the assistant CFO. Voicemail. Try the IT manager: reaches. Use the four-move plain-language explanation, then piggy-back the SOC’s verification question: “Did she run anything unusual yesterday or this morning? Anything involving PowerShell or what looked like an automated update?” IT manager: “She’s been in meetings all morning, hasn’t touched her machine. I’ll grab her between sessions. Five minutes.”

  5. 14:18 — Verification

    IT manager calls back. She didn’t run anything. She doesn’t recognise the scheduled task. Activity is not legitimate.

  6. 14:19 — Approve remediation

    Click approve on the scheduled-task remediation. The agent picks it up.

  7. 14:21 — Verify

    Portal shows the remediation applied. The scheduled task is gone from the endpoint’s task list. The associated binary remains at its path (the SOC didn’t recommend file remediation), but without the scheduled task firing it, it’s inert. Watch for re-detection. Five minutes pass. Nothing fires.

  8. 14:26 — Recovery checklist

    Remediations applied and verified: yes. No re-detection within the last hour: yes. SOC sign-off on release: standard remediation-complete state. IT manager has the user. PSA running entry is current. Five checks green.

  9. 14:27 — Un-isolate

    Click. Within a minute, the host is back online. Watch the portal for another five minutes. No new detections.

  10. 14:33 — Confirm with user

    Call the IT manager: “Her machine is back online. Full network access. Let me know if anything’s off.” IT manager confirms.

  11. 14:35 — Close in Huntress

    Resolution disposition set. Close.

  12. 14:37 — Close in PSA

    The PSA note is already current from the running entry. Final summary added; time entry of 28 minutes against Security-Incident-EDR-High. Close.

What made this High rather than Low

Three things, any one of which alone might land the incident in High:

  1. Active outbound to a known-bad domain. Not “suspicious-shaped activity”; documented attacker infrastructure.
  2. PowerShell with encoded commands. A common attacker technique.
  3. The host has elevated access to financial systems. Blast radius if the activity had time to spread.

A Low version of this incident might be PowerShell-flavoured activity on a sandbox-shaped endpoint with no outbound to known-bad. The SOC’s classification accounts for the actual risk, not just the surface pattern.

What changed from the Low walkthrough

  • Isolation in the Recommendation drove the isolate-first reflex.
  • User verification paired the remediation with a confirmation call.
  • The recovery checklist before un-isolation has no Low equivalent.
  • Longer documentation. More actions, more contacts, more verifications.
  • 28 minutes versus 11. Roughly three times as long, which is normal for a High with isolation.

The shape is the same: claim, review, action(s), verify, close in both systems, document. The six-step spine carried.

The customer pushes back after release — frame it cleanly

After un-isolation, the user calls back: “I’m back, but I missed a key part of my board prep. We should talk about whether this isolation thing was really necessary.” Don’t apologise for the isolation itself; the action was right. Acknowledge the timing hurt, name what the activity actually was (encoded PowerShell calling a known-bad domain), flag the impact to the account manager so they can talk with the customer about coordinating around high-priority days. Honest framing: the action was right; the timing was hard; here’s the path to talk about it.

Decision walkthrough

The user calls 90 seconds into the High — what do you say?
You just clicked Isolate. The portal confirms isolation active. Your phone rings — it's the assistant CFO, calling from her mobile, frustrated: "What did you just do to my machine? I'm in the middle of a board prep." Pick the response.
Mid-isolation, user calls frustrated. What do you say?
Loading quiz…
Next lesson