How do you find a known-clean recovery point after ransomware?

Why the latest backup is the wrong default

Ransomware groups rarely encrypt on the first day. They commonly operate inside a network for days or weeks first, moving laterally, creating accounts, disabling defenses and staging their payload. That window is called dwell time, and it means your most recent backups often already contain the compromise: encrypted or half-encrypted files, dormant malware, backdoor accounts, or altered configuration.

So the instinct to "just restore the newest backup" is exactly backward. Restoring the freshest point can re-detonate the attack or hand the intruder their foothold back. The point you want is the newest one that is still clean, and finding it is detective work, not a button.

The signals that narrow the search

You are looking for the boundary between "before the attacker" and "after." A few signals draw that line:

• Detection and first indicators. Work back from when you detected the attack to the earliest sign of intrusion. Clean points live before that first indicator, not before detection.
• Anomaly detection. Sudden spikes in change rate, mass file modifications, high-entropy writes that signal encryption, and unusual deletions all mark where damage began.
• Threat scanning. Scanning backup content for known malware and indicators of compromise rules candidate points in or out.
• Immutability window. Only copies that could not have been altered are trustworthy candidates. If a copy could have been tampered with, you cannot rely on it.
• Identity and configuration drift. New privileged accounts, changed group policy, or disabled logging in a backup are tells that it already captured the attacker.

How to actually pick one

1. Preserve everything firstStop backups from expiring or rotating. Extend retention and place a legal or compliance hold so you do not lose the very points you need while you investigate.
2. Build the timelineEstablish when the attack was detected and when the earliest indicators appeared. Your candidate points must predate the earliest indicator.
3. Shortlist from protected copiesDraw candidates only from immutable and air-gapped copies that predate the intrusion. These are the copies the attacker could not reach.
4. Scan the candidatesRun malware and anomaly analysis against each candidate point rather than trusting a date alone.
5. Validate in isolationRestore a candidate into an isolated recovery environment and confirm it is healthy, that services start, data is intact, and nothing is beaconing out.
6. Promote and documentOnce a point passes, make it your known-clean baseline, record why it qualified, and use it to drive the rest of the recovery.

What people get wrong

• Trusting the newest backup because it has the least data loss. Least data loss is worthless if the point is infected.
• Assuming immutable means clean. Immutability protects a copy from being changed. It says nothing about whether the copy was already compromised when it was made.
• Skipping isolated validation and restoring a candidate straight into production, which risks reinfection and destroys forensic evidence.
• Not preserving backups early, so the clean points age out or get overwritten during the incident.

How KELYN makes this operational

KELYN operationalizes clean-point selection on Commvault: immutable and air-gapped copies to keep the options alive, anomaly and threat indicators to narrow the search, and isolated recovery to validate a candidate before anyone trusts it. Crucially, KELYN rehearses this selection with you before an incident, so the first time you hunt for a clean point is not during the worst day of the year.

Sources

• Commvault Cyber Recovery Readiness research with GigaOm ↗