How to Detect Anomalies in Modbus and DNP3 Traffic

Understanding Modbus and DNP3 Protocols

Modbus and DNP3 carry the commands that move physical processes in industrial control systems (ICS): opening a breaker, changing a setpoint, tripping a relay. Both protocols predate the threat they now face. They grew up inside supervisory control and data acquisition (SCADA) systems built for reliability and determinism on trusted wires, and as NIST SP 800-82 Rev. 3, the Guide to Operational Technology Security puts it, that design came long before network-based attacks were a realistic concern. That gap is why watching the traffic itself matters: on these protocols, the wire is where you catch an attack before it reaches the process.

What is Modbus?

Modbus dates to 1979, when Modicon (now Schneider Electric) built it for its programmable logic controllers (PLCs). It became a de facto standard across industry. The model is simple: a master queries one or more slave devices for data, or writes values to them, in a client-server exchange.

The protocol's behavior is fully described in the Modbus Application Protocol Specification published by the Modbus Organization. Each request carries a function code that tells the slave what operation to perform: read coils (0x01), read holding registers (0x03), write a single register (0x06), write multiple registers (0x10), and so on. Crucially, the specification defines no authentication, no encryption, and no integrity checking beyond a simple checksum. Any device that can reach a Modbus endpoint on TCP port 502 can issue any function code it likes. That design choice is exactly why traffic-level anomaly detection matters so much: the wire is the only place where intent becomes visible.

What is DNP3?

DNP3, the Distributed Network Protocol, arrived in the 1990s for electric and water utilities. It does more than Modbus: time-stamped data, event logging, and operation over long, noisy links, which is why it shows up so often in remote monitoring.

DNP3 is formally standardized as IEEE 1815, the Standard for Electric Power Systems Communications. Unlike Modbus, DNP3 organizes data into objects and points (binary inputs, analog inputs, counters, control relay output blocks) and supports unsolicited responses, where an outstation pushes events to the master without being polled. The standard also defines DNP3 Secure Authentication (SAv5), which adds challenge-response authentication on top of the base protocol. Where it is not deployed, the same fundamental exposure as Modbus applies: a reachable outstation will act on any well-formed command.

Why Network Visibility Comes First

You cannot flag an anomaly in traffic you never see. Network visibility is the precondition for everything that follows, and on Modbus and DNP3 it does triple duty. It surfaces the unexpected behavior or traffic pattern that signals a breach. It satisfies regulatory requirements such as NIST 800-171, CMMC, and the NIS2 directive, which all mandate monitoring of network activity. And it shortens downtime, because an operator who can see the conversation can find the faulting device fast. Without it, an intrusion or an unauthorized write can sit undetected until it shows up as a physical problem on the plant floor.

Why Passive Monitoring Fits OT

OT networks prize availability and determinism above almost everything else. Active scanning or in-line probing can crash fragile devices or introduce latency that disrupts a control loop, which is why NIST SP 800-82 recommends passive techniques in many OT settings. Passive monitoring observes a copy of the traffic through a SPAN port or network TAP, so the monitoring system never injects a single packet onto the control network. The detector sees every Modbus and DNP3 exchange, builds an inventory of devices and conversations, and learns normal behavior without ever touching the process. This is the approach that makes continuous anomaly detection safe to run in production.

Establishing a Baseline of Normal Traffic

Anomaly detection is only as good as the definition of "normal" it works against. OT traffic is unusually well suited to baselining because it is repetitive and predictable: a master polls the same registers on the same outstations at the same cadence, day after day. Before alerting on anything, capture a representative window of traffic and characterize it along several dimensions:

• Device pairs: which masters talk to which slaves or outstations, and over which ports.
• Function codes and objects: which Modbus function codes and which DNP3 objects each device pair actually uses.
• Register and point ranges: the specific address ranges that are read and written, distinguishing read-only telemetry from writable setpoints.
• Timing: polling intervals, request rates, and typical response latency.

Once this profile is stable, it becomes the reference against which every new exchange is compared. Anything outside the learned envelope is a candidate anomaly. Plan to refresh the baseline as legitimate operations evolve, because an outdated baseline is the most common source of false positives.

Detecting Anomalies in Modbus Traffic

Modbus carries no security of its own, so the only line of defense is reading what the protocol is actually doing on the wire and comparing it to what it should be doing. That takes protocol-aware monitoring, not generic netflow.

Common Anomalies in Modbus Traffic

1. Unauthorized Access: Access from unrecognized IP addresses or devices, or any client reaching an endpoint it has never spoken to before.
2. Unexpected Function Codes: A device that has only ever issued read function codes suddenly sending write commands (0x05, 0x06, 0x0F, 0x10), or the appearance of diagnostic and programming function codes that have no place in normal operation.
3. Out-of-Range Writes: Writes to register addresses outside the baselined writable range, or writes that push a setpoint to a physically implausible value.
4. Timing Deviations: Polling that is far faster or slower than the established cadence, often a sign of scanning, brute forcing, or a denial-of-service attempt.
5. Data Tampering: Unexpected changes in data values that may indicate an attempt to alter system behavior.

Techniques for Anomaly Detection

• Deep Packet Inspection (DPI): Parsing each frame down to the function code and register payload so that intent, not just connectivity, is evaluated against the baseline.
• Behavioral Analysis: Comparing live traffic to the learned baseline of device pairs, function codes, address ranges, and timing, and flagging deviations.
• Allowlisting: Permitting only the specific function codes and register ranges each device pair is known to use, and treating everything else as suspect.

Detecting Anomalies in DNP3 Traffic

DNP3 adds authentication options that Modbus never had, but most deployments still run without them, and even when they are on, the protocol's richness gives an attacker more to work with. Because DNP3 is object-oriented and supports unsolicited responses, detection turns on which objects and function codes show up, and whether they fit the outstation's normal role.

Common Anomalies in DNP3 Traffic

1. Unauthorized Control Commands: Operate or direct-operate requests against control relay output blocks from a master or for a point that has never issued or received them, the classic precursor to an unauthorized actuation.
2. Unexpected Object Variations: Requests for objects or point ranges outside the outstation's baselined profile, which can indicate reconnaissance of the device's data map.
3. Replay Attacks: Re-transmitting previously captured valid data packets to disrupt normal operations, detectable through time-stamp and sequence inconsistencies.
4. Data Injection: Inserting false telemetry or events into the communication stream to mislead operators or trigger automated responses.
5. Restart and Configuration Abuse: Cold restart, warm restart, or configuration function codes appearing outside a planned maintenance window.

Techniques for Anomaly Detection

• Object and Function-Code Analysis: Inspecting DNP3 objects, variations, and function codes against the outstation's learned profile, as defined in IEEE 1815.
• Time-Stamp and Sequence Verification: Validating the integrity of time-stamped data and sequence numbers to expose replay and injection.
• Secure Authentication: Implementing DNP3 Secure Authentication (SAv5) so that critical control commands carry cryptographic proof of origin.

Practical Steps to Enhance Security

To enhance the security of Modbus and DNP3 traffic, consider the following best practices, which align with the CISA Recommended Practices for Industrial Control Systems:

1. Implement Network Segmentation: Use segmentation to isolate critical network areas, limiting potential attack surfaces and creating natural chokepoints where Modbus and DNP3 traffic can be inspected.
2. Monitor Passively at Segment Boundaries: Deploy anomaly detection on a TAP or SPAN port so monitoring never disturbs the process, and concentrate sensors where traffic crosses between zones.
3. Baseline, Then Allowlist: Learn normal function codes, objects, and address ranges per device pair, then alert on anything outside that envelope.
4. Regularly Update and Patch Devices: Maintain an up-to-date inventory of all networked devices and ensure they are patched against known vulnerabilities, using the passive inventory as the source of truth.
5. Conduct Regular Security Audits: Perform periodic audits using frameworks like NIST 800-171 and NIST SP 800-82 to ensure compliance and uncover potential security gaps.

Conclusion

Detecting anomalies in Modbus and DNP3 traffic requires protocol-specific monitoring: deep packet inspection to read function codes, objects, and register values, baselining to establish normal command patterns and timing, and allowlisting to block unexpected commands and unauthorized writes. Run it passively through a TAP or SPAN port so monitoring never disrupts the process, and deploy it at segment boundaries where Modbus and DNP3 traffic crosses between zones. Alert on deviations from baseline, investigate every alert, and refine your baselines as operational patterns change.