Welcome back, my aspiring network forensic investigators!
Now that you have a basic understanding of Wireshark and have conducted an analysis of a malware attack using Wireshark, let’s expand our purview of network attacks to that critical but often overlooked area of IT security, SCADA/ICS security.
Unlike most attacks on IT security, attacks on SCADA/ICS systems are not targeted at confidential information, but rather at the process. While a DDoS attack on the web server can be expensive and inconvenient, a DDoS attack on a SCADA system might be life threatening! The DoSing of a valve or subsystem might be sufficient to disable an entire plant and may have explosive consequences.
Another key difference between traditional IT systems and SCADA systems are the communication protocols. SCADA/ICS systems are built on legacy seria protocols such as modbus and DNP3. Although they have now been encapsulated into TCP/IP for external communication, internally they are still rather simple serial protocols.
Step #1: Finding modbus Traffic
Now that we know how to use Wireshark on normal TCP/IP traffic, let’s use it to analyze and isolate SCADA/ICS traffic. Let’s look at the ubiquitous modbus over TCP packet, probably the most common SCADA/ICS protocol. Although modbus was originally developed to be used over a serial medium such as RS232 or RS485, it has been adapted to being used over TCP/IP networks.
As you can see, the modbus protocol is lightweight and simple.
Now, let’s use Wireshark to open some sample modbus traffic. In this tutorial, we will be using a pcap file of some modbus test data. To open it, use Wireshark to open (File –> Open) modbus_test_data_part1.pcap.
Now that we have this capture file loaded, we can use Wireshark to do analysis. First, let’s develop some filters for modbus traffic. The most basic modbus filter would be;
mbtcp
This would filter out all traffic, but the modbus over TCP traffic.
If we click on any one of those packets, we can begin a more detailed analysis of the packet. Expanding the TCP header, we can see its destination port and protocol (502 and mbap, respectively).
If we scroll down a bit, we will come to the Modbus and Modbus/TCP fields and read their values there.
In order to build more specific modbus filters, click on the Expression tab next to the filter window and open the Expression builder. We can scroll down to the M’s in the field name sub-window until we come to modbus.
As you can see above, there are three (3) field names with modbus in them. Let’s expand each and see what they include. The filter for Modbus/TCP only includes the fields unique to the TCP implementation of modbus. The Modbus protocol includes all the fields in the original modbus protocol.
If we are looking for specific fields in the Modbus protocol, rather than the TCP/IP implementation of modbus, we will use these fields.
Step #2: Filtering for Modbus Diagnostic Codes
First, let’s look for diagnostic codes on our modbus communication (for more on modbus diagnostic codes, see my article on the modbus protocol).
We can do that by entering;
modbus.diagnostic_code
into the filter window.
When you do, Wireshark will retrieve all the modbus packets with the diagnostic code field filled. When we examine one of those packets and scroll down to the Modbus protocol fields, you can see that this one has a Diagnostic Code = 4 or “Force Listen Only Mode”. We could filter further and only look for packets with that Diagnostic Code by creating a filter like this;
modbus_diagnostic_code ==4
When we do, we can see that Wireshark has only found 3 packets with that Diagnostic Code.
Step #3: Filtering for Other Suspicious Modbus Packets
Of course, we can build many different filters looking for packets that meet some field criteria. Here we are looking for “restart communications” by building the following filter;
modbus.diagnostic_restart_communication_option
This diagnostic code can also be used to initiate a DoS attack as it sends a signal to restart the PLC.
Step #4: Attacker Reading Registers
Here, we are looking for packets thatare reading the contents of the 16-bit register by crafting a filter such as;
modbus.register.uint16
These packets may indicate an attacker is trying to read the data values in the register in an attempt to understand their functioning before attack (a type of reconnaissance) or before attampting to change these values to something with malicious content and impact.
Conclusion
Wireshark can be used for analyzing SCADA/ICS attacks as well, if you know what to look for. Any security engineer working in SCADA/ICS security must be proficient in Wireshark and the details of communication protocol used at their facility to be adequately armed for this type of analysis.
