Publicly documented attacks on Ukrainian electricity systems in December 2015, December 2016 and April 2022 show a consistent pattern: attackers got into IT networks, reached operational controls, and tried to slow recovery. The defensive lessons are plain: control remote access, know your assets, isolate control networks, and keep a tested manual fallback.
What happened in December 2015?
On 23 December 2015, Ukrainian power companies had unscheduled outages affecting a large number of customers. A US interagency team that traveled to Ukraine, drawing on interviews with staff at six organizations, assessed that remote cyber intrusions at three regional distribution companies caused outages affecting about 225,000 customers. The team noted it could not independently review the technical evidence, though many independent accounts matched.
According to the account, the attacks at the three companies occurred within 30 minutes of each other, and people operated breakers remotely, using either operating system remote administration tools or industrial control system client software over VPN. The companies believed the actors had obtained legitimate credentials earlier. Afterward the actors ran KillDisk to wipe systems, damaged firmware in serial-to-Ethernet devices at substations, and scheduled disconnects for server uninterruptible power supplies. The team assessed these steps as attempts to interfere with restoration.
BlackEnergy malware was found at each company, reportedly delivered by spear-phishing emails with Office attachments. The report stresses that its role remained unknown and that any remote access trojan could have served. In July 2021 CISA updated the alert to say the US Government attributes the activity to Russian nation-state cyber actors.
What happened in December 2016?
ESET's research records that malware it named Industroyer was responsible for the blackout affecting Kyiv in December 2016. It could talk to industrial control equipment using protocols typical of electric power systems, including IEC-101, IEC-104, IEC 61850 and OPC DA. ESET also notes that in 2020 the US government indicted six officers of a Russian military intelligence unit for roles in multiple cyberattacks, including Industroyer.
What happened in April 2022?
ESET, working with CERT-UA, analyzed a new variant, Industroyer2, aimed at high-voltage substations at a Ukrainian energy provider. The destructive actions were scheduled for 8 April 2022, and artifacts suggested the attack had been planned for at least two weeks. Alongside it, attackers deployed disk wipers for Windows, Linux and Solaris. ESET believes a wiper was meant to slow recovery and stop operators from regaining control of ICS consoles. At the time of the report, ESET did not know how the attackers got in or how they crossed from the IT network to the ICS network.
What should defenders learn?
Take care with lessons drawn from three incidents. The sources describe what was observed, and your environment differs. That said, the 2015 alert's own mitigation guidance reads as a checklist.
Remote access is the front door. The alert advises limiting remote access, rejecting persistent vendor connections into the control network, and making access operator controlled and time limited, "procedurally similar to lock out, tag out." It also advises strong multifactor authentication that avoids similar token types that are easily stolen together, and the same standards for vendors and employees.
Know what is on your network. The alert calls first for information resource management basics: trusted hardware and software procurement, asset management automation, timely patching and planned technology refresh.
Isolate control networks. Keep ICS networks away from untrusted networks, shut unused ports and services, and use one-way paths where a task allows.
Assume the control system is hostile during an incident. The alert says contingency plans should allow safe operation or shutdown on the assumption that the ICS is working against the process.
Plan for wipers and firmware damage. If systems and field devices can be wiped or corrupted, recovery depends on offline backups, spare devices and manual operating procedures.
Block unexpected code. Application allowlisting suits static systems such as database servers and HMI computers.
What to do
- List every remote path into operational networks, including vendor ones, and remove any that are always on.
- Require multifactor authentication with different factor types on those paths.
- Maintain an automated inventory of hardware, software and firmware in operational environments.
- Review network separation and close unused ports.
- Keep offline, tested backups and spare hardware for critical field devices.
- Rehearse manual operation and safe shutdown on the assumption that systems are compromised.
- Run application allowlisting on static systems after baselining with the vendor.
- Include operational software in your supply chain inventory so you can answer what runs where.
Quick check
Was malware the cause of the 2015 outages?
The US team's report says outages were caused by remote intrusions where people operated breakers. BlackEnergy was found, but its exact role was unknown, and any remote access trojan could have been used.
What single control would you start with?
Remote access into operational networks. The 2015 alert emphasizes limiting it, removing persistent vendor connections and requiring strong multifactor authentication.
Sources
- CISA, ICS Alert IR-ALERT-H-16-056-01: Cyber-Attack Against Ukrainian Critical Infrastructure
- ESET Research, Industroyer2: Industroyer reloaded
Last reviewed: 18 October 2026.
