What is Modbus?

Modbus is one of the most widely used open communication protocols in the industrial world. Originally developed for Programmable Logic Controllers (PLCs), it has become a de facto standard for device-level communication. Whether you're working with SCADA systems, sensors, actuators, or even modern IoT devices, chances are you’ll come across Modbus.

It’s designed to facilitate communication between a master device (like a PLC or computer) and one or more slave devices (like sensors, actuators, or HMIs). Modbus supports multiple communication channels, including RS-232, RS-485, Modbus TCP, and even wireless networks, making it extremely versatile in industrial environments.

What Can Modbus Do?

Modbus enables seamless communication in industrial environments by letting devices talk to each other in simple, structured ways:

• Data Read and Write: Read values like temperature, pressure, and flow rates from sensors. Write commands to actuators (e.g., turn on a pump).
• Device Control: Control devices like motors, lights, and valves remotely using Modbus commands.
• Process Monitoring: SCADA systems use Modbus to gather real-time status updates and flag any issues.
• Data Logging: Transfer process data to logging tools for future analysis and compliance tracking.
• Interconnectivity: Bridge devices from different manufacturers easily. Modbus promotes interoperability across vendors.

Why Is Modbus Still Important Today?

Even with newer protocols available, Modbus hasn't disappeared. Many older industrial systems still rely on it, and even modern SCADA systems often include Modbus support to ensure compatibility.

But there's a catch:

• Modbus was designed before cybersecurity was a major concern.
• It has no built-in encryption or authentication.
• Anyone who can talk to a Modbus device can read or change values.

This makes it essential for modern engineers, pentesters, and security researchers to understand how Modbus works both for maintaining systems and protecting them.

Tools You’ll Need for This Hands-On Modbus Lab

Before diving into the action, you’ll need a few things set up:

• VMware Workstation: For virtual environments.
• GRFICSv2 VM: An environment simulating an industrial process.
• Kali Linux: Our attack/scan machine.
• mbtget: A tool for sending Modbus TCP commands

Getting into the Network

Step 1: Use arp-scan to Discover Devices

Start by scanning your local network using tools like arp-scan.This helps identify which IP addresses are active and communicating.

Step 2: Identifying Modbus Communication in Wireshark

First things first let’s fire up Wireshark to start analyzing the network traffic between devices in the industrial setup.

Once it’s running, we can immediately spot communication between two IP addresses: 192.168.90.117 and 192.168.90.5.

These devices are exchanging HTTP packets over TCP port 8080, which gives us a crucial clue:

Port 8080 is typically used for web interfaces often where HMI (Human-Machine Interface) dashboards are hosted.

This observation sets the stage for deeper analysis. Now we know where to point our browser and start interacting with the system.

Accessing the HMI Dashboard

Now that we know the target IP and port (from Wireshark), we can try accessing the HMI interface via a browser at

http://192.168.90.117:8080

Once the login screen appears, we try logging in. In many cases, industrial systems still use default credentials, especially in testing environments or poorly secured setups.

You can try commonly used defaults like:

• Username: root


• Password: root

If that doesn’t work, a quick online search for the default credentials of SCADABR or similar systems often reveals the correct combination.

Once you're in you now have access to the front-end that controls part of the process.

As we monitor the chemical process via the SCADABR interface, we notice something important: the main tank pressure is designed to operate within a specific range between 2650 and 2750 kPa. This gives us a clear window into how stable the system is during operation.

Since we’re already observing network traffic in Wireshark, this opens the door to explore how those values are being transmitted and more importantly, how we might interact with or modify them. From here, we shift focus from just watching to actively testing: identifying key Modbus packets and seeing what happens when we attempt to write new values to the system

Interacting with Modbus Traffic

Step 1: Set Wireshark Display Filter

Use the modbus display filter to view only Modbus TCP traffic.

modbus

Digging further into Wireshark, we observe that the IP address 192.168.95.2 likely a PLC (Programmable Logic Controller) is continuously communicating with 192.168.90.5.

The packet analysis shows that it’s sending data in 1-byte chunks, specifically targeting Modbus register address 40.

Step 2: Pinpointing the Register Value

Next, we want to find out what value is being stored at address 40.

By scrolling through the captured packets in Wireshark, we see that the value at Modbus address 40 is consistently set to 0.

The system keeps sending this same value repeatedly, which strongly hints that it’s monitoring or controlling something important perhaps a process switch or a system state flag.

So what happens if we try to change that value?

Let’s flip the bit set the value at address 40 to 1 and observe what changes in the system behavior.

Using mbtget to Interact with Modbus

With mbtget already installed on our system, the next step is to get familiar with how it works.

To begin, we check out the help menu to understand the available options and syntax:

mbtget --help

This gives us a quick overview of how to construct read and write commands for Modbus devices. Once we know the correct flags, we’re ready to take action.

Reading the Modbus Register Value

Now that we know address 40 is being written repeatedly and may control something critical, we’re going to read the current value using mbtget.

Since we’re working with single-bit values, the function code used is 1 (Read Coils). That’s why we’ll use the -r1 flag.

mbtget -r1 -a40 -m tcp -t1 -i 192.168.90.5

This command tells mbtget to:

• -r1: Use function code 1
• -a40: Target address 40
• -m tcp: Communicate over TCP
• -t1: Use unit ID 1
• -i 192.168.90.5: Contact device at IP 192.168.90.5

We’ll start by using the -a flag to specify the Modbus address—we’re targeting address 40 in this case. The port is the standard Modbus TCP port, 502, and finally, we provide the target IP address to complete the command.

Now let’s see what happens when we change the value to 1. All we need to do is switch the initial flag from -r1 to -w5, and then specify the value 1.

mbtget -w5 -a 40 -p 502 -t 192.168.90.5 -v 1

Now, let’s check our HMI again to see if the change has taken effect.

The tank pressure starts plummeting over 1000 kPa in under a minute!

Let’s see what happens here….

Eventually, it settles around 97 kPa, indicating that the process has effectively been shut down.

This shows how simple Modbus attacks can disrupt critical infrastructure when not secured properly.

Final Thoughts

What we’ve explored here is more than just reading values from a sensor. Using Modbus, you can interact with industrial systems in real time, observe the effect of commands, and understand how systems respond to certain values. This type of insight is not only helpful for testing but also critical for learning how secure or insecure an industrial environment really is.