They deleted the backups at both data centres

They deleted the backups at the primary data centre. And at the recovery one. Before launching the encryption, and again afterwards. The second site being far away saved it from nothing, and that is the part worth looking at slowly.

On 10 August 2026, six agencies — the FBI, CISA, the NSA, the US Department of Defense Cyber Crime Center, the US Secret Service and the Republic of Korea National Police Agency — published joint advisory AA26-222A on Gunra ransomware. It is one of those documents you skim: techniques, indicators, recommendations, the usual shape. The sentence that stopped us is in the impact section, and it comes with its own limits attached: "against one Gunra victim, Gunra actors deleted backup and archived data stored on backup infrastructure at both the primary data center and disaster recovery center before and after" the encryptor was deployed. The technique table draws the same boundary: "in one instance".

Before and after. That is not spite, it is method. You delete beforehand so the victim cannot restore while they negotiate, and you come back afterwards for whatever they created during the incident — which is exactly when everybody remembers to take a copy. The advisory documents it at a single victim, and one is enough for our purposes: the manoeuvre is now written down, in sequence, in a public document anyone can read.

When the recovery site is not a separate site

A recovery site exists so that a disaster at the primary one does not take the company with it. And it works: against fire, flood, a long power cut or the digger that cuts the fibre in the street, distance is exactly the right defence. The problem is the disaster it was not designed for. Against somebody logging in with a valid credential, the kilometres between the two rooms are covered in the time it takes a session to open.

In another section, the same advisory describes how this actor got hold of a set of keys of that calibre. From an already-compromised virtual desktop, the actors reached an access control server over SSH — the advisory identifies it as a Hiware unit — and stole a symmetric encryption key stored on it. With that key they decrypted the passwords for enterprise server accounts held in its database. Not a password: the whole drawer, and the key to the drawer.

The route, step by step, and how unexotic it is

It is worth seeing the whole chain, because there is not one piece in it you could not have yourself:

1. The door. Two authentication bypasses in FortiOS and FortiProxy: CVE-2024-55591 and CVE-2025-24472. Both have had patches since early 2025.
2. The wedge. Both flaws let an attacker abuse the firewall's scheduled tasks to create a persistent super-user account with a hard-coded password and a thoroughly reassuring name: forticloud-sync. Persistent means patching does not remove it. If you go looking for it on your kit today and it is not there, good; if you have never looked, that is tomorrow morning's job.
3. The credentials. secretsdump.py, from the Impacket suite, against several domain controllers, to extract account hashes from the NTDS files. From the same toolkit come psexec.py and smbclient.py, which is what they moved from machine to machine with.
4. The second factor. They modified the authentication processing on the corporate VDI portal so that one one-time password, of their choosing, always worked. MFA was still enabled. It still asked for the code. And they had a code that never expired.
5. The key cabinet. The access control server, over SSH from a compromised virtual desktop, and its symmetric key.
6. The exit. Data compressed and uploaded to MEGA, plus a custom executable, main.exe, to take what was in OneDrive and SharePoint.

Not one line of that route needs a zero-day. It needs a firewall missing two patches from eighteen months ago, a directory you can pull hashes from, and one place where the passwords for everything else are kept. We go into other people's infrastructure to audit it fairly often, and those three things together turn up a good deal more than anyone would admit in a meeting.

Two sites that accept the same credential are one site

Here is the idea we take away, which is not from the advisory but our own reading of it — and we are not the only ones making it these past weeks. When you draw redundancy, you draw boxes and cables. Two rooms, two arrays, two links, a replication arrow between them. What almost nobody draws is who can log into each box, and that is the layer where it is actually decided whether you have two sites or one.

We always put it the same way: failure is inevitable, an outage is a design decision. A disk dying in a system with replication is maintenance paperwork; the same disk in a system without it is a day of lost business. Credentials work exactly the same way, except that here the "disk" is a person who no longer works with you, or an unpatched firewall. If the account that administers site A also administers site B, you have replicated the data and replicated the single point of failure along with it. It is the geographical version of asking who can switch off your servers.

The domestic version of this we run into most weeks, and you do not need two data centres to suffer from it: the backup server joined to the very domain it protects, so that restoring the directory requires authenticating against the directory you have just lost. We have written about that circular dependency and what it costs to undo. It is the same mistake, two zeros smaller.

Immutability protects the blocks, not the door

The usual reaction to a headline like this is "we have immutable backups". Good: it is the right control and it works. A properly configured retention lock stops an administrator with every credential in the world from deleting anything inside the window, and that is exactly what you want to have. But it is worth knowing what falls outside that umbrella, because it is not trivial: backup jobs can be disabled, restore points that had not yet entered retention can be removed, a lost catalogue turns an afternoon's restore into several days of archaeology, and future policies can be rewritten. None of that breaks immutability. It just goes around it.

That is why the advisory's recommendation does not say "have immutable backups" and leave it there. It says: offline, immutable copies, in a physically separate, segmented location, and tested. All four conditions together — and the last one is the one almost nobody meets. We told the story of the Romanian land registry to explain why the word that really matters is "immutable".

The key-cabinet test: six checks for this week

None of these requires buying anything. Four can be answered in an afternoon with a sheet of paper; two have to actually be run, and those are the ones that matter.

1. Write down which credentials open both sites. Named accounts, not "the systems team". If the list has more than three entries, you have found this quarter's work.
2. Check what the backup system authenticates against. If it is the same directory it protects, you have the circular dependency. A local account, separate, that does not exist in the domain.
3. Find your key cabinet. The password manager, the bastion, the access control server: wherever the keys to everything else are kept. That server is not an office tool; it is the most critical system you own and it deserves its own second factor, its own network and its own record of who opens it.
4. Try to delete a restore point at site B using site A's credentials. This one has to be run, not reasoned about. It has to fail. If it works, you do not have two copies: you have one copy and a mirror of that copy.
5. Confirm there is a copy that cannot be reached over the network. Tape that comes out, a disk that gets disconnected, a storage account at another provider with credentials that do not live in your directory. Something that, to be deleted, requires a person to physically go somewhere.
6. Restore something. Today. With a stopwatch. Not "verify the backup": bring the service up and use it. Our last full recovery drill took fourteen minutes — an internal figure of ours, a test and not a contractual guarantee — and that number only exists because somebody timed it. If you have never timed yours, your RTO is an intention, not a number.

What the advisory does not say

It is us who have joined those two sentences together. The document says, on the one hand, that they took the key from the access control server and, on the other, that they deleted the backups at both sites. It does not say the second was done with the first, nor does it detail which credential opened the recovery centre. We have put it forward as a working hypothesis because it is the one we have most often seen turn out to be true, but it is not a fact of the advisory and it would be dishonest to present it as one.

Nor does it follow that having a second data centre is pointless. It is far from pointless, for what it was built for. What it cannot do is cover two risks with a single measure while nobody checks whether the measure works for both. And the last thing that does not follow: that you need to buy anything. Four of the six checks above are paper and a conversation. We make a living from the fifth and the sixth, so read that with the appropriate pinch of salt; but if you run them this week and the answers put your mind at rest, you have gained an afternoon and you owe us nothing.

Sources: everything this post asserts about the attack comes from a single document, joint advisory "#StopRansomware: Gunra Ransomware", AA26-222A, dated 10 August 2026, authored by the FBI, CISA, DC3, NSA, USSS and KNPA (PDF on ic3.gov, 21 pages, which is the copy we read). From it: the deletion of backup and archived data at the primary and disaster recovery centres, scoped to a single victim ("against one Gunra victim", and "in one instance" in the T1490 table); the two FortiOS/FortiProxy CVEs and the persistent forticloud-sync account created by abusing scheduled tasks (Table 5); secretsdump.py against multiple domain controllers to extract hashes from the NTDS files, with psexec.py and smbclient.py for lateral movement; the modification of the VDI portal's authentication files so that an attacker-designated one-time password always succeeded (T1556.006); the SSH access to the Hiware access control server and the theft of its symmetric key (T1555); the exfiltration to MEGA and from OneDrive and SharePoint via main.exe; and the verbatim recommendation of "offline, immutable backups stored in a physically separate, segmented location", tested. Translations from the English are ours. The reading that two sites sharing a credential are one site, what falls outside a retention lock, the six checks and the fourteen minutes of our last drill (our own internal figure, a test and not a guarantee) are ours and not the advisory's.