When ransomware operators get into a contractor's network, one of their first goals is not encryption. It is finding and disabling whatever could let you recover without them. Backup consoles, backup service accounts, and the storage those backups sit on are high-value targets, because a company with no working backups has far fewer options.
That makes the accounts that manage your backups some of the most important credentials in the business. Many small and mid-size firms protect them less carefully than the email account of a project manager. This post explains where the common weaknesses are and how to fix them without a large budget.
Why backup accounts are targeted
Backup software usually has broad access. It reads every server, database, and file share, and it often runs under an account with domain administrator rights. If an attacker steals that credential, they inherit the same reach. They can also log into the console and delete restore points, shorten retention settings, or reformat the backup repository.
Two patterns make this easy:
- The backup server is joined to the same Windows domain as everything else, and the same admin password works across systems.
- The backup storage is a network share that any compromised admin account can write to and delete from.
Separate the identities
The first rule is that nobody should use the same account for daily work and for backup administration.
- Create dedicated backup administrator accounts that are used for nothing else.
- Do not give those accounts email mailboxes, and do not use them to browse the web.
- Use unique, long passphrases stored in a password manager, not in a shared spreadsheet.
- Require multifactor authentication on the backup console wherever the product supports it.
- Keep the list of people with backup admin rights very short, and review it quarterly.
If your backup product allows role-based access, give operators the ability to monitor jobs and start restores without the ability to delete restore points or change retention.
Take the backup server off the main domain
A backup server that is joined to your production domain trusts the same directory the attacker is already inside. Where practical, run it on a workgroup or a separate management domain with its own credentials. If that is not possible, at minimum restrict which machines can reach the backup console on its management ports, and block that access from ordinary user workstations.
Make at least one copy hard to delete
The strongest protection is a copy that cannot be modified or deleted for a set period, even by an administrator. Many backup products and cloud storage services offer this as immutability or object lock. You should also keep one copy that is logically or physically disconnected from your network, so that a stolen credential cannot reach it.
Ask your provider or vendor these questions:
- Can an administrator shorten the retention period on the immutable copy?
- Who at the vendor can delete data, and how is that request verified?
- Is the cloud storage account protected by its own separate login and MFA?
Watch for tampering
Backup tampering usually leaves signs before the real attack starts. Set up alerts for:
- Failed or missed backup jobs
- Changes to retention settings
- New administrator accounts or role changes on the backup console
- Large deletions of restore points
- Logins to the backup console from unusual locations or at unusual hours
An alert only helps if someone reads it. Decide who receives these notifications and what they must do within the same business day.
Protect the cloud side too
If you back up Microsoft 365 or a cloud accounting platform, the same logic applies. The account that holds the backup subscription should have MFA, a unique password, and should not be a shared mailbox login. Recovery access should be documented so that two trusted people can reach it if one is unavailable, without anyone keeping credentials in a personal notebook.
A simple review you can do this week
Consider a hypothetical 80-person mechanical contractor. In one afternoon, the controller and the IT lead could do the following:
- List every account that can log into the backup console.
- Confirm each one is named, needed, and protected by MFA.
- Check whether the backup server is on the production domain.
- Confirm that one copy is immutable or offline.
- Run a test restore of a single file and a single server to confirm the process works.
None of that requires new software. It does require someone to own the task and put it on a calendar.
Where Ironfield Cyber fits
Ironfield Cyber helps contractors and energy companies design backup environments that survive a determined attacker, not just a failed disk. If you would like a second set of eyes on how your backup accounts, storage, and alerts are set up, we can walk through it with you and give you a short list of fixes in priority order.