SoK: A Reality Check for DNP3 Attacks 15 Years Later

Highlights

What are the main findings?

• Simplification of several complex theoretical attacks on DNP3 shows they can be executed with simpler methods, such as bypassing IP allow-list restrictions using ARP spoofing and dynamic NAT table modifications.
• Practical implementation of man-in-the-middle attacks demonstrated the ability to bypass IP allow-list restrictions on IEDs in a controlled environment, addressing challenges like sequence numbers and checksum adjustments.
• Real-world defense mechanisms, including protocol hardening, encryption, and anomaly detection, effectively mitigate or prevent DNP3 attacks when implemented correctly.

What is the implication of the main finding?

• Recognizing that simpler methods can replicate complex attacks highlights the importance of robust basic security measures, such as IP allow-listing and protocol monitoring.
• The feasibility of bypassing standard configurations necessitates the integration of advanced authentication and encryption protocols in OT systems to strengthen security.
• Defense-in-depth strategies, supported by regulatory standards like NERC CIP, underscore the importance of operational measures, including continuous monitoring and SOC practices, for effective cybersecurity in critical infrastructure.

Abstract

OT (operational technology) protocols such as DNP3/TCP, commonly used in the electrical utility sector, have become a focal point for security researchers. We assess the applicability of attacks previously published from theoretical and practical points of view. From the theoretical point of view, previous work strongly focuses on transcribing protocol details (e.g., list fields at the link, transport, and application layer) without providing the rationale behind protocol features or how the features are used. This has led to confusion about the impact of many theoretical DNP3 attacks. After a detailed analysis around which protocol features are used and how, a review of the configuration capabilities for several IEDs (Intelligent Electrical Devices), and some testing with real devices, we conclude that similar results to several complex theoretical attacks can be achieved with considerably less effort. From a more practical point of view, there is existing work on DNP3 man-in-the-middle attacks; however, research still needs to discuss how to overcome a primary hardening effect: IEDs can be configured to allow for communication with specific IP addresses (allow list). For purely scientific purposes, we implemented a DNP3 man-in-the-middle attack capable of overcoming the IP allow-list restriction. We tested the attack using real IEDs and network equipment ruggedized for electrical environments. Even though the man-in-the-middle attack can be successful in a lab environment, we also explain the defense-in-depth mechanisms provided by industry in real life that mitigate the attack. These mechanisms are based on standard specifications, capabilities of the OT hardware, and regulations applicable to some electrical utilities.

1. Introduction

Attacks against Industrial Control Systems (ICSs), particularly against Critical Infrastructures such as electrical utilities, are a reality; also, the complexity of the attacks increases over time [1]. An attack occurred in Ukraine in 2015, where several electrical substations were disconnected for around three hours [2]. After more than six months of reconnaissance, attackers injected malware (Blackenergy) through common IT attack vectors. Once enough information was gathered, the attackers opened the circuit breakers through remote-controlled HMIs (Human–Machine Interfaces).

In 2016, there was a second incidence of two more automated and simultaneous attacks in Ukraine named Industroyer and Crash Override [3,4]. Instead of executing manual operations—through a graphical interface—the attack was orchestrated on a given date. It was capable of properly using four OT-specific protocols to change the state of the actuators, e.g., circuit breakers, by impersonating the original master. The malicious software included the capability to use (1) IEC 608750-101 (IEC 101), a serial protocol, (2) IEC 60870-5-104 (IEC 104), an extension of IEC 101 transmitted over TCP/IP, (3) IEC 61850 MMS (Manufacturing Message Specification), a connection-oriented protocol used to exchange messages between an IED and a SCADA system, and (4) OPC Data Access, a part of a specification known as OPC Classic.

On the one hand, IEC protocols (101, 104, MMS, etc.) are predominant in Europe, whereas other geographical locations, e.g., North America, rely more on other protocols, such as DNP3. Thus, we took a proactive approach to assess the real impact of previously described DNP3 attacks assuming an attacker has breached the OT network perimeter, e.g., in a similar way as the incidents in 2015 and 2016. As a starting point, we realized that there had been previous work to perform man-in-the-middle attacks. A prime example is how Modbus can be modified using Ettercap [5,6,7]. In addition, existing approaches for man-in-the-middle attacks in TCP-based OT protocols make assumptions and downplay real-life deployment challenges to avoid detection. For one, after a single injection, an attacker may fail to keep sequence numbers consistent, so future packets will not be adequately processed, and the connection will be dropped or reset. The process will likely alert an operator about an anomaly. Another challenge widely ignored is that specific OT devices, e.g., an IED for some vendors, validate the IP address from the master. On the other hand, although an early DNP3 attack taxonomy [8] was novel 15 years ago, the analysis needed to be deeper to realize that many attacks are not feasible or require an excessive amount of effort in comparison to more straightforward techniques. Among other aspects, a critical concept missed by previous work was that modern DNP3 deployments rely on an IP-based network for its transport; in turn, this renders many protocol aspects useless since transport-specific matters are covered by IP and the transport layer (TCP or UDP).

After realizing the lack of a thorough, up-to-date analysis from both perspectives, namely the practical aspect of a TCP-based OT man-in-the-middle and the real impact of a DNP3 attack, we decided to perform a Systematization of Knowledge. This work required a detailed review of documentation related to standards, OT device configurations, and hands-on implementation and testing with real OT devices.

This work assumes a threat model where the attacker has already breached the OT network perimeter. The attacker’s goal is to manipulate DNP3 communications to disrupt operational technology, potentially leading to substation outages or device compromise. Risks include the lack of encryption or authentication in legacy OT protocols, reliance on static configurations, and limited real-time anomaly detection in some environments. These factors amplify the potential impact of man-in-the-middle and injection attacks as analyzed in this paper.

This paper introduces an innovative approach to bypass IP allow-list restrictions configured on OT devices. Unlike prior methods, this approach combines ARP spoofing with dynamic NAT table modifications to preserve the original source and destination IP addresses, ensuring seamless communication with the target device while circumventing IP filtering mechanisms. Using this method, we demonstrate how advanced OT security measures can be practically bypassed.

Our paper has the following contributions:

• We explain the origin of some inaccurate assumptions (commonly made by previous man-in-the-middle publications in the OT realm). Notably, we describe the misunderstandings regarding the cost–benefit and impact of previously described DNP3 attacks.
• We overcome a restriction posed by an appropriately configured device (which only connects to a given IP address as the master) and test scenarios, where it is unclear whether the impact may be as high as claimed previously. According to our analysis, the impact of DNP3 attacks previously mentioned is overrated, especially when the effort/gain ratio is considered.
• We explore defense-in-depth countermeasures already available in real-life OT devices, as well as other secure configurations that would mitigate the risk of a man-in-the-middle attack. This paper is the first to view defense-in-depth real-life countermeasures from an applied perspective comprehensively.

Section 2 covers the state of the art. The rationale behind many DNP3 protocol features is presented in Section 3, followed by the lab setup employed in Section 4. Section 5 shows a detailed theoretical and practical analysis of the real-life feasibility of existing DNP3 attacks. Section 6 provides an overview of an attacker’s technical challenges when performing a man-in-the-middle attack in an OT environment. Section 7 describes how an attacker may bypass an IP allow list (an OT-specific restriction previously not addressed in the literature). Section 8 explains defense-in-depth mechanisms available today before the conclusion in Section 9.

2. State of the Art

East et al. published an early analysis of potential attacks related to DNP3 based on an interpretation of the standard [8]. Later on, Rodofile, Radke, and Foo implemented several attacks from the taxonomy using real IEDs [9] and published an initial version of the DNP3 layers described in another publication [10] while publishing the code as open source [11]. Irvene, Shekari, and Beyah collected data from real-life scenarios to estimate the likelihood of theoretical attacks against DNP3 based on statistics such as application function codes observed in [12].

Bratus et al. created a hardened parser for DNP3 [13] and evaluated using it as a proxy (and tested it with the AFL fuzzer). They considered semantics from the protocol to cover corner cases that could be more obvious by looking at the protocol’s syntax. Ömer et al. implemented a DNP3 man-in-the-middle attack using real hardware; however, it requires the attacker to be physically inline [14]. On the other hand, Wlazlo et al. implemented attacks that would have a high impact on top of a network emulator, i.e., Common Open Research Emulator (CORE) [15]; unfortunately, details about the capabilities to modify the traffic in a real-life scenario are left out, i.e., the assumption is that an attacker rewrites the MAC address of all packets.

Taxonomies have evolved from protocol-focused analysis to a comprehensive set of attackers, tactics, and procedures that are widely accepted. The state-of-the-art standard is based on either the MITRE Att&CK^® for ICS matrix [16], or based on the ICS Cyber KillChain [17]. From the offensive point of view, work has also evolved to include multiple stages. Green, Krotofil, and Abbasi describe the challenge of process comprehension and possible list sources to understand a system before attacking it. Process comprehension is based on critical building blocks, namely PLC configurations, HMI and Workstation configurations, Historian configuration, network traffic, and Piping and Instrumentation Diagram (P&ID) [7].

Sarkar, Benkrouda, and Maniatakos propose an automated generation of attacks against ICS where they leverage open datasets to train a machine learning algorithm to recognize the ICS sector and the process so that a perturbation-based attack can be created [18]. Esquivel-Vargas et al. propose a mechanism to identify a single-shot (one modification only) attack with the maximum impact possible, but for an attacker with a restricted view (only the P&ID diagram) [19]. We contribute to improving the state of the art by providing a comprehensive view of TCP-based man-in-the-middle attacks (exemplified through DNP3) and describing existing protection mechanisms.

Previous research, including [9,14], has demonstrated man-in-the-middle attacks on DNP3 but often relies on oversimplified or simulated environments. Unlike these studies, this paper focuses on overcoming real-world constraints such as IP allow-list configurations and validates the findings using an operational lab setup with ruggedized devices. This approach ensures practical relevance and highlights defense gaps not previously addressed. A summary of the state of the art is presented in

Table 1. Comparison of DNP3 attack studies.

Study	Attack Focus	Limitations	This Paper’s Contribution
East et al. [8]	Theoretical taxonomy of DNP3 attacks	Lacks practical implementation and focuses on deprecated features.	Demonstrates practical IP-based attacks with real IEDs.
Rodofile et al. [9]	Implemented DNP3 attacks on real IEDs	Does not address man-in-the-middle attacks or IP allow-list bypass.	Introduces NAT-based IP allow-list bypass mechanism.
Wlazlo et al. [15]	Man-in-the-middle DNP3 attacks on simulated networks	Assumes all devices allow MAC spoofing and does not consider IP allow-list restrictions.	Performs attack on hardened, real-world OT devices.
Ömer et al. [14]	Man-in-the-middle attacks requiring physical inline access	Inline access is not feasible in many scenarios.	Uses ARP spoofing to achieve the attack without inline access.
Irvene et al. [12]	Statistical likelihood estimation of theoretical attacks against DNP3	Does not address real-life constraints in attack execution.	Evaluates real-world feasibility of theoretical attacks in controlled environments.
Bratus et al. [13]	Vertically hardened DNP3 parser evaluation using fuzz testing	Focuses on protocol semantics but lacks implementation for live systems.	Clarifies feasibility of such attacks in modern TCP-based environments.
Sarkar et al. [18]	Automated generation of process-independent ICS attacks	Does not incorporate practical constraints of hardened OT systems.	Addresses practical challenges and explores realistic defense-in-depth mechanisms.
Esquivel-Vargas et al. [19]	Single-shot attacks with maximum impact based on limited process knowledge	Limited to theoretical impact without real-world deployment validation.	Validates attack effectiveness on real OT devices and explains mitigation strategies.

.

3. Rationale Behind Key DNP3 Characteristics

Understanding the essence of DNP3’s complexity is a difficult requirement for understanding the impact of attacks; thus, we describe the rationale for crucial aspects of the protocol required to dive deeper into attacks and their impact in future sections.

Table 2. Key DNP3 fields involved in attacks.

Field	Role in Protocol	Potential Exploitation
Source Address	Identifies the originating device in communication.	Can be spoofed to impersonate another device.
Destination Address	Specifies the target device for the message.	Can be altered to redirect communication or disrupt connections.
CRC (Cyclic Redundancy Check)	Ensures data integrity for each message.	If improperly recalculated, leads to packet drops.
Length	Indicates the length of the message payload.	Incorrect values can cause parsing errors or dropped packets.
Application Sequence Number	Tracks sequence of application-layer messages for reliability.	Mismatch can disrupt application-level communication.
Transport Sequence Number	Tracks sequence of transport-layer frames for data assembly.	Mismatch can disrupt frame reassembly, leading to dropped messages.

illustrates the DNP3 protocol structure and highlights fields relevant to potential attacks. These include transport sequence numbers, application function codes, and CRCs, which must be recalculated for successful packet injection.

DNP3 was initially developed for serial connections, so source and destination values in the link layer allowed multiplexing messages over a single serial line and potentially allowed a single physical device to have multiple addresses for different processes. DNP3 dedicates chapter 13 [20] to IP networking to cover how to handle communication when DNP3 is delivered through TCP or UDP. In a nutshell, the decision was to leave all the layers already comprising the standard (data link layer, transport, and application) unchanged and let TCP or UDP be the means of transport. TCP became the recommended transport protocol unless concerns over additional overhead for TCP or broadcasts are required. We will delve into more detail to describe the impact this has on the initial interpretation of DNP3 attacks in Section 5.

Modbus is another protocol initially developed for serial connections, which can now be executed on top of TCP. Modbus conveys only basic information, such as the value of a register or a coil, and only responds when there is a query (either read or write). Although DNP3 still supports configurations where outstations provide data when the master sends a request (i.e., a poll), there are several differences. For instance, DNP3 defines multiple data formats from binary inputs, counters, or analog values based on objects (which contain an object group and a variation). Also, DNP3 included a fundamental improvement known as RBE (report by exception). An outstation (e.g., an IED) device can send unsolicited messages (the standard includes unsolicited and solicited messages) to communicate events. However, enabling a report by exception capability in DNP3 has a ripple effect on the complexity of the protocol specification.

For instance, the protocol must let the master specify which data points should send exceptions to the master (i.e., enabling unsolicited messages). Also, it becomes necessary to enable the configuration of what constitutes an exception, i.e., an event that needs to be reported in an unsolicited message. The definition of events is configurable through a deadband—a range where values are considered normal. Generally, a deadband including the whole range of values will prevent the generation of any event. In contrast, a deadband containing zero values will report events whenever there is any change, regardless of how small it is.

Also, given the time-related nature of events, it is essential to have the capability to be time aware at the protocol level. So, this requires the introduction of mechanisms for an outstation (e.g., an IED) to notify a master that it needs time synchronization, the mechanisms to synchronize the time between both parties, and the capability to include timestamps into events. Since DNP3 still supports the capability to report information when an outstation is queried, outstations require an event buffer (where events are stored) as well as a mechanism to let a master know if there is an event missing, e.g., if it had to be removed due to the lack of space in an event buffer (also known as an event buffer overflow).

Another advanced feature of DNP3 is the capability to freeze values. When a value is frozen, a copy of the (analog or counter) is made in a separate memory space associated with the value. This copy does not affect the current values; frozen values are a snapshot used for future reference. The frozen value will remain unchanged until a new freeze operation is executed, which copies the current value to the memory for the frozen value. Freeze values can be “scheduled” so they are executed after a specific period. Also, a mechanism freezes the value and simultaneously resets the current value to zero. For example, this mechanism may be necessary if a value holds an aggregated sum over time. An intuitive example is that if the value is a counter related to volume, the frozen value presents a flow rate (i.e., total volume over a time period).

4. Lab Setup

Figure 1 shows the one-line diagram, as well as the protocols and connections of our setup. The lab layout with real IEDs was used for our testing. The operational scenario is defined based on a circuit breaker failure, which includes IEC 61850 Sampled Values, IEC 61850 GOOSE, and DNP3. Our testing approach lets us validate whether the IED under attack stops performing its functions (i.e., transformer differential protection) with broader visibility across multiple protocols.

The one-line diagram shows that the proposed scenario is inspired by setups found in electrical substations where the incomer is protected by a Siemens SIPROTEC 5 7UT85 differential protection relay monitoring the state of a transformer. Within the substation, there is a SIPROTEC 5 7SJ85 Overcurrent protection relay monitoring a substation feeder. In a real-life scenario, each relay would receive information from a separate merging unit, such as current or voltage. In our scenario, we simulate both data sources with a single device sending Sampled Values called GooseAir.

Sampled Values are modified through the GooseAir UI so they are above the threshold for the Overcurrent protection for IED 1. We simulate a breaker failure (e.g., the breaker is not physically capable of opening the circuit), which prompts the IED 1 to send a command to IED 2. Even though the IED 2 is originally meant to protect the grid by opening the circuit in case of a transformer differential anomaly, it would trigger a circuit breaker upstream and therefore de-energizing the whole substation to prevent damage to the feeder monitored by IED 1. The attempt to trip the circuit breaker controlled by the IED 2 produces an audible clicking sound, allowing us to validate our results. On top of this scenario, the IED 2 provides information to a SCADA gateway using DNP3.

We evaluated attacks by implementing them between the IED 2 and the SCADA system. However, whenever there was doubt whether the IED 2 had been impaired, we executed the circuit breaker scenario to validate whether IED functionality had been affected by attacks.

From the networking point of view, we used a RuggedCom RST2228 switch to connect the Sampled Value simulator with the IEDs, and a RuggedCom RX1500 to connect the IED2 with the SCADA system using DNP3.

5. Revising Theoretical Attacks

Our work is the first systematic review of the theoretical attacks by analyzing the following: implementation details for the proposed attacks, the DNP3 standard (IEEE 1815) published in 2012 [20], and IED documentation available. Based on these three sources, we evaluated whether the expected outcome would be obtained. We selected attacks where the impact of an attack was not clear, e.g., when there is the possibility of a device-specific flaw, and implemented a man-in-the-middle attack in our lab as described in Section 4 (executing an attack in a single environment does not guarantee the same results when vendors or configurations change, but it serves as an initial probe to have an indication whether the attack could succeed).

5.1. Data Link Layer

There are a number of data-link-layer-specific attacks described in [8] with an inaccurate description of their impact. Particularly, since DNP3 has been deployed on top of TCP, the security relevance of the link layer was diminished for a number of reasons. To begin with, the link layer contains source and destination fields (two bytes each), which become redundant because data contained in DNP3 are delivered to an IED or a master station, which is identified by an IP and a TCP port. Therefore, the Destination Address Alteration attack (D8), whereby an attacker can influence which device receives a DNP3 packet, is not realistic, i.e., delivery of the message to the right device is guaranteed by TCP. Also, there are a number of attacks described in the documentation that rely on mechanisms solely used for confirmed data services in DNP3, which are not used due to the guarantees provided by an IP-based network. Now, we will present aspects previously considered relevant to perform attacks and clarify the real impact, and effort, associated with each attack. To structure information in a simple way, we split the discussion of possible link layer transactions into three groups: transactions required to deliver data on top of the link layer, transactions provided by the link layer for different purposes (such as checking the link’s status), and replies to link layer transactions. Afterwards, we cover a separate matter referenced by previous DNP3 attacks, namely modifying the length of a data link layer frame.

5.1.1. Using the Link Layer to Deliver Data

Data points, e.g., current or voltage, are present in the application layer, which relies on the transport layer. In turn, the transport layer will require support from the link layer. The link layer uses two kinds of transactions to deliver data: CONFIRMED_USER_DATA and UNCONFIRMED_USER_DATA. The main difference is whether a link layer confirmation (ACK or NACK) should be sent after the frame. In fact, DNP3 messages transmitted over TCP or UDP use link layer frames that do not require confirmation, i.e., UNCONFIRMED_USER_DATA (this is explicitly mentioned in the CONFIRMED_USER_DATA Section 9.2.6.3 [20]).

5.1.2. Link Layer Transactions Used for Different Purposes than Data Delivery

In addition to delivering data for upper layers, the link layer has transactions allowing any party involved in the communication to perform checks on the the link and synchronize (if needed). The party initiating the link layer transaction is called the Primary Station (this is not necessarily the master, it just describes the entity initiating the transaction). According to Table 9-1 [20], outlining primary-to-secondary function codes, the only link layer transactions available besides the two variants of USER_DATA are RESET_LINK_STATES, TEST_LINK_STATES, and REQUEST_LINK_STATUS. Notably, the function code listed by the Reset Function Attack (D5) is obsolete. What is more, 9.2.6.1 [20] clarifies that the RESET_LINK_STATES function code is only used for CONFIRMED_USER_DATA, which implies that IP-based DNP3 (TCP or UDP) will not use it.

5.1.3. Replies to Link Layer Transactions

Section 9.2.7 [20] states that replies to the primary-to-secondary link layer transactions can never include user data blocks; particularly, responses cannot contain any application layer information because they are just meant to be link layer-specific (e.g., check if the link is alive). The only options listed in Table 9-2 describing the second-to-primary function codes are ACK, NACK, LINK_STATUS, and NOT_SUPPORTED. Unavailable Function Attack (D7) and DFC Flag Attack (D4) mention the use of the NOT_SUPPORTED, as well as the use of the Data Flow Control bit. Both mechanisms are only used in the link layer reply, which is not extensively used, given that the most used transaction is UNCONFIRMED_USER_DATA, which does not require a response. However, A DNP3 master may send TEST_LINK_STATES transactions when an IED is configured to have a “keep alive”.

Additionally, we tested injecting a DNP3 link layer response with the NOT_SUPPORTED code to rule out the possibility that our device in the lab would react to the injection, but the behavior of the system remained unchanged. Another important point is that an attacker already eavesdropping, who also has the capability to modify traffic, would be more successful performing simple non-OT-specific injections to break the communication between devices. For example, an RST packet could be injected whenever there is a new connection attempt, or packets could be dropped and not forwarded once the attacker is in the middle. In practical terms, this would achieve the same results as the initially expected impact, i.e., prevent DNP3 masters and outstations from communicating.

5.1.4. Link Layer Length Modification

The Length Overflow Attack (D2) was expected to to result in data corruption, unexpected actions, or device crashes when the length of a packet is modified at the link layer; however, our analysis led us to conclude that simply modifying the length does not have the desired impact (Rodofile, Radke and Foo have already explained that link layer modifications are unlikely to be successful, albeit without analyzing how a frame could be delivered with a modified length [9]). Although it is possible to change the length of the link layer, this will result in a malformed packet that will be dropped early in the parsing process due to a wrong checksum (previous work already described that packets are malformed [8]; we clarify the reasons and explain a possible way to test for buffer overflow vulnerabilities); thus, an attacker is not more likely to discover vulnerabilities than using basic fuzzing. We explain another approach to test for vulnerabilities after reasoning about the protocol and the way it is parsed.

Figure 2 shows three packets (one well formed, one where the length is modified, and one where there is a packet containing data beyond the expected DNP3 frame). Packets are represented as a horizontal array, and the number of bytes used by each field is written below the name of the field, e.g., 2 bytes for CRC.

Let us look at the first packet, i.e., the well-formed packet, as the basis for all examples in Figure 2. After the length, control octet, source, and destination, there is a CRC (Cyclic Redundancy Checksum). Optionally, there can be several user data blocks after the first CRC. Each data block contains up to 16 bytes of data and is followed by its CRC. The last user data block can have less than 16 bytes, so we depict an example with two user data blocks where the last length is a variable x with $1\le x\le 16$. The length specifies how many non-CRC bytes will follow.

The packet with altered length in Figure 2 shows how a DNP3 packet would be parsed if the length would be changed, e.g., by decreasing the length value by 2 bytes. The example shows that the DNP3 parser would conclude that the user data have 2 bytes less due to the modification. As a result, the parser will use the gray area as the CRC, instead of the actual CRC represented by the box with the cross over it. Thus, the CRC calculation will not match the last two bytes of the user data, which leads the parser to discard the packet altogether (there is an analog situation where the initial bytes of the next DNP3 frame are interpreted as CRC if the length is increased, which produces the same results). We conclude that simply changing the length of a packet is equivalent to trying random bytes after the first 2 bytes match the protocol start sequence (0x0564), i.e., random fuzzing. On the other hand, device crashes, data corruption, and security vulnerabilities take place when the code fails to handle corner cases appropriately, e.g., copying a longer buffer in less memory space by mistake. A better approach when trying to find a vulnerability would be to ensure that messages are not discarded due to trivial CRC checks; instead, the length should be used in the packet processing on DNP3 while an attacker provides a packet that has additional data that are not accounted for, in the length value.

The packet with additional data not included in the length shown in Figure 2 would be processed by the DNP3 parser, but there would be additional data trailing the DNP3 packet. In case the DNP3 parser being tested relies on the length from the protocol to allocate a memory buffer for the incoming message, it would be vulnerable to a buffer overflow, which commonly crashes the device and can be potentially exploitable to have remote code execution. Technically, this would be implemented by sending the DNP3 packet along with the additional attacker’s data over a socket either if it is a TCP or UDP socket. Also, in the case of a serial communication, the same concept would apply. We tested this modification with large buffers appended after the DNP3 message without having any indication that the IED in our lab crashed or changed behavior.

While the concept of buffer overflow was tested by appending additional data to DNP3 packets, no vulnerabilities leading to remote code execution were observed during our experiments. The devices either discarded malformed packets or remained unaffected, as their DNP3 parsers correctly validated CRCs and lengths. Demonstrating remote code execution would require further testing and is outside the scope of this paper. Future work will involve fuzzing techniques to explore further exploitability.

Figure 3 shows the screenshot of the modified traffic towards the IED (the additional data contain 0xab bytes continuously). The attack was performed through a man-in-the-middle attack; thus, there were two streams of information from the same source and IP addresses (one from the actual IED to the man-in-the-middle, and another one from the man-in-the-middle to the SCADA system). The highlighted packet had 100 additional bytes, i.e., 178 bytes long in Wireshark in comparison to the packet sent originally, which had 78.

5.2. Transport Layer

It is possible that a DNP3 message contains more data than what a single link layer frame can carry. For this reason, the transport layer adds sequence numbers and bits to indicate which frame is a start (FIR) or an end of a packet (FIN). This allows an application or an IED to gather multiple frames and reassemble them once they are all received. If the packet has only one frame, it would have both bits on, the FIR and the FIN.

The Fragmented Message Interruption (P1) attack described a scenario by which modifying the FIN or the FIR flags would disturb the assembly of a DNP3 message. We tested the behavior of the SCADA master and the IED when bits were changed (and CRC checksums properly recalculated). When the FIN bit was switched from on to off, a different behavior was seen from the SCADA system or the IED. The IED acknowledged, at the TCP level, the reception of several DNP3 messages with the FIN bit off, but after several of them were received, the IED eventually closed the connection with a TCP FIN. Wireshark showed that the packets as unassembled DNP3 packets. On the opposite direction, the master received packets (shown as unassembled packets) without closing the connection. A similar behavior was observed when the FIR bit was switched off, namely the IED closed the connection after several messages and the SCADA system kept the connection alive. Even though it is possible to disturb the assembly of a packet, in this scenario, an attacker could break the communication with TCP-based disturbances with less effort, such as sending a TCP RESET or withholding packets.

The Transport Sequence Modification (P2) attack mentions that an attacker could predict the next transport layer sequence number and inject additional data. Modifying a transport sequence number is not an attack per se; however, it may be needed when an attacker wants to inject arbitrary messages into the communication stream. A structured discussion around the modification of traffic and challenges is covered in Section 6.

5.3. Application Layer

The application layer includes the actual data points, events, and the means to trigger changes, e.g., trip a circuit breaker. Unsurprisingly, there are misconceptions related to the meaning of function codes, as it happens with other protocol features. The Outstation Write Attack (A3) mentions that an attack can corrupt information stored in the outstation’s memory, causing an error or overflow; however, this is highly unlikely because write requests are limited in very specific scenarios. Write requests are mentioned in several contexts: file transfers, time synchronization, deadbands, and restart internal indication. The most common use of the write application function code is when an IED (outstation) requires time synchronization. To clear the time synchronization required field, a write must be issued to object group 8 variation 1, according to the DNP3 standard (Section 4.5.5 INN1.4—Time Synchronization Required [NEED_TIME]) [20]. However, depending on the DNP3 support, a device should implement writable deadbands or even custom device attributes (vendor specific) using object group 0.

There could be an operational impact when a timestamp or a deadband is altered, but a memory corruption or an overflow is highly unlikely. Also, the write function code is not used to perform operational changes such as opening a circuit breaker or a valve, which can seem counter intuitive based on the name. Instead of using write requests, the DNP3 explains that the control-element descriptors CTLS (Control Status element) and CTLV (values) are used to specify elements whose state can be changed, such as breakers or valves, using the following commands: SELECT, OPERATE, DIRECT_OPERATE, and DIRECT_OPERATE_NR. The DNP3 standard in Tables 5–10 shows the element types in control requests, and responses state that outstations ignore the value in CTLV and CTLS values in write requests [20]. It is more likely that an attacker would try to perform changes using OPERATE commands instead of write requests. Additionally, performing such requests requires an attacker to preserve all the sequence numbers and checksums mentioned before, plus the DNP3 application sequence numbers (different than DNP3 transport sequence numbers).

The Clear Object Attack (A4) mentions that using function code 9 or 10 can cause a device to malfunction or crash after performing a freeze and clear, which will not happen. Freeze makes a copy of a data point in a separate memory address. This feature was necessary when a master had to read the values of multiple stations at a given point in time, which would not be possible if each one was polled separately, especially over serial connections. Also, freezes can be scheduled with the FREEZE_AT_TIME. On the other hand, when there is a cumulative value that is incremented over time, such as the total volume that has passed over a pipeline, or energy consumed a common requirement, is to know the flow rate or energy demand (total amount over a period of time). Freeze and clear allow a device to read the current cumulative value and set it to zero. This will not create a crash, although modifying it would affect the process.

The rest of the attacks rely on function codes that have been deprecated or not implemented in practice. Outstation Data Reset (A6) mentions a function code that has been deprecated. Outstation Application Termination (A7) mentions the use of function 18 to terminate applications running on a device. A closer look reveals that applications are optional, and unique to an outstation device vendor, and as such, they are not defined by the DNP3 protocol. Applications are to be specified in a request using object 90; however, we were not able to find an example of an initialize, start or stop application for the devices used in our lab. Also, the protocol states three levels of interoperability in Chapter 14 to classify the different levels of DNP3 support for a device (1 is the lowest support); none of the levels includes the function code for application termination. Rodofile, Radke and Foo have already noted that master devices may not store configurations [9] which makes Configuration Capture Attack (A14) unfeasible. Also, function code 19 (SAVE_CONFIG) has been deprecated, and the configuration of IEDs happens through engineering software (using vendor-specific protocols). In the case of the IEDs used in our lab, it would even be possible to ensure that IEDs can only be reconfigured from an engineering software installation using a valid trusted certificate before the configuration of the device is changed [21].

6. Revising the Man-in-the-Middle in OT

There are multiple ways to perform a man-in-the-middle attack depending on the attacker’s goal and the configuration of the environment (e.g., hardening), among other factors. However, we guide our analysis by the attacker’s goal and discuss which protocol fields may be affected and therefore need to be managed by an attacker to be successful. Attackers’ goals are listed in

Table 3. Modifications at the network level.

Layer	Field	Eavesdrop	Modify (Length Fixed)	Modify (Length Changed)	Injecting
DNP3 Application	CRCs		x	x	x
DNP3 Application	sequence				x
DNP3 Transport	CRC		x	x	x
DNP3 Link	length				x
TCP	checksum		x	x	x
TCP	sequence			x	x
TCP	acknowledgement			x	x
TCP	length			x	x
IP	source		x	x	x
IP	destination		x	x	x
IP	length			x	x
Ethernet	MAC source	x	x	x	x
Ethernet	MAC destination	x	x	x	x

and are sorted from low to high impact (left to right). Now, we will discuss each scenario separately.

6.1. Eavesdropping

A TCP-based man-in-the-middle attack starts from lower layers, for example, by poisoning the MAC (Ethernet) address to IP address mapping stored by both sides of the communication, i.e., the IED and the master, so an attacker can obtain the traffic. Another option is to use ICMP messages to change the path of the IP packets to be “routed” by the attacker. Regardless of the approach, the most likely scenario is that an attacker receives packets and forwards them from its machine. Therefore, an Ethernet frame will be sent with a different source MAC address; also, in some cases, the packet may be sent to a different destination MAC address, i.e., the attacker’s, when there is ARP spoofing involved. The literature always assumes that the switch/router will allow an attacker with a new MAC address to plug into the network and send ARP frames or ICMP packets. This assumption is not always true. In Section 8, we discuss existing capabilities supported by OT hardware today. The MAC address change is only visible for the master and the IED if there is no routing between the master and the IED, and it will go unnoticed since the data are delivered properly. On the other hand, if the hardening methods mentioned in Section 8 are not applied, there are also passive monitoring solutions capable of monitoring the traffic and identifying new assets connected to the network and OT anomalies. Particularly, the networking equipment we used in our lab has the capability of running several solutions [22].

6.2. Modifying Network Traffic

The ultimate goal of an attacker is usually to modify DNP3 fields, for instance, to affect the state of a circuit breaker. Depending on how complex modifications are at the upper layers, e.g., a DNP3 object in the application layer, the harder it is to keep the communication running. Besides the case of eavesdropping, Table 3 classifies attacks where traffic can be modified into three groups: content changes keeping the length of every packet (length fixed), modifications that require an alteration of the length of a packet in the TCP stream (length changed), or attacks that require injection of completely new messages (and potentially handling responses to injected messages).

6.2.1. Length Fixed

Unlike DNP3, simpler OT protocols such as Modbus (which does not have multiple layers and complex ways to calculate checksums) allow a few byte modifications to modify a value transmitted, e.g., a register [5], without breaking the protocol. These attacks can be performed with tools such as Ettercap [23]. The upside is that Ettercap can modify traffic without modifying the source or destination IP address; however, this is not feasible for DNP3 because there are several changes at the DNP3 level, i.e., DNP3 application and transport layers. Additionally, Ettercap does not permit a change in the length of a network packet. We suspect that this is avoided due to the complexity involved.

Fixing the length of every packet limits what is possible for an attacker, but it makes the implementation of a framework (such as Ettercap) easier. If possible, an attacker would rather modify a measurement sent to the master that results in a circuit breaker trip instead of adding a new object to an existing sequence of SELECT and OPERATE commands to achieve the same purpose. The latter would require an attacker to rebuild the network packets (potentially with a different length), whereas the former can be achieved with a modification to the packet’s length.

Simple on-the-fly traffic modifications are not possible in DNP3 (i.e., modification of a few bytes without complex code). If a bit is flipped at the DNP3 application layer, all checksums must be recalculated (from IP to the DNP3 application layer). Due to the complexity of DNP3, this attack has not been performed in a realistic scenario from the networking point of view. For example, [14] requires the attacker to be physically inline while [15] assumes that modifying MAC addresses in a simulated network would have the same results in a real-life deployment. Another challenge that has not been widely discussed in the literature is that some IEDs may reset a connection when the source IP address of the packets they receive does not match the expected packets in the configuration. This is reflected in Table 3 by the source and destination IP modification that an attacker must take care of. This restriction depends on the configuration and the device vendor.

In case an IED supports these validations and is properly configured, like in our lab, reusing typical man-in-the-middle tools used in IT networks, e.g., a TCP proxy, would fail. The man-in-the-middle would fail because the IED would refuse to open a new TCP connection when the other endpoint has the attacker’s IP address instead of the master’s address. In Section 7, we describe a way to ensure that an attacker can reuse the IP address from the master and establish a new connection; however, there are other approaches that can be deployed for a defense-in-depth approach against man-in-the-middle attacks in OT (see Section 8).

6.2.2. Length Changed

In some cases, it may not be enough to alter some bits in a single packet to achieve the attacker’s goal. Therefore, it may be necessary to interfere with the TCP stream by modifying the length of a packet. Changing the length or injecting a new TCP packet would create a discrepancy between the TCP sequence and acknowledge numbers used by TCP to track which bytes have been processed on each side of the communication. Therefore, an attacker must find a way to avoid damaging the state of the TCP connection so the data can keep flowing (see Table 3). There are multiple ways to achieve this: adjusting every single IP packet independently, or setting up an attack based on a high-level API such as a socket. There are frameworks to modify IP packets in real time for man-in-the-middle purposes such as the Bettercap packet proxy [24]. Alternatively, an attacker may reset an existing TCP connection and respond to the new TCP handshake so it can establish a new connection. This approach is equivalent to a transparent TCP proxy albeit with additional configurations explained in Section 7.

6.2.3. Injecting Packets

In some other cases, being able to modify the length of a packet may not be enough; for example, an attacker who wants to send a command to an IED to perform a change on demand (without necessarily waiting until there are network packets that can be modified) will need to inject a new DNP3 message and handle the acknowledgements. Figure 4 shows the DNP3-specific changes required to avoid breaking the DNP3 communication. Figure 4 shows a subset of the DNP3 protocol fields, excluding unsolicited messages, and showing only application and transport sequence numbers as app seq and trans seq, respectively. Application sequence numbers let the IED and the master map an application request (Req) and in response (Res) to a given application request; thus, both messages will have the same application sequence number. On the other hand, the transport sequence numbers reflect the number of transport frames sent for a particular direction of the communication, e.g., IED to master. So, they will be increased whenever the source sends a new frame. For the sake of simplicity, we also depict a situation where every DNP3 application (request or response) fits into one DNP3 transport frame.

Figure 4 shows the first two messages flowing between the master and the IED. Later, a man-in-the-middle injects messages 3 and 4; as a result, the attacker must send the right sequence numbers so they are processed by the IED. Afterwards, when the master attempts to communicate to the IED, the attacker must adjust sequence numbers so the IED observes the expected values (as if the injection had not happened). For this reason, the transport and application sequence numbers must be incremented towards the IED and reduced towards the master. These changes are also reflected in Table 3. In practice, operating a circuit breaker or a valve configured according to best practices would require a SELECT followed by an OPERATE command, as well as hiding the responses once they are sent back; thus, the injection would have four DNP3 frames instead of two (assuming every message still fits into one DNP3 frame).

7. Bypassing IP Address Allow Lists

Existing tools can easily eavesdrop or perform a few byte modifications for TCP-based protocols without altering its length, e.g., Ettercap; however, these solutions are not good enough to modify DNP3 packets due to their complexity (see Table 3). To intentionally modify the traffic, an attacker needs to rebuild a DNP3 packet after modifications are performed with the right checksums, or even to craft a completely new packet. Thus, it is important to have a fully fledged programming language and parsing support from an existing library (such as the DNP3 scapy layers created by Rodofile, Radke, and Foo [9], which we used).

While reviewing possible tools, such as Ettercap [23], Bettercap [24], among others, mitm_relay [25] is interesting because it is focused on TCP streams and a similar approach would avoid the need to adjust every single IP packet, as it would be needed with a packet proxy for Bettercap. After having a deeper look, we understood that mitm_relay describes using a NAT iptables rule to let the tool obtain the traffic. This learning process allowed us to create a new tool (simpler than mitm_relay) to overcome the challenge posed by master IP whitelists configured in an IED using the same concept that mitm_relay uses only for the incoming connection.

Figure 5 shows the scenario from our lab where a man-in-the-middle tricks the master and the IED to forward packets to the attacker’s machine by using ARP cache poisoning; moreover, the figure exemplifies the use of NAT PREROUTING and POSTROUTING rules to rewrite IP addresses can be preserved. The first challenge is that when an attacker runs a TCP proxy in the MiTM machine, the network stack will expect IP packets with a destination address matching an interface with which the TCP socket is bound to, e.g., an assigned IP address matching a network card. However, Figure 5 shows how packets received after ARP poisoning would have the IED’s IP address (10.50) instead of the MiTM machine (10.21). To “fix” this mismatch, a command such as the following will rewrite the destination to 192.168.10.21 for packets initially destined for the IP 192.168.10.50 (IED) coming from the IP 192.168.10.12 (DNP3 Master) for port 20000 in the prerouting phase. This mapping is represented by the dashed bold line inside the MiTM proxy in Figure 5.

iptables -t nat -A PREROUTING -s 192.168.10.12/32 -p tcp –dport 20000 -d 192.168.10.50 -j DNAT –to-destination 192.168.10.21

If an attacker only uses the previous iptables rule (as mitm_relay README recomends), an IED configured with a list of allowed master IPs will reject the incoming packets because they will arrive to the IED interface with MiTM address (192.168.10.21) as the source IP. To overcome this issue, the attacker can also use the following command to rewrite the source IP in POSTROUTING for those packets sent to the IED.

iptables -t nat -A POSTROUTING -s 192.168.10.21/32 -p tcp –dport 20000 -d 192.168.10.50 -j SNAT –to-source 192.168.10.12

There are a couple of important aspects regarding the previous approach when it comes to the setup and the state of the existing connection. First of all, there is no need for the attacker to create an actual NAT network; instead, it is enough to use the SOURCE NAT and DEST NAT jump targets and rewrite the packet. Second, any existing connections will be interrupted with an RST packet because these connections do not exist in the MiTM proxy stack, i.e., no open socket with the sequence and acknowledgment numbers received. In other words, even though the IP source is rewritten for existing packets (destined for the IED), the socket will not find a stream associated with this connection, so it will send a reset. The next SYN handshake will be successful (unless there are any additional countermeasures) because a new connection will be established with the man-in-the-middle.

8. Defense-in-Depth Mechanisms

If the network is monitored, a man-in-the-middle will leave some evidence at the network level. For instance, there will be ARP cache poisoning, ICMP redirect messages, a duplicated use of IP addresses, a new asset (MAC) in the network, etc. Additionally, in the case of the man-in-the-middle, we explained before that there will be a connection RESET when the attacker starts the new handshake. All these indications can potentially trigger events from multiple sources (Operating Systems, Antivirus agents, Endpoint Detection and Response agents, IDS, etc.). Whenever events are generated, it is common practice to aggregate security events in SOCs (Security Operation Centers), even for OT environments. A SOC will be operated by analysts who will notice an alert on suspicious behavior whenever security alerts appear.

The latest DNP3 standard [20] describes a possible extension to include DNP3 Authentication enabling pre-shared keys, as well as the use of public key cryptography to authenticate devices in an OT network. The standard recognizes that utilities were more comfortable (by 2012) to have pre-shared key authentication instead of having a Public Key Infrastructure (PKI) in place for this purpose (see Section 7.3.5 Pre-shared keys [20]). Also, the standard describes that a “bump in the wire” approach to encrypt the traffic, e.g., TLS, would be an option, while noting that using authentication at the application layer provides end-to-end security (see Section 7.2.2 Application Layer Security of the standard). From a practical point of view, modern SCADA systems and IEDs can use TLS and IPSec tunnels for MMS and DNP3 and can have mutually authenticated connections with MMS [21,26]. From an academic perspective, it must be noted that studies for other protocols such as MQTT and OPC UA have shown that adoption secure configurations leveraging encryption have been slower than desired.

Also, IEEE 802.1x can be deployed to ensure that only authorized devices join the network (using dual certificate-based authentication). To leverage this functionality, IEDs and other assets connected to the network are configured as 802.1x Supplicants [21]. Network switches or routers are Authenticators [27], which query a central RADIUS (Remote Authentication Dial-In User Service) server, i.e., the Authenticator Server. This approach would prevent an attacker from plugging in a foreign network device into the network and start a man-in-the-middle attack because the switch or router would refuse any communication until proper dual certificate authentication has taken place.

Some of the countermeasures mentioned thus far may be less attractive for utilities due to the overhead associated with certificate and key management; however, physical port security at the networking device is considered standard (good) practice. In a nutshell, port security ensures that only traffic associated to certain MAC addresses can flow through a network device, e.g., switch or router. It can be implemented in several ways:

• Configuring an allow list of MAC addresses;
• Map physical ports to MAC addresses, to ensure only a specific MAC address through a port;
• Learning port-MAC mappings from an initial configuration, and later switch to enforcement mode.

Even though port security does not deliver an authentication mechanism equivalent to 802.1x, it mitigates the risk to some extent because an attacker would need more knowledge prior to the attack and more configuration to perform the MAC spoofing.

There has been significant work invested to understand the scale of OT devices that remain open to the Internet and have unprotected or improperly configured security connections [28,29,30]. Particularly, the authors of a large-scale analysis of OPC UA servers [30] claim they have been able to map 594 devices to 3 vendors. In the case of electrical utilities, one of the most prominent users of DNP3 in North America stated that OT assets are widely connected to the Internet and are vulnerable, which is also not an accurate statement. From a regulatory point of view, the North American grid is deeply interconnected, and therefore, all utilities must comply with NERC standards (North American Reliability Corporation) [31]. As such, the NERC CIP (Critical Infrastructure Protection) standard covers cybersecurity requirements, which mandate utilities to classify their assets according to the impact they have on the grid and to fulfill various, and sometimes very stringent, requirements. For one, changes to systems must be thoroughly tested and documented before they are put in production. Also, there are very clear guidelines discouraging direct connectivity to critical assets, as well as clear ways to classify and protect information that can be misused by attackers (such as technical details of assets and information about Electronic Access Control and monitoring). Last but not least, another key requirement is to collect security logs and periodically review them, which would alert the cybersecurity team in the event of any breach.

9. Conclusions

We have analyzed the practicality of man-in-the-middle attacks for DNP3/TCP (see

Table 4. Summary of experiments and results for DNP3 attacks.

Main Attack	Sub-Attack	Description of Experiment	Result
DNP3 Man-in-the-Middle (MiTM) Attack	ARP Spoofing	Spoofed ARP tables to redirect traffic through the attacker’s machine.	Successfully redirected traffic; no immediate detection, but could be mitigated with proper network monitoring.
	Traffic Interception	Captured traffic between the master and IED to analyze communication patterns.	Successfully captured communication; required knowledge of protocol for further exploitation.
	Traffic Modification	Modified captured traffic to alter data fields or commands within the intercepted packets.	Successfully altered traffic; required complex recalculations to maintain protocol compliance.
Link Layer Length Modification	Decrease Length Field	Reduced the length field in the DNP3 link layer packets to simulate parsing errors.	Packets were dropped due to checksum mismatches; no operational impact observed.
	Increase Length Field	Increased the length field in the DNP3 link layer packets to introduce additional data.	Packets were dropped due to mismatched CRC values; no operational impact observed.
Transport Layer Sequence Modification	Modify FIN Bit	Altered the FIN bit in transport layer headers to disrupt packet reassembly.	Devices closed connections after receiving several packets with altered FIN bit; disrupted communication.
	Modify FIR Bit	Altered the FIR bit in transport layer headers to simulate fragmented packets.	Devices showed unassembled packets; communication was partially disrupted.
	Alter Sequence Numbers	Modified transport sequence numbers to test packet reassembly logic.	Sequence mismatches caused communication failure; devices eventually closed the connection.
Application Layer Command Injection	Inject SELECT Command	Injected unauthorized SELECT commands to simulate preparation for operational changes.	SELECT commands were processed but required subsequent OPERATE commands for full effect.
	Inject OPERATE Command	Injected unauthorized OPERATE commands to manipulate circuit breakers or devices.	Successfully manipulated device states; required precise sequence and checksum adjustments.
	Inject Unauthorized Data Modification	Altered data fields in application layer to introduce false information.	Successfully introduced false data; effects depended on application configuration and monitoring.
IP Allow-List Bypass	Rewrite Source IP	Rewrote source IPs of packets using NAT rules to mimic an allowed master device.	Successfully bypassed IP restrictions; demonstrated feasibility of attack.
	Rewrite Destination IP	Rewrote destination IPs to redirect packets through the attacker’s machine.	Successfully redirected communication; required proper NAT configuration.
	Use NAT Rules	Applied NAT rules to transparently forward traffic while modifying source and destination IPs.	Allowed seamless bypass of IP restrictions; effective but required significant network control.

for a summary). However, many of our findings are applicable to all TCP-based OT protocols; particularly, our analysis can be easily extrapolated to other protocols if it is conducted based on the four cases we used: eavesdropping, modification with fixed length, arbitrary length modifications, and injection. One of our findings implies that OT devices may refuse to connect to a man-in-the-middle whenever they are configured to communicate with a specific master IP.

We overcome this obstacle in our lab environment but we explain several defense-in-depth approaches and best practices already employed in real-life scenarios that mitigate or prevent the attack altogether. Last but not least, we have also systematically analyzed previous theoretical work that had misinterpreted the potential impact as it neglected the way DNP3 deployed in IP networks.

Overall, we believe that one of the strongest remaining challenges is that an attacker can gather enough information about a given system and potentially carry out selective data alterations that have maximal impact. This, however, can be performed without executing the most complex protocol-related attack. So, we believe future efforts should prioritize studying and stopping an attacker focused on gathering process details and attempting to maximize any negative impact on operations.