5 Advanced Protocol Analysis Techniques for Modbus

Modbus is everywhere, and it was never designed to be defended. First published in 1979, it remains the most widely deployed industrial protocol in SCADA and PLC environments globally, running on everything from water treatment controllers to power grid RTUs. It carries no authentication, no encryption, and no session integrity. In threat terms, that means any device that can reach a Modbus-accessible controller can read its registers, write to its coils, and in many environments, affect physical processes, without leaving a single credential log entry.

This article gives OT/ICS security engineers, SOC analysts, and incident responders five advanced protocol analysis techniques for Modbus, practical, implementable approaches that build genuine detection capability rather than compliance checkboxes. By the end, you should be able to adopt at least two techniques in your environment within a working day.

Modbus in the Wild

Modbus operates in two primary variants: Modbus RTU, a compact binary format over serial links (RS-232/RS-485), and Modbus TCP, which wraps the same Application Data Unit in a TCP/IP envelope, typically on port 502. Most modern OT environments run Modbus TCP, which makes packet-level analysis tractable with standard network tooling.

The protocol structure is simple. A Modbus request contains a function code (what operation to perform), an address (which register or coil), and a quantity or data value. Common function codes include FC01 (Read Coils), FC03 (Read Holding Registers), FC06 (Write Single Register), and FC16 (Write Multiple Registers). The simplicity that makes Modbus interoperable also makes it trivially parseable by an adversary.

Core weaknesses from a security standpoint:

• No authentication, any network-connected device can issue commands
• No encryption, all register values and process data traverse in plaintext
• No message integrity, Modbus RTU uses a CRC, but Modbus TCP relies on TCP checksums only
• No session concept, there is no handshake or authorization sequence to monitor

These characteristics mean that traditional signature-based detection, looking for malware hashes, known-bad IPs, or authentication failures, is almost entirely blind to Modbus-level threats. Protocol analysis is not optional for OT environments running Modbus. It is the primary detection mechanism available.

Technique 1 – Deep Payload and Stateful Correlation

Standard packet inspection tells you a Modbus write occurred. Stateful correlation tells you whether that write was expected, from the right source, to the right register, at the right time, given the current process state. It is the difference between seeing a function code and understanding what it means in operational context.

How to implement

Begin by building a communication baseline using at least two to four weeks of passive packet capture during normal operations. Record: source IP, destination IP, unit ID, function code, register address range, and request frequency. This becomes your expected-behavior matrix.

Deploy your capture at a SPAN port or TAP at the network segment where Modbus TCP traffic flows between HMIs/SCADA servers and PLCs. Tools like Zeek with the Modbus protocol analyzer script can parse and log each transaction field to a structured log format that feeds directly into a SIEM or data platform.

For each observed Modbus session, maintain state across the request-response pair. Correlate:

• The function code of the request against what that master device is authorized to issue
• The register address against the known I/O map for that slave device
• The data value written against the engineering range for that register

What to look for

• A write function code (FC06 or FC16) from a source that has only ever issued reads in your baseline
• Register addresses outside the documented I/O map for the target device
• FC08 (Diagnostics) issued from a non-engineering workstation, often indicative of reconnaissance
• Exception responses (FC + 0x80 offset) at elevated frequency, suggesting probing behavior

Example observable:

[Modbus TCP] Src: 10.10.5.47 → Dst: 192.168.1.101:502

Unit ID: 1 | FC: 06 (Write Single Register)

Register: 40023 | Value: 0xFFFF

Time: 02:14:33 (outside maintenance window)

Baseline: Src 10.10.5.47 has issued FC03 (Read Holding Registers) only.

No writes observed from this source in 90-day baseline.

→ ALERT: Unauthorized write function from non-writing master

Technique 2 – Sequence and Timing Analysis

Legitimate SCADA polling is rhythmic. A master device polls its slaves on a defined scan cycle, typically every 100ms to 2 seconds per device, with function codes issued in a predictable order. Deviations from this rhythm are among the earliest detectable indicators of automated scanning, replay attacks, or adversary tooling interacting with a Modbus device.

How to implement

Extract inter-frame timing from your packet capture data, the delta between each request from a given master to a given slave. Calculate the mean and standard deviation of the polling interval for each master-slave pair across your baseline. Statistical outliers in inter-arrival time indicate behavioral deviation.

Implement this analysis in tshark with a Modbus display filter and timestamp output, then pipe the output into a Python or pandas’ script for interval distribution analysis. Zeek’s Modbus log (modbus.log) includes timestamps suitable for this directly.

For sequence analysis, model the ordered list of function codes issued by each master per polling cycle. Any insertion of an unexpected function code, particularly FC05 (Write Single Coil), FC16, or FC08, in a position where the baseline only shows read operations warrants immediate investigation.

What to look for

• Polling intervals that drop significantly (e.g., from 500ms to 5ms) , characteristic of automated scanning tools
• The same request replayed at irregular intervals, potential replay attack behavior
• Burst requests targeting a sequential range of register addresses, indicative of register enumeration
• Time-of-day anomalies, write operations outside business hours or defined maintenance windows

Example observable:

Baseline: Master 10.10.1.10 polls Slave 192.168.1.50 every 500ms ± 30ms

Observed at 01:47 UTC:

Requests at intervals: 4ms, 3ms, 5ms, 4ms (352 requests in 2 seconds)

Function codes: FC03 (Read Holding Registers), addresses 0–125 sequential

→ ALERT: Scan-rate anomaly, register enumeration pattern detected

Technique 3 – Context-Aware Anomaly Detection

A Modbus write to a setpoint register is syntactically valid. Whether it is safe depends entirely on the value written, the current process state, and the engineering limits defined for that loop. Context-aware anomaly detection layers process knowledge, setpoint ranges, physical constraints, sensor interdependencies, on top of protocol analysis to flag commands that are syntactically correct but operationally dangerous.

How to implement

Obtain the I/O mapping documentation from your engineering or OEM team, the register map that defines what each address represents (temperature setpoint, pump speed, valve position) and its valid engineering range. This is the foundation; without it, this technique is not possible.

Integrate your Modbus capture stream with your historian or process data platform to correlate protocol-level events with real-time process values. When a write to a setpoint register is observed, compare the written value against:

• The documented engineering range (hard limits)
• The current operating setpoint (soft deviation threshold)
• The rate of change (delta per unit time) for that parameter

Build detection rules in your OT monitoring platform or SIEM that trigger when written values exceed either the hard limit or a configurable deviation threshold from the current operating value.

What to look for

• A write to a temperature setpoint registers with a value exceeding the documented maximum safe operating temperature
• A motor speed command value that would produce mechanical overspeed
• A valve position command (0–100%) written with a value outside the 0–100 range, indicating either a malformed command or a unit mismatch

Example observable:

Register 40051 = Pump Speed Setpoint (0–3600 RPM, operating at 1800 RPM)

Observed write: FC06, Register 40051, Value: 3601

Written value exceeds documented hard limit (3600 RPM)

Source: 192.168.10.33 (unrecognized, not in authorized master list)

→ ALERT: Out-of-range setpoint write, process safety boundary exceeded

Technique 4 – Multi-Protocol Cross-Correlation

Modbus-level attacks rarely happen in isolation. An adversary who reaches a Modbus-accessible controller typically traverses IT networks first, a phishing compromise, a VPN credential abuse, a pivot through an exposed historian. Cross-correlating Modbus events with DNS queries, authentication logs, firewall flows, and IT network telemetry reveals the full attack chain and dramatically accelerates investigation.

How to implement

Ingest Modbus session logs (Zeek modbus.log) into the same SIEM or data platform receiving IT security telemetry. Define a correlation time window, typically five to fifteen minutes, within which anomalous Modbus activity is searched for preceding network events.

Build correlation queries that look for:

• New source IPs appearing in Modbus traffic that have no prior history in OT network flows
• Modbus anomalies preceded by DNS lookups to external domains from the same network segment
• Authentication events (failed or successful) on jump hosts or remote access infrastructure within the correlation window prior to a Modbus write anomaly
• Lateral movement indicators (SMB traffic, RDP sessions) from the same source as the anomalous Modbus traffic

What to look for

• A new Modbus master IP that appeared on the OT network within the same hour as an RDP session from an IT workstation to an OT jump host
• A burst of write operations immediately following a VPN authentication event for a vendor account outside business hours
• Modbus exception responses correlated with outbound DNS queries from the same segment, potential command-and-control communication

Example correlation event:

T+00:00, VPN auth: vendor_acct@vpn (outside maintenance window)

T+00:03, RDP session: 10.0.0.88 → OT jump host 10.10.0.5

T+00:07, New Modbus master: 10.10.0.5 → PLC 192.168.1.20:502

T+00:08, FC16 (Write Multiple Registers): registers 40100–40115

→ CORRELATION ALERT: Vendor VPN → jump host pivot → Modbus write chain

Technique 5 – Heuristic and Signature Tuning for Modbus

Generic IDS signatures for Modbus generate significant false positives in real OT environments, flagging legitimate engineering operations, maintenance writes, and protocol diagnostic traffic. Properly tuned, environment-specific signatures dramatically reduce alert fatigue while maintaining detection fidelity for genuinely suspicious behavior.

How to implement

Start with an open-source baseline ruleset. Suricata includes Modbus-aware rules in its OT protocol coverage; the Claroty and Dragos platforms (commercial) ship with curated OT signatures. For open-source deployments, the CISA-published Snort/Suricata rules for ICS protocols are a defensible starting point.

Tune each rule against your baseline traffic in a passive (alert-only) mode before enabling blocking. For each rule, document:

• The expected false-positive rate based on baseline traffic
• The business justification for suppressing or adjusting the rule threshold
• The detection scenario the rule is intended to address

For heuristic detections, anomaly-based rather than signature-based, define your threshold multipliers conservatively at first (e.g., alert at 3× baseline polling rate) and tighten over time as your baseline matures.

What to look for (signature categories to prioritize)

• FC08 (Diagnostics) from non-engineering sources, high-fidelity indicator; rarely legitimate from SCADA polling masters
• FC43 (Read Device Identification) from external or unexpected sources, recon indicator
• Malformed MBAP header, transaction ID mismatch between request and response suggests spoofing or replay
• Unit ID 0 (broadcast) in Modbus TCP, legitimate in some implementations but worth alerting on given its abuse potential
• Exception response rate exceeding baseline, suggests probing of non-existent registers

Conclusion

Modbus will remain in production OT environments for decades. It will not gain authentication or encryption at scale. That means protocol analysis, stateful correlation, timing baselines, context-aware detection, cross-protocol correlation, and well-tuned signatures, is the practical defensive layer available to security teams protecting these environments. Start with passive capture and a communication baseline this week. Add Zeek logging and one Suricata rule set. The techniques are within reach, and the detection capability they build is genuinely meaningful.