Lights Out and Stalled Factories: Using M.A.T.R.I.X to Learn About Modbus Vulnerabilities

Let’s explore the critical role of Modbus in energy and manufacturing systems, then demonstrate real-world exploitation techniques using Docker-based simulations and the custom-built Python tool M.A.T.R.I.X.

The danger here is an attacker who gains unauthorized access to a misconfigured Modbus TCP server can send malicious write commands to turn coils ON or OFF, thereby illegally activating or deactivating physical devices.

If focused on a power grid, this type of attack could result in localized or widespread blackouts, while a manufacturer could face a production line shutdown.

Back in 2018, security researchers uncovered VPNFilter, a sophisticated malware targeting network routers and certain network-attached storage devices.

Notably, VPNFilter was designed to infect devices that use the Modbus protocol, which is commonly employed in industrial settings for communication between control systems and hardware. The malware included specific modules capable of intercepting and manipulating Modbus SCADA communications.

As recently as April 2024, security researchers discovered FrostyGoop, an ICS-specific malware that exploits the Modbus protocol to target industrial control systems.

This malware can send unauthorized Modbus TCP commands to manipulate control parameters, modify data, and disrupt operations in industrial environments.

As industrial environments become increasingly interconnected, the risk of cyberattacks continues to rise. Therefore, understanding Modbus vulnerabilities and the methods attackers use to exploit them is crucial for securing these systems.

A Deep Dive into Modbus

Let’s start out with a hard look into Modbus by first exploring its role in the energy and manufacturing sectors.

Then we will move to examine a real-world Modbus exploitation from an attacker's perspective by demonstrating Docker-based simulations using the Python-based tool, M.A.T.R.I.X (Modbus Attack Tool for Remote Industrial eXploitation), a specialized security testing tool crafted especially for this article.

This will include unauthorized read operations, coil and holding register manipulation attacks, denial-of-service exploitation, and many more attack vectors.

Shodan (the widely used OSINT tool) was utilized to investigate Modbus exposures in the wild.

First Findings

Our findings revealed intriguing yet alarming details, exposing publicly open Modbus instances that malicious actors could target.

Additionally, insights were examined from a peer-reviewed IEEE publication (for which I was the lead author).

The publication highlights a Big Data fusion model that integrates darknet and honeypot-based monitoring to analyze cyber-physical system (CPS) activities and Modbus attack patterns. Finally, mitigation strategies are outlined to protect industrial systems from evolving cyber threats.

Modbus Intro

Modbus is a widely used industrial communication protocol that plays a crucial role in the automation and control of industrial control systems, such as those in the manufacturing and energy sectors.

It was originally developed in 1979 by Modicon (now part of Schneider Electric) for programmable logic controllers (PLCs).

Modbus has become one of the most enduring and reliable communication protocols in industrial environments.

Its open and simple structure allows seamless integration between various devices such as PLCs, remote terminal units (RTUs), sensors, actuators, and supervisory control and data acquisition (SCADA) systems.

Modbus operates primarily over serial communication (RS-232, RS-485) and Ethernet (Modbus TCP/IP) which makes it highly adaptable to modern industrial networks.

Due to its straightforward request-response messaging format, Modbus remains a preferred protocol for industries requiring real-time data exchange.

Despite its widespread adoption, Modbus has inherent safety limitations, and it's primarily due to its original design, which lacked built-in authentication and encryption mechanisms.

This makes Modbus-based systems vulnerable to a plethora of cyber threats such as:

• Unauthorized read operation (data exfiltration)
• Passive sniffing attacks, coil manipulation attacks (turning devices on/off illegally)
• Holding registers manipulation attacks (illegally altering control parameters)
• Denial-of-service attack (compromise system availability)
• Replay attack (reusing captured Modbus requests)
• Register overflow attack (writing out-of-bounds values)
• Malicious slave response injection (spoofing data).

In industries such as manufacturing and energy, where system integrity and reliability are paramount, securing Modbus communication has become a priority.

Figure 1: The Modbus protocol is commonly employed in industrial settings for communication between control systems and hardware.

Modbus in the Energy Sector

In the energy and power sectors, Modbus plays a pivotal role in grid automation, substation monitoring, and power distribution management.

Electrical utilities and energy companies use Modbus to connect meters, circuit breakers, transformers, and protective relays to centralized SCADA systems, which enables real-time monitoring and control of power networks.

The ability of Modbus to transmit crucial operational data, such as voltage, current, power factor, and frequency, allows operators to optimize power generation and distribution efficiency.

In renewable energy, Modbus is widely used in solar inverters, wind turbines, and battery storage systems to monitor energy production and system health. Its compatibility with remote monitoring systems ensures power plants and substations can operate autonomously while providing remote access to operators for diagnostics and performance evaluation.

However, the widespread reliance on misconfigured Modbus introduces significant security risks.

The protocol's lack of built-in encryption and authentication mechanisms makes it vulnerable to exploitation.

One notable example is the malware framework known as Incontroller (also called Pipedream), which includes the Codecall tool designed to interact with Schneider Electric industrial control systems using protocols like Modbus and CODESYS.

Codecall enables attackers to identify devices, read and write registers, and execute unauthorized commands, potentially leading to operational disruptions.

These threats highlight the urgent need for enhanced security measures to protect modern power grids from cyber threats targeting unsecured industrial protocols like Modbus.

Modbus in the Manufacturing Sector

In the manufacturing sector, Modbus serves as a vital component for industrial automation by enabling efficient data communication between control devices and field instruments.

Factories rely on PLCs, human-machine interfaces (HMIs), and SCADA systems to monitor and control production processes, and Modbus ensures these components can communicate effectively.

With its ability to handle discrete and analog data, Modbus facilitates precise control of industrial machines, conveyor belts, robotic arms, and assembly lines.

The protocol is particularly useful in legacy systems that still depend on serial communication but can also be extended to modern Ethernet-based industrial networks using Modbus TCP.

Additionally, its vendor-neutral nature make it an attractive choice for manufacturers looking to integrate third-party devices without being locked into proprietary communication protocols.

However, the widespread use of misconfigured Modbus in manufacturing also introduces significant security concerns.

One of the most well-known cyberattacks on the manufacturing sector occurred in 2014, when a German steel mill suffered extensive physical damage due to a cyber intrusion.

While many technical details, including the specific attack vectors, were never publicly disclosed, the attackers successfully gained access to the plant’s industrial control systems, disrupting operations and causing a furnace to overheat beyond safe limits.

The breach was initiated through a phishing attack, which allowed the adversaries to move laterally from the corporate network into the ICS environment.

Although the exact protocols exploited remain unknown, Modbus is widely used in industrial automation, and its lack of security features could make it an attractive target for similar intrusions.

This incident highlights the destructive potential of cyberattacks on manufacturing infrastructure, where operational disruptions can escalate into physical damage and major financial losses.

Modbus Vulnerabilities

There are numerous attack vectors that can be exploited in misconfigured Modbus-based industrial environments due to the protocol's lack of built-in security mechanisms.

Enumerated below are the Modbus attack simulations that will be conducted in this article. This list is randomly organized and is not ranked by severity or complexity.

1. Unauthorized Read Operation (Data Exfiltration) – Extracting sensitive process data from PLCs and SCADA systems without proper authentication.
2. Passive Sniffing Attack (Eavesdropping on Modbus Communications) – Capturing Modbus traffic to analyze commands, responses, and system behavior in real time.
3. Coil Manipulation Attack (Turning Devices On/Off Illegally) – Sending unauthorized write commands to modify coil states, potentially disrupting industrial processes.
4. Holding Registers Manipulation Attack (Illegally Altering Control Parameters) – Changing critical configuration values within holding registers to tamper with operational settings.
5. Denial-of-Service Attack (Compromising System Availability) – Overloading Modbus communication with excessive requests to degrade or halt system functionality.
6. Replay Attack (Reusing Captured Modbus Requests) – Resending previously recorded Modbus commands to execute unauthorized actions without detection.
7. Register Overflow Attack (Writing Out-of-Bounds Values) – Injecting out-of-range values into registers, potentially causing erratic behavior or system crashes.
8. Malicious Slave Response Injection (Spoofing Data) – Crafting fraudulent responses from a rogue Modbus slave to mislead the master device and operators.

Modbus Attack Simulations via Docker

Docker is used by cybersecurity teams to test vulnerabilities by creating isolated, reproducible environments.

It allows security professionals to simulate attacks, run exploits, and analyze responses without affecting the host system. Docker's containerization ensures consistent testing conditions, making identifying, assessing, and mitigating security flaws easier.

Docker can be used to carry out experiments, allowing cybersecurity professionals to have first-hand experience conducting simulated attacks on Modbus targets.

The goal of this simulation is to create a misconfigured Modbus TCP server running to demonstrate the potential attack vectors threat actors might exploit to attack industrial control systems (ICS).

The Docker image oitc/modbus-server was used to simulate the vulnerable Modbus TCP server. It is designed to simulate a misconfigured Modbus server environment, which facilitates testing, development, and educational purposes related to industrial control systems (ICS).

This Docker image allows users to deploy a Modbus server quickly without the need for physical hardware which makes it an invaluable tool for developers and cybersecurity professionals aiming to understand Modbus operations and potential vulnerabilities.

By leveraging this image, users can emulate a Modbus server's critical functionalities such as handling requests and managing registers which are essential components in ICS communications.

The `server_config.json` File (Modbus Config)

As shown in Figure 2, the `server_config.json` configuration file defines the setup for the Modbus TCP server.

It specifies key parameters related to networking, security, logging, and register values. The "server" section outlines the core settings, including the listenerAddress set to "0.0.0.0", which means the server will accept connections from any available network interface as intended for these simulations. Furthermore, the listenerPort is set to 502, which is the standard Modbus TCP port (502).

The protocol is set to "TCP" to indicate that the server operates over Transmission Control Protocol to ensure reliable data transmission.

The "tlsParams" subsection is for configuring Transport Layer Security (TLS) to encrypt Modbus communication. However, with the privateKey and certificate fields set to null, TLS remains disabled, leaving data transmissions in plaintext and vulnerable to interception or manipulation as intended for these simulations.

The "logging" section defines log entry formats using placeholders for timestamps, thread names, logging levels, modules, line numbers, and messages. With logLevel set to "DEBUG", detailed logs are recorded for troubleshooting.

The "registers" section defines the different types of Modbus registers, which are crucial for storing and processing data within industrial control systems (ICS).

The "description" field provides a general note, while `"zeroMode": false` means that registers are 1-based rather than 0-based, which aligns with traditional Modbus addressing. Moreover, the `"initializeUndefinedRegisters": true` setting ensures that any registers not explicitly defined in the configuration will still be initialized, which prevents unexpected errors during operation.

Finally, there are essentially four types of registers broken down individually below.

• Discrete Inputs: These are read-only binary values, typically representing digital sensor states. The configuration defines eight inputs, where some are set to true (high/on) and others to false (low/off) to simulate an industrial scenario where certain sensors are active while others are not.
• Coils: These are read/write binary values that control actuators or output devices such as relays and motors. Similar to discrete inputs, this section defines eight coil states with varying values, illustrating a partially active system where some outputs are enabled (true) and others are disabled (false).
• Holding Registers: These are read/write 16-bit registers that typically store configuration parameters, setpoints, or other operational values. The configuration specifies four registers, with values represented in both decimal (e.g., 52225, 52227) and hexadecimal (e.g., 0xCC02, 0xCC04) formats, which may correspond to specific control parameters.
• Input Registers: These are read-only 16-bit registers, often used for sensor readings or diagnostic data. The file defines four input registers, with values in, hexadecimal (0xDD01, 0xDD03) and decimal (56578, 56580) formats, simulating real-world industrial sensor feedback.

Figure 2: The `server_config.json` file (Modbus TCP server config).

The Docker Run Setup

Finally, with the necessary configuration file in place, a `docker run` command can now be executed to launch a Modbus server container.

As shown in Figure 3, this command starts a container based on the oitc/modbus-server:latest image while applying the custom JSON configuration file. The container is named `modbus-server` and runs with the `--rm` flag, ensuring it is automatically removed after stopping. Additionally, port 502 is mapped between the host and the container, allowing Modbus clients to communicate with the server.

Furthermore, the `-v` flag mounts the `server_config.json` file from the local machine into the container, which enables dynamic configuration.

The `-f /server_config.json` argument ensures the Modbus server inside the container reads from this configuration file upon startup.

At last, with these parameters set, the command effectively deploys a Modbus TCP server.

Figure 3: The `docker run` command execution.

M.A.T.R.I.X (Modbus Attack Tool for Remote Industrial eXploitation)

The M.A.T.R.I.X (Modbus Attack Tool for Remote Industrial eXploitation) is a specialized security testing tool (crafted especially for this article) designed to simulate specific Modbus attack vectors on a Dockerized Modbus TCP server.

The class diagram in Figure 4 reveals the overall framework of the MATRIX CLI tool which implements various attack modules including unauthorized reading, coil/register manipulation, overflow attacks, DoS attacks, and spoofing. Furthermore, the package diagram shown in Figure 5 essentially shows the file structure of the entire project repository.

The tool features a command-line interface that allows users to specify attack parameters and view results, with the ability to interact with PCAP files for replay attacks.

The tool leverages external dependencies like `pymodbus` and `scapy` libraries for protocol and PCAP interaction, respectively.

As shown in Figure 6, the workflow diagram illustrates the execution paths for different attack types, showing how M.A.T.R.I.X connects to Modbus targets, manipulates industrial protocols, and analyzes system responses. Each attack module follows specific steps, from connecting targets and reading/writing values to crafting spoofed packets, monitoring behavior, and then all producing result reports.

All these diagrams culminate in the MATRIX command-line interface (CLI) tool.

As shown in Figure 7, the MATRIX help menu reveals comprehensive attack capabilities, including unauthorized read operations, coil and register manipulation, overflow attacks, DoS attacks with configurable thread counts, replay attacks using PCAP files, and response spoofing with customizable IP addresses.

Command-line parameters allow users to specify target hosts, ports, verbosity levels, and network interfaces for packet operations.

It should be emphasized that the MATRIX CLI tool is not a comprehensive or robust Modbus attack framework. It was developed specifically for this blog to target a particular set of attack vectors against a specific Dockerized Modbus TCP server.

Its functionality is limited to the test cases designed for this environment, and it has not been tested on any other targets, whether real or virtualized. As such, its effectiveness and behavior outside this controlled scenario remain unknown.

Figure 4. The MATRIX class diagram.

Figure 5: The MATRIX package diagram.

Figure 6: The MATRIX workflow diagram.

Figure 7: The MATRIX CLI help message output.

Unauthorized Read Operation (Data Exfiltration)

As shown in Figure 8, MATRIX was executed with the `read` attack module to conduct an unauthorized read operation (data exfiltration) simulation on the vulnerable Modbus TCP server.

The tool systematically queries and retrieves data from different Modbus register types, including coil status, discrete input status, holding registers values, and input registers values.

This simulated attack has demonstrated how a threat actor may be able to extract critical industrial process information from an exposed and misconfigured Modbus device.

In real-world manufacturing or energy sectors environments, such an attack could expose sensitive operational data, including machine states, sensor readings, and control parameters, potentially leading to industrial espionage.

Figure 8: The MATRIX `read` attack module.

Modbus Sniffing Attack (Eavesdropping Modbus Communications)

As shown in Figure 9, the Modbus traffic sniffing simulation starts with a `tcpdump` command execution where the `-i` parameter was used to specify to listen on the `docker0` interface (default Docker virtual bridge interface), the `-nn` was used merely to disable the resolution of port numbers into service names and finally, the `-p` parameter was used to filter for Modbus-specific network traffic.

To simulate a normal Modbus activity to be sniffed, the MATRIX tool along with the `read` module was once again executed, as shown in Figure 10. Consequently, the Modbus network traffic was successfully captured as shown in Figure 11.

There are several interesting network activities captured.

First, the captured traffic logs reveal the TCP three-way handshake (SYN [S] => SYN-ACK [S.] => ACK [.]) between the attacker's system (172.17.0.1) and the Modbus TCP server (172.17.0.2), indicating a successful connection establishment.

Second, the captured middle parts are riddled with several PSH [P], PSH-ACK [P.], and ACK [.] flags, which suggest data exchange between the attacker and the server that likely consists of Modbus requests and responses.

Finally, the presence of FIN-ACK [F.] flags toward the end signifies connection termination after the data extraction process was completed.

This simulation has highlighted the risk of passive reconnaissance in misconfigured Industrial Control System (ICS) and Operational Technology (OT) environments.

This is particularly true in manufacturing and energy sectors, where an attacker could leverage sniffed data such as PLC status codes, sensor readings, actuator states, power grid load levels, circuit breaker positions, turbine control parameters, and substation voltage levels to enable planning of further disruptive or manipulative cyberattacks on the infrastructure.

Figure 9: Start the `tcpdump` Modbus traffic sniffing command.

Figure 10: Executing the MATRIX `read` attack module to be sniffed by `tcpdump`.

Figure 11: The `tcpdump` sniffer successfully capturing the Modbus traffic.

Coil Manipulation Attack (Turning Devices On/Off Illegally)

Essentially, coils in a Modbus system control critical actuators, such as circuit breakers, motor starters, pumps, and industrial machinery, which are fundamental to the operation of power plants, factories, and automated control systems.

An attacker who gains unauthorized access to a misconfigured Modbus TCP server can send malicious write commands to turn coils ON or OFF, thereby illegally activating or deactivating physical devices.

In a power grid, such an attack could disable circuit breakers, leading to localized or widespread blackouts, causing service disruptions and potential damage to electrical infrastructure.

In a manufacturing plant, an attacker could shut down assembly lines, disable safety mechanisms, or force machinery into dangerous states, resulting in production halts, worker injuries, or equipment failure. Therefore, coil manipulation attacks on a real misconfigured Modbus server in the manufacturing and energy industries poses a severe threat to operational safety, reliability, and financial stability.

It's Simulation Time

To start off this simulation, the current coil status is extracted using MATRIX `read` module, as shown in Figure 12. The current coil status read `01101001` in binary.

As shown in Figure 13, the MATRIX was successfully executed along with the `coil` attack module and the output suggests that the coil status has been rewritten to have the value modified into `11110000`.

To confirm this, the MATRIX `read` module was once again executed to indeed confirm that the coil status has been changed as shown in Figure 14.

Figure 12: Checking the initial coils values using the MATRIX `read` module.

Figure 13: The MATRIX `coil` attack module.

Figure 14: Checking the modified coils values using the MATRIX `read` module.

Holding Registers Manipulation Attack (Illegally Altering Control Parameters)

Basically, holding registers store critical configuration parameters, setpoints, and operational thresholds for industrial equipment such as turbines, voltage regulators, motor speed controllers, boiler pressure systems, and programmable logic controllers (PLCs).

An attacker who gains unauthorized access to the misconfigured Modbus TCP server may be able to write a single register or even write multiple registers to alter these values, potentially causing operational failures. In a power generation plant, modifying generator voltage or frequency settings can lead to grid instability, equipment damage, or even blackouts.

On a manufacturing floor, unauthorized changes to pressure, temperature, or flow rate setpoints could trigger safety shutdowns, production losses, or hazardous material leaks, leading to environmental disasters.

To start off this simulation, the current holding register status are extracted using MATRIX `read` module as shown in Figure 15.

The current holding registers values read `0xCC01` to `0xCC04` for `register 0` to `register 3` respectively. As shown in Figure 16, the MATRIX was successfully executed along with the `register` attack module, and the output suggests that the holding register has been rewritten to have the values modified into `0x0000` and `0xFFFF`.

To confirm this, the MATRIX `read` module was once again executed to indeed confirm that the holding register values have been changed, as shown in Figure 17.

Figure 15: Checking the initial holding register values using the MATRIX `read` module.

Figure 16: The MATRIX `register` attack module.

Figure 17: Checking the modified holding register values using the MATRIX `read` module.

Denial-of-Service (DoS) Attack (Compromising System Availability)

A Denial of Service (DoS) attack on a real misconfigured Modbus server in the manufacturing and energy industries poses a severe threat to operational technology (OT) environments, where continuous availability and real-time communication are crucial for safety and efficiency.

In manufacturing, this could lead to production line disruptions, unexpected machinery shutdowns, or malfunctions, resulting in costly downtime and potential damage to sensitive equipment.

In the energy sector, a DoS attack on a misconfigured Modbus-controlled power grid component such as a substation or a turbine control system could cripple critical infrastructure, or delaying power distribution.

Unlike IT-focused DoS attacks, which often target websites or online services, a DoS attack on Modbus directly impacts physical systems, creating failures that compromise worker safety, disrupt supply chains, and introduce financial and reputational risks for affected organizations.

The simulation jumpstarts by executing the MATRIX `dos` attack module and using the `-t` parameter to input the intended threads value to apply, which was `10000` in this case, as shown in Figure 18.

To test out the effect of the denial-of-service attack, the MATRIX `read` module is executed to demonstrate how the Modbus TCP server had great difficulty in mustering a response and eventually failed to respond to the read requests, as shown in Figure 19.

To further demonstrate the effects of the DoS attack, the before-and-after of the built-in Kali linux CPU monitoring display (as shown in Figure 20 and Figure 21, respectively) and the graphical `htop` output (as shown in Figure 22 and Figure 23, respectively) exhibits the stark contrast of the processing usage and validate the toll this attack takes on the CPU.

Figure 18: The MATRIX `dos` attack module.

Figure 19: Failed execution of the MATRIX `read` module.

Figure 20: Kali's built-in CPU monitor before the MATRIX `dos` attack.

Figure 21: Kali's built-in CPU monitor after the MATRIX `dos` attack.

Figure 22: The `htop` tool's CPU monitor before the MATRIX `dos` attack.

Figure 23: The `htop` tool's CPU monitor after the MATRIX `dos` attack.

Replay Attack (Reusing Captured Modbus Requests)

A replay attack on a really vulnerable misconfigured Modbus server in the manufacturing and energy industries is a highly dangerous cybersecurity threat that exploits the protocol’s lack of authentication and encryption.

In a replay attack, an adversary captures legitimate Modbus requests, such as commands to adjust machine settings, open or close circuit breakers, or modify setpoints in industrial controllers. It then replays these requests at a later time to manipulate system behavior.

In a manufacturing environment, this could lead to production inconsistencies, unauthorized activation or deactivation of machinery, or damage to precision equipment by altering parameters outside safe operating conditions.

In the energy sector, an attacker could replay control commands to disrupt power grid operations, falsely trip protection relays, or shut down critical infrastructure. Moreover, replay attacks mimic legitimate commands which may enable them to bypass basic security controls, and therefore making them difficult to detect in real time.

To start this simulation, a `tcpdump` command similar to the sniffing attack simulation is executed. However, the big difference in this case is that all captured traffic will be save to a `ModbusTraffic.pcap` file as shown in Figure 24.

The MATRIX `read` module was then executed to capture its Modbus communication traffic, as shown in Figure 25. Once that was done, the running `tcpdump` command is revisited and exited to reveal that it has successfully capture 19 packets as shown in Figure 26.

Finally, the MATRIX `replay` module is executed. As shown in Figure 27, the 19 packets are filtered to isolate only Modbus request traffic to eventually strip down to 4 packets.

The four packets are further analyzed, categorized and processed to reveal their raw data, and direction (request).

Finally, the four of the request packets are replayed, which acquire the coil, discrete input, holding register, and input register statuses, and the Modbus responds with the expected values as shown in Figure 28, Figure 29, Figure 30, and Figure 31, respectively.

The execution is then completed as shown in Figure 32 to conclude the simulation of this replay attack.

Figure 24: Start the `tcpdump` Modbus traffic sniffing command and save to a PCAP file.

Figure 25: Executing the MATRIX `read` attack module to be capture into a PCAP by `tcpdump`.

Figure 26: Stop the `tcpdump` Modbus traffic sniffing command.

Figure 27: The MATRIX `replay` attack module.

Figure 28: Replaying the coil status request packet.

Figure 29: Replaying the discrete input status request packet.

Figure 30: Replaying the holding register status request packet.

Figure 31: Replaying the input register status request packet.

Figure 32: Termination of the MATRIX `replay` attack module.

Register Overflow Attack (Writing Out-of-Bounds Values)

A register overflow attack on a real vulnerable, misconfigured Modbus server in the manufacturing and energy industries is a critical cybersecurity risk that can lead to system instability, unpredictable behavior, and even catastrophic physical damage.

Modbus relies on a structured register system for controlling and monitoring industrial devices, but it may lack built-in protections against out-of-bounds writes or invalid values.

In a register overflow attack, a malicious actor sends specially crafted Modbus write requests to overwrite registers with values far beyond their intended range.

In manufacturing, such an attack could result in precision equipment producing defective products, conveyor belts moving erratically, or robotic arms behaving dangerously, posing serious safety hazards to workers.

In the energy sector, an attacker could manipulate registers in a power plant’s control system, potentially causing overvoltage conditions, turbine instability, or forced shutdowns of generators, leading to large-scale outages.

The register overflow simulation starts by executing MATRIX `overflow` module, as shown in Figure 33. The attack simulation begins by testing two specific scenarios. First, an "Overflow 16-bit value" test where it attempts to write `65536` or `0x10000` to register 0, which initially contains `65535` or `0xFFFF`.

This fails with an error stating "'H' format requires 0 ≤ number ≤ 65535", indicating the value exceeds the allowable range for a 16-bit register. Next, it performs a "Negative value" test by attempting to write -1 (0x-001) to register 0, which also fails with the same error message. The simulation concludes after these two test cases.

It's important to note the target in this simulation is a Dockerized Modbus TCP server written in Python. Python's strict data type enforcement prevents overflow attacks by raising errors when values exceed defined limits, unlike low-level languages where overflows can corrupt memory.

This is the main reason the overflow attack fails to do further damage to the Dockerized target. In real-world scenarios involving vulnerable Modbus TCP servers, overflow attacks can lead to memory corruption.

Figure 33: The MATRIX `overflow` attack module.

Malicious Slave Response Injection (Spoofing Data)

A malicious slave response injection attack, also known as spoofing data, poses a significant cybersecurity threat to manufacturing and energy industry environments that rely on a misconfigured Modbus protocol for industrial automation and control.

In this attack, a threat actor impersonates a legitimate Modbus slave device and injects falsified responses to a Modbus master’s queries, effectively feeding operators and automated systems misleading or completely false data.

In a manufacturing facility, this could lead to manipulated sensor readings such as incorrect temperature, pressure, or production speed data causing industrial processes to operate outside safe parameters without triggering alarms.

In the energy sector, an attacker could spoof critical telemetry data from transformers, circuit breakers, or generators, misleading operators into thinking that grid conditions are stable when they are actually reaching dangerous thresholds.

The simulation jumpstarts by executing the MATRIX `spoof` module and using the `-s` parameter to input the intended IP address to spoof and then using `-i` parameter to specify the network interface to send the spoofed packets to, which was `192.168.1.50` and `docker0` respectively in this case as shown in Figure 34. Upon execution of this command, several different things happen.

First, the `Fake Holding Register` test case is executed where it spoofs a holding register with value `0x00FF`.

Second, the `Fake Coil Status` test case is executed, where it simulates all coils being `ON`.

Third and finally, the `Fake Input Register` is executed where it injects a maximum value of `0xFFFF`. For each test case, the tool crafts a specially formatted Modbus TCP packet with the malicious payload, sets the source IP to 192.168.1.50 (the spoofed address), on port 502, and transmits the packet through the `docker0` network interface.

Each spoofed response is successfully sent, as confirmed by the log messages, potentially causing the target system to process incorrect industrial control data. The attack simulation completes after all three test cases have been executed.

Unfortunately, the current dockerized Modbus TCP server setup cannot simulate the complete effects of reading out spoofed data sent by the MATRIX spoof attack.

To better illustrate this attack vector, Figure 35 presents a conceptual view of the MATRIX spoof attack.

This diagram shows its potential impact on industrial control systems. The diagram depicts the flow of legitimate Modbus clients, such as HMI or SCADA systems.

These clients make legitimate requests to the Modbus TCP server. However, at the same time, the server also receives spoofed responses.

These fake responses override or interfere with legitimate communications. This tampering ultimately affects the PLCs, logic controllers, and physical I/O systems.

Figure 34: The MATRIX `spoof` attack module.

Figure 35: Attack workflow diagram of the MATRIX `spoof` attack module.

OSINT Investigations (Shodan Research)

Shodan is a search engine that indexes exposed devices and systems. It is primarily used for discovering internet-connected devices and systems, including servers, webcams, routers, industrial control systems, and more.

It enables security professionals to assess potential risks and vulnerabilities by providing insights into exposed, vulnerable, or misconfigured devices by scanning the web for publicly accessible IP addresses.

In this research, Shodan will be used to investigate the public exposure of Modbus-enabled devices across the globe.

A broad analysis will be conducted using a heat map to visualize the global distribution of exposed Modbus systems. In addition, a deep dive will focus on a specific case of particularly concerning Modbus exposure in the wild as well as the discovery of the presence of ICS honeypots in cyberspace.

Heat Map

As shown in Figure 36, the query `port:502` is searched to find all of the targets that have the standard port for Modbus opened.

The results were astonishing as the query pulled a total of 771,581 results, as shown in Figure 37. In addition, Shodan was also able to provide a heat map (as shown in Figure 38) to display the varying concentrations of the exposed Modbus devices around the world.

As observed, Americas (North and South), Europe, Asia Pacific, Oceania and the Middle East appear to exhibit some significant Modbus port exposure while Africa seem to display the least amount.

Figure 36: Shodan search for `port:502` targets.

Figure 37: Shodan total results output for `port:502` query.

Figure 38: Shodan heat map output for `port:502` query.

There are several insights to be drawn from the tags section results shown in Figure 39. Firstly, the results show a surprising number of "cloud" and "cdn" tags linked to port 502.

This raises some interesting questions. Port 502 is typically known for Modbus, a protocol used by industrial control systems. It's not normally associated with cloud services. This disconnect might have a simple explanation.

A significant factor that may explain the inflated numbers is that many of these targets might simply be using port 502 for non-Modbus systems.

Organizations often arbitrarily assign available ports for various services, and port 502 may have been chosen randomly without knowledge of its traditional association with Modbus protocol.

This could explain why many cloud services and CDNs appear in these results and how they might be running entirely different applications that happen to use this port number.

Other possible explanations include hosting industrial control systems in cloud environments, tag misattribution in Shodan's system, or virtualized ICS environments.

However, the fact that "cloud" tags (359,620) vastly outnumber "ics" tags (32,326) suggests many of these aren't actually Modbus systems at all.

It's important to note that these observations are based on rudimentary research from examining only a handful of individual cases.

A dedicated, comprehensive research effort would be necessary to confirm any of these assumptions or hypotheses.

Such research would likely involve deeper target inspection to determine whether these services are actually implementing Modbus protocol or are simply non-industrial applications using the same port number.

This distinction holds significance when assessing the true security landscape of internet-exposed industrial systems.

Finally, the prevalence of the `honeypot` tags (4,102) confirms that some of these exposed systems are security researchers' decoys designed to monitor and research attack patterns against industrial infrastructure.

Figure 39: Shodan tags output for `port:502` query.

Real Modbus Server Detection

As shown in Figure 40, the prior Shodan scan has revealed a target with a publicly exposed real Modbus TCP server running on a Fastwel CPM713 PLC. Upon further investigation, it seems to be utilizing MODBUS TCP PLC Runtime v2.69.23953.

Fastwel is a Russian industrial embedded system manufacturer that produces PLCs used for automation, industrial control, and SCADA applications.

The presence of multiple unit IDs (0, 1, 255) suggests that the PLC is configured to manage multiple Modbus slave devices or virtual instances. Possibly, Unit ID 255 is being used for broadcast messages, which indicates a broader control mechanism.

The exposure of this Modbus TCP server on Shodan indicates that it was misconfigured to be internet-facing due to the fact as Shodan was able to scan and archive it with an open Modbus port.

This level of exposure provides threat actors with direct visibility into the device’s existence, including its product type and version. Such information serves as a valuable reference point for attackers which allows them to identify whether known public exploits exist for the specific device or even conduct research to develop zero-day exploits.

Given the potential ramifications of such exposure, if this device is part of critical infrastructure, immediate remediation is necessary.

It should be removed from direct internet access and placed behind a secure industrial network with proper segmentation and monitoring.

The figure reference in this analysis will have the visible hash query redacted to avoid directly exposing the target of this Shodan scan. Responsible disclosure is essential when assessing real-world vulnerabilities.

Figure 40: Sample exposure of a real Modbus system.

ICS Honeypot Detection

A honeypot is a security mechanism designed to mimic legitimate systems, which attracts potential cyber attackers to look further into them and allow researchers to analyze their behavior (e.g. TTP). Conpot is an Industrial Control Systems (ICS) honeypot which emulates various industrial devices such as Siemens SIMATIC S7-200 PLCs to provide researchers with insights into attack patterns.

Deploying honeypots like Conpot is crucial for security researchers, as they offer valuable data on attack methodologies, and thereby helping to enhance defensive strategies.

In this analysis, the prior Shodan scan has revealed a target hosting the Conpot honeypot. As shown in Figure 41, the system under observation was tagged as both a "honeypot" and "ics", indicating its role as a decoy designed to attract and monitor potential attackers.

The presence of open common ICS ports, including port 502 (Modbus), further supports this setups as shown in Figure 42. Additional banner information of ports 80, 161, 502, and 44818 is shown in Figure 43, Figure 44, Figure 45, and Figure 46, respectively.

However, this honeypot appears to have minimal modifications from its default Conpot configuration. Therefore, making it easily identifiable even by less sophisticated attackers (e.g. script kiddies) due to unaltered or barely changed banner information.

To substantiate this claim, Figure 47 shows a plethora of honeypot hosts from a variety of countries and IP addresses (both redacted) that were all flagged as honeypots by Shodan.

A more effective approach for researchers would involve customizing the honeypot's configuration to avoid detection and ensuring it isn't indexed by internet scanners like Shodan or GreyNoise. This strategy would allow genuine attackers to interact with the honeypot and thus enabling researchers to monitor and analyze their behavior more effectively.

Figure 41: Discovery of an ICS-honeypot target.

Figure 42: Honeypot open ports output.

Figure 43: Honeypot port 80 banner output.

Figure 44: Honeypot port 161 banner output.

Figure 45: Honeypot port 502 banner output.

Figure 46: Honeypot port 44818 banner output.

Figure 47: Shodan exposure of honeypot targets.

IEEE Publication on CPS and its Finding on the Modbus Protocol

In my previous role working in a prestigious academic institution, I was deeply involved in Cyber-Physical Systems (CPS), Industrial Control Systems (ICS), and Operational Technology (OT) research which has allowed me to explore the critical intersection of cybersecurity and industrial automation.

As part of a research initiative that culminated in an IEEE publication, I contributed to an in-depth study that examined cyber threats targeting CPS environments.

Our work, published in IEEE Xplore (DOI: 10.1109/ACCESS.2020.3029870), leveraged honeypot and darknet monitoring to analyze real-world attack patterns against CPS and industrial protocols.

To summarize, this study presents a Big Data fusion model that integrates darknet and honeypot-based monitoring to analyze CPS-related cyber activities.

Findings indicate that honeypots, though more challenging to deploy, provide stable insights into targeted attacks. On the other hand, darknets capture broader scanning activities.

The study also highlights geographical distributions of threats, identifying Europe as the predominant source of honeypot-targeted attacks and Asia as the most active region for darknet-originated traffic.

The research underscores the necessity of cross-validation using external threat intelligence sources like AbuseIPDB to enhance the accuracy of cyber threat confirmation.

In particular, the study finds that Modbus-related traffic exhibits both high and critical severity attack patterns. Since misconfigured Modbus is known to lack built-in encryption or authentication mechanisms, attackers have the inclination to attempt to manipulate communications between Programmable Logic Controllers (PLCs) or field devices of their targets.

These findings emphasize the importance of proactive security testing and real-world simulations to assess vulnerabilities and develop effective mitigation strategies.

Mitigation

Securing a misconfigured Modbus-enabled system requires addressing its inherent vulnerabilities through layered security controls.

One of the major weaknesses of Modbus is its lack of built-in authentication and authorization which allows any device on the network to issue read and write commands. Implementing network segmentation, access control lists (ACLs), and firewalls can help restrict Modbus traffic to authorized systems.

Since Modbus does not natively support encryption, communications are vulnerable to passive sniffing and replay attacks.

To mitigate this, organizations can use secure tunneling methods such as VPNs or TLS (in-transit) encryption to encrypt traffic and protect sensitive data.

Moreover, Modbus lacks integrity verification mechanisms, making it susceptible to data manipulation, including malicious slave response injection and register overflow attacks.

Deploying intrusion detection systems (IDS) to monitor for anomalous Modbus traffic and using cryptographic integrity checks at the application layer can help mitigate these risks.

Another concern is uncontrolled write access, which can lead to unauthorized coil and holding register modifications. Enforcing strict write permissions at the device level and using firewall rules to limit write operations from unauthorized sources can help mitigate this threat.

Lastly, the absence of rate limiting in Modbus makes it prone to denial-of-service (DoS) attacks. Implementing network-based rate limiting, monitoring traffic for abnormal spikes, and segmenting critical control systems from external networks can help prevent service disruptions.

By applying these security measures, organizations can significantly reduce the risk of cyber threats targeting Modbus-based industrial control systems.

Conclusion

The continued reliance on misconfigured Modbus in the energy and manufacturing sectors underscores the urgent need for stronger security measures. While its simplicity and widespread adoption make it invaluable for industrial automation, its inherent lack of encryption and authentication mechanisms leaves critical infrastructure vulnerable to cyber threats.

Through attack simulations and OSINT investigations, this article has highlighted the variety of ways to manipulate Modbus-based systems, whether through unauthorized data exfiltration, passive sniffing interception, or direct sabotage of industrial processes.

Moreover, the insights gained from IEEE research reaffirm that practical attack simulations are not just theoretical exercises but essential tools for understanding real-world threats. By bridging the gap between research and practice, we can ensure that energy grids, manufacturing lines, and critical automation systems remain resilient in an increasingly hostile cyber landscape.