Backup servers: the forgotten attack surface

Ransomware operators have a playbook. Before encrypting anything, they find the backup server and delete or encrypt it first. Removing your recovery option before triggering the ransom note is standard practice. It is also why the backup server is one of the first things a sophisticated attacker looks for on an internal network.

Why backup servers are such a good target

Backup servers have three properties that make them attractive. First, they hold a copy of everything: databases, source code, HR files, email archives. Getting to the backup server is almost as good as getting to every other server. Second, they tend to be lightly monitored. The security team watches the web apps and the domain controllers; the backup server runs quietly in the background. Third, they often run old software. Veeam, Commvault and Windows Server Backup receive less patching attention than customer-facing services.

The right place for your first decoy

If you only deploy one decoy, put it in the same subnet as your real backup infrastructure, at an IP that looks like another backup server. Give it a hostname like nas-backup or backup-srv02. Set it up as a NAS profile: SMB on 445, SSH on 22, a web admin console.

When the attacker's lateral movement script finds that IP and tries to enumerate its SMB shares or log in via SSH, you get the alert before they reach your real backup server. You know the source IP. You disconnect it. You reset the credentials. The backup is intact.

What the SMB enumeration event looks like

An SMB share enumeration on a Kandaro NAS decoy looks like this: a connection from an internal IP, an NTLM negotiate, sometimes a successful challenge-response with a stolen hash, and a series of tree connects as the attacker maps which shares exist. Kandaro groups the whole sequence into one incident: Internal workstation enumerated the backup NAS and tried to log in as backup-admin.

Read where to put your first three decoys, or deploy the NAS profile now.