Ransomware detection on backups
By Lucas Flores, IT Systeme Flores UG. Last updated
Every backup sees what changed on the system it protects. When
ransomware encrypts a file server, the next backup sees thousands of
files change at once, files renamed to .locked, ransom
notes in every folder and file contents that suddenly look like
random bytes. Since 0.4.0, in every edition, Restow judges every new
restore point from these traces, marks the suspicious ones, alerts
once per attack, points every restore view to the newest restore
point without findings and pauses retention of the object until an
administrator resolves the finding, so the clean old restore points
are not pruned away while encrypted ones pile up.
It is a tripwire, not an antivirus. It works only from data the backup already has, never reads the backed-up data a second time, never scans files for malware and never blocks a backup.
What it looks at
A restore point is suspicious when at least one signal fires. Every finding carries the numbers that made it, so you can see how far off it is. Each object is compared with itself: the baseline is its last 14 restore points that count as clean, and with fewer than 5 such restore points the signal says "learning". The defaults below can be changed under Installation, Ransomware detection.
Since 0.4.6, the baseline of a container begins with its newest backup chain. The first backup of a container's new chain (its repository was missing, or reset) used to be judged against the old chain and flagged as suspicious, because every file is new in an empty repository. A restore point flagged that way before the update stays flagged: mark it as a false alarm.
| Signal | Fires when (defaults) |
|---|---|
| Amount of change | New and changed files, or bytes added, are far above the object's usual (more than 8 median absolute deviations above its median, at least 5 times the median) and reach 500 files or 1 GiB. |
| Deletions | At least 1,000 files deleted, and at least 25 percent of the files the previous restore point had. |
| Renamed extensions | At least 100 files renamed with an appended or replaced extension (a.docx to a.docx.locked), and at least 2 percent of the files. |
| Known names | At least 20 new or changed files with a known ransomware extension, or at least 2 new files named like a ransom note. The lists are versioned and matched on the server, so a list update needs no agent update. |
| Entropy | Of the sampled new or changed files that are not of a compressed format, at least 3 and at least half look encrypted (random bytes). Only the first and last 64 KiB of a handful of files are measured. |
| Compression and deduplication | The run added at least 256 MiB of new data that hardly compresses, or hardly deduplicates, far beyond what is usual for that object. Encrypted data does neither. |
An object whose new data is always incompressible, such as media files, never alerts on the compression signal; its amount of change is still judged.
Which signals exist for which object
| Object | Amount of change | Deletions, renames, names, entropy | Compression and deduplication |
|---|---|---|---|
| Server or client | Yes | With agent 0.4.0 or newer | Deduplication always, compression from agent 0.4.x |
| File share | Yes | With the 0.4.0 runner | Yes |
| Proxmox VE container | Bytes added | Not available | From nodes with restow-pve 0.4.x |
| Proxmox VE VM | Bytes uploaded | Not available | Yes, on the server |
| OneDrive | Yes | Yes | Yes |
| SharePoint site, mailbox, IMAP account | Yes | Not available | Yes |
A signal that has no data says "not available", never "clean": an older agent that sends no activity report, a first backup, or a kind that has no such data. The dialog behind a restore point lists every signal with its state: finding, no finding, learning, not available or switched off.
What you see
A red "Suspicious" badge on the restore point and on the object in every restore view: the machine page, the file share page, the guest page, the explorer of a mailbox or OneDrive. A restore point without findings gets no badge, because no finding is no proof. When the newest restore point is suspicious, the restore views say since when restore points show signs of ransomware and offer the newest restore point without findings. A click on the badge shows each finding with its numbers, the state of every signal and what the detection cannot see.
False alarms
A planned migration moves a lot of files. Technicians and administrators can mark a finding as a false alarm with a note, and take it back. The restore point then counts as clean, its numbers join the baseline so the same amount of change does not alert again, and the episode ends. Both actions are written to the audit log.
The retention hold
The real damage is not the encrypted restore point. It is retention
removing the clean old restore points while encrypted ones accumulate:
after a week of daily encrypted backups and seven daily restore
points kept, nothing clean is left. So while an object has a
suspicious restore point nobody resolved, retention, restic
forget and prune delete no restore point of that object. The
object shows "Retention paused". Backups go on, so storage grows;
budgets and their warnings still apply.
Only an administrator ends a hold, never a later clean restore point. There are two ways: "Mark as false alarm", or "Release hold", after which retention resumes with its next run and deletes what the rules no longer keep, suspicious restore points included. Releasing needs a recent sign-in and is audited. A hold that is still open after 14 days is announced again, and every 14 days after. The owner can switch the hold off under Installation, Ransomware detection.
Notifications
backup.suspicious is an error, raised once per attack
episode, and says that retention is paused.
backup.suspicious_hold is a warning for a hold that is
still open. Both reach the notification bell, the alert rules and
the webhooks through the notification matrix under Integrations,
Notifications. The alert mail lists every finding with its numbers.
Stated limits, not hidden ones
- It is a tripwire, not a virus scanner. A restore point without findings does not prove that no file was encrypted, and a finding is not proof either.
- Ransomware that encrypts a few files per day, or only parts of large files, stays within the baseline, and intermittent encryption that leaves the first and last 64 KiB of a file intact is invisible to the sampled files. Below 256 MiB of new data the compression and deduplication ratios are not judged.
- Data the backup does not see is not judged: excluded folders, files above a size limit, data changed after the backup. For Proxmox VE VMs only the amount of changed blocks exists, for mailboxes only the amount of new items.
- An attacker who knows the detection can stay below the thresholds, encrypt into compressed formats (never judged by the sampled files) or encrypt the backup history first. Immutable storage protects the history; the retention hold only stops Restow's own retention from deleting it, and an administrator account that the attacker holds can release it (with a recent sign-in, audited). Malware that does not encrypt, such as data theft, leaves no trace in these signals.
- The first backup of an object and objects with a short history have nothing to be compared with: the amount of change is still being learned.
- The activity report (deletions, renames, names, sampled files) needs the endpoint agent 0.4.0 on machines; the compression signal needs agent 0.4.0 on machines and restow-pve 0.4.0 for containers. Older agents show "not available".
- It was built from the published behaviour of ransomware families and tested with simulated attacks (random bytes, renamed extensions, notes in every folder), not with live ransomware. Runs older than 72 hours are not judged afterwards, so an outage does not flood the alerts.
- A hold keeps data that would otherwise expire. If you must delete something for a legal reason, resolve the finding first, and note that locked data on an immutable repository cannot be deleted before its lock ends (see immutable backups).
The signals, defaults, episodes and the agent protocol are described in docs/RANSOMWARE.md in the product repository.
Frequently asked
Is this a virus scanner?
No. It never scans files for malware and never reads the backed-up data a second time. It judges what the backup already saw: how much changed, what was deleted or renamed, which names appeared, and what a few sampled files look like. A finding is a reason to look, not proof, and a restore point without findings does not prove that nothing was encrypted.
Does it block a backup that looks suspicious?
No. Backups go on. A suspicious restore point is marked, announced once per attack, and the object's retention is paused, so the clean older restore points are not pruned while encrypted ones pile up.
What does the retention hold do to storage?
Nothing of that object is deleted while the hold lasts, and backups go on, so its storage grows. Storage budgets and their warnings still apply, and a backup that a used-up budget refuses fails as usual. A hold that is still open after 14 days is announced again, and every 14 days after that.
Who can end a hold?
Only an administrator, and never a later clean restore point: ransomware that was cleaned up still leaves its encrypted restore points, and an attacker who stops encrypting for a day must not restart pruning. An administrator either marks the finding as a false alarm, or releases the hold after a recent sign-in. Both are written to the audit log.
What if a planned migration looks like an attack?
Technicians and administrators can mark a finding as a false alarm, with a note. The restore point then counts as clean and its numbers join the object's baseline, so the same amount of change does not alert again.
Which kinds of backup are judged?
Servers and clients, file shares, Proxmox VE containers and VMs, mailboxes, OneDrives, SharePoint sites and IMAP accounts. Not every signal exists for every kind: deletions, renames, names and sampled files exist only for machines, file shares and OneDrives. A signal without data says "not available", never "clean".
Is it on by default, and can I tune it?
It is on after the update to 0.4.0, retention hold included, and judges backups of the last 72 hours. Under Installation, Ransomware detection every signal has its threshold and its switch, and the hold has a switch and its reminder days. Every provider admin reads them, the provider owner changes them, and every change is audited.
Is ransomware detection in the Community edition?
Yes. It is part of the Community core and therefore in every edition.
Immutable backups: what can be locked, and what cannot →
Proving backups actually restore →
Read more in Learn: immutable backups, WORM, air gaps and ransomware →