Why OT Threat Hunting Requires a Different Approach

Threat hunting in IT environments relies on EDR telemetry, Windows event logs, and process execution data from endpoints. In OT environments, those sources don’t exist. PLCs, RTUs, DCS controllers, and HMIs don’t run commercial EDR agents. Many are running embedded OS versions that haven’t been updated in years. Some communicate on proprietary serial protocols that predate IP networking.

The equivalent visibility in OT comes from the network. Industrial control system protocols — Modbus, DNP3, EtherNet/IP, IEC 61850, PROFINET, BACnet — are chatty. Controllers send process data updates, receive commands, and respond to polls on predictable schedules. This predictability is the hunter’s advantage: in a healthy ICS network, traffic is remarkably consistent. Deviations from that baseline are high-fidelity signals.

This guide covers passive network monitoring as the primary OT hunting methodology, with specific hunting queries and protocol-level anomaly patterns for Zeek with ICS protocol analysers and Suricata with the Emerging Threats ICS ruleset.

Passive Monitoring Architecture

The cardinal rule of OT monitoring is never disrupt the process. Active network scanning — sending probes to controllers, running vulnerability scanners, attempting banner grabs — can cause unexpected behaviour in PLCs and real-time control systems. Controllers running hard real-time processing may drop packets, buffer overflow, or respond to unexpected queries in ways that affect output signals.

Passive monitoring taps network traffic at strategic points without generating any traffic of its own. Placement options:

Managed switch SPAN/mirror ports: The most common approach. Configure a SPAN session on managed switches at the OT DMZ, at each network level transition (Levels 1-2, 2-3 per the Purdue model), and at any point where IT and OT networks converge.

Network taps: Hardware taps placed inline on critical links. Unlike SPAN ports, taps provide 100% packet capture without load-related packet drops. Use taps on the highest-priority segments where complete fidelity matters.

Serial tap/protocol converter: For legacy serial fieldbus networks (RS-485 Modbus, PROFIBUS PA), hardware serial taps convert serial traffic to IP encapsulation for capture. Useful for L1/L2 visibility in older facilities.

Historian and HMI mirroring: Application-level data from historians can supplement packet-level analysis. OPC-DA and OPC-UA logs, Wonderware historian queries, and SCADA alarm logs provide process context that helps distinguish legitimate operations from attacks.

Zeek for ICS Protocol Analysis

Zeek (formerly Bro) is the standard open-source framework for network traffic analysis in OT environments. Several ICS-specific protocol analysers extend Zeek’s parsing capabilities:

  • zeek-plugin-enip-cpf: Parses EtherNet/IP and Common Industrial Protocol (CIP) traffic
  • icsnpp-modbus: Full Modbus TCP parsing including function code, register addresses, and value logging
  • icsnpp-dnp3: DNP3 serial and IP traffic parsing
  • icsnpp-bacnet: BACnet/IP for building automation systems
  • icsnpp-opcua-binary: OPC-UA binary protocol analysis
  • icsnpp-ethercat: EtherCAT for high-speed motion control applications

Install the CISA-maintained ICS protocol pack (available at github.com/cisagov/icsnpp):

git clone https://github.com/cisagov/icsnpp
cd icsnpp
./setup.sh
zeek -i eth0 icsnpp-modbus icsnpp-dnp3 local.zeek

Zeek generates structured log files (.log) for each protocol. The Modbus log (modbus.log) captures function codes, unit IDs, register addresses, and values. This is the foundation for hunting.

Hunting Hypothesis 1: Rogue Engineering Workstation or Unauthorized Modbus Master

Hypothesis: An attacker who has gained access to the OT network may attempt to directly poll controllers or issue commands. Legitimate Modbus master traffic comes from known SCADA servers or HMIs; unexpected masters are an anomaly.

Zeek Modbus hunt:

# Identify all Modbus masters (sources) in the log
cat modbus.log | zeek-cut ts uid id.orig_h id.resp_h func | awk '{print $4}' | sort | uniq -c | sort -rn

# Alert on Modbus write function codes (FC 5, 6, 15, 16) from unexpected sources
cat modbus.log | zeek-cut ts id.orig_h id.resp_h func | \
  awk '$4 ~ /WRITE|FORCE|PRESET|MASK/' | \
  grep -v -E "10\.0\.1\.(10|11|12)"  # exclude known SCADA servers

What to look for: Any Modbus FC6 (Write Single Register) or FC16 (Write Multiple Registers) from a source IP that isn’t your SCADA server, historian, or known engineering workstation. Legitimate operations data flows — polling, reading — are far more common than write commands.

Known attack pattern: PIPEDREAM/INCONTROLLER (the ICS-specific toolkit disclosed in 2022) included a Modbus module that could enumerate coils and registers and issue write commands. Traffic patterns from this module are distinctive: rapid sequential register reads across the full coil address space (0x0000 to 0xFFFF) followed by targeted writes.

Hunting Hypothesis 2: DNP3 Outstation Scanning or Spoofed Master

Hypothesis: DNP3 defines “masters” (control systems) and “outstations” (RTUs, meters). A scanning attacker may send DNP3 requests to enumerate outstations or attempt to spoof a master address to issue unsolicited commands.

Zeek DNP3 hunt:

# Show all DNP3 master/outstation pairs and function codes
cat dnp3.log | zeek-cut ts id.orig_h id.resp_h fc_request | sort | uniq -c

# Hunt for DNP3 Confirm messages from unexpected masters
# DNP3 FC 0x00 (Confirm) after an unsolicited response may indicate a spoofed master ACKing unsolicited data
cat dnp3.log | zeek-cut ts id.orig_h id.resp_h fc_request iin | \
  awk '$4 == "0x00"'

Anomalies to flag:

  • DNP3 traffic from IP addresses not in the known master list
  • FC 0x03 (Direct Operate — immediate command) from an unexpected source
  • Unusual IIN (Internal Indication) bits in responses, particularly IIN bit 1.0 (Broadcast message received) which indicates someone is broadcasting to multiple outstations

Hunting Hypothesis 3: OPC-UA Credential Enumeration or Unauthorized Session

Hypothesis: OPC-UA is increasingly used as the data highway between OT data sources and SCADA/historian systems. Attackers targeting the upper OT layers may attempt to enumerate OPC-UA servers, establish unauthorized sessions, or attempt to invoke method calls against server objects.

Zeek OPC-UA hunt:

# List all OPC-UA sessions with source, destination, and session IDs
cat opcua-binary.log | zeek-cut ts id.orig_h id.resp_h opcua_msg_type session_id | \
  sort | uniq -c

# Look for CreateSession requests from non-standard clients
cat opcua-binary.log | zeek-cut ts id.orig_h opcua_msg_type | \
  awk '$3 == "MSG" && $2 !~ /10\.0\.1\.(10|11|12)/'

What to look for: OPC-UA sessions established from unexpected clients (IP addresses outside the SCADA/historian subnet), rapid session establishment and teardown (enumeration pattern), or method invocation calls (OPC-UA Type ID 449 — Call Request) from unexpected sources.

Hunting Hypothesis 4: Historian to Internet Connection

Hypothesis: Data historians are a common pivot point in OT attacks — they sit at the IT/OT boundary and hold process data. An attacker who has compromised a historian may use it to exfiltrate data or as a C2 hop. The historian should not initiate outbound connections to internet addresses.

Zeek DNS + conn log hunt:

# Find all outbound connections from historian IP (adjust)
HISTORIAN_IP="10.0.2.50"
cat conn.log | zeek-cut ts id.orig_h id.resp_h id.resp_p service bytes | \
  awk -v hist="$HISTORIAN_IP" '$2 == hist && $3 !~ /^10\./' | sort -k7 -rn

# Correlate with DNS queries from the historian
cat dns.log | zeek-cut ts id.orig_h query answers | \
  awk -v hist="$HISTORIAN_IP" '$2 == hist'

Alert conditions: Any outbound connection from historian to an external IP (non-RFC1918) warrants investigation. DNS queries from the historian for domains outside your expected IT infrastructure are high-fidelity indicators.

Suricata ICS Ruleset

Suricata with Emerging Threats ICS rules (category emerging-scada) provides signature-based detection for known ICS attack patterns. Deploy Suricata in IDS mode (no inline blocking — passive only in OT):

# suricata.yaml snippet — passive mode for OT
outputs:
  - eve-log:
      enabled: yes
      types:
        - alert
        - dns
        - http
        - flow

af-packet:
  - interface: eth0
    cluster-id: 99
    cluster-type: cluster_flow
    defrag: yes

Key rule categories for OT:

  • emerging-scada.rules — Attacks against Modbus, DNP3, IEC 104, PROFINET, EtherNet/IP
  • emerging-exploit.rules — Exploitation of known ICS-adjacent CVEs (Mitsubishi, Siemens, Schneider vulnerabilities)
  • Custom rules for your environment — alert on function codes that should never appear (FC 8 — Diagnostics in a production environment, or FC 22 — Mask Write Register)

Establishing Baselines

The hardest part of OT threat hunting is determining what’s normal. Industrial processes are cyclical — shift patterns, batch cycles, maintenance windows all affect traffic volumes and patterns.

Traffic baseline approach:

  1. Capture 2-4 weeks of normal operation across multiple operational states (production, maintenance, startup, shutdown)
  2. Use Zeek’s sumstats framework or a SIEM (Splunk, Elastic) to compute per-source/destination/protocol statistics
  3. Define “normal” as within 3 standard deviations of the mean across each dimension
  4. Use these baselines as detection thresholds rather than static signatures

Critical baselines to establish:

  • Number of unique Modbus masters active per shift
  • Register addresses written in each shift period (legitimate SCADA writes should be to a known address range)
  • DNP3 outstation poll frequency from each master (deviations indicate either failure or unexpected querying)
  • OPC-UA session count and duration per server
  • Historian outbound connection patterns

OT threat hunting requires patience. The baseline period needs to be long enough to capture normal variation across all operational modes. But once established, the baseline makes anomaly detection far more precise than signature-based detection alone — and far more likely to detect novel attack tooling that doesn’t match known ICS malware signatures.

Tags
OT threat huntingpassive monitoringZeekSuricataModbusDNP3EtherNet/IPICS protocolsSCADAnetwork analysis2026