Improving Detectability of Advanced Persistent Threats (APT) by Use of APT Group Digital Fingerprints

Abstract

Over the last 15 years, cyberattacks have moved from attacking IT systems to targeted attacks on Operational Technology (OT) systems, also known as Cyber–Physical Systems (CPS). The first targeted OT cyberattack was Stuxnet in 2010, at which time the term Advanced Persistent Threat (APT) appeared. An APT often refers to a sophisticated two-stage cyberattack requiring an extensive reconnaissance period before executing the actual attack. Following Stuxnet, a sizable number of APTs have been discovered and documented. APTs are difficult to detect due to the many steps involved, the large number of attacker capabilities that are in use, and the timeline. Such attacks are carried out over an extended time period, sometimes spanning several years, which means that they cannot be recognized using signatures, anomalies, or similar patterns. APTs require detection capabilities beyond what current detection paradigms are capable of, such as behavior-based, signature-based, protocol-based, or other types of Intrusion Detection and Prevention Systems (IDS/IPS). This paper describes steps towards improving the detection of APTs by means of APT group digital fingerprints. An APT group fingerprint is a digital representation of the attacker’s capabilities, their relations and dependencies, and their technical implementation for an APT group. The fingerprint is represented as a directed graph, which models the relationships between the relevant capabilities. This paper describes part of the analysis behind establishing the APT group digital fingerprint for the Russian Cyberspace Operations Group - Sandworm.

1. Introduction

The Stuxnet attack [1] in 2010 marks a paradigm shift in the cyberattack landscape. This was the first cyberattack on an Operational Technology (OT) system, also known as Cyber–Physical Systems (CPS), and was the first Advanced Persistent Threat (APT). The Stuxnet attack was both targeted and sophisticated. The campaign combined multiple elements in a tightly coordinated manner. In addition to delivering malware, it incorporated techniques for modifying control system code, exploiting zero-day vulnerabilities, and manipulating legitimate processes to remain undetected. This integration of technical exploits, operational knowledge, and stealth mechanisms made Stuxnet exceptionally difficult to identify and mitigate.

APTs are most often two-stage cyberattacks, involving both significant reconnaissance to gather details regarding the target and the actual cyberattack. APTs have become ever more sophisticated and targeted over the fifteen years since the Stuxnet attack, and today they are part of hybrid warfare. By an Advanced Persistent Threat (APT) in the ICS/OT context, we mean a highly resourced adversary conducting multi-phase operations over weeks to years, with objectives that include manipulation of physical processes. Such campaigns often rely on valid traffic, pre-acquired plant knowledge, short scheduled execution with little or no command-and-control (C2), and wipers that erase artifacts—conditions that undermine signature-, anomaly-, and protocol-conformance detectors. Therefore, in this paper we analyze multiple Sandworm operations across years to extract stable group-level invariants, which we later formalize as a digital fingerprint for detection (see Section 5).

There are a significant number of nation-state attacker groups, and their attack capabilities have advanced dramatically. These nation-state attackers are in many cases referred to as specific APT groups, and many are involved in both defensive and offensive cyberspace operations [2]. Another difference in the cyberattack landscape is that once the attackers have gained foothold inside a target, the compromise is achieved within minutes [3], while it takes an average of 207 days for defenders to detect and react [4]. In fact, existing detection paradigms have proven to be inefficient in detecting APTs. This includes behavior-based, signature-based, protocol-based, and other types of Intrusion Detection and Prevention Systems (IDS/IPS). This inefficacy stems from the fact that conventional IDS (based on signature-, anomaly-, and protocol-conformance) are tuned to novel byte patterns, sustained command-and-control, malformed PDUs, or statistical deviations from a baseline, whereas ICS-focused APTs such as Sandworm routinely (i) operate using valid and protocol-compliant (e.g., IEC61850-104 [5]) messages, (ii) avoid long-lived persistence and C2 by time-boxing execution via scheduled tasks, (iii) embed target-specific IPs and parameters (e.g., Information Object Addresses) in binaries, thereby eliminating noisy on-network discovery, and (iv) pair operations with wipers that remove host artifacts shortly after execution. These properties suppress signatures, minimize anomaly exposure, and evade protocol-conformance checks; documented cases include Industroyer (2016) and Industroyer2 (2022) [4,6,7,8]. Today’s detection capabilities are heavily dependent on highly skilled security analysts, that is, manual detection activities. Therefore, it is necessary to not only develop better detection capabilities but also to better understand offensive cyberspace operations, including Advanced Persistent Threat (APT) groups and attacks.

In an attempt to close the gap between attacker capabilities and time to detect, this work investigates APT groups and their capabilities. The aim is to understand how the various capabilities are implemented in practice, and from this information then map APT group capabilities by means of a digital fingerprint. The fingerprint models the implementation of the APT group’s capabilities across the known campaigns and cyberattacks that a specific group have performed or been part of. By analyzing the malware involved, such as Industroyer2, it is possible to model the activities that the malware performs on the target OT system, such as sending single or double IEC 104 [5] commands in a substation. Additionally, the order of activities involved in, e.g., Industroyer2 has a purpose; by identifying activities and placing these in a timeline, it is possible to create a detectable pattern. However, the attacker could change the order and replace malware; therefore, it is important to add variability and uncertainty into the detection models. To support the development of our detection model, we analyzed and documented the campaigns and cyberattacks attributed to the Sandworm group, along with a description of the implemented attacker capabilities. These implementations form the basis for the digital fingerprint and are used to improve its detectability. This paper includes both a summary of Sandworm’s capabilities and how these have been implemented. Our work does not describe the complete digital fingerprint of the Sandworm team, but provides examples to demonstrate the detection concept.

This paper delivers the following outcomes:

• Evidence-backed limits of conventional IDS for ICS APTs: We formalize the mechanism-level reasons that signature-, anomaly-, and protocol-conformance detectors miss ICS-focused APTs. We consolidate these in a detection–evasion matrix (

  Table 1. Detectors vs. Sandworm-style evasion patterns (with evidence).

  Approach	What It Flags	Why ICS APTs Evade	Evidence
  Signature-based	Known byte/host IOCs	Recompiled, target-specific binaries; valid IEC-104/61850 frames yield no novel signature; wipers remove artifacts	[7,8]
  Anomaly/behavior	Baseline deviation	Short, scheduled execution; maintenance confounders; low dwell	[3,4,7]
  Protocol-conformance	Malformed/forbidden PDUs	Industroyer(2) used correct TESTFR/STARTDT/single/double commands; impersonated master	[7,8]

  ) with case evidence (Section 2 and Section 4.1.2).
• New technical findings from an Industroyer2 analysis: Through static and dynamic analysis, we document (i) hard-coded target specifics (e.g., IPs and IOAs), (ii) strictly valid IEC-104 message sequences (TESTFR/STARTDT, single/double commands), (iii) time-boxed execution via scheduled tasks, (iv) coordinated wiper cleanup, and (v) minimal error handling (no retries, ignores unexpected IOAs). We then derive explicit detection implications from these observations (Section 4.1.2).
• APT group digital fingerprint for Sandworm: We instantiate a machine-interpretable graph-structured fingerprint as a directed graph over MITRE ATT&CK for ICS steps and encode sequence and state relations; from this, we derive rule sets for state- and sequence-aware detection (Section 5).
• Cross-campaign invariants and OT capability mapping: We provide a timeline of Sandworm’s OT activities and a capability comparison across BlackEnergy, Industroyer, and Industroyer2, highlighting invariants that persist when tools/IOCs change (Section 5).
• Illustration of detection concept: We show how the fingerprint would elevate risk for otherwise “normal” IEC-104 traffic when it occurs in improbable sequences or plant states (e.g., bursts of single/double commands outside maintenance). In addition, we demonstrate the specific Industroyer2 path on the fingerprint (Section 5).

The remainder of the paper is organized as follows: Section 2 provides background and discusses related work; Section 3 describes the core part of the substations and associated communication protocols; in Section 4, the Sandworm APT group and some of this group’s cyberattacks are described, while Section 5 outlines part of the APT group digital fingerprint for the Sandworm team; finally, Section 6 provides a short discussion and summarizes the main contributions of this paper.

2. Background and Related Work

The increasing convergence between Information Technology (IT) and Operational Technology (OT) in industrial environments has introduced new cybersecurity challenges. Industrial Control Systems (ICS) and Supervisory Control and Data Acquisition (SCADA) systems once operated in isolated and deterministic networks, but are now increasingly connected through standardized communication protocols such as TCP/IP. This connectivity enhances operational efficiency but significantly expands the attack surface, making these systems attractive targets for advanced cyber adversaries.

Numerous studies have investigated cyberattacks targeting digital substations, including attacks on IEC 61850 [9] -based automation networks [10], denial-of-service (DoS) attacks [11], exploits against the IEC 60870-5-104 protocol [12], and time synchronization attacks on the Precision Time Protocol (PTP) [13].

A growing body of research highlights how state-sponsored threat actors have exploited these vulnerabilities. One of the most prominent is the Advanced Persistent Threat (APT) group called Sandworm (APT44) [14,15]. Sandworm has demonstrated a deep understanding of both IT and OT domains, orchestrating high-impact campaigns such as the BlackEnergy attacks on Ukraine’s energy sector in 2015 [6], the deployment of Industroyer [16] in 2016, and the deployment of Industroyer2 [17] in 2022. These malware variants were specifically designed to manipulate industrial communication protocols such as IEC 60870-5-104, IEC 61850, and OPC DA, enabling the adversary to remotely open circuit breakers and disable protective mechanisms in electrical substations.

Researchers have emphasized the strategic nature of these attacks. For instance, Slowik [16] reassessed Industroyer as a protection-focused threat rather than merely a disruptive one, while Di Pinto et al. [18] analyzed TRITON, another milestone in ICS malware, which uniquely targeted Safety Instrumented Systems (SIS). These findings underscore the shift in threat actor focus from IT infrastructure disruption to direct interference with physical process safety and availability.

Parallel to malware-specific studies, broader surveys have examined systemic protocol vulnerabilities. Gaspar et al. [17] provided a comprehensive review of smart substation communication protocols and their inherent cybersecurity limitations. Protocols such as IEC 104, while operationally efficient, lack built-in encryption or authentication, exposing critical infrastructure to unauthorized command injection and impersonation attacks. These insights highlight the need for supplementary security layers such as encrypted tunnels, Intrusion Detection Systems (IDS), and behavioral monitoring.

Cyberdefense frameworks such as the Lockheed Martin Cyber Kill Chain [19] and NATO’s Allied Joint Doctrine for Cyberspace Operations (AJP-3.20) [20] offer structured approaches to threat analysis and mitigation. These models are increasingly being adapted to the ICS context, where understanding attacker behavior across the full cyberattack lifecycle—from reconnaissance to action on objectives—is crucial for effective defense.

Despite significant progress, the literature reveals a gap in fine-grained APT fingerprinting tailored to OT environments. Current approaches often rely on high-level textual descriptions, limiting their practical utility for detecting protocol-specific or timing-sensitive behaviors common in ICS-targeted attacks. There is an emerging need to build more context-aware threat profiles that reflect how attackers leverage system-specific knowledge such as hardcoded IP addresses, Information Object Addresses (IOAs), and scheduled task execution to disrupt or manipulate physical infrastructure.

This paper contributes to this research domain by analyzing the behavioral patterns of APT operations in power grid substations. By examining malware execution flows, protocol interactions, and adversary tactics across multiple case studies, we propose a framework for improving the detectability of ICS-specific APT campaigns through APT group digital fingerprinting.

Why Existing IDS Approaches Struggle with ICS APTs (Evidence and Failure Modes)

In ICS campaigns, adversaries can reach physical objectives while emitting only protocol-compliant traffic and short-lived host artifacts, thereby defeating detectors tuned to signatures, baseline deviations, or malformed PDUs.

Signature-based IDS: Effective for previously-seen payloads but blind to environment-specific recompiles and valid-frame OT actions; Industroyer/Industroyer2 issued legitimate IEC-104 sequences and produced few reusable byte-level IOCs [7,8].

Anomaly-/behavior-based IDS: Powerful in IT networks, yet prone to false negatives in OT where “abnormal” states overlap with maintenance/startup states. When APT actions are compressed into minutes and followed by wipers, there is insufficient dwell to accumulate statistical deviations [3,4,7].

Protocol-conformance/whitelisting: Raises alerts on malformed or disallowed PDUs. Industroyer(2) conformed to IEC-104 and impersonated a legitimate control station; conformance does not capture intent or sequence semantics [7,8].

Table 1 summarizes these gaps and the supporting evidence.

3. Power Grid Substations and Communication Protocols

Power grid substations are critical nodes within electrical transmission and distribution systems, serving as intermediary points where voltage levels are transformed to facilitate efficient power flow across long distances and into local distribution networks. Substation equipment such as transformers, circuit breakers, and protection relays are used to control the operation of the substation as well as to isolate the faults and maintain grid stability. Substations play a pivotal role in balancing load demand, ensuring operational continuity, and safeguarding infrastructure from cascading failures. Due to their centrality in power delivery and high degree of automation, substations are increasingly recognized as vital assets in the resilience and cybersecurity of modern power systems.

Substations rely on a range of specialized communication protocols to support monitoring, control, and protection functions within the power grid. Typical substation protocols are IEC 61850, DNP3 (Distributed Network Protocol), and Modbus. IEC 61850 is a modern object-oriented protocol designed specifically for substation automation, offering high-speed peer-to-peer communication, standardized data modeling, and support for advanced features such as GOOSE (Generic Object-Oriented Substation Events) messaging for time-critical operations.

IEC 60870-5-104 (commonly referred to as IEC 104) is a widely adopted tele-control protocol used for communication between control centers and substations over TCP/IP networks. It is an extension of the serial (peer-to-peer) IEC 60870-5-101 protocol that has been adapted for modern IP-based infrastructures, allowing for real-time data exchange across wide-area networks. IEC 104 supports both monitoring and control operations, and is designed to function reliably over potentially insecure and latency-prone networks. The protocol employs a client–server model in which control centers (masters) issue requests and substations (slaves) respond with data or execute commands. Data are transmitted in the form of Application Service Data Units (ASDUs), which carry information such as measured values, status indications, and command instructions. Typical command types include single commands (C_SC_NA_1) and double commands (C_DC_NA_1) used to open or close circuit breakers as well as set-point commands (C_SE_NA_1) for adjusting analog values such as voltage or frequency setpoints. In addition, the protocol supports interrogation commands (C_IC_NA_1) to request the current state of devices and clock synchronization commands (C_CS_NA_1) to align time across systems, which is critical for event logging and sequence-of-event analysis. IEC 104 also incorporates mechanisms for spontaneous transmission of data when changes occur as well as cyclical reporting, making it efficient for real-time grid supervision. Despite its operational utility, IEC 104 lacks built-in encryption or authentication in its original specification, making secure deployment a challenge in modern environments where cyber threats are a concern. This has prompted growing interest in supplementing the protocol with external security measures such as VPNs or transport-layer encryption in order to protect critical communication pathways within substations and between remote sites.

4. The Sandworm Group

The Sandworm group is a highly sophisticated Advanced Persistent Threat (APT), officially designated as APT44, and is widely believed to operate under the Russian military intelligence agency, the GRU. The group is known for conducting complex cyber operations targeting both Information Technology (IT) and Operational Technology (OT) infrastructures. These operations typically align with Russia’s strategic military and geopolitical objectives. Over the years, Sandworm has been linked to numerous high-profile cyberattacks, some of which have had significant global impact. A selection of these notable incidents is summarized in

Table 2. Major cyberattacks attributed to Sandworm (APT44).

Year(s)	Attack Name	Target(s)	Impact
2014–2016	BlackEnergy	Ukrainian power grid, media, government	First known cyberattack to disrupt power (Ukraine, 2015 [6]).
2016	Industroyer/CrashOverride	Ukrainian power infrastructure	Purpose-built ICS-disruption malware; caused power outage in Kyiv.
2016–2018	VPNFilter	Routers and NAS devices worldwide	Large-scale botnet campaign enabling espionage and sabotage.
2017	NotPetya	Ukrainian supply chain (MeDoc); global spread	Fake ransomware/wiper; caused $10B+ in global damages.
2018	Olympic Destroyer	PyeongChang Winter Olympics	Disruption of IT systems; sophisticated false-flag operation.
2022	Industroyer2	Ukrainian electric grid	Updated Industroyer malware; attempt to cause blackout during invasion.
2022	AcidRain	Viasat KA-SAT satellite modems	Wiper malware disabled satellite comms across Ukraine and parts of Europe.
2016–present	Operation Ghostwriter	Eastern Europe (esp. Poland, Baltics)	Info ops with cyberattacks (phishing, defacements, disinfo campaigns).

. We intentionally consider multiple Sandworm operations over a span of years in order to identify group-level regularities (capabilities and ordering constraints) that persist across campaigns; these regularities, not one-off IOCs, are the basis for the group fingerprint developed in Section 5.

Table 3. Sandworm (APT44) capabilities and tactics.

Capability	Examples/Tools	Description/Notes
Wiper Functionality	KillDisk, Olympic Destroyer, CaddyWiper	Destructive malware used to erase or corrupt data, often targeting critical infrastructure or during hybrid operations.
Custom Backdoors	BlackEnergy, Exaramel	Used for long-term access and command-and-control; often part of initial infection chains.
ICS/SCADA-Specific Modules	Industroyer, Industroyer2	Modules tailored for industrial protocols (e.g., IEC-104), demonstrating deep operational technology (OT) knowledge.
DDoS Capabilities	BlackEnergy (with plugins)	Supports large-scale disruption campaigns; used against media and energy sectors in Ukraine.
Persistence Techniques	Registry keys, Scheduled tasks	Common techniques for maintaining foothold across reboots and user sessions.
Credential Dumping	Mimikatz, custom scripts	Used for privilege escalation and lateral movement within the network.
Driver Exploitation	Vulnerable Windows drivers	Abuse of known driver flaws to escalate privileges or bypass protections like Driver Signature Enforcement.
Lateral Movement	Custom tools, PsExec-like methods	Internal network traversal to reach high-value targets, often post-compromise.
Defense Evasion	Legitimate binary abuse, false flags (e.g., Olympic Destroyer)	Techniques to avoid detection or mislead attribution, including use of signed binaries and mimicking other threat actors.

provides an overview of key attacker capabilities along with tools that have been used or developed by the Sandworm group. The table includes a brief description of each tool’s main characteristics and functionality.

4.1. OT Related Sandworm Examples

This section highlights several notable cyberattacks attributed to the Sandworm group. These examples provide insight into the group’s evolving tactics and strategic objectives. We collected several observations from previous analyses and conducted our own detailed analysis to complement these findings by investigating the most recent Sandworm attack, Industroyer2.

4.1.1. Industroyer-2016

Industroyer, also known by its alias Crashoverride, marked a significant milestone in the evolution of cyber threats targeting critical infrastructure. Operating without the need for continuous human oversight, it was the first known malware capable of autonomously controlling electrical substations. This represented a major leap in the sophistication of malware designed to disrupt physical systems.

Engineered with a modular architecture, Industroyer included several distinct components: a backdoor for remote access, a data wiper to erase traces and hinder recovery, and a launcher module to coordinate the execution of its payloads. What truly set it apart, however, was its suite of protocol-specific payloads tailored for industrial communication standards such as IEC 60870-5-101, IEC 60870-5-104, IEC 61850, and OPC DA. These protocols are commonly used in power grid automation systems, making Industroyer especially dangerous.

Interestingly, the malware was also designed with the potential to support additional protocols such as DNP3, although no evidence has surfaced indicating that these were actively used in known attacks. This extensibility suggests that the developers had a broader vision to create a flexible vendor-agnostic platform capable of causing prolonged power disruptions across a variety of environments and configurations.

The sophistication and general-purpose nature of Industroyer hint that its deployment may have been a proof-of-concept or a test run rather than a one-off operation. Its architecture implies a strategic intent to develop a reusable cyberweapon that could be adapted to different targets with minimal modification.

Among its various components, the IEC 60870-5-104 payload stands out as particularly impactful. This module was later refined and enhanced in the development of Industroyer2, underscoring its central role in the malware’s ability to effectively manipulate power systems.

Industroyer’s IEC 60870-5-104 module was one of its most critical components, enabling direct interaction with industrial control systems over standard communication protocols. Its core functionalities included:

• Scanning the local network to identify IEC-104 endpoints (target devices).
• Establishing TCP connections using the standard IEC-104 port (default: TCP 2404).
• Transmitting various Type Identification (Type ID) messages, including single commands, double commands, general interrogations, and measurement values.

The primary objective of this module was to disable automatic protection mechanisms and open circuit breakers, thereby disrupting the normal operation of electrical substations.

It is important to emphasize that there is no evidence suggesting an intent to coordinate simultaneous attacks across multiple substations in the original Industroyer campaign; however, had such synchronization been implemented, it could have resulted in widespread and prolonged power outages, potentially lasting several days.

This concept of coordinated substation attacks was later realized and refined in Industroyer2, which introduced more advanced capabilities for orchestrating multi- target disruptions.

4.1.2. Industroyer2-2022

Analyzing the behavior of Advanced Persistent Threats (APTs) requires a deep understanding of the structured methodologies and capabilities they employ throughout the various stages of an attack. To guide our analysis of Industroyer2, we adopt two complementary frameworks: the Lockheed Martin Cyber Kill [19,21], and the OT-specific two-stage cyber kill chain tailored for industrial control systems [22].

Our investigation draws on both publicly available intelligence such as prior technical analyses from reputable sources [7] and on our own hands-on examination of malware samples obtained from trusted repositories [23].We conducted a comprehensive analysis of the Industroyer2 binary using a combination of static analysis (reverse engineering) and dynamic analysis within a controlled sandboxed environment.

In the following sections, we present a summary of our key findings structured according to the distinct phases of the attack lifecycle.

Pre-Reconnaissance

Our analysis, supported by previous malware reports [7,8], reveals that Industroyer2 was developed with a high degree of target-specific knowledge embedded directly into the executable. This is evidenced by the presence of hardcoded configuration data, including IP addresses and protocol-level parameters. For instance, the analyzed sample contained the hardcoded IP address 10.82.40.105, which was embedded in the binary and used as the target endpoint. The malware’s entry routine includes this IP and the corresponding port, as illustrated in Figure 1.

Moreover, the malware was preconfigured with detailed knowledge of the target system’s IEC 60870-5-104 protocol implementation. This included specific Information Object Addresses (IOAs) for both single-point and double-point information types, along with their expected operational states (e.g., ON or OFF). Using the IEC 60870-104 protocol, a client can issue single or double commands to manipulate the state of devices within a substation. The malware leveraged this capability to send crafted packets that altered the state of known IOAs, as shown in Figure 2, indicating that the attacker had prior access to these sensitive configuration data.

Possessing such granular knowledge of internal IP addresses, protocol-specific object mappings, and expected device states strongly suggests that the threat actor conducted extensive reconnaissance prior to deployment. This reconnaissance could have been achieved through earlier intrusions, passive monitoring, or insider assistance. Notably, Industroyer2 was not a one-size-fits-all tool; it was tailored for multiple targets, with each variant containing unique hardcoded network and protocol parameters specific to its intended environment.

Initial Infection

The initial infection vector for Industroyer2 remains undisclosed, meaning that the exact method by which the threat actor gained access to the IT or OT network is still unknown. However, forensic evidence links Industroyer2 to the CaddyWiper malware, suggesting a coordinated and multi-stage attack strategy.

According to the ESET report [7], a scheduled task was configured to execute the Industroyer2 payload on 8 April 2022 at 16:10 UTC. Additionally, a second scheduled task was set to launch CaddyWiper exactly ten minutes later. The purpose of this secondary execution was likely to erase forensic traces and hinder post-incident investigation by wiping the system after Industroyer2 had completed its mission.

The presence of both the Industroyer2 executable and CaddyWiper files on the target network indicates that the attacker had either remote or physical access to the environment. While the exact method of access remains speculative, several plausible scenarios exist:

• Compromised credentials used to access the network via VPN.
• Use of another remote access mechanism or backdoor.
• An insider physically transferring the malware to the target system.
• Deployment via an unknown dropper that placed both Industroyer2 and CaddyWiper on the target device.

Although it is unclear whether Industroyer2 was delivered by another malware component and no such dropper has been publicly identified, the attack clearly demonstrates a well-orchestrated and compartmentalized approach. Each component had a distinct role, contributing to a broader synchronized operation designed to disrupt and conceal.

Persistency

There is currently no publicly available evidence indicating that Industroyer2 employed any form of built-in persistence mechanism. The executable itself lacked features typically associated with persistence, such as registry modifications, service creation, or autorun configurations.

However, this absence appears to be intentional and aligned with the malware’s operational design. In the context of this coordinated attack, persistence was delegated to a separate component responsible for establishing scheduled tasks. As reported in prior analyses [7], these tasks were configured to execute Industroyer2 at a specific time, eliminating the need for the malware to remain resident in memory or re-initiate itself autonomously.

This design choice is consistent with the objectives of malware targeting critical infrastructure. By avoiding persistent presence on the system, the malware reduces its footprint, minimizes detection risk, and ensures a more covert and time-controlled execution. In such high-stakes environments, stealth and precision often take precedence over long- term access.

Attack Actions

Based on our analysis, the execution of Industroyer2 follows a clearly defined sequence of steps, demonstrating a focused and protocol-compliant approach to disrupting substation operations. The following actions were observed during execution:

• Termination of existing processes: The malware begins by identifying and terminating processes responsible for communication between the substation and its control center. This is achieved using process enumeration and the TerminateProcess Windows API call (Figure 3).
• Establishing a TCP connection: It then initiates a TCP connection to the target substation using the hardcoded IP address and port 2404, the standard port for IEC 60870-5-104 communication.
• Sending test frames: The malware sends test frame messages (Figure 4) to verify the availability of the target. If no response is received, execution is aborted.
• Initiating communication: Upon receiving a valid test frame response, the malware sends a STARTDT (Start Data Transfer) message to begin communication. If the corresponding confirmation is not received, the malware terminates.
• Interrogation: A general interrogation command is issued to retrieve a list of active Information Object Addresses (IOAs).
• Issuing single commands: The malware sends single commands to set 28 IOAs to the ON state. These IOAs fall within the address range 130202–338501 (Figure 1).
• Issuing double commands: It then sends double commands to set 16 IOAs to the OFF state, targeting addresses between 1101–1404 (Figure 1).
• Terminating communication: A STOPDT (Stop Data Transfer) message is sent to end the session.
• Closing the connection: Finally, the TCP connection is closed, completing the attack sequence.

The malware’s behavior is notably straightforward and adheres strictly to protocol specifications. All TCP and IEC 60870-5-104 messages, such as STARTDT, single, and double commands, are valid and correctly formatted. There is no evidence of protocol misuse or exploitation of low-level vulnerabilities. Instead, the malware operates by impersonating a legitimate control station, leveraging its privileged network position. This simplicity reflects a deliberate design choice: the attacker did not need to over-engineer the malware, as standard protocol functionality was sufficient to achieve the intended disruption.

To further understand the malware’s dynamic behavior, we simulated several unexpected scenarios using a custom substation client simulator. These included:

• Absence of responses to test frame (TESTFR) or STARTDT messages.
• Responses containing previously unknown IOAs during interrogation.
• Failure of the substation to confirm state changes for specific IOAs.

Our findings indicate that the malware performs basic validation of communication readiness. If test frame or STARTDT confirmations are not received, execution halts. However, the malware does not verify acknowledgments for single or double commands. When receiving unexpected responses, such as unknown ASDU types or deactivation confirmations, the malware does not retry or adapt. Similarly, when presented with additional IOAs during interrogation, it ignores them entirely.

This behavior suggests a rigid and minimalistic implementation, likely reflecting high confidence in prior reconnaissance or a deliberate effort to keep the codebase small and focused. The lack of error handling or adaptability reinforces the notion that the malware was tailored for a specific well-understood environment.

The exact functions of the devices associated with the targeted Information Object Addresses (IOAs) remain unknown. However, our analysis revealed a distinct pattern in the commands issued by the malware: all single commands attempted to set their corresponding IOAs to the ON state, while all double commands were used to set IOAs to the OFF state. Because circuit breakers are typically opened by issuing an OFF command via a double command, this behavior raises questions about the nature of the devices controlled by the single commands.

Therefore, it is unlikely that the IOAs targeted by the single commands were circuit breakers. Instead, they may have represented other types of equipment or logical control points within the substation. Based on this observation, we propose two hypotheses to explain the command pattern:

• The ON and OFF states may be logical representations, with their physical effects determined by wiring configurations. If ON and OFF were reversed due to system setup, the attacker may still have achieved the intended outcome, indicating deep knowledge of the target environment.
• Alternatively, the single-command IOAs may not have controlled circuit breakers (which typically require double commands for safety). In this case, the attacker may have attempted to activate all available systems in order to increase load or create confusion, followed by selectively opening breakers using double commands.

Accompanying Tools

Industroyer2 was deployed as part of a broader coordinated cyber operation that included an accompanying wiper module known as CaddyWiper. This destructive tool was designed to inflict rapid and irreversible damage by targeting Windows operating systems, specifically by deleting user files and overwriting their contents to prevent recovery.

As with Industroyer2, CaddyWiper did not include any persistence mechanisms or command-and-control (C2) capabilities. Its role was purely destructive and time-bound, intended to execute once and leave no trace. The separation of responsibilities between the OT-targeting Industroyer2 module and the IT-focused CaddyWiper reflects a modular and compartmentalized attack strategy in which each component was tailored for a specific function within the overall campaign.

Covering Tracks—Obfuscation

CaddyWiper played a critical role in the attack’s cleanup phase, helping to conceal the presence and activity of Industroyer2. According to available reports, CaddyWiper was executed at least twice: once prior to the deployment of Industroyer2, and again shortly after its execution.

A scheduled task was configured to launch CaddyWiper exactly ten minutes after Industroyer2 had run. This delayed execution was likely intended to ensure that all traces of Industroyer2—including logs, temporary files, and other forensic artifacts—were removed from the system, thereby complicating post-incident investigation and attribution.

Summary of Industroyer2

The following points summarize the key findings from our analysis of Industroyer2:

• Clear separation of OT and IT roles: The executable responsible for Operational Technology (OT) actions was a standalone Portable Executable (PE) file that was focused solely on issuing IEC 104 commands. It did not include any IT-related functionalities such as persistence mechanisms or forensic evasion. This separation aligns with known tactics of the Sandworm group, which is believed to operate an OT-focused subgroup known as Electrum.
• Minimalist and protocol-compliant OT execution: The OT module executed its tasks using only standard well-formed IEC 104 protocol messages. There was no evidence of protocol misuse or exploitation. The malware simply leveraged its privileged network position along with pre-acquired knowledge such as IP addresses and IOA mappings to issue legitimate control commands.
• Modular IT components: The IT side of the operation was handled by separate independent modules. One or more of these modules likely deployed the Industroyer2 executable to the target environment. Scheduled tasks were created by another component, and the wiper module (CaddyWiper) functioned as a standalone tool responsible for post-execution cleanup.
• No OT-level zero-day exploits: The malware did not rely on any previously unknown vulnerabilities in OT systems. Its success was entirely dependent on having accurate reconnaissance data and access to the appropriate network segment.

Detection Implications

• On-wire: All IEC-104 PDUs (TESTFR/STARTDT/single/double) were valid, meaning that protocol-conformance sensors would not trigger.
• On-host: No long-lived persistence or C2; execution was scheduled and time-boxed, and a wiper removed artifacts minutes later, starving host anomaly detectors of dwell.
• Recon: IOAs/IPs were embedded, thereby eliminating noisy discovery on OT networks. Together, these implications explain why signature-, anomaly-, and protocol-conformance approaches were prone to false negatives for Industroyer2 [7,8].

5. APT Group Digital Fingerprint: Sandworm

In this work, an APT group digital fingerprint is a machine-interpretable and graph-structured model of a specific group’s recurring ICS capabilities along with their temporal and state relationships across campaigns. Concretely, we represent the fingerprint as a directed graph/Bayesian Belief Network (BBN) in which nodes map to MITRE ATT&CK for ICS techniques and phases, while edges encode ordering and state constraints observed across the group’s operations; from this, we derive rule sets for sequence- and state-aware detection (see Figure 5). This representation is well suited to long-horizon, multi-campaign APT activity because it captures cross-campaign invariants that persist even when byte-level IOCs, specific tools, or exact procedures change; it is explainable, incrementally updatable as new evidence appears, and portable across substations by binding rules to the plant state.

Since 2014, the Sandworm APT group has demonstrated a clear and sustained effort to expand its capabilities in targeting Operational Technology (OT) environments. Early activities focused on gaining access to critical infrastructure networks and conducting detailed reconnaissance to map out target systems. When sufficient access and intelligence were obtained, the group began developing modular malware tailored specifically for OT operations.

Modularity has been a defining characteristic of Sandworm’s approach. It allows the group to operate through specialized sub-teams, each responsible for a distinct phase of the attack lifecycle such as initial access, reconnaissance, malware development, and payload deployment. This structure enables parallel development and execution, increasing both efficiency and specialization. As one of the latest known malwares attributed to Sandworm, Industroyer2, exemplifies this modular strategy. It features clearly separated components for different OT functions as well as distinct modules for various stages of the attack, including persistence, synchronization, and post-execution cleanup.

Table 4. Timeline of Sandworm’s OT activities.

Time	Activity	Capabilities
2014–2015	Reconnaissance starts	Credential harvesting, information gathering of various types
2015	BlackEnergy deployed in Ukraine	Less sophisticated OT functions with focus on accessing control stations and manually issuing OT commands
16 December 2016	Industroyer (CrashOverride) attack on Pivnichna substation near Kyiv, Ukraine	First modular OT malware: separate modules for IEC-101, IEC-104, and OPC protocols; included wiper module and Windows persistence mechanisms
8 April 2022	Industroyer2 detected targeting Ukraine’s energy infrastructure	Compact, tailored OT modules per target; synchronized attacks across multiple substations; no persistence, designed for rapid execution

presents a timeline that illustrates the evolution of Sandworm’s OT capabilities from 2014 to today, while

Table 5. APT capabilities summary for BlackEnergy, Industroyer, and Industroyer2.

Capability Area	BlackEnergy (2015)	CrashOverride/ Industroyer (2016)	Industroyer2 (2022)
Initial Access	Spearphishing with malicious Office macros and BlackEnergy3 loader	Likely spearphishing or lateral movement from earlier compromise	No new vector; relied on previous compromise
Persistence	DLL side-loading; scheduled tasks	Registry run keys; service installation	No long-term persistence; scheduled execution
Privilege Escalation	PowerShell scripts; custom tools	Unknown but likely achieved; reused access	Elevated privileges already present
Defense Evasion	Custom packers, signed drivers, misleading filenames	Native ICS communication to avoid IT detection	Small footprint; fast execution; timed shutdown
Credential Access	Mimikatz, password dumping	Likely used; not central	Not disclosed; assumed pre-obtained
Discovery/Lateral Movement	PsExec, SMB, network scanning	ICS network scanning; knowledge of device layout	Manual reconnaissance evident; binary hardcoded for target
ICS-Specific Capabilities	None directly; relied on manual control	Native ICS protocol modules: IEC-101, IEC-104, OPC, IEC-61850	Custom IEC-104 messages; directly opened breakers
Command & Control (C2)	HTTP/S, Tor proxies	Local-only, time-triggered execution	No C2; single-use binary
Impact/Disruption	Breaker manipulation via HMI; triggered KillDisk	Automated breaker control; optional KillDisk wiper	Breaker manipulation and system corruption with wipers
Wiper/Destruction	KillDisk to damage systems post-attack	KillDisk re-used to delay recovery	CaddyWiper (Windows), ORCSHRED/ SOLOSHRED/ AWFULSHRED (Linux/Solaris)
Targeting Approach	IT & OT; operator involvement required	Protocol-agnostic, modular for reuse	Fully hardcoded to a single infrastructure layout

provides a detailed comparison of the capabilities exhibited by the three primary malware families targeting OT that have been attributed to the Sandworm group.

Motivated by these observations, the fingerprint precisely targets the failure modes described in Section 2 and Section 4.1.2; where detectors see only valid singletons, we encode sequence and state relations (e.g., bursts of IEC-104 single/double commands outside maintenance) as graph constraints and derive rule sets from them. This elevates risk for otherwise “normal” events when they occur in improbable sequences or plant states; in addition, it correlates time-coupled host events (e.g., scheduled OT action → wiper), thereby improving detectability without relying on brittle signatures or protocol violations.

Current cyberattack detections are based on behavior-based, signature-based, or protocol-based detection methods. All three detection methods represent distinct approaches to identifying cyberattacks, each with unique strengths and limitations. Signature-based detection relies on predefined patterns or “signatures” of known threats, making it highly effective against previously identified attacks but ineffective against zero-day exploits or evolving threats. Behavior-based detection, on the other hand, monitors system activities and user actions to identify anomalies or deviations from normal behavior, allowing it to detect unknown or polymorphic attacks. However, this method often suffers from higher false positive rates due to legitimate variations in behavior. Protocol-based detection focuses on analyzing network traffic and communication protocols for irregularities or violations of expected rules, providing strong visibility into network-layer threats but limited coverage for attacks occurring at the application or system level. In practice, these methods are often combined to balance detection accuracy, reduce blind spots, and provide layered defense against both known and novel cyber threats. For a concise comparison of these approaches and their ICS-APT failure modes, see Table 1.

However, Advanced Persistent Threat (APT) group attacks are extremely difficult to detect even when applying a combination of behavior-based, signature-based, and protocol-based approaches. APT groups typically operate with substantial resources, skilled teams, and the ability to acquire or develop new capabilities, allowing them to modify attack patterns, alter typical behaviors, and evade detection mechanisms. Our approach is unique because it does not rely on concrete signatures or protocol misuse. Instead, we propose a higher-level model that maps how a specific APT group operates by learning from its previous campaigns. This enables the identification of characteristics and patterns in capability usage and relationships rather than isolated technical indicators, supporting a more proactive and resilient detection strategy. In our APT group digital fingerprint, the APT capabilities summary from Table 5 is transferred into a directed graph with associated probability functions, implemented as (for example) a Bayesian Belief Network (BBN), as shown in Figure 5. In general, BBNs are probabilistic graphical models that represent set of variables and their conditional dependencies using directed acyclic graphs. When using this to improve detectability, rule sets are created based on the underlying analysis. Each phase has its own ruleset, and the rulesets across all phases are combined into sets of alternative attack paths. Note that Figure 5 only shows the structure of the directed graph and not the probability distributions associated with the transitions between the nodes of the graph. Also note that all transitions are initially considered as uniformly distributed; ongoing work is currently testing possible alternative attack paths in order to update the probability distributions for the various attack paths.

Figure 5 shows the BBN of the APT group digital fingerprint for the Sandworm group. The BBN is made up of relevant attack steps from MITRE ATT&CK for ICS, and models the core capabilities used by Sandworm in BlackEnergy, Industroyer, and Industroyer2. Each capability (or technique) has an associated color to help keep track of the state of each step, while pointed arrows model the alternative attack paths. For example, it is assumed that previously achieved access was used in Industroyer2. The attack in this case started with the Evasion step, where Native Commands are used (modeled using yellow color in Evasion step in Figure 6); the attack then moved directly to the Impact step to cause Loss of Control (modelled using green color in Impact step in Figure 6), as shown in Figure 6. More specifically, native IEC 104 commands were used and the attack had a very low footprint, including only two attack steps (Evasion and Impact). To detect such a low-footprint attack, detection methods need to compute the possible alternative attack paths and monitor all attack paths, including all variations (all possible combinations of attack steps and techniques that Sandworm could use based on their capabilities). Detection methods also require both process and system knowledge; for example, it is important to monitor the IEC 104 command sequences and associate them with the state of the process, such as whether the substation is in normal operation, maintenance, shutdown, etc. The reason for this is that while sending IEC 104 commands represents normal activity, it is not normal to send multiple single and double IEC 104 commands during normal operation, which should have been flagged as suspicious in the case of Industroyer2.

Although our BBN was developed for a single APT group, the underlying approach is generalizable. The set of nodes in the network represents common stages and capabilities observed across APT campaigns, which are broadly applicable to other threat actors. What differentiates one APT group from another is primarily the structure of dependencies between the nodes and the conditional probabilities that quantify their relationships, which together forms a unique fingerprint for each group. Consequently, while the specific digital fingerprint for another APT would have different parameterizations and possibly slightly adjusted nodes, the methodology would remain the same.

6. Discussion and Summary

Detecting APTs is difficult because of the many attack steps involved. Additionally, APT attacks are often performed over a long time period that includes several dormant periods. This makes it difficult to keep track of attacker actions and combine these into something that can be classified as potential or actual undesired activity. Furthermore, APT groups use capabilities native to the target system in many of their attacks, which means that there is no new communication to detect, just normal communication with malicious intent. Intent is not directly observable and needs to be coded into the detection, e.g., multiple single and double IEC 104 interrogation commands executed outside of a startup or maintenance period are suspicious, and even though the activities are permitted, the timing is not. This can be coded into detection mechanisms.

This paper has focused on the Sandworm APT group and their known cyberattacks and campaigns. This paper provides an overview of how Sandworm has evolved over the last ten years based on publicly available information and our analysis of malware and cyberattacks attributed to Sandworm. Furthermore, the paper discusses how to use this knowledge to improve detectability by means of APT group digital fingerprinting. In sum, we do not claim that all IDS are ineffective; rather, we delineate the specific conditions—valid-frame OT actions, compressed execution windows with scheduled tasks, minimal host persistence/C2, and target-specific embedding—under which signature-, anomaly-, and protocol-conformance methods are prone to false negatives and show how a state- and sequence-aware group fingerprint can counter these conditions [4,7,8].

Future work will include testing the APT group digital fingerprint for Sandworm in two Hardware-In-the-Loop (HIL) laboratories, namely, the Digital Station Enclave [24] and OpenLab [25].