Backups exist for the day everything else fails, which is exactly why ransomware gangs now deliberately target them first. A business that discovers its backups were encrypted, deleted, or quietly corrupted alongside the primary systems has lost the one safety net it was counting on completely, often in the very same few minutes as the main attack, with no warning that the safety net was ever under threat until it was already entirely gone.
Ransomware groups actively and deliberately hunt for your backups
Modern ransomware playbooks explicitly include a step for locating and destroying backups before encrypting production data, because attackers know a business with clean, accessible backups can simply restore and refuse to pay. If your AWS backup buckets sit in the same account, under the same credentials, and behind the same permissions as your live systems, a single compromised admin credential can wipe out both your production data and your recovery plan in one coordinated sweep, leaving nothing at all to fall back on when it matters most.
A properly scoped AWS pen testing assessment specifically examines whether your backup architecture would survive a compromise of your main environment, rather than simply confirming that backups exist and run on schedule as most routine reviews do, without ever testing what actually happens once the attacker already holds the keys to everything, including the recovery plan.
Immutability alone turns a backup into a genuine safety net worth having
The fix is not more backups. It is backups an attacker with full admin access still cannot touch. AWS supports genuinely immutable storage through S3 Object Lock, and separating backup credentials into a different account entirely means a compromised production admin role cannot reach the recovery copies at all. Without that separation, you have a backup in name only, sitting one stolen credential away from being just as useless as the systems it was meant to save, which defeats the entire point of having it in the first place.
William recalled a case that illustrated exactly why this particular distinction matters so much more than it first appears to.
“The client had backups running every night without fail, which gave them real confidence. But the backup role used the same permissions boundary as their production admin account, so when we simulated a compromise of that account, we could delete every recovery point in about ten minutes flat.”
— William Fieldhouse, Director of Aardwolf Security Ltd
Ten minutes was all it took to erase a safety net the client had trusted completely. The backups themselves were technically flawless. The isolation around them was the part nobody had tested until we did, and it was the only part that actually mattered once an attacker had a foothold.
Make your recovery plan genuinely attacker-resistant, not merely reliable
Separate backup accounts and credentials from production wherever possible, enable immutability on critical recovery points, and confirm regularly through vulnerability scan services that nothing has quietly drifted back into a shared, vulnerable configuration. A recovery plan is only ever as good as its weakest assumption, and ‘the backups are safe’ is an assumption genuinely worth testing properly rather than simply taking on trust because the nightly job report happened to say success. Aardwolf Security can help you pressure-test your backup strategy thoroughly, so reach out before ransomware finds the gap for you.
