Compromised-Session Incident Runbook (2026)

1Tell us where to send it
Your name and work email — nothing more.
2Check your inbox
Your guide arrives in seconds, not days.
3Use it with your team
Editable and ready to share — make it your own.

A peek inside

See exactly what you're getting

Free PDF

Spotsaas · 2026

Compromised-Session Incident Runbook

✓ When to invoke this runbook

✓ Incident response phases

✓ Containment decisions by scenario

✓ Evidence & notification checklist

Get the guide →

What it is

The Compromised-Session Incident Runbook is a step-by-step playbook for the moment you suspect a remote-access session has been hijacked, a credential has been stolen, or an external connection is doing something it shouldn't. It's built for the on-call responder who needs to act in minutes, not read theory, and it walks the full lifecycle — detect and triage, contain, eradicate, recover, and learn — with explicit guidance on what to kill first, how to preserve the session recording and logs as evidence before any cleanup, who to notify, and how to bring access back safely.

Each phase is concrete. Detect and triage confirms the signal is real (which session ID, identity, source, target), classifies severity by what the session can reach (production and privileged targets are P1), assigns an incident lead, and opens a timestamped log. Contain terminates the active session, disables the implicated identity and revokes its tokens everywhere, force-revokes its standing access to other systems, isolates the target host if compromised, blocks the source, and — critically — preserves the recording, logs, and host telemetry before any cleanup. Eradicate rotates the compromised credential and reachable secrets, hunts for persistence, reviews what the session touched, and scans the originating endpoint. Recover restores access only after rotation and posture re-verification, with step-up auth and tightened privilege. Learn runs a blameless review, names the control that should have caught it, and updates the runbook.

It includes a scenario quick-reference (hijacked privileged session, stolen credential with MFA bypassed, compromised vendor/jump host, rogue service/unattended session, EDR detection mid-session) mapping each to its first containment move and the evidence to grab, plus an evidence-and-notification checklist covering tamper-evident recording export, timeline reconstruction, stakeholder notification, legal/compliance engagement, and the breach-notification clock. It's designed to be kept where responders can reach it without a login — because the moment you need it, the systems may be exactly what you can't trust.

What it's used for

When a remote session goes bad, the cost is measured in minutes and in whether you preserved the evidence. The runbook is what turns panic into a sequence. It's used to:

✓ Respond to a suspected hijacked, hijacked-privileged, or anomalous remote-access session in minutes, with a defined order of operations rather than improvisation under pressure.
✓ Contain fast and correctly — terminate the session, disable the identity and revoke its tokens everywhere, force-revoke its other access, and isolate the target host — in the right sequence.
✓ Preserve the session recording, access logs, and host telemetry before any cleanup, so you have a real timeline instead of a guess after eradication.
✓ Work the specific scenario at hand using the quick-reference — stolen credential with MFA bypassed, compromised vendor/jump host, rogue unattended session, EDR detection mid-session — each with its first move and evidence list.
✓ Eradicate the foothold methodically: rotate credentials and reachable secrets, hunt for persistence (new accounts, SSH keys, scheduled tasks), and scan the originating endpoint.
✓ Recover safely — restoring access only after rotation and posture re-verification, with step-up auth and time-boxed privilege — and monitor closely for recurrence.
✓ Run a blameless post-incident review that names the control which should have caught it, fixes the root cause, and feeds improvements back into the runbook and the broader access program.

Who uses it

A compromised-session incident pulls in the responder, the system owner, and the people who must be notified. The runbook assigns each their part.

On-call / incident respondersThey're the primary audience — the runbook gives them the minutes-not-theory sequence of what to kill first and what evidence to grab before anything is cleaned up.

SOC analysts and security engineersThey detect and triage the signal, drive containment and eradication, and reconstruct the attacker timeline from the recording and logs.

Incident leads / IR managersThey own the timestamped incident log, classify severity, coordinate notification, and run the blameless post-incident review the runbook closes with.

IT and infrastructure ownersThey isolate and later restore affected hosts, rotate credentials and secrets in their domain, and re-verify posture before access comes back.

Legal, privacy, and compliance teamsThey're engaged when regulated data may be involved, assess the breach-notification clock and obligations, and the runbook prompts exactly when to bring them in.

Vendor / third-party managersWhen a vendor's access was the vector, they notify the vendor's security contact and cut the vendor access tier per the runbook's compromised-jump-host scenario.

Context & good to know

Every compromised remote session is, by definition, a failed control — posture, conditional access, recording, or expiry let something through. That framing matters because it shapes both the response (move fast, preserve evidence, contain blast radius) and the learning (name the gap, close it). The runbook is built for the reality that you'll be acting under uncertainty and time pressure, possibly on systems you can no longer fully trust, which is why it's meant to live somewhere responders can reach without logging into the very environment that's compromised.

Containment order is where responders most often go wrong, and where the runbook is most opinionated. The instinct is to clean up immediately; the correct first moves are to stop the bleeding (terminate the session, disable the identity, revoke tokens everywhere, isolate the host) and then preserve the evidence before any cleanup. If you rotate credentials and wipe the host before exporting the recording and logs, you've destroyed the timeline you need to understand what happened and to meet any breach-notification obligation. 'Contain, then preserve, then eradicate' is the sequence that keeps the evidence intact.

The session recording is the single most valuable artifact in a remote-access incident, which loops back to why recording is mandated upstream. Without it, you're reconstructing the attack blind — guessing at what an attacker did instead of watching it. Preserving the recording in tamper-evident storage before eradication is the difference between a defensible timeline and a guess, and it's the first thing both an auditor and a legal team will ask for. This is why the runbook treats evidence preservation as a containment step, not an afterthought.

Dwell time — how long between the first malicious action and detection — is the headline metric the post-incident review fixates on, because shrinking it is usually worth more than any single new control. And the recurring root cause is over-privilege: an over-privileged identity turns one hijacked session into a major incident, while least-privilege limits the blast radius when, not if, a session is compromised. The runbook's 'learn' phase deliberately asks which control should have caught it and whether the compromised identity had more access than it needed — feeding answers back into the zero-trust checklist, the posture policy, and the access reviews that prevent the next one.

✓ Independent · vendors can't pay to rank

Built on verified data, not vendor spin

Every Spotsaas resource draws on the Spotsaas Score — a blend of verified review ratings, review volume, and feature depth across 57 remote access software tools. Refreshed regularly; data as of June 2026.

FAQ

Questions, answered

What's the very first thing to do when I suspect a session is compromised?

Confirm the signal is real — identify the specific session ID, identity, source, and target host — then classify severity by what the session can reach (production and privileged targets are P1) and assign an incident lead with a timestamped log. The first containment action is to terminate the active session via your remote-access or PAM console, then disable the identity and revoke its tokens everywhere. Speed matters, but a misidentified target wastes the minutes that count.

Should I clean up the compromised host right away?

No — contain first, then preserve evidence, then eradicate. Terminate the session, disable the identity, and isolate the host, but export the session recording, access logs, and host telemetry before any cleanup. If you wipe or rotate before preserving, you destroy the timeline you need to understand the attack and to meet breach-notification obligations. Eradication (credential rotation, persistence hunting, endpoint scanning) comes after the evidence is safe.

Why is preserving the session recording so important?

Because it's your only reliable, detailed account of what the attacker actually did — without it you're reconstructing the incident blind. It's the first artifact an auditor or legal team requests, and the basis for the attacker-action timeline. The runbook treats exporting it to tamper-evident storage as a containment-phase step precisely so it survives the eradication that would otherwise overwrite or destroy it.

What if the attacker bypassed MFA with a stolen credential?

Treat it as a credential compromise, not just a session compromise. Revoke all sessions for the identity, force MFA re-enrollment, and rotate the credential and any secrets it could have reached. Collect auth logs, IdP sign-in logs, and device fingerprints as evidence. Then hunt for what else the credential touched in the window and check whether the same identity opened other sessions, because a bypassed-MFA credential is often used more than once.

How do I handle a compromised vendor or jump host?

Cut the vendor access tier immediately and isolate the jump host, then preserve jump-host logs, network flows, and recordings. Because a jump host is a shared pivot, assume blast radius beyond the single session — force-revoke the vendor's standing access to other systems and check what else transited the host. The runbook also has you notify the affected vendor's security contact, since their access was the vector.

When do I bring in legal and compliance?

As soon as regulated data (PII/PHI/PCI) may be involved. The runbook's evidence-and-notification checklist prompts you to engage legal, privacy, and compliance, assess the breach-notification clock and obligations under applicable regulation or contract, and notify stakeholders per policy. Engaging them early matters because notification deadlines can be tight and start running from discovery, not from when you finish the investigation.

How do I safely restore access after containment?

Only after the credential is rotated and the originating device's posture is re-verified. Bring isolated hosts back only once they're cleaned and confirmed clean, re-enable the identity with step-up authentication and tightened, time-boxed privilege, and monitor the restored accounts and host closely for recurrence. Restoring before rotation and posture re-check just hands the access back to the same attacker.

What should the post-incident review focus on?

Three things: dwell time (how long between first malicious action and detection — the headline metric), which control should have caught it and why it didn't (posture, conditional access, recording, or expiry), and whether the compromised identity had more access than it needed. The review is blameless, run within a week, and its output is concrete: revoke orphaned access, tighten policy, add the missing alert, and update the runbook with what was slow or unclear.

Where should this runbook live?

Somewhere responders can reach without logging into the environment that may be compromised — a printed copy, an out-of-band wiki, or a separate system. The moment you need it, the systems you'd normally use to find it may be exactly what you can't trust. Keep the owners and tooling references current so the on-call responder isn't paging the wrong person at 2am.

Keep exploring