Analysis of the Attack on Poland's Energy Sector (29.12.2025)

From Initial Access to System Wipe

Even a Junior Security Engineer understands that protecting the organization's perimeter is its first line of defense. There is no space for "Shadow IT" or the absence of a SIEM system, let alone other security measures.

In reality, many micro and small businesses struggle with perimeter protection. Startups too. The main problem: the business is launched with the goal of getting a product to market as quickly as possible to start generating revenue. Asset security falls to the background.

I have frequently encountered perimeter security issues where access to network devices or servers was obtained within the first hour of a penetration test. Moreover, beyond our team, attackers had often been "sitting" there for years. This was the case even when we were writing custom exploits rather than using public ones.

I want to emphasize that the Internet is crawling with bots scanning for all IP rangesand attackers quickly gain an understanding of exactly where they can "dive in." Of course, we can use passive reconnaissance services like Shodan, Censysand Fofa, which collect data on open ports and services across the Internet.

A clear example: open SSH access on your VPS. If you cannot monitor requests, simply install a Fail2Ban solution and leave it for two hours. You will be surprised by the number of brute-force attempts in your SSH logs, likely within the first 20-30 minutes. This simple example illustrates that we live in an era where any configuration error, lack of expertise, or neglect of cyber hygiene can cost you the permanent loss of all information and even your business.

During the Initial Access phase, vulnerabilities in Fortinet NGFW (core-level) were also exploited, which functioned as both Firewalls and VPN concentrators. Specifically, the well-known Fortinet SSL-VPN, which seems to receive a new critical CVE almost every quarter. It must be replaced with IPsec (starting with FortiOS 7.6.3, SSL VPN Tunnel Mode has been removed from both the GUI and CLI).

For instance, with a SIEM implemented that receives logs from Fortinet NGFW, you might see at least 1,200 brute-force attempts on an open SSL-VPN port within 24 hours—that's the work of bots. If you see significantly more failed authorization attempts, then someone is likely targeting your credentials specifically.

Screenshot from the incident report at the CHP Plant

RDP bookmark from the Fortinet configuration (screenshot from report)

This is an example of how attempts to take "shortcuts" for convenience often lead to very unpleasant consequences for a company. In fact, the attacker then proceeded with standard actions within the network—performing the Reconnaissance phase, identifying attack vectorsand gaining access to several workstations. All software used thereafter was entirely public—nothing custom: Advanced IP Scanner, Edge browser in private mode, Impacketand the rsocx tool for creating a Reverse SOCKS Proxy, which allowed them to bypass NAT and Firewalls from within the network.

After a successful reconnaissance phase, the attackers followed a familiar and classic path, well-known to anyone with experience as a Network Pentester or who has passed CPTS or OSCP certification exams:

• Dumping LSASS
• Creating copies of the SYSTEM and SAM hives
• Creating a shadow copy of the "C:" partition to hunt for ntds.dit

The attacker packed all the information into a zip archive and sent it to their server for further processing and data dumping. Interestingly, preparation for the attack began long before "H-hour": changes to the HMI configuration (opening SMB, firewall rules) were made as early as December 8th, meaning the attackers had at least three weeks to prepare for the final push.

Following this, the Fortinet configuration was stolen and new policies were injected into the device's operation. On the morning of 29.12.2025, DynoWiper (wiper malware) was uploaded to one of the domain controllers (DC):

Notably, the wiper files were accessible to all workstations in the subnet. The antivirus did not react to these files, but the EDR was able to identify potentially suspicious behavior through the modification of files subject to heightened control (typically system directories or specifically defined files) on more than 100 workstations. This highlights the value of deploying so-called canary files, designed to attract an attacker's attention based on their appearance or content.

Using KVM on one of the domain controllers, the attacker deployed a Tiny Core Linux image and was able to overwrite information on the storage drives with random data. Finally, an attempt was noted to change the RAID configuration on one of the servers.

In the case of the next incident (Manufacturing Sector Company), the attacker gained access via a Fortinet network device (core-level). This device previously had vulnerabilities through which its configuration was stolen and published by attackers on an online forum used by criminal groups. Once inside, the attacker deployed CLI scripts scheduled for weekly execution to maintain persistent access, even if user passwords were changed.

Particular attention should be paid to the data exfiltration method. One of the scripts on the FortiGate collected the results of command execution and sent them to an external Slack Webhook. This is a brilliant example of a Living off the Land technique, which allows bypassing standard DLP systems because traffic to hooks.slack.com is often permitted:

Not everything with a "good" name is legitimate

The attack then unfolded in a similar fashion to the CHP plant. A wiper from the LazyWiper family was used, whose code was likely developed with the help of AI.

Furthermore, after discovering credentials for which corresponding accounts existed in Microsoft 365, the attacker downloaded data from services such as Exchange, Teamsand SharePoint. They were particularly interested in files and emails related to OT network modernization, SCADA systemsand technical work being performed within the organizations.

Outdated OT Firmware as a Foundation for Plant Shutdowns

Here we move to the most fascinating part for us as specialists who understand the difference between IT and OT. The attack on industrial automation was not aimed at process manipulation (like Stuxnet, for instance), but at Denial of Service (DoS) through irreversible damage to the firmware and configurations of Hitachi RTU560 controllers. These are critical mechanical elements in substations.

Two key issues must be highlighted that led to Initial Access:

• The attackers utilized the built-in Default account, which is often ignored during configuration. This account has privileges to upload firmware via the web interface.
• Even the presence of a firmware signature verification mechanism did not stop the attack. First, the feature is often disabled. Second, there is also vulnerability CVE-2024-2617, which allows an authorized user to bypass this verification. Thus, the attacker would have achieved their goal in any case.

The attacker then uploaded a modified firmware file in ELF format, in which the first 240 bytes were overwritten with a sequence of 0xFF.

Screenshot from the report

Effectively, now when attempting to load such firmware, a read of exactly 0xFF is performed. This is a so-called "invalid opcode." It triggers a hardware fault, which leads to a system reboot. Since the "corrupted" firmware is already written to the flash memory, the device enters an infinite bootloop. Recovery requires physical intervention for every single device, which, across 30 substations, is a logistical nightmare.

In addition to RTUs, Hitachi Relion 650 relay protection devices (IEDs) were also targeted. The attack on them was carried out via FTP using default credentials, allowing the attackers to delete critical system files. This demonstrates that the attack affected not only the telemetry level but also the protection level of the substations.

Another troubling factor: the use of default settings (credentials). The attacker gained access to Mikronika RTU (controllers) and Moxa NPort systems:

• The attack on Mikronika RTU was carried out via SSH using the default root password. The destruction command was trivial (likely rm -rf /* or overwriting block devices via dd), leading to the total deletion of files and data.
• Moxa NPort devices are used to convert RS-232/485 to Ethernet. The attacker reset them to factory settings, changed the administrator passwordand set the IP address to 127.0.0.1 (localhost). This is a classic example of a "logic bomb": the device is running but unreachable from the network, as its interface is "listening" only to itself. Recovery is only possible via the physical console port on-site.

And finally, something that must be emphasized is once again the default account configurations. In some cases, Mikronika Syndis software was used as the HMI, installed on Windows 10 systems. The machines were configured using the standard password set during the deployment of a local administrator account.

The attacker utilized these credentials to gain access to the workstation via RDP. Subsequently, the attackers used PowerShell scripts to hide shared directories (SMB):

Screenshot from the report

• The PowerShell script performed a registry modification.
• A value of 0 was set for AutoShareWks and AutoShareServer (HKLM\System\CurrentControlSet\Services\LanmanServer\Parameters).
• This results in the disabling of hidden administrative SMB shares (C$, ADMIN$, IPC$).

The attackers then used Impacket and DynoWiper to disable the workstations.

Attribution of the Hybrid Attack

Currently, we are witnessing a fusion of toolsets and tactics that were previously attributed to various Russian intelligence services (as strange as that may sound). Let's briefly examine which indicators belong to whom.

In CERT group reports, this group appears under the name Static Tundra. This is a team that specializes in attacks on critical infrastructure. Analysis of the code used in the wipers and tools points to a connection with another well-known group—Sandworm.

1. Static Tundra

   Analysis of network indicators (IP addresses, proxy servers, compromised routers) clearly points to the Static Tundra group (also known as Berserk Bear, Dragonfly, Energetic Bear). Key indicators of their involvement include:

   • Exploiting vulnerabilities to compromise routers and using them as proxies.
   • "Harvesting" credentials and configuration data from VPN concentrators and gateways.
   • Long-term, covert presence in energy sector networks (previously used primarily for espionage).
2. Sandworm

   Regarding the tactical maneuvers and the core objective (judging by the report), we see a destructive signature—the hallmark of Sandworm (Voodoo Bear, Seashell Blizzard, GRU, unit 74455). Key indicators of their involvement include:

   • Use of wipers (KillDisk, CaddyWiper, Industroyer).
   • Attacks on OT with the aim of causing power outages.
   • Timing (winter, holidays)—elements of psychological pressure.

Strategic Recommendations for Strengthening Defense

After analyzing the CERT-PL report, I must emphasize that while it might seem the blame lies solely with leaked credentials or perimeter device configurations—and that simply changing passwords is enough—this is far from the case.

Given the cases examined, I want to highlight the security controls and network architecture principles that should be kept in mind. It is important to break these recommendations down into separate levels:

1. Network Architecture Protection
   • Abandon "flat networks." Under no circumstances should IT and OT devices be placed in the same subnet or VLAN.
   • Access to OT devices should only occur via Jump Hosts or PAW (Privileged Access Workstations) that do not have direct Internet access.
   • For OT devices, always keep firmware versions current. Yes, there are cases where this is nearly impossible due to certain additional solutions implemented in the company. In such cases—isolate access to the devices as much as possible, monitor traffic, respond immediately to incidentsand conduct Threat Hunting.
   • It's excellent if OT devices have "write protect" switches, which prevent unauthorized overwriting or interference with the device's software.
   • Deploy Deception solutions (for example, test T-POT) to divert attention and respond instantly to attacker activity.
   • Demand that OT equipment manufacturers implement hardware-based Secure Boot that cannot be disabled via software or bypassed through CVE/Zero-Day vulnerabilities.
2. OS Level Protection
   • Deploy or configure a SIEM (while a FIM module helps, Sysmon is often more informative in these scenarios) to monitor the integrity of critical OS files and track registry modifications.
   • Place Ransomware Canaries on critical workstations for rapid response when files are accessed. The EDR should respond to attempts to change these files with immediate host isolation.
   • Monitor login attempts under default accounts (Default, admin, root) and file upload attempts (SCP, HTTP).
   • Don't forget about EDR solutions in general. The standard Windows antivirus is not a solution that protects well even in many fairly trivial cases.
3. No IAM and PAM Without...
   • Implementation of MFA for access to all critical services.
   • Abandon permanent administrative rights. Administrators should receive rights only for the duration of the work (so-called JIT admin access).
   • Implement the AD Tier Model.
   • Implement LAPS for automated rotation of service account and local administrator passwords.
   • Transition from manual password management to automated systems that ensure password rotation and session isolation.
4. Incident Response Tabletop Exercises (TTX): Regular training of top management and technical teams to respond to scenarios of such attacks before they become a reality.

The December 29 incident serves as a vital lesson for the entire community. It demonstrated that in the era of hybrid warfare, cybersecurity is an inseparable part of a nation's physical security. On a positive note, the Polish energy grid held firmand at certain facilities, the attack was successfully repelled by technical means.

Our task is to use this experience to strengthen our own borders. Remember: security is not a state, but a process. And in this process, there are no "minor problems."

Stay safe!