Backup and ransomware: why the firm’s NAS is not enough

In many firms the backup of the practice management software and the client folders ends up on a NAS in the same office, mapped as a network drive on the PCs and reachable with a domain administrator account. Against ransomware this is the most fragile configuration: whoever obtains those privileges encrypts the copies first, then the production data. The backup existed, but it is of no use.

The owner of the firm should ask for a restore test and know how much work could be lost. The technician can use the following checks to verify that the copies are separated.

How ransomware reaches the firm’s NAS

The attack often follows a familiar sequence. The attacker gets in with a stolen credential or an exposed remote access service, looks for an account with administrator rights, then deletes the local Windows copies with commands such as vssadmin delete shadows /all /quiet and works through the network shares. A NAS mapped as a drive letter, or accessible with the same domain credentials, is just another folder. If the NAS management panel is reachable from the office network with a weak password, the attacker can also delete the snapshots directly.

Three requirements for an immutable backup

• Separate credentials: the backup software writes with a dedicated account outside the domain, and the NAS is not mapped on any PC. The administration panel has its own password and, where possible, a second factor.
• Immutability: snapshots that cannot be deleted before they expire, or object storage with Object Lock in compliance mode, which, unlike governance mode, cannot be bypassed even by the account administrator. Alternatively, a “hardened” Linux repository that enforces immutability at file-system level.
• An off-site copy, with a provider other than the one hosting the production data, using credentials that do not appear on any PC in the firm.

This is the 3-2-1 logic, updated: three copies, two different media, one off-site, at least one of which is immutable or disconnected. The lock period should be chosen according to how much time may pass before the encryption is noticed, because ransomware can stay dormant for days before activating.

The restore test to document

A backup that has never been restored is a hypothesis. Commands such as RESTORE VERIFYONLY on SQL Server confirm that the file is readable, not that the practice management software starts up again. Once a quarter it is worth restoring the database on an isolated machine, starting the application, opening a recent client file and timing everything. The measured time should be compared with the RTO, the maximum acceptable downtime. The RPO, on the other hand, indicates the acceptable data loss, expressed as a time interval: the recovered copy must make it possible to meet this objective.

The entry points used before encryption are described in the note on remote access to the firm. For an analysis of the true cost of downtime and for the first decisions after an attack, the first 48 hours checklist is a good starting point.