The ransom note is the last thing that happens, not the first. By the time your incident response team is looking at encrypted files and a Bitcoin wallet address, the attackers have already been in your environment for days, sometimes weeks, and your backup systems are already gone. New analysis from Acronis confirms what threat researchers have suspected: ransomware actors now treat backup destruction as a required phase of every attack. If your cybersecurity recovery plan still centers on “restore from backup,” you’re planning for a scenario attackers have already engineered around.

Backup Destruction Is Now a Planned Attack Phase

The attack sequence has changed. Ransomware groups don’t encrypt production systems and hope for the best. They enumerate your backup environment during reconnaissance, establish persistence on backup servers and agents, and then delete or corrupt backup catalogs before the main payload runs. Some groups exfiltrate data first, destroy backups second, then encrypt. Three stages. Your incident response plan probably only accounts for the third.

The mechanism varies by group, but the targets don’t. Veeam agents, Acronis management consoles, Windows Server Backup, Commvault catalogs. Some groups go after the storage layer directly, deleting volume shadow copies and offline snapshots. Others compromise backup credentials and remove backup jobs from the management interface. The result is identical regardless of method: when you try to recover, there’s nothing to recover from.

The threat detection gap here is significant. Most organizations monitor production systems for anomalous behavior but apply far less scrutiny to backup infrastructure. A backup agent running at 2am isn’t inherently suspicious, which is exactly why attackers use legitimate backup tooling to perform the deletions. Your SIEM probably isn’t alerting on backup job deletions, catalog access outside normal windows, or unexpected schedule changes unless someone has explicitly built those rules. Most haven’t.

This matters beyond the obvious cost. Paying a ransom after backup destruction gives you almost no leverage. Decryptors often don’t work fully, and exfiltrated data still gets sold or published. Backups were never a perfect counter to ransomware, but they were at least a negotiating position. Systematic destruction eliminates even that.

When Ransomware Is Just the Cover Story

MuddyWater, the Iranian state-sponsored group also tracked as Mango Sandstorm and Static Kitten, recently demonstrated something worth sitting with: ransomware deployed as a false flag. The actual objective was credential theft. The encryption payload arrived at the end of the attack, not as the primary goal but as misdirection. Rapid7 documented the campaign in early 2026, and the infection chain started with a Microsoft Teams social engineering message impersonating IT support. A few exchanges later, the attacker had credentials. The ransomware arrived after the real work was done.

This is a meaningful shift in how you should interpret ransomware incidents. Encryption is increasingly a cleanup step or a distraction, used to disrupt forensic investigation, trigger insurance processes, and collect additional payment on top of whatever data was already stolen. Nation-state actors with financial motives can accomplish both objectives simultaneously: exfiltrate what’s valuable, then encrypt to disrupt the victim and cover the trail.

The Microsoft Teams vector deserves specific attention from a security hardening perspective. Teams is trusted inside most organizations because it’s authenticated, corporate-provisioned, and feels internal. That trust is precisely what makes it useful for social engineering. A convincing message from a compromised account or a lookalike external tenant gets more cooperation than a phishing email because users aren’t conditioned to be suspicious of it. Defense in depth for Teams should include restrictions on external domain communications, mandatory IT support verification procedures that bypass Teams entirely, and user awareness training that covers internal-looking social engineering specifically.

The attribution problem this creates for incident response is also real. If you treat every ransomware incident as a financially motivated criminal operation, you might miss that the primary objective was espionage, and that the most sensitive exfiltrated data left days before your threat detection triggered on the encryption event.

Your Cybersecurity Response Starts at the Recovery Layer

If ransomware actors are specifically targeting backup infrastructure, the defensive posture has to go where the attack goes. Treat your backup environment with the same cyber security hardening rigor you apply to production systems. Concretely:

• Isolate backup agents and management consoles on a dedicated VLAN with strict firewall rules. Backup systems should not be reachable from general workstation or server segments without explicit, logged access.
• Use immutable backup targets. Object storage with object lock, air-gapped tape, or cloud vaults with deletion protection enforced at the storage level prevent attackers from removing backups even with full admin credentials.
• Add backup-specific rules to your threat detection stack: alerts on job deletions, catalog access outside maintenance windows, and changes to retention policies or schedules.
• Apply separate credentials and MFA to backup management consoles. Backup admin accounts should not share credentials with production admin accounts.
• Test restores on a documented schedule. Recovery time assumptions built without real tests will fail you when you need them most.

On the false flag side, your incident response plan needs a pre-containment forensic preservation step that runs before remediation. If ransomware triggers and the first action is rebuilding affected systems, you lose the evidence that might show you whether credentials were harvested beforehand, what data was accessed, and whether this is a criminal or nation-state operation. Preserve memory dumps, network captures, and authentication logs before wiping anything.

The brute-force reality is this: ransomware groups have more time inside your environment than you assume, they know exactly where your backups live, and they plan around your recovery options before you’re aware there’s a problem. Stop treating backup infrastructure as an administrative afterthought and start treating it as a primary attack surface. Because that’s exactly what it already is.

Sources

• Why ransomware attacks succeed even when backups exist
• MuddyWater Uses Microsoft Teams to Steal Credentials in False Flag Ransomware Attack