Runbook: Endpoint Compromise

🔑 Key Takeaway: A compromised workstation is a credential incident, not a hardware incident. Contain the device, inventory what it could reach, revoke in the right order, and rebuild rather than clean.

This is an example runbook. Review and customize for your organization before use. Fill in your isolation procedure, credential inventory, and named approvers.

This runbook covers a contributor workstation (laptop or desktop, macOS/Windows/Linux) that is suspected or confirmed compromised: infostealer malware, a malicious dependency or fake job "test task", a trojanized meeting client, or hands-on access. Servers and mobile devices are out of scope, since server containment usually means snapshot and quarantine.

The person on the other end of this runbook is a colleague, and they may be frightened. Hand them Malware Infection for the victim-facing side of the same incident.

Quick Reference

Severity follows what the device could reach. Access is observable within the first twenty minutes and impact is not, so this table stands in for the impact bands defined in the Incident Response Policy.

Escalate a tier when any of these hold. The first two amount to holding a deployer key: a pipeline with no approval gate deploys on the attacker's behalf, and a threshold only delays execution once a trusted signer is proposing. The third turns one laptop into a campaign against users.

Until the inventory in Credential Revocation Order is complete, treat the incident at the higher tier. Severity gets set before anyone has finished listing what the user could reach.

This runbook stops at P3. The policy also defines P4 and P5, but their response times ("can be scheduled" and "no immediate action") do not fit a confirmed endpoint compromise, where a stolen session cookie stays valid until someone revokes it.

Identification

Symptoms

Extension and plugin installs deserve their own check: a malicious one reads every session the browser holds, and a repository can pressure the install through its own recommendations. See Integrated Development Environments.

If you have EDR: a single quarantined detection still triggers this runbook, since quarantine only proves the product caught one payload. Treat the signals below as confirmation, and remember that an unmanaged device produces none of them.

Differentiation

If a wallet drained but the device shows no sign of compromise, the user most likely signed a malicious approval. Use Key Compromise and the Drainer playbook instead. If several contributors are affected at once with no shared file or link, suspect the identity provider or the supply chain rather than a single endpoint.

Two of the lures above are documented campaigns. Both playbooks carry screenshots of the messages attackers sent, so you can put them in front of the user and ask whether theirs matched. A meeting link that resolved to an unfamiliar domain, or a fake recruiter task, matches North Korea (DPRK) Attack. A Zoom call where the caller asked for screen share or remote control matches ELUSIVE COMET. Naming the campaign tells you which follow-on accounts to check.

Immediate Actions

Step 1: Reach the User Out of Band

Why: Their chat, email, and phone accounts may already be in the attacker's hands.

If the user does not answer, keep going. Session revocation, identity provider lockout, and cloud access cuts all work without them, and the account is the urgent part. Leave a message with one instruction: leave the device alone.

If the user may be the threat actor (fake contributor, suspected DPRK IT worker, hostile departure): do not call them and do not reveal that you detected anything. Preserve access logs and device state, cut access quietly, and engage Legal before contact. See Mitigating DPRK IT Workers.

Step 2: Contain the Device

Why: Stop live session abuse and further exfiltration without destroying what you need to scope the incident.

Pick the one row that matches your capability:

Powering off destroys running processes, injected code, and secrets decrypted in memory, which is the evidence that tells you what actually ran and therefore what must be rotated. It also stops an active thief. Choose speed when nobody is positioned to capture memory: a machine left running on a desk "for forensics" that nobody ever images is the worst of both options.

Expect the first row often, since Malware Infection tells the affected person to power off immediately. Booting the device only runs the persistence again, so that case proceeds from the credential side.

Step 3: Scope What the Device Could Reach

Why: Severity, revocation order, and blast radius all depend on this list, and nobody recalls it reliably under pressure.

If you have endpoint management: pull the installed application list, the extension inventory, and recent process history instead of relying on the user's memory.

Credential Revocation Order

Why order matters: the usual failures are sequencing errors. Rotating an SSH key before killing the attacker's live session lets them add the new key themselves. Changing a password before revoking sessions leaves the stolen cookie valid. Re-enrolling 2FA from a cloud backup restores the stolen seed.

Work top to bottom. Each row links to whoever owns the procedure.

Investigation

Key Questions

Evidence to Collect

Collect in order of volatility, following NIST SP 800-86. The top rows vanish on their own; the rest wait for you. If the device is still running, memory outranks everything.

Rows 1 and 2 are why Step 2 forks on memory capture. Rows 4 through 6 depend on retention windows set long before the incident. See Forensic Readiness for chain of custody and retention design, which only helps if it is already in place when the incident starts.

If the same lure reached other contributors, treat that wider exposure as its own incident and send the team the specific indicators to look for.

If the investigation shows the lure arrived but was never executed, and no credential exposure is confirmed, downgrade the incident and close it. Record what ruled execution out in the Incident Log. A P1 that nobody closes buries the next real one.

Recovery and Prevention

Rebuild, Do Not Clean

Finish identifying every foothold before you start removing any of them. Rebuilding the laptop while an OAuth grant, mail rule, or deploy key survives moves the attacker off the device and leaves them in the accounts, and the rebuild destroys the evidence that would have found them.

Wipe and rebuild, or replace the hardware. Do not restore the user profile from a backup taken after the compromise window opened, and do not accept "the antivirus removed it" as an outcome. You cannot prove an infostealer is gone, and the cost of being wrong is handing back signing authority.

Return-to-Service Gate

Privileged access returns only when a named approver confirms all of the following:

Prevention

Device tiers belong to Endpoint Security: signers and production admins on managed hardware, contractors on VDI, everyone else behind a managed browser.

Closing the Incident

The rebuild is the midpoint. NIST SP 800-61r3 treats improvement as a standing function rather than a meeting held once the noise dies down, so the work below closes the runbook. Lessons Learned carries the review questions and the blameless format.

Escalation

Legal owns external notification, but the clock starts at discovery and runs while you are still containing. Raise it early, while the timing is still yours to pick. For wording, cadence, and who speaks, use Communications and Communication Strategies.

Further reading

• Runbooks overview: how the runbooks in this section fit together
• Malware Infection: the victim-facing guide to hand the affected person
• Key Compromise: rotation procedures for signer and deployer keys
• Forensic Readiness: preserving evidence before you rebuild
• Endpoint Security: device tiers, EDR, and MDM that limit the blast radius
• Developer-targeted intrusions: how the lure reaches a contributor in the first place