Immutability protects a backup copy from being changed after it is written. It does nothing about what was in the data at the moment it was written. If an attacker was present in the environment for several weeks before encryption began, the backups taken during those weeks captured their tools, their accounts and their persistence mechanisms, and locked them in place with the same care applied to the legitimate data.
That is the shape of the problem organizations meet during recovery. The copies are intact, verified and restorable, and restoring them puts the intruder back into the environment. The recovery question stops being whether a backup exists and becomes which backup is safe to use.
There is rarely any tampering with the backup system involved. Backup software faithfully copies whatever is on the protected systems, so anything an attacker installed becomes part of the copy through the normal process. Three forms account for most cases.
Dormant tooling is the most common: remote access utilities, scheduled tasks and modified binaries that sit quietly and are captured in every backup taken after installation. Account and configuration changes are the second: a new privileged account, a modified group policy, a weakened setting that is restored along with everything else. The third is corrupted or altered business data, where records were modified before the visible attack, which is the hardest to detect because it looks like ordinary content.
All three survive immutability because they predate it. The lock guarantees that the copy is exactly what was taken, and in this case that is the problem rather than the protection.
Recovery in this situation requires an estimate of when the intrusion began, and then a restore point earlier than that. Establishing the date is incident response work rather than backup work, drawing on log analysis, endpoint telemetry and forensic examination, and it typically produces a range rather than a single moment.
Two constraints then collide. Restoring from before the intrusion means losing the business data created since, which may be weeks. Restoring from after it means reintroducing the compromise. Most organizations end up choosing a clean system state combined with selective recovery of business data that has been examined, which is slower than either pure option and considerably safer than the second.
This is the practical reason retention has to reach back further than the recovery objective suggests. If every retained copy falls inside the intrusion window, there is no clean point to return to, which is the calculation behind setting retention against dwell time.
Examination has to happen somewhere that cannot harm anything if what is being examined turns out to be live. That means an isolated environment with no route back to production, which is the same facility a clean room recovery provides.
| Check | What it finds | Limitation |
|---|---|---|
| Malware scanning of restored systems | Known tools and signatures | Misses custom or novel tooling |
| Comparison against a known good baseline | Modified binaries and unexpected files | Requires a baseline to exist |
| Privileged account and group review | Accounts and rights added by an attacker | Needs a trusted reference state |
| Scheduled task and service inventory | Persistence mechanisms | Volume of legitimate entries obscures additions |
| Configuration drift against policy | Weakened security settings | Only covers settings under policy management |
| Data consistency checks on business records | Altered content | Application specific, rarely automated |
| Outbound connection monitoring in isolation | Tools that call out on start | Dormant tooling stays silent |
No single check is conclusive, and the combination is what gives confidence. The most valuable of them is the comparison against a known good baseline, which is only possible if a baseline was captured while the environment was trusted. Capturing one is inexpensive and it is rarely done before it is needed.
Where the intrusion date is uncertain, a staged approach reduces the risk. Rebuild operating systems and applications from trusted sources rather than restoring them, so the system layer carries nothing from the compromised period. Then restore data selectively onto that clean base, with examination proportionate to the sensitivity of each dataset.
This is slower than a wholesale restore and it is frequently the only defensible option, because it separates the two questions: the system state comes from a source that was never in the attacker's reach, and the data is examined on its own terms. Where full rebuilds are not practical for every system, the ones that were most exposed deserve the treatment first.
Whichever path is chosen, restored systems should come back into an isolated network segment first, with monitoring in place, and be promoted only once they have been observed. Bringing everything back at once removes the opportunity to notice that something came back with them.
The defense against poisoning is depth of history rather than protection of a single copy. Object storage with S3 Object Lock on Scality RING or ARTESCA holds each copy unaltered for its retention period, so a set of restore points spanning weeks or months remains intact and an attacker with administrative credentials cannot remove the older ones to force a recent restore point to be used.
That matters because the attacker's interest is the opposite of the defender's. Removing history narrows the choice of restore points to those inside the compromise window. Locked copies with a retention period long enough to cover a realistic dwell time keep the clean point available, and the capacity implication of that longer history is a planning exercise worth doing deliberately rather than discovering later.
The decision that a restore point is clean has to be made by someone, under time pressure, with incomplete information. Agreeing in advance what evidence is required, who makes the call and what level of residual risk is acceptable removes a stalled discussion from the middle of an incident.
Capturing a known good baseline now is the single most useful preparation, because every check in the table above works better when there is something trustworthy to compare against. It costs an afternoon and it is the difference between examining a restored system and guessing about it.