> ## Content Index
> Fetch the complete content index at: https://www.ostering.com/llms.txt
> Use this file to discover other available public pages before exploring further.

# Recovery Denial (RD)

- URL: https://www.ostering.com/taxonomies/critical-infrastructure/bks-recovery-denial/
- Published: 2026-11-05T21:00:00.000Z
- Updated: 2026-11-05T20:48:06.315Z
- Description: How a state adversary stops essential services being restored: 13 threats with mitigation principles, design measures and ATT&CK for ICS mappings.
- Author: Brett Crawley

[Taxonomies](https://ostering.com/taxonomies/) › [Critical Infrastructure](https://ostering.com/taxonomies/critical-infrastructure/) › RD · Recovery Denial

Making the outage last: what stops the operator restoring service, and what makes restored service untrustworthy. Part of The Campaign deck, ranked Ace to 2 by severity in the game. This page is part of the [Critical Infrastructure (Cyberwarfare) Threat Taxonomy](https://ostering.com/taxonomies/critical-infrastructure/), the reference for the Black Start card game.

![RD Recovery Denial taxonomy table, 13 entries: BKS-RD-A Long-lead equipment destroyed; BKS-RD-K Black start depends on the network; BKS-RD-Q Reinstall needs the vendor's servers; BKS-RD-J Devices bricked with bad firmware; BKS-RD-10 Project files and workstations wiped; BKS-RD-9 Backups reachable from the attack; BKS-RD-8 Restores bring the adversary back; BKS-RD-7 Recovery cannot be verified; BKS-RD-6 Incident communications taken down; BKS-RD-5 Vendors overwhelmed at once; BKS-RD-4 Key people worn out or targeted; BKS-RD-3 Replacements arrive as weak as before; BKS-RD-2 Insurance and contracts fail in war. Each row gives the threat, any public case, the mitigation principle and the design measures.](https://www.ostering.com/media/posts/181/critical-infrastructure-recovery-denial-taxonomy-table.png =1400x2162)

## Mappings at a glance

STRIDE, CAPEC 3.9, CWE 5.0, ATT&CK for ICS v20.0, the Cyber-Informed Engineering principles (main one first) and standards, entry by entry. The same mappings are in each entry below and in the [Excel, SKOS and STIX downloads](https://ostering.com/taxonomies/critical-infrastructure/#downloads).

![RD Recovery Denial mapping table, 13 entries: BKS-RD-A Long-lead equipment destroyed; BKS-RD-K Black start depends on the network; BKS-RD-Q Reinstall needs the vendor's servers; BKS-RD-J Devices bricked with bad firmware; BKS-RD-10 Project files and workstations wiped; BKS-RD-9 Backups reachable from the attack; BKS-RD-8 Restores bring the adversary back; BKS-RD-7 Recovery cannot be verified; BKS-RD-6 Incident communications taken down; BKS-RD-5 Vendors overwhelmed at once; BKS-RD-4 Key people worn out or targeted; BKS-RD-3 Replacements arrive as weak as before; BKS-RD-2 Insurance and contracts fail in war. Each row gives the STRIDE categories, CAPEC patterns, CWE weaknesses, ATT&CK for ICS techniques, Cyber-Informed Engineering principles and standards for the entry.](https://www.ostering.com/media/posts/181/critical-infrastructure-recovery-denial-mapping-table.png =1400x1198)

## Entries

<h3 id="bks-rd-a">BKS-RD-A · Long-lead equipment destroyed †</h3>

Transformers, turbines, large pumps and compressors can be damaged by commands that drive them beyond their limits. Replacements take months to make and ship, so a few minutes of control turn into a regional outage measured in seasons.

**Principle.** Equipment that cannot be replaced quickly must be protected by limits no command can override.

**Design measures.**

1. Protect long-lead equipment with independent, non-networked protection that trips before damage occurs.
2. Hold strategic spares or share them through sector pools, sized for loss of several units together.
3. Identify every item with a replacement time over a month and record how it could be damaged digitally.

*Mappings:* STRIDE D · [CAPEC-547](https://capec.mitre.org/data/definitions/547.html) · ATT&CK for ICS [T0879](https://attack.mitre.org/techniques/T0879/), [T0837](https://attack.mitre.org/techniques/T0837/) · CIE 1, 10, 2

<h3 id="bks-rd-k">BKS-RD-K · Black start depends on the network †</h3>

The systems needed to restart after total loss, such as black-start generators, their controls and their communications, share networks and accounts with the systems under attack. When the grid or plant goes down, the means of bringing it back is already compromised.

**Principle.** Restart capability must be isolated and able to work without the systems it restores.

**Design measures.**

1. Keep black-start plant and its controls on isolated networks with their own credentials and power.
2. Test black-start procedures with the normal control systems assumed unavailable.
3. Hold paper or offline copies of restart procedures, settings and contact lists at the sites that use them.

*Mappings:* STRIDE D · [CWE-653](https://cwe.mitre.org/data/definitions/653.html) · ATT&CK for ICS [T0826](https://attack.mitre.org/techniques/T0826/), [T0813](https://attack.mitre.org/techniques/T0813/) · CIE 10, 7

<h3 id="bks-rd-q">BKS-RD-Q · Reinstall needs the vendor's servers</h3>

Rebuilding HMIs, engineering tools and controllers needs software downloads, licence activation or a cloud account at the vendor. In a conflict those servers may be down, sanctioned, overwhelmed by every customer at once or attacked themselves, so recovery stalls at every site together.

**Principle.** Every system needed to restore the critical functions must be rebuildable from material the operator holds, with no outside connection.

**Design measures.**

1. Hold offline installers, licence files, firmware images and their hashes for every version in service.
2. Agree offline activation or licence escrow with each vendor in the contract.
3. Rehearse a full rebuild of a control system with the internet disconnected, and time it.

*Mappings:* STRIDE D · [CWE-1357](https://cwe.mitre.org/data/definitions/1357.html) · ATT&CK for ICS [T0826](https://attack.mitre.org/techniques/T0826/) · CIE 10, 9

<h3 id="bks-rd-j">BKS-RD-J · Devices bricked with bad firmware</h3>

Field devices, gateways and modems accept firmware remotely without signature checks or a protected recovery image. Overwritten with corrupt firmware, they stop working and must be replaced by hand, at every site, from spares that may not exist.

*Case:* Ukraine grid attack, 2015; Viasat KA-SAT modems, 2022.

**Principle.** Devices must refuse unsigned firmware and keep a recovery image an attacker cannot overwrite.

**Design measures.**

1. Require signed firmware and reject updates that fail verification.
2. Keep a protected boot or recovery image that cannot be written remotely.
3. Hold spares of each critical device type, configured and ready, sized for loss at many sites.

*Mappings:* STRIDE T, D · [CAPEC-638](https://capec.mitre.org/data/definitions/638.html) · [CWE-494](https://cwe.mitre.org/data/definitions/494.html), [CWE-1326](https://cwe.mitre.org/data/definitions/1326.html) · ATT&CK for ICS [T1693](https://attack.mitre.org/techniques/T1693/), [T0800](https://attack.mitre.org/techniques/T0800/) · CIE 2, 10

<h3 id="bks-rd-10">BKS-RD-10 · Project files and workstations wiped</h3>

Engineering workstations hold the only current copies of controller programs, configurations and network settings. Wiped together with the HMIs and historians, they leave the operator unable to rebuild the plant as it was, and recovery means re-engineering from memory.

*Case:* Ukraine grid attack, 2015; NotPetya, 2017; Industroyer2 attempt, 2022.

**Principle.** The configuration of the plant must exist in protected copies that do not depend on the engineering workstations.

**Design measures.**

1. Keep offline, versioned copies of every controller program and configuration, stored away from the control network.
2. Store engineering files in a managed repository with integrity checks, not on individual workstations.
3. Practise rebuilding an engineering workstation and reloading a controller from the offline copy.

*Mappings:* STRIDE D, T · ATT&CK for ICS [T0809](https://attack.mitre.org/techniques/T0809/) · CIE 10, 11

<h3 id="bks-rd-9">BKS-RD-9 · Backups reachable from the attack</h3>

Backups sit on the same network and accounts as the systems they protect, or have never been restored. The adversary destroys or encrypts them first, and the operator discovers during the crisis that there is nothing to restore from.

*Case:* NotPetya, 2017.

**Principle.** At least one copy of every critical backup must be offline, immutable and proven by restore tests.

**Design measures.**

1. Keep an offline or immutable copy of backups that the production accounts cannot delete or alter.
2. Test full restores on a schedule and record how long they take.
3. Separate backup administration credentials from the directory used to run the plant.

*Mappings:* STRIDE D, T · [CWE-530](https://cwe.mitre.org/data/definitions/530.html) · ATT&CK for ICS [T0809](https://attack.mitre.org/techniques/T0809/) · CIE 10

<h3 id="bks-rd-8">BKS-RD-8 · Restores bring the adversary back</h3>

Backups, golden images and project files may already contain the adversary's implant or altered logic. Restoring from them rebuilds the compromise, so the plant fails again soon after recovery and confidence in every later restore is lost.

**Principle.** Anything restored must be checked against a known-good reference before it is trusted.

**Design measures.**

1. Keep known-good hashes for firmware, images and logic, recorded at approval and stored offline.
2. Scan and compare restored systems before connecting them back to the control network.
3. Hold older restore points as well as recent ones, so a clean point predates any implant.

*Mappings:* STRIDE T · [CAPEC-441](https://capec.mitre.org/data/definitions/441.html) · [CWE-353](https://cwe.mitre.org/data/definitions/353.html) · ATT&CK for ICS [T0873](https://attack.mitre.org/techniques/T0873/), [T0889](https://attack.mitre.org/techniques/T0889/) · CIE 10, 8

<h3 id="bks-rd-7">BKS-RD-7 · Recovery cannot be verified</h3>

Historians, logs and configuration records may have been altered, so there is no trusted record of what the plant looked like before. Operators cannot tell which settings and data are good, and restart is delayed while every value is checked by hand.

**Principle.** There must be a trusted record of the plant's correct state that the adversary could not alter.

**Design measures.**

1. Write key configuration and process records to write-once storage outside the control network.
2. Sign approved configurations so their integrity can be checked during recovery.
3. Define in advance which values must be checked by hand before restart, and who signs them off.

*Mappings:* STRIDE T, R · [CAPEC-268](https://capec.mitre.org/data/definitions/268.html) · [CWE-353](https://cwe.mitre.org/data/definitions/353.html), [CWE-1293](https://cwe.mitre.org/data/definitions/1293.html) · ATT&CK for ICS [T0809](https://attack.mitre.org/techniques/T0809/), [T0832](https://attack.mitre.org/techniques/T0832/) · CIE 11, 10

<h3 id="bks-rd-6">BKS-RD-6 · Incident communications taken down</h3>

Phone lines, email and chat used to coordinate response run on the same networks or providers as the systems under attack. Flooding call centres or compromising email cuts responders off from each other and from the public at the moment they need to talk.

*Case:* Ukraine grid attack, 2015.

**Principle.** Incident coordination must have channels that do not depend on the systems under attack.

**Design measures.**

1. Provide out-of-band communications, such as radio, satellite phones or a separate messaging service, for incident teams.
2. Keep offline contact lists for staff, vendors, authorities and other sectors.
3. Prepare public messaging routes that work if the operator's own phone lines and website are unavailable.

*Mappings:* STRIDE D · [CAPEC-125](https://capec.mitre.org/data/definitions/125.html) · CIE 10, 7

<h3 id="bks-rd-5">BKS-RD-5 · Vendors overwhelmed at once</h3>

Many operators depend on the same vendor or integrator for recovery, and contracts assume one incident at a time. When every customer is hit together, the vendor's engineers, tools and spares are rationed, and recovery waits in a queue.

*Case:* Kaseya VSA and Coop Sweden, 2021; Supermarket refrigeration attacks, 2026.

**Principle.** Recovery must not depend on vendor capacity that every other customer will claim at the same moment.

**Design measures.**

1. Build in-house capability to restore critical systems without the vendor on site.
2. Agree surge support and priority by consequence with vendors, and test it.
3. Hold the licences, tools and installation media needed to rebuild without the vendor's help.

*Mappings:* STRIDE D · CIE 9, 10

<h3 id="bks-rd-4">BKS-RD-4 · Key people worn out or targeted</h3>

A few engineers know how the plant really works, and a long incident leaves them exhausted. They can also be targeted directly through intimidation, doxxing or attacks on their families. When they cannot continue, recovery stops.

**Principle.** Knowledge needed for recovery must be shared across enough people to survive a long campaign.

**Design measures.**

1. Document critical knowledge and train deputies for every role in the recovery plan.
2. Limit public information about the identities and roles of key OT staff.
3. Plan rest and rotation for incident staff from the first day.

*Mappings:* STRIDE D, I · CIE 12, 11

<h3 id="bks-rd-3">BKS-RD-3 · Replacements arrive as weak as before</h3>

Replacement devices and rebuilt systems come with default credentials, old firmware and factory settings. Restored in a hurry, the site is as exposed as it was before the attack, or more, and the adversary returns through the same route.

**Principle.** Rebuilt systems must be hardened to the same standard as the original before they go back into service.

**Design measures.**

1. Keep hardened build standards and configuration scripts ready to apply to replacements.
2. Update firmware on spares in storage, and record their versions.
3. Check credentials, remote access and firmware on every rebuilt site before reconnecting it.

*Mappings:* STRIDE E · [CWE-1188](https://cwe.mitre.org/data/definitions/1188.html), [CWE-1392](https://cwe.mitre.org/data/definitions/1392.html) · ATT&CK for ICS [T1694.001](https://attack.mitre.org/techniques/T1694/001/) · CIE 10, 8

<h3 id="bks-rd-2">BKS-RD-2 · Insurance and contracts fail in war</h3>

Insurance, support contracts and service levels may exclude acts of war or state action, and attribution can take months. The operator finds that the money and support it planned for recovery are disputed, while repairs wait.

*Case:* NotPetya, 2017.

**Principle.** Recovery funding and support must be planned for an attack that may be classed as an act of war.

**Design measures.**

1. Review insurance and supplier contracts for war, state-actor and force majeure exclusions.
2. Fund a recovery reserve, or agree public support arrangements, that do not depend on attribution.
3. Set out in contracts what vendors must do during a state-attributed incident.

*Mappings:* STRIDE D · CIE 10


## Public cases cited in this suit

- **Ukraine grid attack, 2015.** On 23 December 2015 attackers used three Ukrainian distribution companies' own control systems to open breakers, cutting power to about 225,000 customers. They also overwrote firmware on serial-to-Ethernet converters, wiped systems with KillDisk, tampered with backup power and flooded call centres with calls. *Attribution:* Attributed by the US Department of Justice (2020 indictment) to Russia's GRU Unit 74455 (Sandworm). *Sources:* [CISA ICS alert IR-ALERT-H-16-056-01](https://cisa.gov/news-events/ics-alerts/ir-alert-h-16-056-01); [MITRE ATT&CK campaign C0028](https://attack.mitre.org/campaigns/C0028)
- **Viasat KA-SAT modems, 2022.** As Russia invaded Ukraine on 24 February 2022, the AcidRain wiper bricked tens of thousands of KA-SAT satellite modems across Europe; about 5,800 Enercon wind turbines in Germany lost remote monitoring and control, and many modems had to be replaced. *Attribution:* Attributed by the EU, UK and US governments (May 2022) to Russia. *Sources:* [DatacenterDynamics: satellite outage impacts more than 5,000 wind turbines](https://www.datacenterdynamics.com/en/news/satellite-outage-impacts-more-than-5000-wind-turbines-across-europe/); [energate: Enercon, thousands of wind turbines need new hardware](https://www.energate-messenger.com/news/220914/enercon-thousands-of-wind-turbines-need-new-hardware)
- **NotPetya, 2017.** In June 2017 NotPetya, destructive malware disguised as ransomware, spread from a Ukrainian accounting software update. Maersk rebuilt its network and recovered its directory from a domain controller in Ghana that had been offline during a power cut; Mondelez's insurer cited a war exclusion, a dispute settled in 2022. *Attribution:* Attributed by the UK and US governments (2018) to the Russian military. *Sources:* [Redmond: the domain controller nightmare](https://redmondmag.com/blogs/scott-bekker/2018/08/domain-controller-nightmare.aspx); [The Record: Mondelez and Zurich reach settlement](https://therecord.media/mondelez-and-zurich-reach-settlement-in-notpetya-cyberattack-insurance-suit)
- **Industroyer2 attempt, 2022.** In April 2022 attackers planted Industroyer2 and disk wipers to switch off high-voltage substations of a Ukrainian energy company; CERT-UA and ESET stopped it before it ran. *Attribution:* Attributed by CERT-UA to Sandworm. *Sources:* [ESET WeLiveSecurity: Industroyer2](https://welivesecurity.com/2022/04/12/industroyer2-industroyer-reloaded); [TechCrunch: Ukraine disrupts attempt to take down energy provider](https://techcrunch.com/2022/04/12/ukraine-disrupts-attempt-by-russian-hackers-to-take-down-energy-provider)
- **Kaseya VSA and Coop Sweden, 2021.** In July 2021 ransomware was pushed through Kaseya VSA, a remote management tool used by managed service providers; Coop Sweden's tills stopped working and it closed about 800 stores for several days. *Attribution:* Attributed by the FBI to the REvil ransomware group. *Sources:* [The Record: Coop closes 800 stores after Kaseya ransomware attack](https://therecord.media/supermarket-chain-coop-closes-800-stores-following-kaseya-ransomware-attack/); [Truesec: Coop restored within 6 days](https://www.truesec.com/hub/blog/back-in-business-after-the-largest-ransomware-attack-of-all-time)
- **Supermarket refrigeration attacks, 2026.** Overnight on 11 to 12 October 2026 attackers forced the remote-managed refrigeration controllers of hundreds of French supermarkets into defrost, heating cabinets to as much as 50C; stock was destroyed and some equipment caught fire. CERT-FR told operators to disconnect the controllers or tightly filter access to them. A second wave on 2 November hit supermarkets and food businesses in Sweden, Belgium, Ireland, Luxembourg, Estonia and Italy, and five Danish companies, where the attacks were stopped quickly. Danfoss confirmed its products were involved, and France's cyber agency judged the campaign probably still under way. *Attribution:* Unattributed at time of writing; Paris prosecutor's investigation open. *Sources:* [The Hacker News: attackers heat French supermarket fridges](https://thehackernews.com/2026/10/attackers-heat-french-supermarket.html); [BleepingComputer: cyberattack shuts down refrigerators at French supermarkets](https://bleepingcomputer.com/news/security/cyberattack-shuts-down-refrigerators-at-french-supermarkets); [DR: what we know about the attacks on European supermarkets](https://www.dr.dk/nyheder/udland/det-ved-vi-om-hackerangreb-paa-europaeiske-supermarkeder); [Today.it: attacks on refrigeration in Italy, ACN alert](https://www.today.it/attualita/attacchi-hacker-frigoriferi-supermercati-italia-allarme-acn.html)

---

*© 2026 Jonathan Brett Crawley. Licensed under [CC BY-NC-ND 4.0](https://creativecommons.org/licenses/by-nc-nd/4.0/) with additional permissions: see the licence on the [overview](https://ostering.com/taxonomies/critical-infrastructure/#licence). † marks a physical-safety consequence.*
