They Deleted the Backups at the Disaster Recovery Site Too

On August 10, six government agencies — the FBI, CISA, the Defense Department's Cyber Crime Center, the NSA, the Secret Service, and the Republic of Korea's National Police Agency — published a joint advisory on a ransomware operation called Gunra. It runs 21 pages and is written for security engineers. Most of it will not interest you.

One sentence should.

In describing what Gunra's operators did to one victim, the advisory notes that the actors "deleted backup and archived data stored on backup infrastructure at both the primary data center and disaster recovery center before and after the ransomware deployment."

Read that again. Not the primary site. Both sites. The disaster recovery center — the thing your organization pays for precisely so that a disaster at the primary site does not become an extinction event — was reachable from the compromised network, and the attackers erased it on their way through.

If you have ever sat in a board meeting and heard "we have offsite backups and a DR site," you have been given a true statement that answers the wrong question.

The controls existed. They just didn't work.

Gunra first appeared in April 2025 as a variant built from the Conti ransomware source code that leaked in 2022. By January 2026 its operators had turned it into a franchise — a ransomware-as-a-service affiliate program advertised on criminal forums, complete with a management panel, a configurable payload builder, and documentation. The advisory notes the group has been recruiting penetration testers to serve as initial access brokers in exchange for a cut of the proceeds. Victims span healthcare, financial services, manufacturing, transportation, utilities, government, academia, and retail across five continents.

What makes this advisory worth an executive's time is not the criminal business model. It is the pattern of controls that were present and were defeated anyway.

The front door. The FBI observed Gunra getting in primarily by exploiting two Fortinet authentication bypass flaws — CVE-2024-55591 and CVE-2025-24472 — in internet-facing firewall and VPN appliances. Fortinet patched both in January 2025. Nineteen months later, a six-agency advisory names them as the primary way this group gets into networks. Somewhere in every one of those victim organizations, there was an asset inventory that did not include that appliance, or a patch cycle that did not cover it, or a maintenance window that kept getting deferred because the firewall was working fine.

Multi-factor authentication. At one victim, the actors did not phish an MFA code or spam push notifications. They modified the authentication processing files on the company's virtual desktop login server so that one specific attacker-chosen one-time password would always succeed. MFA remained enabled. It remained on the compliance checklist. It remained on the board slide. And it was, functionally, off — for the attacker only, indefinitely, and invisibly.

Backups. Volume shadow copies deleted before encryption. Backup and archive data destroyed at the primary data center and at the disaster recovery center. The recovery plan existed on paper. It was reachable from the same network the attackers already owned.

This is the distinction I keep returning to in Cyber Risk Is Business Risk: compliance measures whether a control is present. Security measures whether a control works when someone competent is trying to defeat it. Every organization in this advisory could have truthfully reported "MFA enabled, offsite backups maintained, firewalls patched per policy" to its audit committee. The reports would have been accurate. The company would still have been down.

The decision you will make in the first six hours

Here is the part that turns this from a technical story into a governance one.

The advisory discloses that researchers found a flaw in Gunra's Linux encryptor in March 2026. The malware generates its encryption keys using a weak pseudorandom number generator seeded from the system clock. Because the timestamp is recoverable from the encrypted files themselves, defenders can mathematically reconstruct the keys and recover the data without paying.

But that only works if the evidence survives. The advisory's incident response guidance for a Gunra Linux compromise is explicit: preserve the encrypted files, the file timestamps, the ransom notes, and the system logs.

Now picture the actual first hour of a real incident. Systems are down. Revenue is stopped. Somebody's instinct is to reboot the servers. Somebody else wants to wipe and reimage from a clean build to get production back. Both are reasonable-sounding operational reflexes. Both may destroy the timestamps that would have gotten your data back for free.

Meanwhile, Gunra's ransom notes give victims five to seven days to open negotiations before the stolen data goes to the leak site, and the advisory reports the group opens negotiations at figures in the tens of millions of dollars. That is deliberate pressure engineering. It is designed to make a frightened executive team decide fast.

The technical flaw in the malware is luck. Whether your organization is positioned to use that luck is governance — and it comes down to whether your incident response plan has a preservation step that executes before anyone touches a keyboard in anger, and whether the people who will be in that room have ever rehearsed it.

What to ask your CISO this week

Not "are we protected from Gunra." That question invites a reassuring answer about indicators of compromise and blocked IP addresses, and it will be technically true and strategically useless.

Ask these instead:

1. "Show me the last time we restored production data from backup — not tested the backup job, restored the data. What was the date, how long did it take, and who watched?" If the answer is a report from the backup software rather than a date and a duration, you do not have a recovery capability. You have a recovery expense.
2. "Can an attacker who owns our production network reach our backups?" The correct answer involves the words immutable and physically separate. "They're in a different data center" is not an answer — Gunra's victims had a different data center.
3. "Which internet-facing devices are running software with a publicly known exploited vulnerability right now, and what is the oldest one?" You are not asking for a number. You are asking whether anyone can produce the list at all. The Fortinet flaws in this advisory were patchable in January 2025.
4. "In the first six hours of a ransomware event, who decides whether we preserve or rebuild, and have they practiced that decision?" If the answer is a name and a tabletop exercise date, good. If the answer is a document, ask when it was last opened.

None of these are technical questions. They are questions about whether the money you have already spent bought you an outcome or a receipt. That is the only cybersecurity question a board is actually equipped to ask — and the only one that matters when the encryption starts.