Critical Infrastructure Under Fire: What IT/OT Security Teams Can Learn from Ukraine's Energy Grid

War does not stay on the battlefield. Since Russia’s full-scale invasion of Ukraine in 2022, one of the most consistent targets has not been a military base or a weapons depot — it has been the power grid. Substations, gas pipelines, thermal plants, and transmission lines have been hit repeatedly by missiles, drones, and cyberattacks in a deliberate campaign to freeze civilians and collapse critical systems.

For security professionals outside Ukraine, it is tempting to view this as a distant, geopolitical problem. It is not. The techniques used against Ukraine’s grid — spear-phishing, credential theft, SCADA manipulation, wiper malware — are universally applicable. They have already been adapted and used against energy infrastructure in Europe, the Middle East, and Southeast Asia. If your organization operates industrial control systems, a SCADA environment, or any IT/OT converged network, the Ukrainian playbook is your threat model.

This post distills the real operational lessons from a decade of attacks on Ukraine’s energy grid and translates them into concrete SOC and ICS security actions your team can take today.

A Decade of Attacks: The Ukrainian Grid as a Live Laboratory

2015 — The First Cyberattack to Cause a Physical Blackout

On December 23, 2015, attackers remotely accessed control systems at three Ukrainian electricity distribution companies and manually opened breakers at approximately 30 substations across the Kyiv and Ivano-Frankivsk regions. More than 200,000 customers lost power. The attackers used BlackEnergy malware, delivered via spear-phishing emails targeting Windows systems, then pivoted from IT networks into inadequately segmented ICS environments.

The access vector was not sophisticated. Credential reuse and prolonged reconnaissance gave the Sandworm group a foothold they exploited methodically. They also launched a denial-of-service attack against one utility’s customer call center to block coordinated response — a detail that reveals the attack was as much about psychological disruption as physical impact.

2016 — Industroyer: Malware Built to Speak ICS

In December 2016, the same adversary deployed Industroyer (also called CRASHOVERRIDE) — the first malware purpose-built to communicate in native ICS protocols: IEC 101, IEC 104, IEC 61850, and OPC DA. It could directly manipulate remote breakers without going through the operator’s SCADA interface. A wiper component was included to delete firmware and configuration data, extending recovery from hours to weeks. A single transmission substation in northern Kyiv went dark.

The significance was not the scale — it was the capability. Malware that understands industrial protocols is reusable infrastructure. It can be retargeted across any utility running the same equipment, anywhere in the world.

2022–2025 — Scale, Attrition, and Geographic Spread

After the full-scale invasion in February 2022, attacks shifted from surgical to attrition-based. Russia combined missile and drone strikes on thermal plants and gas infrastructure with sustained cyber operations against grid management systems. Ukraine’s available generation capacity fell from approximately 38 GW pre-war to just 12 GW by mid-2024.

The threat then spread beyond Ukraine. In December 2025, the Electrum threat group — the same adversary linked to the 2015 and 2016 Ukraine attacks — conducted what Dragos described as the first major cyberattack to directly target distributed energy resources (DERs), hitting wind, solar, and combined heat-and-power assets in Poland. The attack caused loss of view, loss of control, and denial-of-service conditions across multiple sites. No widespread outage occurred, but the strategic implication is unambiguous: adversaries have evolved from targeting centralized SCADA systems to attacking the distributed edge of the grid, where security controls are weaker and visibility is lower.

Five Lessons That Apply to Any Industrial Environment

Lesson 1: Perimeter Security Is Not Enough

The 2015 attackers entered through spear-phishing — the same initial vector used in the majority of enterprise breaches. Once inside the IT network, they moved laterally into the OT environment because the two were not properly segmented. A perimeter firewall provides no protection once an attacker holds valid credentials.

What this means for your SOC: Adopt an assume-breach posture. The critical question is not whether an attacker can get in — it is whether you can detect lateral movement from IT to OT before it produces operational disruption. Your SIEM must have visibility into both environments, and your detection logic must flag anomalous access to ICS-adjacent systems even when the credentials used are legitimate.

Lesson 2: IT/OT Convergence Creates Shared Risk

Modern industrial environments increasingly connect SCADA, PLCs, and HMI systems to corporate IT networks for monitoring, remote access, and ERP integration. This convergence is operationally necessary — and it is exactly why Ukraine’s utilities were vulnerable. The SSH tunnel through the firewall that enabled vendor remote access to ICS was an intentional configuration exception. It became the attack’s entry point.

What this means for your SOC: Every legitimate remote access path into your OT environment is a potential attack vector. These paths must be logged, monitored, and subject to behavioral alerting. Firmware changes, unexpected SCADA logins, and out-of-band ICS protocol traffic are all high-fidelity detection signals.

Lesson 3: Protocol-Aware Detection Is Non-Negotiable

Industroyer succeeded because it communicated using the same protocols that legitimate SCADA systems use — IEC 104, Modbus, DNP3. Standard IT security tools cannot distinguish malicious ICS traffic from normal ICS traffic because they do not understand those protocols. The attack was effectively invisible to conventional SIEM deployments.

What this means for your SOC: ICS/OT environments require OT-specific detection capabilities — either dedicated network monitoring tools that parse industrial protocols natively, or custom Wazuh decoders built to flag anomalous patterns in PLC logs, HMI event streams, and SCADA audit trails. Generic SIEM rules are insufficient.

Lesson 4: Recovery Capability Is a Security Control

In both the 2015 and 2016 attacks, Ukrainian operators resorted to manual operations — physically driving to substations to close breakers — because remote recovery was blocked. The 2016 wiper component deleted firmware and configuration data across affected systems. Recovery time stretched from hours to weeks not because the physical damage was severe, but because the digital recovery infrastructure had been destroyed.

What this means for your SOC: Incident response plans for OT environments must include offline recovery procedures. ICS configurations, firmware images, and network topology documentation should be stored offline, tested against recovery scenarios regularly, and accessible to OT personnel who may need to act independently of IT during an active incident.

Lesson 5: Adversaries Adapt Faster Than Defenders Patch

The December 2025 attack on Poland’s DER infrastructure is the clearest evidence of adversary evolution. Having mapped the defenses of centralized SCADA environments, the Electrum group shifted to distributed edge targets — smaller renewable assets with weaker security postures, longer patch cycles, and minimal monitoring. This is not coincidence. Sophisticated adversaries systematically identify where defenses are thinnest and invest there.

What this means for your SOC: Threat-informed defense requires tracking adversary evolution, not just responding to past incidents. ICS-specific threat intelligence feeds — Dragos WorldView, CISA ICS advisories, ICS-CERT — should feed directly into your detection engineering pipeline, with emerging TTPs mapped against your current asset inventory on a regular cadence.

Mapping the Attack Chain to MITRE ATT&CK for ICS

The diagram below maps the key stages of the Ukraine grid attacks to MITRE ATT&CK for ICS and shows where a Wazuh + OpenSearch + DFIR-IRIS SOC stack provides detection and response coverage.

flowchart TD
    A["Initial Access\nSpear-phishing / Credential Theft\nMITRE T0817, T0886"] --> B["Execution\nBlackEnergy / Industroyer\nDeployed on IT Endpoints\nMITRE T0853"]
    B --> C["Lateral Movement\nIT to OT Pivot\nvia Unmonitored Remote Access\nMITRE T0812"]
    C --> D["Collection\nOT Reconnaissance\nSCADA Topology Mapping\nMITRE T0840, T0888"]
    D --> E["Inhibit Response\nDoS on Call Center\nWiper on ICS Firmware\nMITRE T0804, T0838"]
    E --> F["Impact\nBreaker Manipulation\nGrid Blackout\nMITRE T0831"]
    A -.->|"Wazuh Endpoint\nand Email Rules"| G["SOC Detection Layer"]
    C -.->|"OpenSearch Lateral\nMovement Alerts"| G
    D -.->|"Custom ICS\nDecoder Rules"| G
    F -.->|"DFIR-IRIS Auto\nCase Creation"| H["Incident Response\nDFIR-IRIS + Shuffle SOAR"]
    G --> H

Where Open-Source SOC Stacks Cover — and Where the Gaps Are

A well-configured Wazuh + OpenSearch + DFIR-IRIS + Shuffle SOAR stack provides meaningful coverage for several Ukraine-class attack vectors:

Strong coverage:

Endpoint telemetry across Windows and Linux IT systems via Wazuh agents
Log aggregation and correlation across network devices, firewalls, and Active Directory
Automated alert triage and case creation via Shuffle SOAR and DFIR-IRIS
Threat intelligence enrichment via VirusTotal and AbuseIPDB for known IOCs

Gaps specific to ICS/OT:

Native parsing of ICS protocols (Modbus, DNP3, IEC 104) requires dedicated OT monitoring tools (Dragos, Claroty, Nozomi Networks) or custom Wazuh decoder development per protocol
PLC and RTU firmware integrity monitoring is not natively supported and requires custom integration
HMI log normalization varies significantly by vendor and requires bespoke decoder work per deployment

The practical recommendation for organizations with industrial environments is a two-layer approach: your existing SIEM handles IT-side visibility, while a dedicated OT network monitor provides protocol-aware coverage for the ICS environment. Both feed into a unified case management system so analysts work from a single pane of glass.

The Regional Context: Southeast Asia and Thailand

Thailand’s industrial sector — manufacturing, petrochemicals, utilities, ports, and data centers — operates significant volumes of ICS and SCADA infrastructure. The Thai Cybersecurity Act B.E. 2562 (2019) explicitly designates Critical Information Infrastructure (CII) operators across energy, water, transportation, banking, public health, and telecommunications as subject to mandatory cybersecurity standards. The National Cybersecurity Committee (NCSC) has mapped these requirements against NIST CSF and IEC 62443.

The practical gap in most Thai industrial organizations is not policy awareness — it is OT visibility. Most have reasonable IT security controls but have not extended logging, monitoring, or incident response planning into their operational technology environments. The Ukraine attacks demonstrate that this gap is exploitable by any adversary, not only nation-states. Ransomware groups now actively scan for exposed HMI and SCADA interfaces, and Southeast Asia is not exempt from this targeting.

For organizations subject to Thailand’s CII designation, integrating OT monitoring into a SIEM/SOAR workflow is both a regulatory expectation and a practical operational necessity.

Five Controls to Implement Now

Based on the ICS Five Critical Controls framework (SANS / Dragos):

1. ICS-Specific Incident Response Plan
Document offline recovery procedures for every critical OT system. Train OT operators — not just IT staff — on what to do if remote access is lost during an active attack.

2. Defensible Architecture
Enforce strict IT/OT network segmentation. All legitimate remote access into the OT environment should route through a dedicated, fully logged jump host. Remove all direct internet-facing connections from ICS components.

3. Visibility and Monitoring
Deploy passive network monitoring in the OT DMZ to capture ICS protocol traffic. At minimum, log all authentication events, remote access sessions, and firmware or configuration changes on SCADA and HMI systems, and forward them to your SIEM.

4. Remote Access Security
Eliminate persistent remote access accounts for vendor and maintenance access. Implement time-limited, MFA-protected sessions with full session recording. Alert on all out-of-hours access.

5. OT Vulnerability Management
Maintain an accurate asset inventory including firmware versions for all OT components. Prioritize patching for internet-adjacent assets and any component with known ICS-specific CVEs. Where patching is operationally infeasible, apply compensating controls through network segmentation and anomaly detection.

Conclusion

Ukraine’s energy grid is the most extensively documented case study in critical infrastructure cybersecurity. The lessons are hard-won and directly applicable everywhere. The attackers did not rely on techniques unique to Ukrainian utilities — they used methods that work against any under-monitored IT/OT environment. Spear-phishing, credential reuse, lateral movement, protocol-aware malware, and wiper tools are in active operational use against industrial targets globally today.

Defense is achievable. Ukraine’s grid did not collapse despite sustained, sophisticated attacks — because operators built manual recovery procedures, shared threat intelligence, and incrementally hardened their OT environments. The same approach applies to any organization: assume breach, build for detection and recovery, and extend SOC visibility all the way to the operational technology layer.

Simplico builds SOC integration pipelines and custom ICS monitoring solutions for Thai industrial and enterprise environments. If you are evaluating how to extend security monitoring into OT environments — or need a Wazuh-based SOC that meets Thailand’s CII cybersecurity requirements — contact us at simplico.net.

Simplico Co., Ltd. is a Bangkok-based software and AI engineering studio specializing in security operations, enterprise systems integration, and AI/RAG applications.