The pressure during a ransomware recovery pushes toward the most recent restore point, because it costs the least data. That restore point was taken while the attacker already had access. Restoring it returns the environment to the state it held shortly before encryption, including the accounts, scheduled tasks and remote access the intrusion depended on. Choosing a recovery point is a security decision before it is a data loss decision.
The opposite error is just as expensive. Going back three months to feel safe discards a quarter of transactions, which in many organizations does more lasting damage than the incident. The work is to find the latest point that is genuinely clean, which means narrowing a window rather than picking a date, and proving the candidate before production depends on it.
Why the newest restore point is the wrong default
Encryption is the last step of an intrusion, not the first. Before it happens an attacker typically spends days or weeks obtaining credentials, moving between hosts, establishing persistence and locating the backup system. Every backup taken in that period captures the environment faithfully, including the modified service, the new local administrator and the scheduled task nobody inspects.
A restore from that period brings all of it back, into an environment where monitoring has been disrupted and the team is working long hours. Reinfection after recovery is rarely a second intrusion. It is the same one, restored by the people trying to remove it.
The decision is also made once for a set of systems rather than per machine. Restoring a domain controller from one date and the application servers from another produces authentication and database states that do not match, so the recovery point becomes a single line in time across the affected estate.
Establishing a dwell time window
The window has two edges and they are found in different places. The late edge is the first confirmed malicious action: the earliest event that is unambiguously attacker activity, often a ransom note timestamp, a mass file rename, or the disabling of a security tool. That edge is usually easy to fix within an hour or two.
The early edge is the difficult one. It is the earliest point at which initial access plausibly occurred, and it is established from authentication logs, remote access and VPN records, firewall and proxy history, and endpoint telemetry. The practical obstacle is retention. Endpoint tools commonly keep a few weeks, firewall logs roll over by volume rather than by date, and the systems holding them may be part of the incident. When the logs stop before the intrusion does, the early edge is unknown before that date, which is not the same as clean.
That distinction changes what the backup retention policy has to be. If the plausible dwell time exceeds the period for which restore points still exist, the choice has already been made by the expiry of the lock rather than by anyone in the room. Retention length and log retention should be set with reference to each other, since a restore point without evidence of its condition is only marginally more useful than no restore point.
Evidence that narrows the window
Once both edges exist, the candidates between them are ranked using evidence from two vantage points. Indicators inside the data describe what a file or configuration looks like. Indicators from the backup system describe how the data behaved over time, measured from outside the guest. They frequently disagree.
| Indicator | What it dates | Why it can mislead |
|---|---|---|
| File modification timestamps | When a file was last written | Timestamps are writable by any process, including the one that altered the file |
| Backup change rate per job | When large volumes of data began changing | Database maintenance, migrations and patch cycles produce a similar shape |
| New services and scheduled tasks | When persistence was established | Legitimate agents install the same way, and creation dates can be altered |
| Authentication records for service accounts | When a credential began being used from a new source | Retention often ends before the intrusion started |
| Dismissed antivirus or endpoint alerts | When a tool first reacted to something | The detection is later than the presence it detected |
| Deduplication ratio and backup size shifts | When stored data stopped compressing as before | New workloads or a settings change produce the same movement |
The disagreement is structural. Everything inside the guest was authored by software running on a host the attacker controlled, so timestamps, event logs and file contents are all subject to editing. The backup system observes from outside and records properties nobody intended to write: job duration, change rate, deduplication behavior. Those are harder to forge and much noisier, since ordinary operations move them too.
The usable rule is directional. Backup side signals select candidates, since they mark the dates on which the environment changed character. File level inspection confirms or rejects a specific candidate, since it can find the artifact itself. Running it the other way around, trusting guest timestamps to pick a date and then skipping inspection, is how a compromised point reaches production.
Staging a candidate before committing to it
A candidate restore point is inspected in an environment that has no route to production, no trust relationship with the directory, and credentials that exist nowhere else. That environment is the same one a recovery drill with production unavailable requires, which is an argument for building it before it is needed rather than during an incident.
Inspection covers three questions in order. Does the system boot and the application start, since a clean but unusable restore point is not a recovery point. Is the known indicator absent, meaning the specific task, account or configuration change found during the investigation. Does a scan with current signatures, run from outside the guest where possible, find anything further.
Candidates are then worked in one direction. Start comfortably before the late edge, confirm that point, and move forward toward the most recent clean one, rather than starting at the newest and working back. Each iteration costs restore time and capacity, so the number of candidates that can be held at once is a planning figure worth knowing in advance. It also assumes a console that was inside the blast radius is not the only thing asserting which restore points exist.
Where ARTESCA fits
ARTESCA is object storage software used as a backup target, presenting an S3 compatible API and supporting immutability through S3 Object Lock. Restore points written to it stay individually addressable for the length of their retention, so several candidates can be read and evaluated in parallel without being consumed by the act of examining them.
Object Lock matters for this process in a specific way. While candidates are being inspected, the restore points under evaluation cannot be deleted or overwritten by the backup client, including one operating under an attacker's control. The length of retention set on those objects determines how far back the selection can reach, which makes the retention figure a direct input into the window described above rather than a storage setting.
Because ARTESCA runs on infrastructure the customer operates, the isolated inspection environment can be given a controlled network path and a separate read capable account on the storage, defined on the platform rather than in the backup application.
What to decide before the day
Record the retention period of every log source that would establish an early edge, alongside the retention of each backup repository, on a single page. Comparing them usually shows that one was set without reference to the other, which is cheap to fix before an incident and impossible during one.
Name in advance who decides the recovery point and what evidence they need, since that decision is otherwise made by whoever is most tired at three in the morning. Write down the acceptable data loss for each major system, and list the two or three representative systems whose inspection will stand for the estate.
Then rehearse the mechanics as part of the normal restore testing program. Restore an arbitrary older point into the isolated environment, time it, and record how long inspection took. That figure determines how much of the window can actually be searched on the day, and it is the number most recovery plans are missing.