Could consequence modelling have stopped Ukraine's APT grid attacks?

Predicting the next attack against an energy grid does not require teams to identify the zero-day vulnerability or malware an adversary might use. It requires us to understand the conditions under which an adversary can turn access into operational control, and operational control into a consequence we cannot accept.

This report argues that consequence modelling would have exposed the built-in paths behind the attacks on Ukraine's grid in 2015, 2016 and 2022, early enough to act on them. A built-in path is any way a system's own setup lets access turn into control. An attacker may still get into the operational technology (OT) environment. Good security architecture stops that access turning into loss of control, damaged equipment or a long outage.

Why the Ukrainian grid?

Three attack campaigns between 2015 and 2022 targeted Ukraine's power grid. Impact on the people and utilities on the receiving end:

• 2015: Three regional power companies were hit within 30 minutes of each other¹. About 225,000 customers lost power for several hours². Crews restored power by hand. More than two months later, the utilities still could not operate their substations remotely².
• 2016: Attackers built tooling to cut power and then make restoring it unsafe. The full attack failed, but its design shows what they were after³.
• 2022: An evolved version of the same tool returned. CERT-UA said it stopped the attack, which was set for the evening of 8 April 2022, although an earlier CERT-UA alert reported nine substations briefly switched off⁴.

What consequence modelling would have surfaced

In each attack, starting from the consequence points at a built-in path that was visible before the attack landed.

2015: Modelling would highlight the remote access path, not the malware

Starting from 'loss of operator control' leads straight to the remote access path, and to months of warning in the logs before the power went out.

The path in

The 2015 attackers did not need an exploit to cut the power. They used stolen credentials, virtual private network (VPN) connections that appear to have lacked a second factor, and the utilities' own distribution management systems⁵. A consequence first exercise asks who can issue commands, from where, and with what proof of identity.

How early the warning was

CyOTE (Cybersecurity for the Operational Technology Environment), the DOE-funded precursor analysis programme at Idaho National Laboratory, puts likely initial access at May 2014, 575 days before the outage. It says earlier investigation could have cut the time to understand the attack 'by as much as 19 months'⁶. That is CyOTE's judgement, made with hindsight.

XINTRA's point is narrower. A utility that had already named loss of operator control as a consequence it could not accept would have had a reason to read its VPN logs long before the cursors moved.

The following is a figure from a Dragos Webinar that breaks down the 2015 attack at a high level across the organisations environment.

The attack on recovery

The 2015 attackers also went after recovery. They uploaded malicious firmware to serial-to-Ethernet devices so that 'even if the operator workstations were recovered, remote commands could not be issued to bring the substations back online'⁷. They wiped systems with KillDisk, reconfigured a UPS in at least one utility so the outage also hit its own buildings, and flooded a call centre with calls⁸. Malware got them in, but neither BlackEnergy 3 nor KillDisk switched the power off⁹.

Dragos reports the operators lost automated control 'for upwards of a year in some locations'¹⁰. A consequence model that names loss of remote restoration as unacceptable asks a second question: which field devices accept new firmware over the network, and how would you restore without them?

2016: Adversaries creating a restoration trap to cripple the grid

The CRASHOVERRIDE attack on Ukrenergo was built so that crews restoring power by hand would close lines with no working protection, and a consequence model asks about that condition before anyone attacks it.

What the attackers were after

The full attack failed, but its design shows the aim. Dragos reports they planned to open breakers, blind operators with a wiper, then disable protective relays³. Dragos itself says 'understanding what the group was attempting to achieve is conjecture – but sufficient information exists to make informed judgement on what the group's ultimate goal was in 2016'¹¹. Lost view is one problem. Lost protection at the moment of restoration is a much bigger one.

The warning was public

The weaknesses the 2016 protection attack relied on were public before it happened. The Siemens relay flaw had a vendor patch from July 2015¹². In March 2016, nine months before the attack, the Electricity Information Sharing and Analysis Center (E-ISAC) was already telling utilities to plan for 'Cyber conservative operations: Intentionally eliminating planned and unplanned changes as well as stopping any potentially impactful processes'¹³.

That is not an argument for counting patches. Dragos's Robert M. Lee, reports that 64% of patches leave the risk in place (see below), adds the caveat that patching 'reduces attack surface and is important'¹⁴. The point is that the consequence—crews closing lines without protection they could see—was foreseeable before December 2016. A patch list would not have told anyone to plan for it. A consequence model would.

2022: The scenario came back, and detection stopped it

The same family of tooling returned in April 2022, and this time detection and response stopped the consequence. That shows the scenario does not expire when the incident report is published.

The tool came back

Mandiant's analysis of INDUSTROYER.V2 shows a stripped-down version that speaks only IEC-104, a common grid control protocol, with configurations built for each target¹⁵. ESET had warned in 2017 that it could be adapted 'to any comparable environment'¹⁶. Mandiant's advice is to treat these tools 'as frameworks or capabilities'¹⁷, and XINTRA agrees.

CERT-UA said it prevented the attack, which was scheduled for the evening of 8 April 2022, although an earlier CERT-UA alert reported nine substations briefly switched off⁴. Mandiant says only that it 'impacted operational technology (OT) supporting power grid operations in Ukraine'¹⁸. In XINTRA's view, April 2022 is evidence that detection and response can stop the consequence when defenders understand what they are defending and how it can be manipulated.

The same built-in path?

The DOE guide describes Industroyer as having 'the capability to issue Unauthorised Command Messages (T0855) to change the state of electrical substation switches and circuit breakers directly'¹⁹. XINTRA assesses with low confidence that the 2022 built-in path is therefore the same one as in 2015 and 2016: the ability to issue breaker commands. The public record does not show how the 2022 targets were exposed to that path, so treat it as a question to ask, not a finding.

Why start from consequences?

In all three attacks, the condition that mattered was a path to control or restoration, not the malware, and you only find that path by starting from what you cannot accept losing. The US Department of Energy (DOE) starts from the same place, telling engineers to 'Expect that any digital component or system may be compromised at some point during its lifecycle'²⁰.

Consequence modelling starts from the outcomes a grid operator cannot accept, such as losing control, losing protection or damaging equipment, and works backwards from the assets that could cause the outcome. It does not start from another vendor's threat actor report or the latest supply chain attack. Start from what you care about.

For each outcome, it asks which functions and built-in paths would let an attacker with access cause it, and what would stop or reveal that before it lands. It is threat-led because those paths come from how real attackers have behaved. It is not a control list, and it is not an actor profile.

A patch list cannot answer the question

Most industrial control system (ICS) security programmes still count patches and controls. Dragos reports that '64% of vulnerability patches don't actually eliminate risk because the components being patched were already insecure by design'¹⁴. If nearly two-thirds of the fixes leave the risk in place, a list of fixes cannot tell you whether someone could take control of the grid away from you. Consequence modelling asks that question directly.

The DOE threat profile guide backs the approach

The DOE's Office of Cybersecurity, Energy Security, and Emergency Response (CESER) and critical infrastructure operators developed the Cybersecurity Threat Profile Development Guide²¹. It gives a practical method for turning fragmented threat updates into actionable insights aligned to an organisation's mission and risk priorities.

The DOE's cybersecurity threat profile helps organisations analyse and prioritise the threats most relevant to their operations. Organisations build a profile by exploring how specific attack scenarios might unfold, what vulnerabilities may be exploited, and what the consequences and impact on the organisation could be.

How should defenders get started?

Start by writing down what you care about and why. Then understand what you would need to declare that an action in OT is malicious, and who holds the logs and can make that call.

Expect much of it to sit in IT and the industrial demilitarised zone (DMZ), because that is where the earliest Ukrainian precursors appeared²². Make sure you can collect ICS network traffic ahead of time, because 'If you don't collect it ahead of time, it's gone'²³.

Three takeaways for defenders

1. Find the function someone else could run.

   • Inspect: one function whose loss you cannot accept, such as breaker control at a transmission substation. List every path that can issue commands to it.

   • Test: in a tabletop with an operator, an engineer and a responder, walk the 2015 path: stolen credentials, VPN, operator human-machine interface (HMI)²⁴. Run a legitimate remote session alongside it and ask what tells them apart.

   • Record: which paths have a second factor, who owns each, and what the test did not prove.

2. Know what proof you need before you need it.

   • Inspect: the logs and captures that would confirm a malicious command, and who holds them.

   • Test: replay the 2016 precursors (new accounts tried across 100+ endpoints²⁵) against your retention and alerting.

   • Record: the gaps that stay invisible, who owns them, and what the test did not prove.

3. Agree who can slow things down.

   • Inspect: who can move to conservative operations or de-energise a line²⁶.

   • Test: run an exercise where supervisory control and data acquisition (SCADA) view is lost and crews restore by hand, protection status unknown¹¹.

   • Record: the decision, the trigger, and what must be true before manual restoration starts.

Appendix: XINTRA's assessment caveat

Method. This report draws only on public post-incident reports, vendor analyses and government guidance, listed under Sources at the end. XINTRA's assessments in this report rest on that public reporting, not on the utilities' own architecture records or logs. Where XINTRA makes its own judgement, we say so and give a confidence level. The support for each outcome is the sources' reasoning, not measured results. Two findings would change our assessment: records showing the 2015 remote access path was not the deciding condition, or evidence that crews in 2016 could see protection status independently of the systems they had lost.

Attribution. Public reporting ties these attacks to the group most vendors call Sandworm. Dragos says the 2015 attack was attributed to the Sandworm team, and ties the 2016 operators, which it tracks as ELECTRUM, to Sandworm 'through confidential sources'²⁷. CERT-UA named Sandworm for April 2022⁴, and Mandiant attributes October 2022 to Sandworm²⁸. Vendor names do not map cleanly onto each other, and the argument in this report does not depend on who did it.