EDR Incident Response Scenario: From Alert to Recovery
This hypothetical EDR incident scenario shows the decisions, evidence, and responsibilities involved when suspicious endpoint activity may be ransomware.
This hypothetical exercise follows a small business from an EDR alert through investigation, containment, recovery, and review. It is not a Quantm customer case study, and it does not claim a measured outcome. Use it to test decisions and responsibilities in your own incident plan.
For the underlying capability, read what EDR is and how it works.
Scenario setup
A finance employee opens an attachment that appears to be related to an expected payment. Soon afterward, the endpoint platform detects a document application launching a script interpreter, followed by unusual credential access and rapid file changes.
The organization has endpoint agents on workstations and servers, protected backups, an external managed security provider, and an internal incident lead. The provider can isolate workstations under defined conditions but needs customer approval before isolating a production server.
Exercise roles and preparation
Assign a facilitator who controls the scenario, a recorder who captures decisions and times, participants who perform their real roles, and observers who do not solve the scenario for the team. Include IT, security or the managed provider, identity, application and backup owners, leadership, privacy or legal contacts as appropriate, communications, and a business representative.
Before the session, give participants the incident plan, contact list, asset and application ownership, response-authority matrix, backup procedure, insurance contact path, and relevant provider terms. Do not reveal every inject. State that the scenario is fictional and no production containment action should be taken without the normal authorization.
Set three objectives: validate the endpoint-to-incident escalation, test workstation and server containment decisions, and prove the handoff to identity, recovery, privacy, and communications owners.
Decision timeline
| Stage | Available evidence | Decision and owner |
|---|---|---|
| Detection | Process tree, user, device, file, command, and time | Provider analyst validates the alert and checks related endpoint activity |
| Scope | Similar indicators, identity activity, network connections, reporting status | Incident lead decides whether to open a wider incident and engage other teams |
| Containment | Affected device, business role, active connections, approved authority | Provider isolates the workstation and records the action |
| Investigation | File origin, script behaviour, credential use, persistence, lateral movement | Joint team determines affected accounts and systems |
| Eradication | Malicious files, persistence, exposed credentials, vulnerable path | Technical owners remove artifacts, reset affected credentials, and close the entry path |
| Recovery | Clean state, backup integrity, application tests, monitoring plan | Business and technical owners approve restoration |
| Review | Timeline, decisions, gaps, costs, communications, retained evidence | Incident lead assigns improvements and tracks them to completion |
Timed injects for a 90-minute tabletop
| Exercise time | Inject | Evidence supplied | Decision to observe |
|---|---|---|---|
| 0 minutes | High-severity endpoint alert on finance laptop | Process tree, user, device, command, destination, and file changes | Who validates, who is contacted, and whether authority is clear |
| 15 minutes | User says the attachment appeared expected | Email subject, sender display name, and user account | Does the team preserve evidence and investigate rather than accept appearance? |
| 30 minutes | Same account signed in from an unfamiliar location | Identity event and session time | Who revokes sessions, resets access, and checks other applications? |
| 45 minutes | Similar command appears on a production file server | Server owner, process event, and current business use | Who can isolate or choose another containment action? |
| 60 minutes | Endpoint sensor on another device stops reporting | Last check-in and inventory record | Is health loss treated as an incident clue and who restores coverage? |
| 70 minutes | A manager asks when systems and files will be available | Backup status and application dependencies | Who gives a qualified recovery estimate and approves restoration? |
| 80 minutes | A customer asks whether its data was affected | Known evidence and remaining uncertainty | Who owns privacy, legal, contractual, and communication assessment? |
Adjust timing to the team. The facilitator should advance when the decision is clear or the gap has been observed, not wait for perfect technical analysis.
Detection and first assessment
The analyst should not rely on the alert title alone. They review the process tree, command line, file path, user, device importance, related detections, and recent identity activity. They also check whether the endpoint is still reporting and whether similar activity appears elsewhere.
The first question is not “Is this definitely ransomware?” It is “What evidence do we have, what could happen next, and which safe action is authorized now?”
The recorder should capture the time, decision, owner, evidence used, missing information, action, and next checkpoint. This reveals whether the team can act under uncertainty without inventing facts.
Containment without losing business context
The workstation is isolated because the behaviour matches the documented trigger and the provider has authority. The user is contacted through a separate channel and asked not to reconnect the device.
The team avoids immediately wiping it. Investigation evidence may be needed to understand entry, scope, credential exposure, and persistence. If a production server shows related activity, the incident lead weighs service impact against the risk of continued attacker access and uses the approval path established before the incident.
Observers should note whether the team distinguishes device isolation from account containment, network segmentation, application shutdown, and business closure. They should also record whether a provider recommendation reaches someone with authority and whether a failed contact has a working fallback.
The EDR and ransomware protection guide explains where endpoint containment helps and why backups and identity controls still matter.
Eradication and recovery
The team removes confirmed malicious artifacts, closes the initial path, resets affected credentials, and checks for persistence or movement to other systems. Recovery uses known-clean systems or validated backups, followed by application tests and additional monitoring.
EDR can supply endpoint evidence and response controls. It does not make recovery decisions, verify every backup, or manage business communications. Those responsibilities remain part of the incident plan.
Recovery evidence should include a known-clean build or restore source, affected credential treatment, application-owner testing, security validation, monitoring plan, business acceptance, and a record of systems still excluded. The exercise does not need to perform a real restore, but the backup owner should be able to show the latest representative restore test and dependencies.
Artifacts participants should produce
- Initial incident record with severity, scope, owner, and timestamps.
- Combined endpoint, identity, email, network, and server timeline.
- Containment decision and response-action audit.
- List of affected, suspected, cleared, and unknown assets.
- Communication and escalation log.
- Recovery decision with technical and business approval.
- Evidence-preservation list and access location.
- Corrective-action register with owners and dates.
What the exercise should test
- Can the team find the device and owner quickly?
- Does the provider have the expected response authority?
- What happens when an approver is unavailable?
- Can identity, email, network, and endpoint evidence be correlated?
- Who decides whether legal, privacy, insurance, or law enforcement support is needed?
- Are protected backups available and restoration steps tested?
- Which evidence must be preserved?
- How are employees, customers, and leadership updated?
CISA's incident response resources and ransomware guide provide public guidance for preparing and responding. Public post-incident reports, including the HSE Conti cyber-attack report, also show why governance, system knowledge, and practiced response matter.
After-action review template
Within a defined period after the exercise, hold a review that asks what was expected, what happened, why it differed, what risk remains, and what will change. Separate observed facts from assumptions.
For each finding, record category, evidence, impact, root cause, corrective action, owner, target date, priority, dependency, and closure evidence. Retest critical gaps such as unreachable contacts, failed alert routing, uncertain server authority, missing inventory, or unproven recovery. Close an action only when the evidence shows the change works.
Use EDR deployment best practices to turn exercise gaps into coverage, testing, and ownership improvements.
Want to run an endpoint incident tabletop for your team? Talk to Quantm.