This is a constructed example, not a real incident. A fictional analyst receives an EDR alert about an unusual command shell launched by a document viewer on a finance laptop. The walk through shows the decisions at each step, from triage to containment to the lessons that change a rule.
Minute zero: what does the alert say?
Our fictional company, Northfield Parts, has about 400 laptops with an EDR agent. At 14:12 an alert fires: a PDF viewer started a command shell, which started a script interpreter that reached out to an address the company had never contacted.
The alert is tagged with a technique name from MITRE ATT&CK, a knowledge base of adversary tactics and techniques based on real world observations. The tag tells the analyst the behaviour class, not whether it is malicious.
The analyst, Dana, asks three questions first. Who is the user? What is the device? Is anything about this expected?
Minute five: is it real?
Dana opens the process timeline. A downloaded invoice was opened at 14:10. The viewer launched a shell two seconds later. The shell ran a script with an encoded argument. Nothing in the company's change calendar explains it.
She checks the user's recent activity. The invoice came by email from an external sender. The sender's domain is new.
This is enough for a working conclusion: probably malicious, not yet proven. In NIST's incident response guidance, SP 800-61 Revision 3, detection and analysis feed response decisions inside a broader risk process. Dana does not need certainty to act, but she does need to pick an action that matches the risk.
Minute ten: contain or watch?
Two options. Watch the host to learn more, or isolate it now. The laptop belongs to a finance user with access to payment systems, so the cost of waiting is high and the cost of isolation is a user without a laptop for an hour.
Dana isolates the device from the network. The EDR console still reaches it, so she keeps the ability to collect evidence. She records the time, the reason and her name in the ticket.
A rule of thumb the team agreed earlier: isolation of a laptop needs no approval, isolation of a server needs the service owner.
Minute twenty: how far did it spread?
Isolating one host is not the end. Dana searches the fleet for the same script argument pattern and for connections to the same address. Two other laptops contacted it, neither ran the script. She checks the mail system: nine people received the message, three opened the attachment.
Notice the dependency. The EDR told her about endpoints. The email facts came from another system. A joined view, or at least a runbook with both consoles open, saves time here.
Hour one: what did it touch?
On the isolated laptop the timeline shows the script wrote a file to the user's profile and tried to read a browser credential store. Dana flags the user's saved sessions as possibly exposed and asks identity staff to revoke active sessions and require a new login.
She does not know yet whether credentials left the machine. She says so in the ticket instead of guessing.
Day one: eradicate and recover
The laptop is rebuilt from a clean image rather than cleaned by hand. The sender domain is blocked. The two laptops that contacted the address are scanned and cleared. The user resets passwords on a clean device.
Week one: what changes?
The review asks what slowed the response and what should be improved.
- The rule fired correctly. Keep it, and tag it with the technique name.
- The fleet search took too long. Save the query as a template.
- Email and endpoint data lived in separate places. Add the email lookup to the runbook.
- Document viewers could launch shells. Ask the endpoint team whether policy can block that behaviour.
What is unrealistic about this example?
Real incidents are messier. Timelines are less clean, evidence conflicts, and people disagree about isolation. Use the sketch to rehearse decisions, and replace the details with your own systems and names.
What to do
- Write the isolation rules per device class before an incident.
- Save fleet search queries for the common patterns you expect.
- Put the email, identity and endpoint checks in one runbook.
- Record every action, with time, reason and name, in the ticket.
- After each incident, change one rule, one query or one policy.
- Rehearse a constructed scenario like this one each quarter.
Safeguard focuses on the application and software supply chain side and does not replace EDR.
Quick check
Should an analyst isolate a device before being sure it is malicious?
Often yes, when the user has sensitive access and the cost of isolation is low. Agree the rule in advance, keep evidence collection possible and record the reason.
Is this a real incident?
No. It is a constructed example. The company, people and events are fictional and exist only to show the decision flow.
Sources
Last reviewed: 18 October 2026.
