Best 12 OT Threat Hunting Techniques (step-by-step)
Industrial control systems (ICS) and operational technology (OT) now sit squarely in the crosshairs of threat actors. Nation-state groups and financially motivated attackers increasingly target process logic, safety systems, and supply-chain access – often blending IT methods with domain-specific manipulations that can cause physical impact. Modern OT threat hunting must therefore be process-aware, protocol-sensitive and hypothesis-driven, and it should map to frameworks like MITRE ATT&CK for ICS to link findings to adversary behavior.
Below I map 12 high-value hunting techniques into practical, repeatable steps you can run in an OT environment – from a first scout to advanced physics-based detection. Each technique contains: the objective, a hypothesis, required data sources, tools/queries/artifacts, what to look for, and recommended next steps. Use them as discrete hunts or stitch them into a regular cadence for a programmatic OT hunt capability. The guidance below aligns with industry playbooks and standards for OT incident response.
1. Asset & Baseline Discovery (Start here)
Objective: Know every device, firmware, protocol and expected behavior on your control networks.
Hypothesis: Undocumented or changed assets are likely entry points or indicators of compromise.
Data sources: Passive network captures, ARP/LLDP, protocol decoders (Modbus, DNP3, IEC 104/61850), asset inventory, CMDB, historian tags.
Tools: Passive sensors (PCAP + protocol parsers), asset discovery tools (Nozomi/Dragos/industrial sniffers), SNMP/SSH/OPC queries.
What to hunt for: New MAC/IPs, unknown device types, mismatched firmware versions, duplicate device identities, unexpected service ports.
Actionable next steps: Quarantine unknown assets, add to inventory, schedule firmware integrity checks. (Start here every hunt – if you don’t know your assets, everything else is guesswork.)
2. Protocol Sequence & Command-Response Integrity Hunting
Objective: Detect anomalous or out-of-order control commands and dangerous command sequences.
Hypothesis: Adversaries alter command sequences to cause unsafe operations or mask actions.
Data sources: Historian time series, HMI logs, PLC command logs, network packet captures.
Tools/queries: Time-series anomaly detection, custom parsers for Modbus function codes, IOC lists for unsafe setpoints.
Indicators: Sudden actuator setpoint changes not correlated with operator input, command bursts at odd hours, single PLC receiving unusual write commands.
Next steps: Cross-verify with operator shift logs; if malicious, isolate PLC, revert to known good program, preserve forensic captures.
3. Cross-Referencing Process Physics (Sensor ↔ Actuator)
Objective: Use physical process invariants (pressure/flow/temp relationships) to spot spoofed telemetry or actuator tampering.
Hypothesis: Cyber changes will cause physical-model deviations detectable in sensor correlations.
Data sources: Historian telemetry, SCADA alarms, physics models (digital twin if available).
Tools: Statistical correlation engines, simple physical rules (e.g., valve position vs. flow), machine learning anomaly detectors.
Indicators: Sensors that violate thermodynamic/process relationships, telemetry replay (values jump to previous patterns), time-lag mismatches.
Next steps: Trigger an operational safety check, initiate manual confirmation from field crews, block suspected command sources.
4. PLC/Controller Memory & Firmware Integrity Checks
Objective: Find unauthorized changes to controller logic and firmware (the classic “Change Program State” attack).
Hypothesis: Attackers replace or modify ladder logic to change process behavior.
Data sources: Firmware images, PLC program backups, vendor checksums, asset baseline.
Tools: Firmware comparison tools, signed firmware verification when supported, YARA rules for known malicious binaries.
Indicators: New or altered logic blocks, unknown routines scheduled at odd intervals, firmware hash mismatches.
Next steps: Restore controller from golden image, conduct root cause analysis and supply chain check. (Technique aligns with historical ICS malware incidents – Stuxnet/Triton style).
5. Lateral Movement & Remote Access Hunting
Objective: Detect attacker pivoting from IT to OT or across OT segments.
Hypothesis: Compromised workstations will be used for VPN/remote desktop or SMB/WinRM pivoting into engineering stations.
Data sources: FW/NAT logs, VPN logs, RDP/SSH session logs, Windows event logs on engineering endpoints.
Tools/queries: Hunt for abnormal remote access, unusual account logons, unusual sequences of cross-segment flows. Use ATT&CK mapping to identify lateral movement tactics.
Indicators: New accounts used at odd times, multi-segment sessions from a single host, RDP tunnelled through jump box.
Next steps: Block accounts, force password rotation, perform memory capture of suspect hosts, check for persistence.
6. Credential & Identity Abuse Hunting
Objective: Root out credential theft, reuse and misuse in OT.
Hypothesis: Adversaries rely on stolen service and operator credentials to issue commands or persist.
Data sources: Authentication logs, LDAP/Azure AD, local accounts on HMIs/PLCs, password vault audit.
Tools/queries: Search for brute force patterns, account lockouts, unusual privilege escalations, JWT/OAuth anomalies.
Indicators: Non-work hours logins, use of stale local accounts, multiple machines using same service account.
Next steps: Enforce MFA for privileged access to gates/HMIs, rotate service credentials, implement least privilege on OT management stations. (CISA and other agencies emphasize identity controls in OT access playbooks.)
7. Network-Protocol Anomaly Detection (Deep DPI for OT protocols)
Objective: Find protocol anomalies (malformed frames, unexpected function codes, replayed packets).
Hypothesis: Attackers will craft protocol messages that deviate from normal grammar/sequence to manipulate devices.
Data sources: Full packet captures, PLC/HMI communication logs.
Tools/queries: DPI engines with industrial protocol parsers, Suricata/Zeek rules adapted for Modbus/IEC/MMS.
Indicators: Bad CRCs, unusual function codes, repeated reads/writes to coil registers, packet timing anomalies.
Next steps: Deploy or tune protocol DPI signatures, create signatures for repeated anomalous commands, alert ops on repeat offenders.
8. Historian & Data Integrity Hunting
Objective: Detect tampering with recorded process data (attackers manipulate logs to hide their tracks).
Hypothesis: Adversaries will alter historian entries or introduce gaps to cover unwanted changes.
Data sources: Historian DB, HMI screenshots, redundant historian copies, tape/archive.
Tools/queries: Compare multiple historian replicas, use append-only logging, checksums over data windows.
Indicators: Gaps or overlaps in time series, duplicate timestamps, uncorrelated archives between replicas.
Next steps: Switch over to read-only historian copy for forensic preservation, raise incident to OT/IR team.
9. Supply-Chain & Third-Party Access Hunting
Objective: Find misuse or compromise via vendor remote support tools and supply-chain updates.
Hypothesis: Vendor support access or firmware updates are a common vector for OT compromise.
Data sources: VPN logs, remote support tooling logs (TeamViewer, vendor OEM portals), patch management logs.
Tools/queries: Audit third-party session records, hunt for remote sessions outside maintenance windows, verify update signatures.
Indicators: Unscheduled remote sessions, file transfers from vendor IPs to engineering assets, unsigned firmware.
Next steps: Enforce strict vendor access policies, recorded sessions, just-in-time access, and ephemeral credentials.
10. Deception & Honeytoken Hunting
Objective: Lure attackers into interacting with decoys (honeypots, fake PLCs, honeytokens) to expose intent and fingerprint tools.
Hypothesis: Attackers who probe decoys can be positively identified without risking real assets.
Data sources: Decoy logs, sinkhole telemetry, darknet collectors.
Tools/queries: ICS honeypots (constrained virtual PLCs), fake credential sinks, fake OPC tags.
Indicators: Interactions with decoys, unauthorized reads/writes, attempted exploitation of virtual devices.
Next steps: Use captured tools/IOCs to enrich detection, block source IPs, share anonymized findings with industry ISACs.
11. Threat Intelligence-Driven IOC Hunting
Objective: Proactively search for known Indicators of Compromise (hashes, C2 domains, YARA signatures) mapped to ICS TTPs.
Hypothesis: Published IOCs and TTPs provide high-value, quick wins when hunting for active campaign artifacts.
Data sources: Threat intel feeds (Dragos/Nozomi/CERTs), endpoint telemetry, network logs.
Tools/queries: Enrich SIEM with OT-specific IOCs, YARA for binaries, DNS/C2 detection.
Indicators: Matches to known ICS malware families, beaconing to known C2 hosts, signatures inside engineering workstations.
Next steps: Validate IOC hit in context (avoid blindplay), escalate to IR if confirmed, patch and remove persistence. (Use ATT&CK mapping to prioritize hunts by adversary intent.)
12. Continuous Improvement: Metrics, Red-Team Emulation & Playbooks
Objective: Turn hunts into measurable program improvements through emulation, runbook validation and KPIs.
Hypothesis: Regularly measured hunting and red-team emulation increase detection speed and reduce dwell time.
Data sources: Hunt telemetry, detection times, containment times, red/blue exercise results.
Tools/queries: ATT&CK-based emulation plans, ATT&CK Navigator, fault-injection in safe testbeds.
Indicators of success: Reduced mean time to detect (MTTD), reduced mean time to respond (MTTR), increased % of hunts that find confirmed threats.
Next steps: Formalize hunt cadence (weekly hypotheses, monthly deep hunts), publish playbooks, align KPIs to business/OT safety outcomes.
Practical tips for OT hunting teams
- Safety first: Always validate hunting actions against safety constraints with OT owners before interacting with live controllers. Never run invasive tests in production without explicit OT approval.
- Keep hunts hypothesis-driven: Use a short, falsifiable hypothesis for each hunt, then gather only the needed data – this reduces noise and respects operational priorities.
- Use process context: Translate network anomalies into process impact (what would happen to flow/pressure/temperature?) – that’s what makes OT hunting actionable.
- Blend deterministic and statistical approaches: Rule-based detectors (protocol grammar violations) + ML for pattern anomalies work best together.
- Share anonymized findings: Participate in industry ISACs/CERTs; sector sharing accelerates detection of new campaigns. (CISA/sector playbooks often recommend cross-agency collaboration.)
Quick starter playbook (weekly cadence)
- Weekly asset & baseline sweep (Technique #1). Add discoveries to CMDB.
- Daily passive DPI review (Technique #7) for protocol violations.
- Twice-weekly historian cross-checks (Technique #8) for data integrity gaps.
- Monthly firmware & PLC program integrity checks (Technique #4).
- Quarterly red-team emulation & deception validation (Techniques #10 & #12).
Conclusion – hunting as a discipline, not an annual checkbox
OT threat hunting is where domain knowledge intersects with forensic rigor. The 12 techniques above provide a practical playbook: start with discovery, layer protocol-aware and physics-aware analysis, hunt credentials and lateral movement, use deception and intelligence, and close the loop with metrics and emulation. Threats evolve fast; building a habit of short, repeatable hunts mapped to ATT&CK and backed by playbooks will materially reduce attacker dwell time and the chance of physical impact. For specific playbooks, vendor detection signatures, and attack reports referenced above, consult the linked industry guidance and threat reports.