What ransomware does on a server | Learn Defense with RoamSwitch

#What ransomware does on a server

Ransomware encrypts files so they cannot be read, and asks for money in exchange for the key. On a server it goes after application data, web document roots, databases and backups.

It usually moves through these stages.

Stage	What happens
Get in	Through a vulnerability or stolen credentials
Remove the way back	Delete snapshots and backups
Encrypt	Replace files with ciphertext and delete the originals
Extort	Leave a ransom demand, sometimes with a threat to publish stolen data

In this module you imitate the encryption stage on a disposable VM. It uses a real encryption tool (openssl), but only on dummy files made on the spot. The features covered are Mass-encryption detection, Detection with decoy files, Record of the random numbers used for encryption (time-limited) and Backup freshness check.

Check what is being watched

This changes nothing. detection-coverage shows which techniques are watched, and how far.

sudo roamswitch detection-coverage --server | grep -A3 -e T1486 -e T1490
sudo journalctl -u roamswitch-server -b | grep -oE 'following these folders.*|Total monitored canaries.*' | tail -2
sudo find / -xdev -name '.roamswitch_security_canary*' | sort
sudo ls /var/lib/roamswitch/canary

Excerpt (Ubuntu 24.04, no web server)

  🟡 T1486 Data Encrypted for Impact  [partial]  on
      covered by: ransomwareCanaryGuard, entropyWatch
      blind spot: Decoy files trip only when touched. The entropy watch reads the head of files written in the watched folders only (the document roots, /var/www, /srv, the standard data folders of MariaDB/MySQL, PostgreSQL, MongoDB and Redis, or entropy_watch_dirs), at most entropy_watch_max_files_per_sec files per second, (snip) By default it only notifies; it stops the writer when entropy_watch_freeze is on, and in a document root also with entropy_docroot_action=freeze_writer when the web service replaced existing files (an upload of new files is only notified).

  🟡 T1490 Inhibit System Recovery  [partial]  on
      covered by: execRecorder
      blind spot: Only btrfs subvolume delete and lvremove run by something other than a known snapshot manager are recognized (EXR-008); other ways of removing recovery points, such as deleting backup files, are not.
Total monitored canaries: 16
following these folders roots=["/srv"]
/etc/roamswitch/.roamswitch_security_canary_do_not_delete.pdf
/etc/roamswitch/.roamswitch_security_canary_do_not_delete.xlsx
/etc/roamswitch/.roamswitch_security_canary_do_not_delete.zip
/opt/.roamswitch_security_canary_do_not_delete.pdf
(omitted)
/srv/.roamswitch_security_canary_do_not_delete.zip
customer_database_export.csv
financial_statement_2026.xlsx
personal_vault_backup.kdbx
project_source_archive.zip

Encryption (T1486) is watched in two ways.

The entropy watch (entropyWatch) reads the content of files written in the watched folders. On this VM it followed /srv only, because there was no document root and no /var/www
Decoy files (ransomwareCanaryGuard): 12 hidden files plus the 4 in /var/lib/roamswitch/canary, 16 in all

No decoy goes into a folder a web server serves (/var/www/html and the like), because anyone could fetch it. A document root is guarded by the entropy watch alone, and entropy_docroot_action decides whether the writer is stopped (tried in Setting your automatic isolation policy).

For removing the way back (T1490), only commands that delete snapshots are watched. Deleting backup files is not reported.

#Catch encrypt-then-delete

Much ransomware writes the ciphertext to a new file, then deletes the original. Mass-encryption detection watches for this. When one writer writes 20 files in 5 seconds whose content looks encrypted, it notifies (the note in the config file).

Replace plain files with ciphertext

Make two practice scripts. The first makes 40 plain dummy files. The second encrypts each one with openssl, adds .locked, and deletes the original. The password is a practice string.

cd ~
cat > make-dummies.sh <<'S'
#!/bin/sh
# Practice: make 40 dummy files with plain-text content
mkdir -p "$1"; cd "$1" || exit 1
for i in $(seq 1 40); do
  yes "invoice $i: dummy line for practice" | head -c 8192 > "report_$i.txt"
done
S
cat > encrypt-demo.sh <<'S'
#!/bin/sh
# Practice: imitate ransomware. Write an encrypted copy, then delete the original
cd "$1" || exit 1
for f in report_*.txt; do
  openssl enc -aes-256-cbc -pbkdf2 -pass pass:practice -in "$f" -out "$f.locked" && rm "$f"
done
S
chmod +x make-dummies.sh encrypt-demo.sh
sudo mkdir -p /srv/appdata && sudo chown "$USER" /srv/appdata

Make the plain files first, then encrypt them.

./make-dummies.sh /srv/appdata
sleep 6
./encrypt-demo.sh /srv/appdata
ls /srv/appdata | head -3
sleep 8
sudo roamswitch notifications | grep -A22 -m1 'written one after another'

Excerpt

report_10.txt.locked
report_11.txt.locked
report_12.txt.locked
  Files that look encrypted were written one after another in a watched folder
    🚨 One process wrote 21 files in a watched folder within 5 seconds, and their content looks encrypted (average entropy 7.98 bits per byte)
    Host: ubuntu (IP: 192.168.64.8)
    /srv/appdata/report_1.txt.locked
    /srv/appdata/report_10.txt.locked
    (omitted)
    ... +11
    Action: Notification only (the process was not stopped). To stop the writer of such a burst automatically, set entropy_watch_freeze=true in /etc/roamswitch/server.conf and restart
    Recommended Action: check whether this process is meant to write here. If it is not, stop it, restore the original files from your backups, and look into how it got in (the web server's access log, recent logins).
    Timestamp: 2026-11-12 01:30:24
    Process: admin / /usr/bin/dash / command: /bin/sh ./encrypt-demo.sh /srv/appdata (pid 5755)
    Parent processes: dash ← tart-guest-agent ← systemd / Service: tart-guest-agent.service
    Look for a free decryption tool for the encrypted files (only if one has been published): No More Ransom https://www.nomoreransom.org/en/decryption-tools.html / Japan National Police Agency https://www.npa.go.jp/bureau/cyber/countermeasures/ransom.html

How to read it:

Writing the 40 plain files raised no notification. Their entropy (how random the content is) is low
The ciphertext averaged 7.98 bits per byte. The maximum is 8, and ciphertext and random bytes come close to it
The Process line names the script that ran the loop (encrypt-demo.sh), not openssl. This is the PID to stop
As the Action line says, nothing is stopped by default. The writer is stopped (SIGSTOP) only with entropy_watch_freeze=true and a restart
The last line points to published decryption tools

Why it counted, although openssl wrote the files

According to the source comments, python3, openssl and gpg are trusted writers for the files they create. Creating encrypted files is not counted by itself. When about as many originals are deleted in the same folders within 5 seconds, the writer or its parent (the shell loop) is counted. The daemon log on this VM said created 21 high-entropy files while unlinking as many in the same folders within 5s.

openssl and rm finish within milliseconds, so the writer may be gone by the time the watcher reads the file. Then the folder is counted instead (20 files created and as many removed in one folder within 5 seconds). The log then reads their writers had exited before they could be read; the process that removed them: 2166, and the notification's Process line still named the looping script. Six runs in a row in the same folder raised six notifications, with 21 to 35 files each. Rewrites of the previous run's .locked files are counted too.

Outside the watched folders, the same activity raises no notification. If application data lives under /opt or elsewhere, add it to entropy_watch_dirs.

Add a folder to watch

This rewrites the config file and restarts the daemon (it changes the system). Run the scripts from the previous lab in /opt/appdata.

sudo mkdir -p /opt/appdata && sudo chown "$USER" /opt/appdata
./make-dummies.sh /opt/appdata; sleep 3; ./encrypt-demo.sh /opt/appdata; sleep 8
sudo journalctl -u roamswitch-server --since -15s | grep -c burst
sudo roamswitch server config set entropy_watch_dirs /srv,/opt/appdata
sudo roamswitch server restart
sleep 8
sudo journalctl -u roamswitch-server --since -12s | grep -o 'following these folders.*'
rm -f /opt/appdata/*
./make-dummies.sh /opt/appdata; sleep 3; ./encrypt-demo.sh /opt/appdata; sleep 8
sudo roamswitch notifications | grep -A3 -m1 'written one after another'

Excerpt

0
  ✓ Server configuration updated and saved. (entropy_watch_dirs = /srv,/opt/appdata)
  To apply: sudo systemctl restart roamswitch-server or sudo roamswitch server restart

  🔄 Restarting roamswitch-server service...
  ✓ roamswitch-server service successfully restarted.

following these folders roots=["/opt/appdata", "/srv"]
  Files that look encrypted were written one after another in a watched folder
    🚨 One process wrote 21 files in a watched folder within 5 seconds, and their content looks encrypted (average entropy 7.98 bits per byte)
    Host: ubuntu (IP: 192.168.64.8)
    /opt/appdata/report_1.txt.locked

Before the folder was added, the daemon log had 0 bulk-encryption (burst) records. After adding it and restarting, the same activity was reported. Saving the setting is not enough. A restart is needed.

To undo it, empty the value and restart.

sudo roamswitch server config set entropy_watch_dirs ""
sudo roamswitch server restart

When the log shows roots=["/srv"] again, it is back to the default.

Only the folders you list are watched

Only while entropy_watch_dirs is empty does the watch follow the document roots, /var/www, /srv and the standard database folders (the note in the config file, and the source). Once you set a value, only the listed folders are watched. To keep a default location, list it too, as /srv is in the example above. Up to 32 folders can be listed.

#When a decoy file is rewritten

Detection with decoy files watches decoy files for changes. The decoys are hidden files with names that normal work does not touch. On Server Edition, a rewritten decoy isolates the whole host.

Overwrite a decoy with ciphertext

This cuts the network of the whole host (it changes the system). The SSH maintenance port stays open, but use a disposable environment. As ransomware would, overwrite a decoy with ciphertext.

sudo sh -c 'openssl enc -aes-256-cbc -pbkdf2 -pass pass:practice -in /srv/.roamswitch_security_canary_do_not_delete.pdf -out /tmp/x.locked && cp /tmp/x.locked /srv/.roamswitch_security_canary_do_not_delete.pdf'
sleep 3
sudo roamswitch server ebpf | sed -n 5,6p
curl -sS -m 5 -o /dev/null https://example.com; echo "curl rc=$?"
sudo roamswitch notifications | grep -A10 -m1 'Canary Tripped'

Excerpt

  Current isolation: [Isolated: host_with_maintenance_ssh]
  Maintenance ports kept open: [22]
curl: (28) Resolving timed out after 5003 milliseconds
curl rc=28
  Ransomware Canary Tripped
    🚨 Ransomware canary file was Tampered / encrypted write
    Host: ubuntu (IP: 192.168.64.8)
    Decoy: /srv/.roamswitch_security_canary_do_not_delete.pdf
    Suspected process: cp (PID: 13928)
    Action: host Air-Gap isolated (the culprit process cp, PID 13928, had already exited, so it could not be frozen)
    Timestamp: 2026-11-12 01:31:24
    Process: root / /usr/bin/cp / command: cp /tmp/x.locked /srv/.roamswitch_security_canary_do_not_delete.pdf (pid 13928) (The process had already exited, so this comes from the exec record made at 2026-11-12 01:31:24.)
    Parent processes: dash ← sudo ← dash ← tart-guest-agent ← systemd / Service: tart-guest-agent.service
    Look for a free decryption tool for the encrypted files (only if one has been published): No More Ransom https://www.nomoreransom.org/en/decryption-tools.html / Japan National Police Agency https://www.npa.go.jp/bureau/cyber/countermeasures/ransom.html

A decoy is checked as soon as it is written (inotify). The daemon log on this VM showed Canary file TAMPERED less than 0.1 seconds after the command started. Waiting 3 seconds is enough.

Outbound traffic stopped. SSH port 22 is kept open for maintenance. The cp that rewrote the decoy had already exited, so nothing was frozen. The last line of the notification points to published decryption tools. RoamSwitch does not decrypt anything itself.

This isolation does not open on its own, even though cp has exited. When you have finished looking, acknowledge the isolation and lift it. The cause could not be confirmed gone, so emergency-restore asks you to type RESTORE. Run where it cannot ask (from a pipe, for example), it does nothing and exits with code 2. The final restart puts the normal protection rules back.

sudo roamswitch server ack
sudo roamswitch emergency-restore
curl -sS -m 5 -o /dev/null https://example.com; echo "curl rc=$?"
sudo roamswitch server restart
sleep 10
sudo head -c 32 /srv/.roamswitch_security_canary_do_not_delete.pdf; echo

Excerpt

  ✓ Acknowledged the current isolation (13s old). While acknowledged it will not auto-degrade or auto-restore; the current isolation stays in place.
  To lift it: sudo roamswitch emergency-restore
  Current state:
    Isolated (trigger: ransomware decoy file tampering, phase: full)

  ⚠️ It could not be confirmed that the cause of the isolation is gone. If it remains, putting the network back now restarts traffic while it is still affected.
  To continue, type RESTORE:
  🔄 Lifting all emergency isolation and restoring network baseline...
    ✓ Isolation records
    ✓ Firewall tables that can stop traffic
    ✓ DNS settings
    ✓ Connection tracking
  These firewall tables were left as they are, as they are not an isolation:
    - roamswitch_server: the server's inbound rules (only ssh_ports and allowed_ports are let in; the usual protection)
  ✓ The network was recovered.
  The rules removed here, such as port-scan detection, stay off until a restart. To put them back: sudo systemctl restart roamswitch-server
  The cause may still be present (it was not confirmed gone). Check what happened with roamswitch timeline.

curl rc=0
%PDF-1.4 ROAMSWITCH_CANARY_INTEG

emergency-restore first shows the trigger and the phase (full). Typing RESTORE at the prompt listed what it removed and brought the network back. The normal inbound rules (roamswitch_server) stay. The decoy has its original content again.

Notifications that could not go out during the isolation are sent again after it is lifted, with [Delayed] in the title. The history on this VM showed [Delayed] Ransomware Canary Tripped. Assume that, while isolated, alerts may not reach outside channels.

The scope of isolation, when it lifts on its own, and how to use the acknowledgement are covered in detail in Setting your automatic isolation policy.

#Keep a clue to the key

Encryption keys are made from random bytes the kernel hands out. Record of the random numbers used for encryption (time-limited) records the random bytes processes receive, for a limited time. If a decryptor exists for that ransomware family, the record can help it rebuild the key. RoamSwitch only records; it does not decrypt. Decryption is not guaranteed.

It is off by default (prn_record=false). The status, export and purge commands of roamswitch-prn-recorder use the language of the person running them (LANG), as roamswitch does. Records are kept 24 hours by default (prn_retention_hours, 1 to 168), up to 256 MiB by default (prn_max_mib, 16 to 4096).

Turn the record on, then remove it

This rewrites the config file and restarts the daemon (it changes the system).

sudo roamswitch-prn-recorder status
sudo roamswitch server config set prn_record true
sudo roamswitch server restart
sleep 10
sudo roamswitch-prn-recorder status

Excerpt

not recording
stored: 0 segments, 0 bytes
[OK] root: running as root
[OK] kernel: 7.0.0-42-generic (the BPF ring buffer needs 5.8 or newer)
[OK] btf: /sys/kernel/btf/vmlinux
[OK] driver hook: the kernel functions the cheap hook attaches to are present
[OK] tracepoints: syscalls:sys_enter_getrandom is available
[WARN] vdso: this kernel's vDSO exports getrandom: a C library that uses it (glibc 2.41 and newer) returns random bytes without a system call, and those are NOT recorded. On x86-64 the kernel parameter vdso=0 turns the vDSO off
  ✓ Server configuration updated and saved. (prn_record = true)
  To apply: sudo systemctl restart roamswitch-server or sudo roamswitch server restart

recording
The bytes taken reach the files within about a second; an export has them only after that
retention 24 hours, size limit 256 MiB
since this start: records 721, skipped own 10, lost in the kernel 0
hook: on the kernel's random-byte functions (no cost to anything else; the export's source is syscall, which says the bytes came through a system call)
stored: 1 segment, 46316 bytes
oldest record about 0 min ago, newest about 0 min ago
(snip)

The first status also checks whether this machine can record. In the second one, "oldest record about 0 min ago" counts from the time of the first record. It was 10 seconds after the restart, so 0 minutes. [WARN] vdso means bytes taken through the path used by C libraries from glibc 2.41 on are not recorded. The glibc on this VM was 2.39.

Imitate the encryption with the scripts from the earlier chapter, then export the record.

./make-dummies.sh /tmp/prn-demo
./encrypt-demo.sh /tmp/prn-demo
sleep 5
sudo roamswitch-prn-recorder export --output /root/prn.jsonl --since-hours 1
P=$(sudo grep -m1 '"command":"openssl"' /root/prn.jsonl | sed 's/.*"pid":\([0-9]*\).*/\1/'); echo "first openssl pid=$P"
sudo roamswitch-prn-recorder export --output /root/prn-one.jsonl --pid $P
sudo ls -l /root/prn-one.jsonl
sudo cut -c1-120 /root/prn-one.jsonl

Excerpt

wrote 1990 records to /root/prn.jsonl
Warning: this file contains the random bytes keys are made from. The retention limit does not apply to it. Delete it securely when you are done
first openssl pid=16653
wrote 2 records to /root/prn-one.jsonl
Warning: this file contains the random bytes keys are made from. The retention limit does not apply to it. Delete it securely when you are done
-rw------- 1 root root 658 Nov 12 01:32 /root/prn-one.jsonl
{"captured_length":8,"operation":"getrandom","process":{"command":"openssl","pid":16653,"tid":16653},"requested_length":
{"captured_length":48,"operation":"getrandom","process":{"command":"openssl","pid":16653,"tid":16653},"requested_length"

As the second line of status says, the bytes reach the files about a second after they are taken. An export right after the encryption may leave the openssl records out. The sleep 5 gives them that time.

--pid exports only the random bytes one process received. Use it to narrow down to the PID in a notification. The exported file is -rw------- (readable by root only).

Turning it off removes the record.

sudo roamswitch server config set prn_record false
sudo roamswitch server restart
sudo roamswitch-prn-recorder status
sudo journalctl -u roamswitch-server --since -10s | grep -o 'prn_record is off.*'
sudo rm -f /root/prn.jsonl /root/prn-one.jsonl

Excerpt

not recording
stored: 0 segments, 0 bytes
(snip)
prn_record is off: the recorded random bytes were removed removed=1

Exported files are not removed by the retention limit or by turning the record off. Delete them yourself, as in the last line.

Treat the record as key material

The note in the config file says the record also holds the secrets of TLS and SSH sessions this host made. Turn it on only once you have confirmed that only root can handle it. Do not paste an exported file into a chat or an issue.

#Keep a way back

Detecting encryption does not bring back files that are already encrypted. For that you need a backup. Backup freshness check checks whether the last backup ran within 7 days. It looks at restic, borg, Timeshift, snapper, rsnapshot, systemd timers, cron and more.

Check how recent the backup is

This adds systemd units and runs a backup (it changes the system). For practice, tar packs /srv/appdata. First delete the files encrypted in the earlier chapter and make plain dummies again.

rm -f /srv/appdata/*; ./make-dummies.sh /srv/appdata
sudo roamswitch status --server | grep -A3 'Backup Recency'
sudo tee /etc/systemd/system/appdata-backup.service >/dev/null <<'U'
[Unit]
Description=Practice backup of /srv/appdata

[Service]
Type=oneshot
ExecStart=/usr/bin/tar -czf /var/backups/appdata.tgz -C /srv appdata
U
sudo systemctl daemon-reload
sudo systemctl start appdata-backup.service
sudo roamswitch status --server | grep -A1 'Backup Recency'
sudo tee /etc/systemd/system/appdata-backup.timer >/dev/null <<'U'
[Unit]
Description=Daily practice backup of /srv/appdata

[Timer]
OnCalendar=daily
Persistent=true

[Install]
WantedBy=timers.target
U
sudo systemctl daemon-reload
sudo systemctl enable --now appdata-backup.timer
sudo systemctl start appdata-backup.service
sudo roamswitch status --server | grep -A1 'Backup Recency'

Excerpt

  [WARN] Backup Recency - No backup job was found
         Looks for the last run of restic, borg, Timeshift, snapper, rsnapshot, systemd timers and cron jobs and checks that it was within the past 7 days. It does not check that a backup can be restored: a restore test writes the user's files, so it is never run automatically.
         ↳ Set up a backup that runs on a schedule (for example restic or borg from a daily systemd timer; on a desktop, Timeshift or Déjà Dup). Keep it on a different disk or server than this machine. If you back up another way that this check cannot see, you can ignore this item.
         Compliance: CIS 11.2 / NIST CSF PR.DS-11
  [WARN] Backup Recency - A backup has run, but nothing runs it on a schedule (no systemd timer or cron entry was found) (backup)
         Looks for the last run of restic, borg, Timeshift, snapper, rsnapshot, systemd timers and cron jobs and checks that it was within the past 7 days. (snip)
Created symlink /etc/systemd/system/timers.target.wants/appdata-backup.timer → /etc/systemd/system/appdata-backup.timer.
  [PASS] Backup Recency - The last backup was within the past 24 hours (backup)
         Compliance: CIS 11.2 / NIST CSF PR.DS-11

The unit name contains backup, so it was found as a backup job. The time of the last run comes from systemd's record (ExecMainExitTimestamp).

Running the service once still leaves a [WARN], because nothing runs it on a schedule (no timer or cron entry). Paired with a timer and run, it passed.

Next, make the backup fail by pointing it at a folder that does not exist.

sudo mkdir -p /etc/systemd/system/appdata-backup.service.d
printf '[Service]\nExecStart=\nExecStart=/usr/bin/tar -czf /var/backups/appdata.tgz -C /srv no-such-folder\n' | sudo tee /etc/systemd/system/appdata-backup.service.d/break.conf >/dev/null
sudo systemctl daemon-reload
sudo systemctl start appdata-backup.service
sudo roamswitch status --server | grep 'Backup Recency'
sudo rm -r /etc/systemd/system/appdata-backup.service.d
sudo systemctl daemon-reload
sudo systemctl start appdata-backup.service
sudo roamswitch status --server | grep 'Backup Recency'

Excerpt

Job for appdata-backup.service failed because the control process exited with error code.
  [WARN] Backup Recency - The latest backup failed (backup: appdata-backup.service)
  [PASS] Backup Recency - The last backup was within the past 24 hours (backup)

When the latest run fails, the item turns into a warning, even after earlier successes. After fixing it and running it again, it passed.

The check does not test whether a backup can be restored. To know that, extract it somewhere else and compare.

rm -rf /tmp/restore-test; mkdir /tmp/restore-test
tar -xzf /var/backups/appdata.tgz -C /tmp/restore-test
ls /tmp/restore-test/appdata | wc -l
diff -r /srv/appdata /tmp/restore-test/appdata && echo "same as /srv/appdata"

Output

40
same as /srv/appdata

To undo it, remove the timer and the units. A new unit in /etc/systemd/system raises a critical file monitoring (FIM) alert at once, naming the process that wrote it. Once the units are removed, sudo roamswitch fim verify is clean again. For a unit you keep, update the baseline with sudo roamswitch fim update.

sudo systemctl disable --now appdata-backup.timer
sudo rm -f /etc/systemd/system/appdata-backup.service /etc/systemd/system/appdata-backup.timer /var/backups/appdata.tgz
sudo systemctl daemon-reload

What not to do

Leave the backup on the same disk as the data it protects. /var/backups in this lab is only a practice location. Ransomware encrypts whatever the machine can read and write
Rush to restore from backup right after an encryption alert. If the way in is still open, the restored files get encrypted too. Stop the writer and look for the way in first
Assume you have a backup without ever trying a restore

When an encryption alert arrives

You know the writer (your own backup, a legitimate job of the application): check that the amount and the place of the writes are normal. If they are, record the time and the writer, and close the check
You do not know it: stop the writer with the PID in the notification. It is not stopped by default. Then follow A containment fired: the first hour to keep evidence and look for the way in
You cannot wait to stop it by hand every time: with entropy_watch_freeze=true and a restart, the writer is stopped automatically from then on. Processes never stopped are set in protected_processes

#What it cannot see

What was checked on this VM, and how far

Folders outside the watch are not seen. Until /opt/appdata was added, the same encryption left 0 records
Slow encryption is not seen. Fewer than 20 files in 5 seconds from one writer is not counted (the detection-coverage text)
Overwriting with a separate command is not counted. That is, writing the ciphertext elsewhere and putting it over an existing file with cp or mv run as a separate command (the detection-coverage text). Even then, if a decoy is overwritten, the decoy trips. In this module's lab, a decoy overwritten with cp isolated the host
A decoy trips only when it is touched. If only folders without decoys are encrypted, no decoy trips
The random-byte record does not see the vDSO path. Bytes a C library from glibc 2.41 on gets without a system call are not recorded (the roamswitch-prn-recorder status check, and the note in the config file)
The backup check only looks for tools and names it knows. A home-made script or an agent of an outside service gives "not found". It does not test restores

Check yourself

An encryption alert arrived. entropy_watch_freeze was never changed. What state is the writing process in

Show the explanation

The default of entropy_watch_freeze is false, and the notification's Action line says "Notification only (the process was not stopped)". Stopping it is up to you. Whole-host isolation is the response to a rewritten decoy.

Check yourself

"Backup Recency" passed. What can you say

Show the explanation

The check looks only at the time and result of the last run, and at whether something runs it on a schedule. It does not look at where the backup is kept or whether it can be restored. To know that, extract it somewhere else and compare, as in the lab.

#What to learn next

Isolation scope, acknowledgement, and freezing and resuming writers are covered in Setting your automatic isolation policy
How to investigate after isolation fires, and the order to undo it, are in A containment fired: the first hour
Delivering alerts to outside channels is covered in Notifications and event forwarding

Features covered

Related techniques (ATT&CK): T1486

What was verified

Verified on 2026-11-12. Target: Linux 1.17.39. On a disposable Ubuntu 24.04 VM with the published 1.17.39, openssl encryption, adding a watched folder, overwriting a decoy (detected and isolated within a 3-second wait) and releasing it with RESTORE at a terminal, recording and exporting random bytes (language by LANG, the oldest-record minutes), and the backup check with and without a timer were run in Japanese and English.

Command output varies with the product version and the environment. If yours differs, check the version first.