During the Ukraine 2015 power grid attack, attackers used compromised HMIs to send legitimate commands that opened circuit breakers where 230,000 people lost power. The commands were valid, sent through normal operator interfaces. The only way to catch it? Knowing what “normal” traffic looks like. That’s what Wireshark gives you, the ability to baseline your OT network and spot what doesn’t belong.

In Part 13b, you mapped GRFICSv3 using tshark and nmap from the command line. Now we switch to the GUI, Wireshark gives you visual packet inspection and deep protocol dissection, while GrassMarlin maps OT network topology automatically. Same baseline_all.pcap, completely different perspective.

In this article, we’ll walk through two key tools for OT reconnaissance and enumeration — Wireshark for deep packet analysis and GrassMarlin for passive network topology mapping.

Wireshark

OT network is full of logs which tell you everything about what’s happening at the protocol level; who’s talking to whom, what function codes are being called, and whether anything looks wrong.

Installing Wireshark

For Ubuntu/Debian:

sudo apt update
sudo apt install wireshark

During installation, select Yes when asked about non-root users capturing packets. Then add your user to the wireshark group:

sudo dpkg-reconfigure wireshark-common
sudo usermod -aG wireshark $USER

Log out and back in for group changes to take effect. Verify with:

wireshark --version

Dissecting Every Section of Wireshark

We will be enumerating the wireshark features at the same time enumerate the create OT Security Lab networks i.e. ICS Network and DMZ network using baseline_all.pcap file from previous series. It has captured the traffic of both ICS network and DMZ network logs.

Open the file: File > Open > baseline_all.pcap

Before diving into filters, get oriented with Wireshark’s interface:

• Menu Bar — File, Edit, View, Go, Capture, Analyze, Statistics, Telephony, Tools, Help
• Display Filter Bar — The green/red text field at the top. This is where you’ll spend most of your time in OT analysis.
• Packet List Pane — Every captured packet in chronological order. Source, destination, protocol, info at a glance.
• Packet Details Pane — Click any packet and see it dissected layer by layer: Ethernet > IP > TCP > Modbus.
• Packet Bytes Pane — Raw hex and ASCII. Useful when Wireshark’s dissector misses something or you’re looking at proprietary protocols.

Display Filters

This is the main search feature of wireshark which can be use as a main stream to search any protocols in the pcap file, anomaly traces etc. Here, we will be exploring from the OT perspective.

Exploring the Protocols
We can type protocol name as “modbus”, “dnp3”, “s7comm” etc. You can see the result in the following screenshot below.

Next we can even search same using default ports of specific protocols 502 for modbus, 102 for s7comm, 20000 for dnp3 default port and so on.

tcp.port == 502, tcp.port == 102 …

Since, this baseline only contains modbus traffic, we’ll focus to explore it in depth.

OT-Specific Display Filters

In the Modbus &DNP3 article, we walked through the key function codes. Now we can put them to use filtering Wireshark captures by function code to pinpoint exactly what’s happening on the wire.

Read functions — modbus.func_code == 1, modbus.func_code == 2, modbus.func_code == 3, modbus.func_code == 4
Write functions — modbus.func_code == 5, modbus.func_code == 6, modbus.func_code == 15, modbus.func_code == 16
Exception responses — modbus.func_code >= 128
When a PLC can’t process a request, it responds with the function code + 128. If you see a flood of exceptions, something is hammering the PLC with bad requests or an attacker is fuzzing it.

Why this matters for OT security: In a healthy OT network, traffic is predictable mostly FC3 reads at regular intervals. An HMI polls the PLC every 1–2 seconds. Write functions (FC5, FC6, FC15, FC16) should be rare and only during operator actions or setpoint changes. A sudden burst of write commands from an unexpected IP? That’s your attack indicator.

Identifying the Modbus Functions

Here’s what the Modbus functions codes look like from the packet perspective in Wireshark.
Click on any Modbus packet in the packet list expand the Modbus section in the packet details pane.

• Function Code — The operation being performed (read, write, diagnostic)
• Reference Number — The starting register address
• Word Count or Byte Count — How many registers are being read/written
• Register Values — The actual data (in responses)

Statistics Menu

Wireshark’s Statistics menu is where reconnaissance gets powerful. Each feature answers a different question about the OT network.

Protocol Hierarchy
Statistics > Protocol Hierarchy
Shows the percentage breakdown of every protocol in the capture. In a healthy OT network, you’d expect 90%+ to be Modbus/DNP3/S7comm over TCP. If you see HTTP, SSH, or SMB in a network that should be purely industrial that’s either misconfiguration or lateral movement.

Conversations
Statistics > Conversations > TCP
Lists every pair of communicating devices with packet counts and byte totals. This maps your master/slave relationships instantly. The IP with the most conversations is likely the HMI or SCADA server. A device that only talks to one other device? Probably a PLC.

Endpoints
Statistics > Endpoints
Lists every IP address that appears in the capture with total traffic volume. Use this to spot unknown devices. If you see an IP that doesn’t match your asset inventory you’ve found something worth investigating.

Statistics > I/O Graphs
OT traffic is rhythmic regular polling creates a flat, predictable pattern.

Statistics > Flow Graph
For Modbus, you’ll see the classic pattern: request from HMI, response from PLC, repeated every polling interval. Breaks in this pattern, retransmissions, timeouts, unexpected initiators stand out visually.

Expert Information

Analyze > Expert Information
Wireshark flags warnings and errors automatically. Look for:

• Modbus exceptions — PLC rejecting requests (wrong register, illegal function)
• TCP retransmissions — Network congestion or a stressed PLC that can’t keep up
• TCP RST packets — Connection resets, potentially from a crashed service

A PLC under attack often shows increased retransmissions and exceptions before it fails.

Packet Lengths

Statistics > Packet Lengths
Shows the distribution of packet sizes. Modbus TCP packets are small and uniform typically 60–70 bytes for requests and slightly larger for responses. Outliers in packet size could indicate firmware uploads, file transfers, or data exfiltration that doesn’t belong on the OT network.

File > Expert Objects > HTTP

Coloring Rules

View > Coloring Rules
Set up OT-specific color coding to spot anomalies at a glance:

• Red — Write functions (FC5, FC6, FC15, FC16)
• Green — Read functions (FC1-FC4)
• Yellow — Modbus exceptions (FC >= 128)
• Orange — Non-OT protocols on the OT network

Custom Columns

Right-click column header > Column Preferences
Add these columns for faster OT packet scanning such as:

• Modbus Function Code — modbus.func_code

Now you can scan hundreds of packets without clicking into each one.

Display Filter Macros

Analyze > Display Filter Macros
Save your most-used OT filter combinations for one-click access example:
modbus_writes → modbus.func_code == 5 || modbus.func_code == 6 || modbus.func_code == 15 || modbus.func_code == 16

Modbus Packet Fields

Breaking down exactly what’s inside a Modbus TCP packet. Every Modbus TCP packet carries an Application Data Unit (ADU) here’s what each field does and why it matters for security:

• Routing fields (Transaction ID, Protocol ID, Length) — get the packet to the right place
• Identity field (Unit ID) — says which slave device the command is for
• Action fields (Function Code, Data) — say what to do and to which register

The problem: none of these fields carry authentication, encryption, or integrity checks. Any device on the network can forge a valid Modbus packet from scratch.

GrassMarlin — Passive OT Network Mapping

GrassMarlin is an open-source tool originally developed by the NSA for passive ICS/SCADA network mapping. Feed it a PCAP file and it automatically generates a network topology showing devices, protocols, and communication patterns.

Installation

# Download from GitHub
git clone https://github.com/nsacyber/GRASSMARLIN.git
cd GRASSMARLIN
# For Linux - requires Java 8
sudo apt install openjdk-8-jre
java -jar GrassMarlin.jar

Loading the Baseline Capture

File > Import PCAP > baseline_all.pcap

Comparing with Your Manual Map

In Part 13b, we manually drew a network map from tshark output. Now, compare it with what GrassMarlin generates authomatically. GrassMarlin might catch connections we missed, especially ARP broadcasts or occasional HTTP requests to HMI web interfaces.

The value of GrassMarlin is speed. What took you 30 minutes of tshark commands and manual mapping, GrassMarlin does in seconds. In a real engagement, we’d use both, GrassMarlin for the quick overview, Wireshark for the deep dive when something looks wrong.

Key Takeaway

TRITON lived inside that Saudi petrochemical network for months. The anomalies were always there unusual writes, rogue sources, protocol drift. Wireshark and GrassMarlin are how you see them. Every packet is evidence. Every deviation is a lead.

Our next Part 13d, we go from reconnaissance to exploitation, Modbus register mapping, HMI correlation, and recreating real-world attack scenarios against the reactor. The network map you built today becomes the attack playbook which is dropping next week. See you there.

Until then, let’s explore OT/ICS security and work toward making critical infrastructure more secure.

Stay curious, stay secure.