A malware outbreak becomes an estate-wide incident when the response is slower than the spread, and the spread usually rides on credentials the malware has already harvested. This template gives [Organisation] a ready-to-adopt playbook for malware that is moving between endpoints and servers: worms, loaders dropping follow-on payloads, credential stealers and pre-ransomware tooling pushed over admin shares or remote management. It is written for security operations, endpoint, infrastructure and identity teams and the managers who approve disruptive containment. Encryption by ransomware has its own template, the Ransomware Playbook Template; use this one when you see spread before (or without) encryption, and hand over if encryption starts. Replace every [bracketed] placeholder and exercise it before you need it.
How to use this template
- Adopt, then tailor: copy sections 1 to 8 into your incident response plan alongside the Incident Response Plan Template, and fill in named owners, tools and network isolation methods.
- Decide isolation authority in advance: the single biggest delay in outbreaks is waiting for permission to isolate hosts or segments. Section 2 pre-authorises it.
- Assume credentials are in scope: most spreading malware moves with valid accounts (T1078) taken from memory or files. Section 5 treats credential and non-human identity (NHI) resets as part of eradication, not an afterthought.
- Use out-of-band channels: CISA's #StopRansomware Guide advises coordinating containment by phone or other out-of-band means so attackers do not learn they have been detected.
- Review annually and after every outbreak, EDR platform change or major network redesign. Owner: [Head of Security Operations].
1. Scope and triggers
1.1 This playbook applies to malicious code observed on more than one [Organisation] system, or on one system with evidence of propagation attempts, across Windows, Linux, macOS, virtualisation hosts and cloud workloads. Single-host detections already remediated by EDR stay with the [SOC runbook].
1.2 Propagation methods in scope.
| Spread method | ATT&CK | Typical signal | First containment lever |
|---|---|---|---|
| Exploiting a network service (for example SMB or RDP flaws) | T1210 Exploitation of Remote Services | Same exploit alert on many hosts within minutes; scanning on 445 or 3389 | Block the port between segments; patch or disable the service |
| Copying tools over admin shares | T1021.002 SMB/Windows Admin Shares; T1570 Lateral Tool Transfer | Writes to ADMIN$ or C$ followed by service creation (Event ID 7045) | Disable the account used; block workstation-to-workstation SMB |
| Remote execution via WMI or scheduled tasks | T1047 Windows Management Instrumentation; T1053.005 Scheduled Task | WmiPrvSE.exe spawning shells; Event ID 4698 task creation on many hosts | Disable the account; restrict remote WMI and task scheduling to admin tiers |
| Credential theft and reuse | T1003.001 LSASS Memory; T1078 Valid Accounts | LSASS access alerts, logons by one account to many hosts (Event ID 4624 type 3) | Reset and restrict the account; isolate the source host |
| Shared content and removable media | T1080 Taint Shared Content; T1091 Replication Through Removable Media | New executables or shortcut files on file shares; USB-originated execution | Make the share read-only; block removable media execution |
| Software deployment and management tools | T1072 Software Deployment Tools | Unexpected packages or scripts pushed from EDR, RMM or endpoint management consoles | Lock the console, revoke its admin sessions and API tokens |
1.3 Triggers: the same malware family or hash detected on [3] or more hosts within [60] minutes; any detection on a domain controller, hypervisor, backup server or management console; EDR tamper alerts or agents going silent in a cluster (T1685 Disable or Modify Tools); a threat intelligence or vendor notice that a worm is exploiting a service you expose; or a supplier reporting malware that has touched shared systems.
2. Roles and contacts
| Role | Named owner | Responsibilities |
|---|---|---|
| Incident Lead | [Security Operations Manager] | Declares the incident, sets severity, owns the decision log |
| Endpoint Lead | [EDR or Endpoint Engineering Lead] | Host isolation, blocking hashes and behaviours, sweeps, agent health |
| Network Lead | [Network Operations Lead] | Segment isolation, ACLs, firewall and DNS blocks |
| Identity Lead | [Directory or IAM Lead] | Account disablement, credential and NHI resets, Kerberos and cloud identity actions |
| Forensics Lead | [DFIR Lead or retained provider] | Evidence capture, malware analysis, scope and root cause |
| Business Owner | [Chief Operating Officer or delegate] | Approves shutdown of business services and recovery priorities |
| Communications and Legal | [Head of Communications], [General Counsel] | Staff and customer messages, regulators, insurer, law enforcement |
2.1 Pre-authorisation. The Incident Lead may isolate any host, and the Network Lead any network segment except [list of safety or revenue-critical segments], without further approval while a trigger in 1.3 is active. Isolation of the excluded segments needs the Business Owner, reachable within [15] minutes.
2.2 Record the 24/7 contacts for the EDR vendor, the incident response retainer, the cyber insurer and the national reporting point. Keep an offline copy and an out-of-band conference bridge. See the Incident Response Retainer Buyer's Guide.
3. Detection and triage
- Confirm and name it: pull the detection, hash, file path, parent process and command line. Check the hash and family against EDR intelligence and internal history. Avoid public sandboxes for samples that may hold [Organisation] data.
- Find patient zero and the vector: earliest detection time, first host, and how it arrived (email, download, exploited service, supplier tool, removable media).
- Map the spread: query EDR and the SIEM for the hash, file name, mutex, network indicators and the accounts seen on infected hosts. Look for service installs (Event ID 7045), scheduled tasks (4698), new local accounts (4720) and logons from infected hosts to others.
- Check the crown jewels: domain controllers, identity providers, hypervisors, backup servers, EDR and RMM consoles, CI/CD runners. Any hit here raises severity to Critical.
- Classify the payload (see the Malware Guide): worm, loader, stealer, remote access tool or wiper. A stealer means credential resets widen; a wiper or encryptor means handover to the Ransomware Playbook Template or the Wiper Malware Guide.
Decision point A: if spread is faster than the team can isolate individual hosts (for example new infections every few minutes), isolate the affected segment or VLAN at the switch or firewall rather than host by host.
Evidence to preserve: memory and disk images from patient zero and [2] or [3] representative hosts, before reimaging; the malware sample in a password-protected archive; EDR telemetry and timelines exported beyond normal retention; Windows Security, System, PowerShell Operational (4104) and Sysmon logs; firewall, proxy and DNS logs; and authentication logs from the directory and identity provider. Follow the Evidence Handling and Chain of Custody Guide and the Memory Forensics Guide.
4. Containment
- Isolate infected hosts with EDR network containment, which keeps the agent connected for investigation. Where EDR is missing or tampered with, disconnect at the switch port or disable Wi-Fi. Power off only when you cannot disconnect, because it destroys volatile memory evidence (CISA #StopRansomware Guide).
- Block the payload estate-wide: add hashes, certificates and behaviour rules to EDR in block mode, and push application control rules where you have them.
- Break the spread path: block workstation-to-workstation SMB (445), RDP (3389), WinRM (5985/5986) and RPC where not needed; block command-and-control domains and IPs at DNS and the proxy.
- Disable the accounts the malware is using, human and non-human, rather than only resetting them; a reset while the host is still infected may be captured again.
- Protect the recovery path: disconnect or lock backup systems and confirm immutable copies are intact. See the Backup Security and Immutable Backup Guide.
- Lock management planes (EDR, RMM, endpoint management, hypervisor consoles) to a named break-glass group with phishing-resistant MFA, and revoke their API tokens if any misuse is suspected.
Decision point B: isolating a business service versus keeping it running with heightened monitoring. The Business Owner decides on the Incident Lead's advice; the decision and its review time go in the log.
Decision point C: an exploited, unpatched internet-facing service goes offline or behind a block rule until patched.
5. Eradication
5.1 Remove the malware and its persistence. Use EDR remediation for well understood commodity malware on standard endpoints. Reimage from a known-good build any server, any host with signs of hands-on-keyboard activity, and any host where the persistence is not fully understood. CISA advises looking for both outside-in persistence (rogue accounts, remote access) and inside-out persistence (implants, admin tools such as PsExec).
5.2 Persistence checklist: services (T1543.003 Windows Service), scheduled tasks, Run keys, WMI subscriptions, new local or domain accounts, added SSH keys, cron entries, browser extensions, and RMM agents that were not deployed by IT.
5.3 Close the vector: patch the exploited service, remove the malicious email or package, and fix the control gap (macro policy, application control, EDR coverage).
5.4 Credential and NHI resets. Run these after the hosts are clean or isolated, in this order:
| Credential type | When to reset | Action |
|---|---|---|
| Accounts logged on to infected hosts | Always | Reset passwords, revoke sessions and refresh tokens, re-register MFA if a stealer was present |
| Local administrator accounts | Always for affected machines | Rotate through LAPS; see the LAPS Guide |
| Service accounts and scheduled task identities | If used on or from infected hosts | Rotate, update dependent services, move to gMSA where possible |
| API keys, tokens, SSH keys and certificates stored on hosts | If a stealer or file access was seen | Revoke and reissue from the secrets manager; check for use from unknown locations |
| Privileged domain accounts | If used on infected hosts or any domain controller is affected | Reset, and reset the krbtgt account twice, with replication time between resets |
| Cloud and SaaS identities synced from the directory | If sync servers or admin workstations were affected | Rotate sync and app credentials; review consent grants and new app registrations |
6. Recovery
- Restore in the priority order agreed by the Business Owner, starting with identity, DNS and core network services.
- Rebuild from standard images or infrastructure as code; restore data only from backups scanned for malware and taken before the earliest infection (NCSC advises scanning backups before restoring and connecting them only to known-clean devices).
- Reconnect hosts in stages to a recovery network, confirming the EDR agent is healthy and in block mode before each host rejoins.
- Remove temporary blocks in stages; keep payload and command-and-control blocks.
- Run heightened monitoring for [30] days: the hashes, accounts, persistence locations and network indicators from this incident, plus any logon by reset accounts from unusual hosts.
7. Communication and notification
| Audience | When | Owner | Content |
|---|---|---|---|
| Executives | Critical or High within [1] hour | Incident Lead | Scope, business impact, decisions needed |
| Staff | When isolation affects work | Communications Lead | What to do (and not do), how to report symptoms, no technical detail |
| Cyber insurer and retainer | Within policy deadlines, often [24] hours | Legal Counsel | Notice of incident, request for support |
| Data protection regulator | If personal data was accessed or lost, for example within 72 hours under UK and EU GDPR Art. 33 | Data Protection Officer | Nature of breach, likely consequences, measures taken |
| Sector or national authority | As NIS2, sector rules or contracts require | Legal Counsel | Incident notification in the required format |
| Law enforcement and national CERT | For criminal or significant incidents | Legal Counsel | Indicators, samples, timeline |
| Customers and suppliers | If their systems or data may be affected | Communications Lead | Facts, indicators they can check, contact point |
8. Post-incident review
8.1 Within [10] business days run a blameless review using the Post-Incident Review and Root Cause Analysis Template.
8.2 Ask: how did it arrive; why did it spread (flat network, shared local admin passwords, over-privileged service accounts); how long from first detection to isolation; did EDR cover every infected host; did pre-authorisation work; were any credentials missed in section 5.4.
8.3 Update detections and share indicators with CISA, the NCSC or your sector ISAC.
Implementation guidance
Containment options compared.
| Option | Strength | Trade-off | Use when |
|---|---|---|---|
| EDR host containment | Fast, precise, keeps telemetry | Needs a healthy agent; malware may tamper with it | Default for every infected host |
| Segment or VLAN isolation | Stops spread regardless of agent state | Disrupts every service in the segment | Spread is faster than host isolation |
| Port and protocol blocks | Breaks the spread path with less disruption | Malware may switch method | Spread method is known (for example SMB) |
| Account disablement | Stops credential-based spread | Breaks services that depend on the account | The malware uses a known account |
Rollout.
- Confirm EDR coverage across all hosts, including servers and Linux, and that agents report tamper attempts. See the EDR Guide.
- Pre-build isolation: EDR containment policies, firewall rule sets that block lateral protocols per segment, and a tested way to isolate each segment.
- Pre-stage evidence collection scripts and storage, and agree the retention period for EDR telemetry.
- Test with a tabletop, then a controlled drill using a harmless test file (such as the EICAR test file) to time detection-to-isolation. See the Tabletop Exercise Guide.
- Rollback: document how to release every containment action, and test release as well as isolation.
Small vs large organisations. A small organisation with a managed EDR service should agree in its contract that the provider may isolate hosts without waiting for a call back, and keep one offline contact sheet. A large organisation needs per-segment isolation runbooks, tiered admin accounts so one infected workstation cannot reach servers, and an identity team ready to run section 5.4 at scale.
Metrics. Time from first detection to first isolation; number of hosts infected after the first detection; percentage of hosts with healthy EDR in block mode; percentage of credentials in 5.4 rotated within [48] hours; reinfection count within 30 days; time to restore priority services.
Framework mapping.
| Framework | References |
|---|---|
| NIST SP 800-61 Rev. 3 and CSF 2.0 | DE.CM-09 monitoring of computing assets; DE.AE-02 event analysis; RS.AN-03 analysis; RS.MI-01 containment; RS.MI-02 eradication; RS.CO-02 notification; RC.RP-01 recovery execution; RC.RP-03 backup integrity |
| NIST SP 800-53 Rev. 5 | IR-4 Incident Handling; IR-6 Incident Reporting; SI-3 Malicious Code Protection; SI-4 System Monitoring; SC-7 Boundary Protection; CP-9 System Backup; CP-10 System Recovery and Reconstitution; IA-5 Authenticator Management |
| ISO/IEC 27001:2022 Annex A | A.5.24 to A.5.28 incident management and evidence; A.8.7 protection against malware; A.8.22 segregation of networks |
| CIS Controls v8.1 | Control 10 Malware Defenses; Control 17 Incident Response Management |
| MITRE ATT&CK v20 | T1210, T1021.002, T1570, T1047, T1053.005, T1003.001, T1078, T1080, T1091, T1072, T1543.003, T1685 |
Standards and references
- NIST: SP 800-61 Rev. 3 Incident Response Recommendations and Considerations for Cybersecurity Risk Management
- CISA: #StopRansomware Guide
- NCSC: Mitigating malware and ransomware attacks
- NIST: SP 800-53 Rev. 5 Security and Privacy Controls
- MITRE ATT&CK: T1570 Lateral Tool Transfer
- MITRE ATT&CK: T1210 Exploitation of Remote Services
Related NHI Mgmt Group resources: Ransomware Playbook Template · Malware Guide · EDR Guide · NIST SP 800-61 Incident Response Guide · Computer Worms Guide