Reversible Response: Build Rollback Into Your Ransomware Plan

Containment is only half the job

Most ransomware plans are written around the first hour: detect it, isolate the machines, stop the spread. That work matters. But once the spread has stopped, the organisation still has encrypted endpoints, unavailable servers, and a business waiting to get back to work. How quickly and how completely you recover decides the real cost of the incident.

Why “re-image everything” plans stall

A common default is to wipe and rebuild every affected machine. It feels safe, and sometimes it's necessary. As the only plan, though, it has predictable problems:

• Downtime: rebuilding hundreds of endpoints takes days, and people can't work in the meantime.
• Lost local data: anything that lived only on the device and wasn't backed up is gone.
• Backlog: IT becomes the bottleneck just as the business is under the most pressure.
• Pressure to pay: the longer recovery takes, the more tempting the attacker's offer becomes.

The three layers of reversibility

1. Endpoint rollback. Where the endpoint platform keeps protected local snapshots, files and settings changed by the malicious process tree can be restored to their state before the attack began. For workstations this is usually the fastest route back.
2. Immutable, offline backups. Servers and shared data need backups that the attacker cannot reach, encrypt, or delete, even with domain administrator credentials. Immutability and separation from the production identity domain are what make them trustworthy.
3. Identity reset. Restored machines are only safe if the attacker's access is gone. That means rotating compromised passwords and keys, revoking active sessions and tokens, and reviewing any accounts or permissions the attacker created.

An example first-hour playbook

Every environment is different, and your timings will vary. As a starting template:

1. Isolate: network-isolate affected hosts and terminate the malicious process trees, so the attack stops spreading.
2. Lock identities: disable or reset the compromised accounts and revoke their sessions before the attacker can use them again.
3. Scope: build the attack storyline and establish patient zero, the entry point, and every host and identity touched.
4. Roll back endpoints: restore affected workstations to their pre-attack state and verify file integrity.
5. Restore servers: bring critical systems back from immutable backups, highest business priority first.
6. Watch for re-entry: keep heightened monitoring on the restored estate and the original entry point.

The order matters. Rolling machines back before you have scoped the intrusion and locked the compromised identities is a reliable way to get reinfected.

Test it before you need it

• Run restore drills on a regular schedule and time them from start to finish.
• Hold tabletop exercises that include leadership, legal, and communications, not only the security team.
• Check backup reachability from a compromised-admin point of view: could an attacker with domain credentials reach it?
• Record time-to-restore for your most critical systems and treat regressions as incidents in their own right.

Common mistakes to avoid

• Backups that are joined to the same domain the attacker has compromised.
• Restoring before scoping, which puts the attacker's foothold straight back into production.
• Forgetting to rotate credentials, tokens, and API keys after recovery.
• Plans that live in a document nobody has rehearsed.

Where the Cursor Platform fits

Reversible response is a core design principle of the Cursor Platform: isolate a host, kill the process tree, and roll the machine back to its pre-attack state from one console, alongside the storyline that tells you what to restore and in what order. The Cursor Complete guided tour walks through containment and rollback step by step.