Ransomware: recovering fast is not evicting the attacker

Of the organisations hit by more than one ransomware attack in the last twelve months, 30% suffered them on the same day. Another 29% within the same week. That is not a statistic about long-term recidivism: it is the fingerprint of access that was never closed. And one figure in the same report says it without ceremony: nearly one in four of those who paid (23%) paid because they could not get the attacker out of their environment. Giving the service back and taking control back are two different jobs, and only one of them is measured in hours.

The figure that is not the headline

The annual ransomware report Semperis published on 14 October 2026 carries the headline that has been going round all week: 69% of the victims surveyed were successfully attacked more than once in the previous twelve months, and 31% made more than one payment. In Spain the figure rises to 81%, with 29% paying the ransom. Striking numbers, and on their own they change no decision.

The number that does change a decision is a few pages further in, and it is the timing of those later attacks. Among those who suffered more than one:

• 30% suffered two or more attacks on the same day.
• 29% within the same week.
• 15% within the same month; another 15% more than a month apart.
• 11% were simultaneous.

Almost six in ten re-attacked organisations were hit again before the week of the first blow was over. The frequency table: among victims, 31% were attacked once, 40% twice, 24% three times and 5% four. Once you are on the list, the normal number is not one attack: it is two.

And the figure that cuts against us, before somebody else raises it: in the per-country highlights, what the report singles out for Spain is that 39% let a month or more pass between attacks, against 15% globally. Of the nine countries it is, precisely, the one that fits the same-day pattern least. So the argument holding up the rest of this article is not the speed of the second attack: it is that access stayed open for as long as it took — here, more often than elsewhere, weeks.

What the report asked, and of whom

The survey covers 1,200 IT and security professionals across nine countries — Spain among them — and eight sectors, with fieldwork by an international market research firm. And it has one inclusion criterion that decides everything: only organisations that had already suffered at least one successful ransomware attack took part.

That makes every percentage a conditional probability. Spain's 81% does not say eight in ten Spanish companies have suffered several attacks; it says that among those who had already suffered one, eight in ten suffered more. That is an enormous difference for the headline and none at all for you, if you are in the group: what the figure measures is precisely what happens after the first one, which is the part of the problem that is in your hands.

Second caveat, said out loud: a report about how badly identity gets recovered is published by a company that sells identity recovery. We do not throw it out for that — doing so would mean binning the only survey with Spanish data this month — but we do choose what to use: we keep the numbers that describe behaviour (when they came back, what they went after) and leave out the ones that measure the need for a product. And all of it is self-reported, not telemetry. We ran the same exercise in July with another vendor's report, when the thing to separate was >.

Two readings of the same day, and the same fix

A second attack on the same day allows two explanations, and the survey cannot tell them apart. One: the attacker never left. They still had an account, a scheduled task, a remote support tunnel or a valid Kerberos ticket, and encrypted again over what had just been restored. Two: the way in stayed open and somebody else used it — access to a compromised network gets resold, and a recent victim is a cheap, fast victim.

There is a third caveat that forces us to lower our voice, and it is in the same report: only 28% were back to normal in under a day, and half needed up to a week. In a good share of those same-day second attacks there was nothing recovered to celebrate yet: there was open access. What the figure proves is not that fast recovery fails; it is that recovering and closing are different things.

For what you have to do tomorrow, it makes no difference which: neither is fixed by restoring faster. Sarah Armstrong-Smith, of the UK Government Cyber Advisory Board, puts it in the report like this: "after an attack, most companies focus on how to recover as quickly as possible, not how to evict the attacker and regain control of the operating system." And then: "you can never trust that operating system again, because you don't know what the bad actors have done to it. They put in malware, they put in backdoors, so regardless of whether you pay the ransom and get the encryption key, you're going to have to rebuild your environment to a known good state."

What they attack is not what you restore

In 87% of the cases in the survey the attack went after the identity system: Active Directory in more than half (51%), Entra ID close behind (48%) and Okta in more than a quarter (27%). Meanwhile, only about half of the organisations surveyed keep dedicated identity backups or tooling that automates identity recovery, and only 60% had documented AD recovery procedures, 52% for Entra ID and 28% for Okta.

Your recovery plan, almost certainly, restores machines: the ERP virtual machine, the file server, the database. That is what has an RTO, what gets rehearsed and what appears in the sign-off. But what they attacked is the piece that says who is who. And identity has an unpleasant property a file server does not: restoring a backup from before the attack does not invalidate what they took. If they stole the >krbtgt account hash, that key still signs valid Kerberos tickets in the freshly restored directory, because it is the same key. You have given the state back; you have not changed the locks.

Tomer Bar, who leads security research at the firm behind the report, says it without ceremony: "a ransomware operation can use Active Directory to encrypt your entire organisation; with the right permissions, they can move laterally from machine to machine." The directory is not one more victim of the incident: it is the vehicle.

The procedure Microsoft publishes and almost nobody has written down

None of this is expensive consulting lore. Microsoft publishes the Active Directory forest recovery guide with the steps and their order, and it is worth reading if only to count how many of them are in your plan. Summarised, the initial phase says:

• Restore a single writeable domain controller per domain, starting with the forest root domain. And the condition that governs everything: "the DC must have a database that hasn't been influenced by whatever caused the forest to fail"; you need a trusted backup, thoroughly tested before it goes into the production environment.
• Do it isolated from the production network: cable unplugged on a physical server, network adapter removed or attached to another network on a VM. And do not join it to production until the data has been restored and verified.
• If intrusion is suspected, reset the passwords of every administrative account — Enterprise Admins, Domain Admins, Schema Admins, Server Operators, Account Operators — before installing further domain controllers, and replace gMSA accounts, because an attacker with administrative control may have taken the material needed to generate their passwords.
• Clean up the metadata of every other DC you are not restoring, seize the operations master roles, rebuild DNS… and one step that gives away whether anyone has actually read the document: raise the available RID pool by 100,000. The reason is subtle: objects created after the backup vanish on restore, but their permissions on the objects they could reach do not; if the pool is not raised, a new user can be issued the same SID as one of them and inherit access nobody granted.
• Reset the computer account password of that DC twice, and the krbtgt password twice — twice, because the history keeps the last two and a single reset would leave the previous one valid. And if the recovery is in response to a breach, reset the trust passwords too.
• And at the end, once the forest is standing: take a new backup of every restored DC. The backup you recovered from is no longer the one for next time.

Read it again thinking about the real day: none of that gets improvised at three in the morning with the managing director asking when the ERP comes back. It is hours of deliberate work, with machines deliberately switched off, while the company is stopped and every bit of pressure pushes the other way — turn it on, turn it on, turn it on. If that order is not written down and rehearsed beforehand, it will not be followed.

The above is for Active Directory on your own premises. If your identity lives in Entra ID or a provider like Okta, there is no cable to unplug and no forest to raise, and the procedure is a different one — break-glass accounts outside conditional access, token and session revocation, replacement of application secrets and workload identities, policy rollback. A different procedure, equally written down. The question keeps its shape: who can still authenticate tomorrow morning?

The clean backup is a decision about dates

Go back to Microsoft's condition: a backup "not influenced by whatever caused the forest to fail". To choose one you need to know when they got in, not when they encrypted. Those two dates are usually weeks apart. This is where an administrative decision taken months ago — log retention — becomes a technical decision on the worst day: if your identity log keeps 30 days and entry was 47 days ago, there is no way to tell which backup is clean, and the choice gets made by feel. We wrote about exactly that on Sunday: >.

And there is an earlier trap, the one that turns this into a dead end: the identity backup cannot depend on identity. A backup server joined to the domain it has to restore uses the same credentials the attacker already controls; its console, its jobs and its retention are within reach of whoever became domain admin. We told that story in full in >, and it is the first place we look when somebody shows us their plan.

When none of this is needed

If you are a twenty-person company with no Active Directory, laptops in Entra ID and the whole business in SaaS, do not build a forest recovery plan: you have no forest. Writing a procedure that does not match your infrastructure is worse than not having one, because it marks as covered something that is not. Yours is two break-glass accounts written on paper in a safe, session revocation tested once, and knowing which number to call if the tenant stops answering you.

And if you do have a domain but not the hands for all of this, two things pay off more than everything else combined: an identity backup that lives outside the domain and is immutable, and one timed rehearsal a year in which somebody restores that backup without help from the directory they are trying to recover. The rest can be written down over time. Those two cannot.

When we call an incident closed

The eight we use, which are not the report's. An incident is not closed because the ERP opens again:

• We know the date of entry, not just the date of encryption, and a log that reaches that far back supports it.
• Identity has been returned to a known good state: krbtgt and the restored DC computer account rotated twice, administrative passwords and gMSAs reset, trusts renewed, service accounts and application secrets replaced — not reviewed.
• The way in is closed and verified from outside, not "patched" in a ticket.
• No restored machine joined production before being verified, and there is a record of who verified it.
• There is monitoring on endpoints and servers for the following weeks, with somebody watching. The window where detection matters most is exactly the one spent catching your breath.
• There is a new backup, taken after recovery, and the previous one is kept aside for forensics and for the insurer.
• If AD CS is in play, the issuing authority has been reviewed and suspect certificates revoked. A stolen or forged certificate survives the double krbtgt reset and the whole restore, and keeps authenticating for however many years of validity it has left. It is the hole we have most often seen left open; we went through it in the certificate authority almost nobody audits.
• Somebody has put a date on the next drill and that record has an owner with a name.

We time those rehearsals: our last full recovery drill closed in 14 minutes. That is an internal figure and we give it for what it is — evidence that the procedure exists and gets executed, not a contractual promise nor a number that will repeat at your place. And half the value of that stopwatch is not the time but what it uncovers: the first time somebody tries to restore identity without the directory in front of them, the dependencies nobody wrote down show up.

We sell disaster recovery and we sell managed detection and response. What we do not sell is anybody's licences, so the recommendation we make the least money from — write the recovery order down and rehearse it — is precisely the one we push hardest, whether you do it with us or with anyone else. The least privilege principle that keeps an office account from ever touching a domain controller is not a product either: it is a design decision taken on an ordinary Tuesday, before it is needed.

The question the 30% leaves behind

If you fully recovered tomorrow, what would have changed compared with the day before the attack, other than the invoice? If the honest answer is "nothing, but it works again", the report has a number reserved for you, and it does not wait a year to collect: it waits until that same week.

Sources and method: the global figures (69% attacked more than once, 31% making multiple payments, timing split 30/29/15/15/11, frequency 31/40/24/5, 23% who paid because they could not eject the attacker, 87% of attacks against identity systems with AD at 51%, Entra ID at 48% and Okta at 27%, 50% with dedicated identity backups and 42% with automated recovery, 60%/52%/28% with documented recovery procedures for AD, Entra ID and Okta, 28% back to normal in under a day with half needing up to a week, and the per-country box where Spain appears with 39% letting a month or more pass between attacks) and both quotes — Sarah Armstrong-Smith and Tomer Bar — are taken from the Semperis Ransomware Risk Report 2026 (published 14 October 2026; 1,200 IT and security professionals, nine countries, eight sectors, only organisations with at least one successful attack), downloaded and read on 20 October 2026. The Spanish figures (81% successfully attacked on multiple occasions, 29% paid, 25% of attacks involving physical threats) come from the Europa Press wire of 16 October 2026 on that same report. The recovery procedure — a backup not influenced by the failure, network isolation, resetting administrative accounts and gMSAs, double reset of the computer account and krbtgt, trust passwords, metadata cleanup, raising the RID pool by 100,000 and a new backup at the end — is Microsoft's official Active Directory Forest Recovery — Perform initial recovery, consulted on 20 October 2026. We have no telemetry of our own for these incidents: what is ours here is the reading (the timing split as a signal of recoveries without eviction, the caution about the conditional sample and about who publishes the report) and the seven-condition list, which is our own. The 14-minute figure is an internal everyWAN drill: evidence, not a guarantee.