APT44: From Network Compromise to Industrial Disruption
An examination of Sandworm, Industroyer2 and the challenges of detecting threats against industrial control systems.
Introduction
When we talk about cyberattacks, we’re usually dealing with familiar consequences. Data theft, ransomware, disruption to business services or compromised infrastructure. But when an attacker gains access to an industrial control environment, the consequences can extend well beyond the systems themselves.
Electricity generation and distribution, water treatment, manufacturing and other critical services depend on industrial control systems to manage physical processes. Interfering with those systems can have consequences that aren’t easily resolved by restoring a backup or rebuilding a server.
APT44, more commonly known as Sandworm, is particularly interesting in this respect. The group has been associated with some of the most significant destructive cyber operations of the last decade, including attacks against Ukrainian electricity infrastructure.
One operation in particular, the attempted deployment of Industroyer2 in April 2022, provides an opportunity to examine how an attacker can move beyond conventional IT compromise and attempt to interfere directly with an industrial process.
It also raises some interesting questions from a detection engineering perspective. What opportunities might exist to identify this activity, what telemetry would be needed, and how much operational knowledge would a SOC require to recognise what was happening?
Who is APT44?
APT44 is the designation used by Mandiant for the Russian state-sponsored threat group widely known as Sandworm. The group has been linked to Russia’s military intelligence service, the GRU, specifically Unit 74455.
Its activities extend beyond conventional espionage. Sandworm has been associated with destructive malware, attacks against critical infrastructure and operations intended to disrupt essential services.
Perhaps its most significant characteristic is its demonstrated willingness to target operational technology.
In December 2015, an attack against Ukrainian electricity distribution companies resulted in power outages affecting customers across several regions. A further attack in December 2016 involved malware subsequently identified as Industroyer, also known as CrashOverride.
Unlike malware designed primarily to steal information or encrypt files, Industroyer was developed to communicate using industrial protocols found in electrical infrastructure.
That distinction matters. It demonstrates an understanding of the technologies used to operate the physical environment, rather than simply the Windows and Linux systems supporting it.
The 2022 Industroyer2 operation
In April 2022, ESET researchers and CERT-UA investigated an attempted attack against a Ukrainian energy provider.
The attackers had prepared a new variant of Industroyer, named Industroyer2, with destructive activity scheduled for 8 April.
The malware was designed to communicate with electrical substation equipment using IEC 60870-5-104, commonly referred to as IEC-104.
Unlike the original Industroyer, which supported several industrial protocols, Industroyer2 was focused specifically on IEC-104.
One of the more interesting findings was that the malware contained configuration information relating to the intended targets. This included addresses and parameters used to communicate with particular industrial devices.
This wasn’t simply malware scanning a network and hoping to find something vulnerable. It had been configured to interact with a particular industrial environment.
Alongside Industroyer2, the attackers deployed destructive malware targeting Windows, Linux and Solaris systems. These included CaddyWiper and several additional tools intended to destroy data and interfere with recovery.
The operation therefore involved two distinct but related elements: attempting to manipulate the industrial process while disrupting the systems that operators might need to regain control.
The attack was disrupted before the intended power outage, but the technical findings provide an insight into the level of preparation involved.
Initial access and movement into OT
One part of the operation that remains unclear is how the attackers originally gained access to the organisation and subsequently reached the industrial control environment.
ESET and CERT-UA were unable to establish the initial compromise method or the exact route taken across the IT/OT boundary.
However, Mandiant’s wider research into APT44 has documented the group’s use of compromised edge infrastructure, including routers and VPN appliances, to gain access to target networks.
Exploiting vulnerabilities in internet-facing equipment is therefore a credible attack scenario to consider, although it hasn’t been confirmed as the method used in this particular incident.
This is particularly relevant to industrial environments, where remote access infrastructure, vendor connections and systems bridging IT and OT networks can provide potential routes into otherwise segregated environments.
From a detection perspective, there are several areas worth considering: unusual remote access activity, unexpected connections between network zones, changes to firewall configurations and privileged access to industrial management systems.
The important point is that an attacker doesn’t necessarily need to exploit a PLC directly. Compromising the infrastructure around the industrial environment may provide the access needed to reach systems capable of controlling the process.
Understanding the industrial attack
To understand why Industroyer2 was significant, it’s worth looking at the protocol it was designed to use.
IEC-104 is an industrial networking protocol used primarily in electrical power systems. It allows supervisory control systems, such as SCADA platforms, to communicate with remote equipment over TCP/IP networks.
These communications allow operators to monitor equipment, receive status information and issue commands to control parts of the electrical network.
For example, a control system might use IEC-104 to communicate with a Remote Terminal Unit (RTU) or intelligent electronic device (IED) at a substation, including equipment responsible for operating circuit breakers.
Industroyer2 used this same protocol to communicate with its intended targets.
The malware contained hardcoded configuration information, including IP addresses, Application Service Data Unit (ASDU) addresses and Information Object Addresses (IOAs).
An IOA identifies a particular information point or controllable object within the industrial system. In an electrical substation, this might correspond to the status or control of a particular piece of equipment.
The presence of this information is significant because it suggests the attackers had acquired detailed knowledge of the target environment before attempting to execute the attack.
Researchers at Mandiant and Nozomi Networks identified how the malware used its embedded configuration to communicate with selected industrial devices and issue control commands.
From a security monitoring perspective, this presents an interesting problem.
The use of IEC-104 isn’t inherently suspicious. Neither is the transmission of a control command. Both may be entirely normal within an electricity distribution environment.
The challenge is determining whether the source of a command is authorised, whether the requested action is expected and whether it makes sense in the context of the process being controlled.
A conventional network security alert identifying IEC-104 traffic would provide very little value on its own.
Understanding what that traffic represents is where industrial monitoring and detection engineering become considerably more interesting.
What could defenders detect?
Looking at the operation from a detection engineering perspective, there are several areas worth examining.
Not all of these behaviours were confirmed in the public investigation. Some are detection hypotheses based on the techniques observed and the wider capabilities of APT44.
The distinction is important. We’re looking at what an organisation might reasonably monitor, rather than claiming that a particular detection would have prevented the attack.
Potential detection opportunities
| Activity | Potential telemetry | Detection opportunity |
|---|---|---|
| Compromise of edge infrastructure | VPN, firewall, appliance and authentication logs | Unusual remote access, configuration changes or suspicious administrative activity |
| Movement across IT/OT boundaries | Firewall, network flow and segmentation monitoring | Unexpected connections between enterprise and industrial network zones |
| Internal reconnaissance | Network telemetry, authentication and endpoint events | Unusual access to industrial assets or management systems |
| Scheduled execution of malware | Windows event logs, task scheduler and endpoint telemetry | Unexpected scheduled tasks or execution of unfamiliar binaries |
| Interference with legitimate processes | Endpoint process and file activity | Unexpected termination or renaming of industrial applications |
| IEC-104 communications | Passive industrial network monitoring and decoded protocol traffic | New communication sources, unexpected destinations or unusual protocol activity |
| Industrial control commands | IEC-104 command telemetry and operational context | Unexpected control operations, including commands against sensitive IOAs |
| Destructive malware | Endpoint telemetry, file activity and security events | Suspicious wiping behaviour, destructive execution or changes affecting recovery systems |
These are starting points rather than ready-made detection rules.
For example, identifying an unexpected IEC-104 command may be straightforward if the appropriate telemetry is available. Determining whether that command is malicious is considerably harder.
A legitimate engineer performing maintenance might generate unusual communications. Conversely, an attacker operating from a compromised but trusted system might issue commands that look entirely normal.
This is where asset inventories, communication baselines, engineering change records and operational knowledge become important.
Activity before the industrial payload
Although the initial intrusion path remains unknown, the operation involved activity that would be familiar to enterprise security teams.
Scheduled task creation, execution of unfamiliar binaries, interference with legitimate processes and deployment of destructive malware all present potential detection opportunities.
These are areas where established SIEM and endpoint monitoring capabilities may already provide useful visibility.
However, the challenge becomes more complicated when that activity occurs within an industrial environment where endpoint monitoring may be limited, system configurations are tightly controlled and security changes require operational approval.
Industrial network communications
Industroyer2 communicated using IEC-104, including commands intended to interact with equipment at electrical substations.
Potential monitoring opportunities include unexpected systems initiating IEC-104 sessions, unusual command activity, communications with previously unseen devices or control operations occurring outside expected patterns.
But these detections depend heavily on context.
A command that appears unusual to a SOC analyst may be part of legitimate engineering activity. Equally, a malicious command may look perfectly normal at the protocol level if it originates from a trusted system and uses expected addressing.
The presence of a valid command doesn’t necessarily mean the activity is authorised.
Destructive activity and recovery
The use of CaddyWiper and additional destructive tools is another important aspect of the operation.
The attackers weren’t solely focused on manipulating electrical infrastructure. They also attempted to interfere with supporting systems and potentially delay recovery.
That creates opportunities for conventional detection engineering, including monitoring for suspicious execution, destructive file activity and unexpected changes to critical systems.
It also highlights why visibility across both IT and OT environments matters.
An organisation monitoring only industrial protocol activity might miss important parts of the wider attack. Conversely, a SOC focused exclusively on conventional endpoint threats might fail to recognise the significance of commands being issued to industrial equipment.
Lessons for industrial security monitoring
There are several things I take away from the Industroyer2 operation.
The first is the importance of understanding the environment being protected. Industrial networks aren’t simply another collection of endpoints, and effective monitoring requires knowledge of the equipment, communications and operational processes involved.
The second is that traditional detection engineering still has a role to play. Many of the techniques used to establish control, prepare an attack and deploy destructive malware are familiar from enterprise environments.
But those capabilities need to be complemented by industrial visibility and an understanding of what constitutes normal activity.
The third is that attackers don’t necessarily need to exploit vulnerabilities in industrial controllers to cause disruption. Access to trusted management systems, knowledge of the industrial environment and the ability to issue legitimate protocol commands may be sufficient.
Finally, there’s the relationship between security teams and operational engineers.
An SOC can identify unusual communications or suspicious activity, but determining whether that activity represents a genuine threat may require knowledge held by the engineers and operators responsible for the process.
That relationship becomes particularly important when responding to an incident. Isolating a system, terminating a process or restarting equipment might be routine in IT, but potentially disruptive or unsafe in an operational environment.
Closing thoughts
Industroyer2 is an interesting example of how a cyberattack can move beyond compromising computer systems and attempt to interfere with physical infrastructure.
It’s also a reminder that detecting threats against industrial environments requires more than simply collecting additional telemetry.
The technology matters, but so does understanding how the environment operates, what normal behaviour looks like and how security monitoring can support the people responsible for keeping those processes running.
For organisations looking to extend their existing SOC capabilities into OT, that combination of conventional detection engineering and industrial operational knowledge is where much of the challenge lies.
Research and references
This article draws on publicly available investigations and technical research. The original analysis and discovery of Industroyer2 are credited to ESET Research and CERT-UA, with additional technical findings from Mandiant, Nozomi Networks and other industrial security researchers.
- ESET Research (2022) — Industroyer2: Industroyer reloaded — Original investigation of the 2022 incident, malware deployment and associated destructive tools.
- Mandiant (2022) — INDUSTROYER.V2: Old Malware Learns New Tricks — Analysis of malware configuration, industrial targeting and protocol behaviour.
- Nozomi Networks Labs (2022) — Industroyer2: Analyzing the IEC-104 Payload — Technical examination of IEC-104 communications and target-specific configuration.
- Mandiant (2024) — APT44: Unearthing Sandworm — Broader analysis of APT44, its operational history and initial access techniques.
- Netresec (2022) — Industroyer2 IEC-104 Analysis — Independent protocol analysis and laboratory-generated packet captures.
- MITRE ATT&CK for ICS — Industroyer2 (S1072) — Documented malware behaviours and associated adversary techniques.