NexusSec.Ransomware attacks are rarely a single click followed by encryption. Attackers usually spend time inside the network first, and one of the things they look for is the backup system, because a business that can restore does not need to pay. If the backups sit where the same administrator account can reach them, they are deleted or encrypted before the ransom note appears.
3-2-1, with one copy out of reach
The long-standing 3-2-1 rule is three copies of the data, on two different types of storage, with one copy off-site. It is still right. For ransomware it needs one addition: at least one copy must be offline or immutable, meaning it cannot be changed or deleted before its retention period ends, not even by an administrator. Some vendors write this as 3-2-1-1-0, where the extra 1 is the offline or immutable copy and the 0 is zero errors when restores are tested.
What “out of reach” means in practice
- Immutable storage: object storage with object lock, or a backup repository that supports immutability, with a retention period longer than an intruder is likely to go unnoticed.
- Locked NAS snapshots: some current NAS platforms can lock snapshots for a retention period. Ordinary snapshots that an administrator can delete do not count.
- Offline media: removable drives or tape, rotated and kept disconnected. Old-fashioned, inexpensive, and very hard to attack remotely.
- A cloud backup service with its own account, separate from your domain, that keeps deleted backups for a recovery period.
Keep the backup system off the domain's keys
The backup server is often joined to the Active Directory domain and run with a domain administrator account. That is convenient, and it means whoever takes over the domain takes over the backups too.
- Use dedicated accounts for the backup console and repositories, not domain accounts, with passwords used nowhere else.
- Put multi-factor authentication on the backup console and on any cloud backup account. See where to switch on MFA first.
- Place the backup server and repository in their own network zone, reachable only from the systems being backed up and from administrators' machines. Zones first covers how.
- Alert on deleted backup jobs, shortened retention and disabled schedules. Those are the settings an attacker changes first.
Decide how much you can lose, and for how long
Two numbers shape the design. The recovery point objective is how much data you can afford to lose, which sets how often backups run. The recovery time objective is how long the business can manage without a system, which sets how quickly you must be able to restore it. Agree both, system by system, with whoever runs the business: the accounts server and the marketing share rarely have the same answer.
Restoring a whole server from an off-site or cloud copy takes time, because the data has to come back over the link or be fetched. Work out how long a full restore of your largest system would take before the day you need to know.
Test the restore
A backup job reporting success tells you data was copied. It does not tell you the data restores, that the restored system boots, or that the application on it works. Test on a schedule:
- Monthly: restore a sample of files and a database to a separate location and check them.
- Quarterly: restore a whole server into an isolated network and confirm the application works.
- Yearly: walk through the full recovery plan, including who does what and where the backup system's credentials are kept if the domain is unavailable.
Record the date and result each time. Insurers and clients ask for it, as covered in what your cyber insurer actually wants to see.
Do not forget email and cloud files
If email and files live in Microsoft 365 or Google Workspace, check what their retention and recycle-bin features actually cover, and for how long. They keep the service available; they are not a copy you control with its own retention and credentials. A third-party backup of mailboxes and shared drives closes that gap.
