SentinelOne rolled back the encrypted host, so why were the mapped share's files still encrypted?

## What the feature actually is Rollback on the Windows agent works from two things: **Volume Shadow Copy (VSS) snapshots** that the agent takes on a schedule and protects against deletion by other processes, and the **agent's own record of the file changes it attributed to the convicted process tree**. When a mitigation decision fires, the agent walks that record and restores the affected files on the endpoint's local volumes from the snapshot material. Because it depends on VSS, it is a Windows capability; the Linux and macOS agents have no equivalent. Two properties follow immediately, and both are what interviewers are testing: - **It is per-endpoint.** The restore happens on the machine running the agent, to that machine's volumes. - **It follows a conviction.** No conviction, no mitigation, no rollback. A host left in detect-only mode has nothing to roll back from. ## Why the mapped share was outside all of it `Z:\Finance` is a drive letter mapped to a share hosted on a different Windows machine. The archiver ran on the endpoint, but the writes to `Z:\` were performed remotely: the client sent SMB operations and the *file server's* SMB stack committed them to its own disks. The endpoint's agent has no ability to reach into another machine's volumes, and the snapshots it holds are of its own disks. So the local documents came back and the departmental share did not — which is the partial recovery this estate actually got. ## Would an agent on the file server have saved it? This is the sharp follow-up, and the answer is usually no, for a reason worth knowing. On the file server there is no adversary process tree to convict. The writes arrive over SMB and are committed by the server's own SMB stack in kernel context, surfacing as system activity rather than as a malicious binary. A behavioural engine that convicts *process trees* has nothing to attribute the damage to, so it neither convicts nor rolls back. Some products add specific server-side detections for mass remote file modification, but you should not assume the generic conviction path covers it. Remote encryption of a share is a known weak spot of endpoint-centric prevention, and the honest control for it is snapshots and backups on the file server itself. ## The other two boundaries that bit **Snapshot recency.** Snapshots are point-in-time. A file created or modified after the most recent snapshot, and not fully captured in the agent's change record, either returns to its snapshot-time state or does not return at all. On a busy working day that is real, current work. **The deletion step in the chain.** The adversary's second move was deleting Volume Shadow Copies, and that is not incidental — it is aimed precisely at destroying the local restore source before the encryption starts. The agent's protection of the snapshots it manages is why the rollback had material to work from at all. It is also why that deletion is such a valuable behavioural signal: it is a step whose only purpose is to remove your recovery options. ## How to describe it afterwards, honestly After an incident like this, somebody will ask whether rollback means backups are unnecessary. The defensible position is a scope statement rather than a yes or no: - Restores **local volumes** on a **Windows** endpoint whose agent **convicted** the activity. - Restores what the agent **observed and snapshotted**, to a **point in time**, not to the last-saved state. - Restores **nothing** on network shares, on hosts without an agent, or in a group left in detect-only. Those three lines are what you should be able to say in an interview, because they are exactly what a business owner needs before they decide how much recovery capability they think they have. Test the boundaries before you rely on them: encrypt a scratch directory and a scratch share with a harmless tool in a controlled test and see precisely what returns. ## The forensic cost nobody mentions Rollback is a destructive-to-evidence operation on the file system: it overwrites the current state with restored content. If you intend to make claims later about what was changed and when, capture what you need from the host — the agent's own story of the incident, and any artefacts you want to preserve — before or alongside the restore, rather than assuming you can reconstruct it afterwards from a rolled-back disk.