Detecting Modbus Protocol Anomalies
Overview
Cybersecurity skill for detecting modbus protocol anomalies. Follows industry best practices and security standards.
When to Use
Trigger phrases:
"detecting modbus protocol anomalies"
"This skill covers detecting anomalies in Modbus/TCP and Modbus RTU communication"
When deploying Modbus-specific intrusion detection in an OT environment
When building baseline models for deterministic Modbus polling patterns
When investigating suspicious Modbus traffic flagged by OT monitoring tools
When implementing function code allowlisting on industrial firewalls
When detecting unauthorized Modbus write commands that could manipulate process setpoints
Do not use for securing Modbus communications end-to-end (Modbus has no native security; see implementing-network-segmentation-for-ot for firewall-based controls), for non-Modbus protocol monitoring (see detecting-anomalies-in-industrial-control-systems for multi-protocol), or for active fuzzing of Modbus implementations (see performing-plc-firmware-security-analysis).
When NOT to Use
- When you lack proper authorization for testing
- For production systems without change management
- When the task requires legal or compliance expertise beyond technical scope
Prerequisites
- Network SPAN/TAP access to monitor Modbus/TCP traffic (port 502)
- Zeek (formerly Bro) with Modbus protocol analyzer or Suricata with OT rulesets
- Python 3.9+ with scapy and pymodbus for custom analysis
- Baseline capture of normal Modbus traffic (minimum 1-2 weeks)
- Documentation of authorized Modbus clients, function codes, and register maps
Workflow
# Example: IOC detection
import re
IOC_PATTERNS = {
"ip": r"\b(?:\d{1,3}\.){3}\d{1,3}\b",
"domain": r"\b[a-z0-9-]+\.[a-z]{2,}\b",
"hash_md5": r"\b[a-f0-9]{32}\b",
"hash_sha256": r"\b[a-f0-9]{64}\b",
}
def extract_iocs(text: str) -> dict:
return {k: re.findall(v, text) for k, v in IOC_PATTERNS.items()}
- Define Detection Scope — Identify the specific modbus protocol anomalies techniques or indicators to hunt. Map to MITRE ATT&CK tactics/techniques where applicable.
- Collect Baseline Data — Gather historical logs and establish normal behavior patterns for modbus protocol anomalies.
- Build Detection Queries — Write detection rules, Sigma rules, or SIEM queries targeting modbus protocol anomalies indicators.
- Execute Hunts — Run queries against the collected data, starting with broad filters and narrowing down.
- Triage Results — Investigate alerts, filter false positives, and validate findings against known-good behavior.
- Document Findings — Record confirmed detections, IOCs, and affected systems. Update detection rules based on findings.
Tools
- SIEM Platform — Central log aggregation and query execution
- Sigma Rules — Vendor-agnostic detection rule format
- MITRE ATT&CK Navigator — Technique mapping and coverage analysis
Process
- Reconnaissance — Gather target information, identify attack surface, enumerate services
- Analysis/Exploitation — Execute the technique, analyze results, document findings
- Reporting — Document IOCs, write findings, provide remediation recommendations
Verification
Anti-Rationalization Table
| Rationalization |
Reality |
| "We are too small to be targeted" |
Automated attacks target everyone. Size does not matter. |
| "Security slows us down" |
A breach slows you down 100x more. Build security in from the start. |
| "We will fix it after launch" |
Vulnerabilities in production are exploited within hours. Fix before deploy. |
1---2name: detecting-modbus-protocol-anomalies3description: Use when this skill covers detecting anomalies in Modbus/TCP and Modbus RTU communications in industrial control systems. It addresses function code monitoring, register range validation, timing analysis, unauthorized client detection, and deep packet inspection for malformed Modbus frames. The skill leverages Zeek with Modbus protocol analyzers, Suricata IDS with OT rules, and custom Python-based detection using Markov chain models for normal Modbus transaction sequences.4license: Apache-2.05---67# Detecting Modbus Protocol Anomalies89## Overview1011Cybersecurity skill for detecting modbus protocol anomalies. Follows industry best practices and security standards.1213## When to Use14**Trigger phrases:**15- "detecting modbus protocol anomalies"16- "This skill covers detecting anomalies in Modbus/TCP and Modbus RTU communication"171819- When deploying Modbus-specific intrusion detection in an OT environment20- When building baseline models for deterministic Modbus polling patterns21- When investigating suspicious Modbus traffic flagged by OT monitoring tools22- When implementing function code allowlisting on industrial firewalls23- When detecting unauthorized Modbus write commands that could manipulate process setpoints2425**Do not use** for securing Modbus communications end-to-end (Modbus has no native security; see implementing-network-segmentation-for-ot for firewall-based controls), for non-Modbus protocol monitoring (see detecting-anomalies-in-industrial-control-systems for multi-protocol), or for active fuzzing of Modbus implementations (see performing-plc-firmware-security-analysis).262728## When NOT to Use2930- When you lack proper authorization for testing31- For production systems without change management32- When the task requires legal or compliance expertise beyond technical scope333435## Prerequisites3637- Network SPAN/TAP access to monitor Modbus/TCP traffic (port 502)38- Zeek (formerly Bro) with Modbus protocol analyzer or Suricata with OT rulesets39- Python 3.9+ with scapy and pymodbus for custom analysis40- Baseline capture of normal Modbus traffic (minimum 1-2 weeks)41- Documentation of authorized Modbus clients, function codes, and register maps4243## Workflow4445```python46# Example: IOC detection47import re4849IOC_PATTERNS = {50 "ip": r"\b(?:\d{1,3}\.){3}\d{1,3}\b",51 "domain": r"\b[a-z0-9-]+\.[a-z]{2,}\b",52 "hash_md5": r"\b[a-f0-9]{32}\b",53 "hash_sha256": r"\b[a-f0-9]{64}\b",54}5556def extract_iocs(text: str) -> dict:57 return {k: re.findall(v, text) for k, v in IOC_PATTERNS.items()}58```59601. **Define Detection Scope** — Identify the specific modbus protocol anomalies techniques or indicators to hunt. Map to MITRE ATT&CK tactics/techniques where applicable.612. **Collect Baseline Data** — Gather historical logs and establish normal behavior patterns for modbus protocol anomalies.623. **Build Detection Queries** — Write detection rules, Sigma rules, or SIEM queries targeting modbus protocol anomalies indicators.634. **Execute Hunts** — Run queries against the collected data, starting with broad filters and narrowing down.645. **Triage Results** — Investigate alerts, filter false positives, and validate findings against known-good behavior.656. **Document Findings** — Record confirmed detections, IOCs, and affected systems. Update detection rules based on findings.6667## Tools6869- **SIEM Platform** — Central log aggregation and query execution70- **Sigma Rules** — Vendor-agnostic detection rule format71- **MITRE ATT&CK Navigator** — Technique mapping and coverage analysis727374## Process75761. **Reconnaissance** — Gather target information, identify attack surface, enumerate services771. **Analysis/Exploitation** — Execute the technique, analyze results, document findings781. **Reporting** — Document IOCs, write findings, provide remediation recommendations7980## Verification8182- [ ] All modbus protocol anomalies procedures executed completely and documented83- [ ] Findings validated against multiple data sources84- [ ] False positives identified and filtered85- [ ] Results documented with evidence and timestamps86- [ ] Recommendations provided with risk-based prioritization8788## Anti-Rationalization Table8990| Rationalization | Reality |91|---|---|92| "We are too small to be targeted" | Automated attacks target everyone. Size does not matter. |93| "Security slows us down" | A breach slows you down 100x more. Build security in from the start. |94| "We will fix it after launch" | Vulnerabilities in production are exploited within hours. Fix before deploy. |