Securing distributed critical systems when adversaries focus on disrupting access rather than taking control.
On 29 December 2025, coordinated cyberattacks targeted Polish energy infrastructure. The attacks coincided with severe winter weather and appear to have aimed at disrupting heat supply to end users by targeting renewable energy farms. The attackers succeeded in disabling controllers linking generation and distribution facilities but, thankfully, were unable to halt electricity production.
The cybersecurity industry often focuses on adversaries gaining control of infrastructure (“pwn’ing”) — and on solutions designed to deny that opportunity. In this incident, however, the objective appears to have been sabotage: denying everyone control by using wiper malware to render devices inoperable (“bricking”). That requires a different mindset for both security architects and engineers, and the incident postmortem provides a useful case study.
CERT.PL published a comprehensive incident report with a timeline and details on the attackers’ tools, techniques, and procedures (TTPs). For the purposes of this article, we focus on the attack on the grid connection point (GCP) and the destructive activity against remote terminal units (RTUs) implementing telecontrol functions at 110 kV substations.
Access to the RTUs was gained via internet-connected firewalls with a VPN concentrator. The VPN did not use multi-factor authentication, and logs of account access were wiped via a factory reset. RTUs reachable through the VPN had connectivity to protection relays and serial SCADA links. A web interface on each RTU was exposed to the GCP network, and the attackers accessed the “Default” account using default credentials. The permissions granted to this account allowed firmware upgrades.
The RTUs were running version 13.5.2, and a malicious version 13.5.3 was loaded during the attack. Although a secure update mechanism had been available since version 13.2.1, it was optional and was not enabled on the affected RTUs. In any event, a secure update bypass disclosed in CVE-2024-2617 could have been exploited and was not resolved until version 13.7.7.
The malicious firmware contained the value 0xFFFFFFFF, which corresponds to illegal instructions in the ARM instruction set. This caused a device reboot, and the process repeated. With the RTU stuck in a reboot loop, it was effectively bricked. Disabling the RTU resulted in loss of telemetry and telecontrol between the GCP and the distribution system operator.
Device security is only as strong as the weakest component in its supply chain. Adversaries don’t need a single catastrophic flaw — they piece together weak links across vendors, firmware, remote access, and configuration into a complete attack path. This incident shows how exposed edge devices, missing MFA, default credentials, and unverified updates can combine into destructive outcomes. A checklist approach to security fails to see the bigger picture that allows adversaries to create these kill chains.
Securing distributed critical systems requires threat and risk assessment (TARA) to model the attack trees adversaries use. At the system level, this is already required by national cybersecurity agencies regulating the NIS2 Directive. TARA is also becoming standard practice at the device and subsystem level under regulations such as the Cyber Resilience Act (CRA). Keysight services are accredited to international cybersecurity standards and can support security design reviews and risk assessments. Certified security architects conducting their own device assessments can also refer to publicly available threat catalogs. Keysight has contributed threat intelligence to EMB3D (e.g., MID-063, MID-059, and TID-101), and to ETSI vertical standards (e.g., Boot Managers) supporting the CRA.
These assessments cannot be one-time events performed at commissioning. They must be continuous, evolving to incorporate new security features, address newly identified high-risk components, and preserve backward compatibility. It is notable in this incident that a secure update feature that could have prevented the RTU attack was available months earlier but had not been rolled out.
The discipline of RAM (reliability, availability, and maintainability) can be neglected when devices are cheap and have short product lifetimes. Rebooting and updating devices can mask underlying reliability issues and create windows of opportunity for attackers. Deploying hot spares may improve availability, but it does not defend against scalable attacks that exploit device vulnerabilities. Maintainability is also under increasing scrutiny from right-to-repair advocates and environmental sustainability initiatives.
The discipline of secure-by-design shifts defense left by integrating security measures throughout the project lifecycle while building in RAM capabilities. There is little value in criticizing vendor design choices after the fact — attackers are already moving on to their next victim, possibly you. Instead, designers should aim to future-proof device security by making strong architectural choices now.
A foundational step is embedding a hardware root of trust. It helps defend against exploits like those described in the incident by authenticating firmware images, encrypting transfers, storing secrets, and enabling secure recovery. Critical infrastructure devices often have long lifetimes, so they must also be capable of supporting post-quantum cryptography and have the agility to adopt new algorithms as they emerge.
For security architects: This incident reinforces the need for end-to-end threat and risk assessment. Security is not a one-time vulnerability hunt — it is a continuous process spanning system architecture and the full lifecycle. Accredited industry services can support these assessments.
Hardware engineers: Resilience must be treated as a first-class design requirement. Irreversible states (such as boot loops, blowing eFuses, or permanently disabling JTAG recovery interfaces) should be scrutinized for how they could be abused to brick devices. A hardware root of trust is essential to authenticate maintenance and recovery operations.
For firmware engineers: This case study illustrates the sophistication of adversaries targeting operational technology in critical infrastructure. Features intended to improve customer experience can be exploited as paths to sabotage. The open-source Caliptra root of trust incorporates industry best practices from hyperscale device security management and can help teams secure devices at scale.
 |
 |
 |
 |
 |
 |
 |
 |
Leave a Reply