Monitoring SCADA Modbus Traffic Anomalies

When to Use

• Monitoring OT/ICS networks for unauthorized Modbus commands targeting PLCs, RTUs, or HMIs
• Detecting reconnaissance activity such as Modbus device enumeration (function code 43, Read Device Identification)
• Identifying unauthorized write operations (function codes 05, 06, 15, 16) to coils and holding registers that could alter physical process parameters
• Baselining normal Modbus communication patterns and alerting on deviations in function code distribution, register access ranges, or timing intervals
• Investigating suspected sabotage or insider threats manipulating SCADA process values through Modbus register writes

Do not use on networks without authorization from the asset owner, for active injection or fuzzing against production SCADA systems, or as a replacement for safety-instrumented systems (SIS) that provide physical process protection.

Prerequisites

• Network tap or SPAN port on the OT network segment carrying Modbus TCP traffic (port 502)
• Python 3.9+ with pymodbus (>=3.6), scapy (>=2.5), and pandas for traffic analysis
• Zeek (formerly Bro) installed with the Modbus protocol analyzer enabled for passive traffic logging
• Wireshark or tshark for initial packet capture and validation of Modbus frame structure
• A baseline period of normal operations (minimum 48-72 hours) to establish communication profiles per device pair
• Network diagram identifying Modbus master-slave relationships, device IP addresses, and expected function code usage

Workflow

Step 1: Capture and Parse Modbus TCP Traffic

Establish passive monitoring on the OT network segment and begin capturing Modbus TCP frames:

• Configure network tap: Position the monitoring interface on the SPAN port mirroring the VLAN carrying Modbus TCP traffic between HMI/SCADA servers and PLCs. Verify bidirectional traffic capture with tcpdump -i eth0 port 502 -c 100 -w modbus_capture.pcap.
• Parse Modbus TCP frame structure: Each Modbus TCP frame contains a 7-byte MBAP (Modbus Application Protocol) header followed by the PDU. The MBAP header includes:
  • Transaction Identifier (2 bytes): Matches requests to responses
  • Protocol Identifier (2 bytes): Always 0x0000 for Modbus
  • Length (2 bytes): Number of following bytes including Unit ID
  • Unit Identifier (1 byte): Slave device address (0-247)
• Extract function codes with Scapy: Use Scapy's Modbus contrib module to dissect captured packets and extract function codes, register addresses, and values:

  from scapy.all import rdpcap, TCP
  from scapy.contrib.modbus import ModbusADURequest, ModbusADUResponse
  
  packets = rdpcap("modbus_capture.pcap")
  for pkt in packets:
      if pkt.haslayer(ModbusADURequest):
          adu = pkt[ModbusADURequest]
          print(f"Src: {pkt['IP'].src} -> Dst: {pkt['IP'].dst} "
                f"Unit: {adu.unitId} FuncCode: {adu.funcCode}")
  

• Enable Zeek Modbus logging: Configure Zeek with @load policy/protocols/modbus/known-masters-slaves to generate modbus.log entries containing timestamp, source/destination IPs, function code, and exception responses. This provides continuous passive logging without custom scripting.
• Validate frame integrity: Check for malformed Modbus frames where the MBAP length field does not match the actual PDU length, Protocol Identifier is not 0x0000, or Unit Identifier falls outside the expected range for the monitored network.

Step 2: Baseline Normal Communication Patterns

Build a behavioral profile of legitimate Modbus traffic to distinguish normal operations from anomalies:

• Catalog function code distribution: Record the frequency of each function code per source-destination pair over the baseline period. In typical SCADA environments, read operations (FC 01-04) vastly outnumber write operations (FC 05, 06, 15, 16), often at ratios exceeding 100:1. A sudden increase in write function codes is a strong indicator of process manipulation.

  Normal baseline example (72-hour period):
  HMI (10.1.1.10) -> PLC (10.1.1.50):
    FC 03 (Read Holding Registers):  432,180 packets  (97.2%)
    FC 04 (Read Input Registers):     10,540 packets  (2.4%)
    FC 06 (Write Single Register):     1,780 packets  (0.4%)
    FC 16 (Write Multiple Registers):      0 packets  (0.0%)
    FC 43 (Read Device ID):               0 packets  (0.0%)
  

…