RTU Forensics: How Sandworm Jumped From the Office Network Into Poland's Grid
15.08.2026 ot-forensicsics-securitywiper-malwarecritical-infrastructure
On the morning of December 29, 2025, more than 30 wind and solar farms in Poland, along with a major combined heat and power plant, simultaneously lost remote control over their substations. CERT Polska’s report, published January 30, 2026, describes how the attacks targeted grid connection points feeding energy from wind and photovoltaic sources into the distribution system, with numerous automation devices including RTUs for telecontrol, local HMIs, protection relays, and communication devices such as serial port servers, modems, routers and switches. After gaining a foothold, the attacker carried out reconnaissance and then prepared a plan of destructive actions: damaging controller firmware, deleting system files, or launching custom-built wiper malware. When the plan was triggered, damage to the RTUs caused the stations to lose the ability to communicate with the distribution system operator’s systems, preventing remote control, although this did not affect ongoing energy production.
From FortiGate to RTU: crossing the IT/OT boundary
The initial access path is what makes this case so instructive for forensic investigators. At the CHP plant, the intrusion followed a more conventional enterprise path — initial access, persistence via a modified FortiGate configuration, and lateral movement into cloud services. The attacker used credentials obtained from the on-premises environment to attempt access to cloud services, and after identifying credentials with corresponding M365 accounts, downloaded selected data from services such as Exchange, Teams, and SharePoint. The targeting was purposeful: the attacker was particularly interested in files and email messages related to OT network modernization, SCADA systems, and technical work carried out within the organizations. Through this activity the actor gained access to privileged accounts allowing free movement within the plant’s systems — though when they attempted to activate the malicious software, its execution was blocked by the EDR software in use.
The tooling itself is notable. A PowerShell-based wiper dubbed LazyWiper overwrote files with pseudorandom 32-byte sequences to render them unrecoverable, with the core wiping functionality suspected to have been developed using a large language model. Against the renewable sites, a separate strain called DynoWiper was used, executed directly on the HMI machine. ESET later attributed the campaign to Sandworm with medium confidence, while CERT Polska noted infrastructure overlap with the cluster also tracked as Static Tundra, Berserk Bear, or Dragonfly.
Why classic forensics breaks down at the RTU
For incident responders, the real challenge isn’t attribution — it’s evidence collection on the embedded devices themselves. Mandiant’s DFIR framework for embedded systems notes that tools such as Redline, FTK Imager, and Volatility have set the standard for DFIR data across IT endpoints and OT intermediary systems, but based on experience, these tools have limited value when collecting data from embedded systems. This isn’t a tooling gap that will close soon: academic work on PLC memory forensics found that existing memory acquisition methods are either inapplicable in real-world investigations — requiring disassembly of the suspect device or a power cycle — or incomplete, capturing only partial memory contents. That exact dilemma applied in Poland: powering down an RTU to “preserve” it would destroy volatile runtime artifacts, while leaving it running risked continued wiper activity.
There’s also a physical dimension that IT-centric playbooks miss entirely. A protection relay or RTU at a grid connection point cannot simply be isolated without weighing safety and process consequences. As SANS puts it, ICS/OT incidents require response plans built around engineering context, process awareness, and operational continuity rather than IT recovery playbooks — without purpose-built planning, organizations risk turning a cyber event into a self-inflicted control system outage.
The practical takeaway for DFIR teams: evidence acquisition procedures for RTUs and protection relays must be pre-tested and documented long before an incident occurs — improvised field imaging is not an option. Firmware hashes, configuration backups, and network baselines for serial and Ethernet traffic belong in forensic readiness planning just as much as pre-agreed criteria for which devices can safely be taken offline. Above all, this case shows that the actual crime scene is the IT/OT boundary itself — the VPNs, private APNs, and reused credentials — and that’s precisely where forensic evidence needs to be captured before an attacker ever reaches the physical layer.
← Back to overview