# Playbook: Malware on an Endpoint ## Summary This playbook structures the response to malware on a single endpoint or a few endpoints: workstations, laptops and servers. Typical cases are infostealers, remote access trojans (RATs), loaders, backdoors, crypto miners and unwanted remote access tools. "EDR deleted it" does not answer whether the malware had already stolen credentials, downloaded further tools or spread. The core of this playbook: **The question is not whether the file is gone, but what it did before.** ## Purpose - Classify malware findings quickly: false positive, blocked or executed - Contain the endpoint without destroying the evidence - Determine the malware's capabilities and impact - Invalidate stolen credentials and sessions - Find further affected systems - Restore the endpoint to a trustworthy state ## Scope Use this playbook if: - EDR or antivirus reports malware that was **executed** - a user ran a suspicious file, macro, script or installer - an endpoint connects to known command-and-control servers - unknown remote access software was installed without authorization - infostealer logs with data from your organization appear - an endpoint shows crypto mining, unusual load or unexplained processes **Boundaries:** - With encryption, mass spread or domain admin misuse, the ransomware playbook takes the lead. - If delivered by email, the phishing playbook runs in parallel. - An attachment blocked at download without execution is an event, not an incident: document it, block the IOC, check the recipients. ## Severity - **Medium:** Brief execution without recognizable credential or persistence capability, single standard endpoint, no follow-on activity - **High:** Executed infostealer, RAT, keylogger, loader, unknown remote access software, or an affected server or admin workstation - **Critical:** Lateral movement, credential dumping, domain rights, ransomware preparation or multiple affected systems The incident lead documents the severity with time, justification and approval to move to the next phase. ## Incident Objectives 1. Establish whether the malware was executed. 2. Isolate the endpoint without destroying evidence. 3. Determine family, capabilities and persistence. 4. Invalidate stolen credentials and sessions. 5. Find further affected endpoints. 6. Restore the endpoint cleanly. ## Core Response Principles - **Executed is executed.** Once code ran, a quarantine message does not close the case. - **Isolate, do not power off.** EDR network isolation keeps memory and running processes; powering off destroys them. - **Capabilities determine the approach.** A miner calls for different steps than an infostealer or a RAT. - **An infostealer is an identity incident.** Stolen browser sessions can bypass MFA; a password reset alone is not enough. - **Reimaging is the norm.** Cleaning only when capabilities and persistence are fully understood. - **Record time consistently.** Document the timeline, forensic artifacts and log exports in UTC; note local time zone differences. - **A finding rarely comes alone.** Search for further systems by hash, domain, file path and behavior. ## Contacts and Escalation Pre-fill these for your organization and keep them available offline: - Incident lead on call - SOC / detection engineering - Endpoint administration - IAM / Entra ID / AD / SSO owners - Helpdesk for password and device replacement - External forensics / incident response - Communications and management escalation ## First 15 Minutes - Name an incident lead, start the timeline and decision log. - Read the alert: was the file **executed** or only detected? Which process, which user, what time and which parent processes? - If executed: isolate the endpoint via EDR. Without EDR: pull the network cable or disconnect Wi-Fi, leave the device powered on. - Ask the user briefly: what was opened, where did it come from, what happened afterwards? - Record hash, file name, path, origin and first IOC data. - Search for further hits by hash and origin in EDR, mail gateway, proxy and DNS. - If an infostealer or RAT is possible, bring in the identity owners immediately. - Start evidence preservation before any cleanup begins. ## Roles and Responsibilities ### Incident lead - Steers the response and classifies the incident. - Prioritizes reimaging or cleaning. - Documents handovers to other playbooks and confirms exit criteria. ### SOC / analysis - Evaluates the alert, process tree and telemetry. - Determines family and capabilities. - Searches for further hits and follow-on activity. ### Endpoint and client administration - Isolates devices. - Preserves artifacts. - Reimages systems and provides replacement devices. ### Identity and access - Revokes sessions. - Rotates passwords, tokens, keys and certificates. - Reviews sign-in activity and privileged use. ### User, line manager and helpdesk - Provide context. - Support communication measures. - Restore the ability to work. ## Decision Model ### Rule 1: Was the malware executed? **Not executed** if the file was blocked on write or download and no process execution is visible: - Document the event - Block the hash, sender and URL - Search for further recipients - Document the closure **Executed** if a process started, a script ran, a macro was enabled or network connections of the process are visible — even if EDR terminated the process afterwards. **Unclear:** Treat as executed until the opposite is established. ### Rule 2: Reimage or clean? **Reimage** if: - a RAT, loader, backdoor or unknown malware is involved - persistence was found or cannot be ruled out - administrator rights on the device were obtained - security software was tampered with - a server or admin workstation is affected **Cleaning** is only justifiable for well-documented, low-risk malware with fully known persistence and no download capability — and only with a subsequent EDR follow-up check. ### Rule 3: Which credentials are affected? With infostealers, RATs and keyloggers, the following are generally considered compromised: - passwords stored in the browser - browser sessions and cookies - password manager contents, if the vault was unlocked - stored credentials for VPN, RDP, FTP, messengers and other clients - credentials entered while the malware was running - SSH keys, API tokens and cloud credentials in files or environment variables Change passwords only from a **clean device**. Revoke sessions, rotate tokens and keys, check MFA methods. ### Rule 4: When to hand over to other playbooks? - **Ransomware playbook in the lead** if encryption, mass spread, or compromise of domain, backup or hypervisor systems is visible. - **Identity compromise in parallel** if sessions, tokens, MFA bypass or privileged accounts may be affected. - **Data breach in parallel** if exfiltration of personal data is likely. ## Typical Malware Categories | Category | Main risk | Most important step besides isolation | |---|---|---| | Infostealer | Theft of passwords and sessions | Revoke sessions, change passwords, rotate tokens | | RAT / backdoor | Remote control by the attacker | Reconstruct activity, search for spread, reimage | | Loader | Downloading further malware | Find downloaded components, check network connections | | Unwanted remote access tool | Direct attacker access | Check the tool's sessions, block the tool organization-wide | | Crypto miner | Resource abuse, often a sign of a vulnerability | Find the entry path, often a vulnerable service | | Adware / PUP | Low risk | Clean up, clarify origin | ## Special Case: Credentials in Infostealer Logs If infostealer logs relating to your organization appear externally or are reported through threat intelligence: - Document source, date, scope and validity. - Identify the associated users, hosts, browser profiles and services. - Have passwords changed only from clean devices. - Revoke sessions, refresh tokens, OAuth consents and app passwords. - Prioritize cloud admin portals, email, VPN, code repositories, password managers and finance systems. - Tell users clearly which private and business accounts may be affected. ## Artifacts for Initial Triage Before reimaging or cleaning, preserve where possible: - EDR alert ID, rule name, severity and the full process tree - Process command line, parent/child processes and user context - Hashes, file name, download URL, referrer, mail metadata or USB origin - Active network connections, DNS queries, proxy destinations and TLS SNI, where available - Persistence mechanisms: scheduled tasks, services, registry run keys, WMI, browser extensions and startup items - List of local administrators and recent changes - Relevant security and operating system logs - Memory image or volatile artifacts, where practical and forensically useful ## Credential Rotation Matrix | Affected context | Minimum action | |---|---| | Standard user | Reset password, revoke sessions, check MFA | | Privileged account | Immediate rotation, session and token revocation, review roles and use | | Developer device | Rotate API tokens, cloud credentials, SSH keys, package registry tokens and CI/CD secrets | | Admin workstation | Start the identity playbook in parallel, review lateral movement and admin activity | | Password manager unlocked | Rotate all prioritized reachable credentials | ## Phase 1: Detect and Triage ### Objectives - Clarify execution, capabilities and initial reach. - Preserve evidence before reimaging or automatic cleanup destroys it. ### Actions - Assess user context, process tree, network communication and origin. - Preserve file system, memory and persistence artifacts. - Search for further devices, users and hits with IOCs. - Set the triage classification: blocked, executed, credential risk or follow-on activity. ### Exit criteria - Preliminary classification documented. - Essential triage artifacts preserved. - Search for further hits running. ## Phase 2: Contain ### Objectives - Stop further communication and spread. - Contain misuse of affected credentials. ### Actions - Isolate the device and keep it isolated. - Revoke sessions and handle accounts according to the credential rotation matrix. - Block known C2 destinations, hashes, file paths and tools. - With multiple hits, examine a spread or campaign hypothesis. - Provide a replacement device so there is no pressure to keep using the affected one. ### Exit criteria - Affected endpoint isolated or out of service. - First identity measures implemented. - Further at-risk systems identified or the search widened. ## Phase 3: Investigate ### Objectives - Determine family, capabilities, persistence and possible follow-on activity. ### Actions - Assess the malware family, TTPs and download behavior. - Investigate persistence, privilege escalation and credential access. - Check for lateral movement, cloud sign-ins, email access and further sessions. - For RATs, reconstruct attacker actions, commands, file access and possible exfiltration. ### Exit criteria - A plausible picture of capabilities and effects documented. - Decision on reimaging or cleaning confirmed. - Handover to related playbooks completed where required. ## Phase 4: Eradicate ### Objectives - Completely remove the malware and its persistence. - Clean up affected credentials and systems. ### Actions - Default: reimage from a trusted source. - Restore only from verified backups or golden images. - Do not carry over executables, scripts or macro documents from the user's backup without checking them. - Remove unwanted remote access tools, persistence and helper tools. - Document rotated accounts, tokens, keys and certificates. - Close the entry path: mail filter, macro policy, application control, patch or browser hardening. ### Exit criteria - Endpoint reimaged or verified clean. - Persistence removed. - Relevant credential measures completed or scheduled. - Entry path closed. ## Phase 5: Recover ### Objectives - Restore the ability to work in a controlled way. - Detect recurrence early. ### Actions - Provide a replacement device or a freshly built device. - Monitor browser sessions, SSO sign-ins and privileged activity closely for 14 to 30 days, depending on severity. - Brief the user specifically: password changes, suspicious follow-up requests and handling private accounts. ### Exit criteria - User able to work. - Monitoring without new anomalies. - Residual risks documented and accepted. ## Phase 6: Review ### Actions - Analyze the entry path: mail, download, macro, script, remote access tool or browser exploit. - Update detection rules, blocklists and hardening measures. - Check whether training, application control (allowlisting), browser hardening or removing local admin rights would have prevented the incident. - Hold the review within ten business days. ## Evidence to Preserve - Alert data, screenshots, EDR exports, rule and telemetry data - Process trees, hashes, network communication and relevant logs - Forensic images or selected artifacts with hash values - Sign-in and audit logs of affected accounts - Timeline, decision log and the rotations performed ## Proof and Retention - Store evidence in an access-controlled incident repository. - Document hash values, export time, the person performing the export and the source. - Set the retention period according to internal policy, regulation and possible legal proceedings. ## Communication Checklist - Inform the user and line manager briefly, factually and with clear actions. - Prepare the helpdesk for password and device replacement. - Do not give the all-clear while credential risks have not been assessed. - Involve legal and data protection if data may have been exfiltrated. ### Template: notice to affected users > Malware was found on your device that can read stored passwords and sign-ins. We have already secured your work accounts. Please also change the passwords of private accounts that you used on this device or stored in the browser — only from another, secure device. Please stop using the affected device. You will receive your replacement device via [channel]. The affected person is an important source of information here, not the cause of the problem. Ask specifically and without blame: What was opened? Where did the file come from? Which sign-ins or unusual windows appeared afterwards? This often provides usable context faster than a long technical first search. ## Legal and Regulatory Considerations Guidance, not legal advice (as of October 2026). Whether an obligation applies depends on the country, sector, size and role of the organization. Deadlines, reporting channels and contacts should be set in advance and confirmed with legal and data protection when an incident happens. **Reporting obligations for cybersecurity incidents** - **Germany — NIS2 (§ 32 BSIG, since 6 December 2025):** Particularly important and important entities report significant security incidents to the BSI: early warning within 24 hours, notification within 72 hours, final report within one month. - **Austria — NISG 2026 (since 1 October 2026):** Essential and important entities report significant security incidents to the competent CSIRT: early warning within 24 hours, notification within 72 hours. - **Switzerland — Information Security Act (ISA, since 1 April 2025):** Operators of critical infrastructure report cyberattacks to the Federal Office for Cybersecurity (NCSC/BACS) within 24 hours. **Data protection** - **Germany and Austria — GDPR Art. 33/34:** Report personal data breaches to the supervisory authority within 72 hours of becoming aware, unless the breach is unlikely to result in a risk to the individuals; if the risk is high, notify the individuals as well. - **Switzerland — FADP Art. 24:** Report to the FDPIC as soon as possible if the breach is likely to result in a high risk for the individuals. All deadlines run from awareness of the incident, not from the end of the technical investigation. An incomplete early warning within the deadline is better than a complete report after it. **For this scenario** - A single endpoint without spread is usually not a significant incident under NIS2 or the ISA. If servers or several systems are affected, or ransomware preparation is suspected, reassess significance. - Infostealers and RATs can capture personal data: mailboxes, files, customer data, credentials. In that case the data protection reporting obligations above apply. - Analyze browser history and private data on work devices only to the extent required; involve data protection and employee representatives according to internal agreements. ## Quick Response Checklist - [ ] Executed or only detected? - [ ] Endpoint isolated, not powered off - [ ] Hash, origin, time and user recorded - [ ] Searched for further hits - [ ] Family or category determined - [ ] Credentials and sessions handled where theft is possible - [ ] Indicators blocked - [ ] Signs of a larger attack checked - [ ] Device reimaged or demonstrably cleaned - [ ] Entry path closed - [ ] Monitoring set up ## Preventive Controls - EDR with isolation capability on all endpoints and servers - No local admin rights for standard users - Macros from the internet blocked, script execution restricted - Application control or allowlisting, at least for servers and admin workstations - Replace browser password storage with a managed password manager - Block unwanted remote access tools by policy - Use DNS filtering, proxy, conditional access and phishing-resistant MFA ## At a Glance This block is not a shortened replacement playbook. It is a quick way in; all sections of this document apply when handling the incident. **Malware on an Endpoint** Response to executed malware — from isolating without losing evidence and invalidating stolen credentials and sessions to searching for further systems and reimaging cleanly. **Core phases:** Detect, Contain, Investigate, Eradicate, Recover, Review. ## References - NIST SP 800-61 Rev. 3 - NIST SP 800-83 Rev. 1 - MITRE ATT&CK: T1204, T1555, T1539, T1219 - BSI IT-Grundschutz: DER.2.1 ## Disclaimer This playbook is a practical community resource. It does not replace legal advice, forensic expertise or organization-specific incident response planning.