The nightmare scenario for any industrial operator isn’t just data theft; it’s a cyberattack that crosses the digital divide to cause a physical disaster. Advanced Persistent Threats (APTs) are actively targeting the Operational Technology (OT) that runs our power grids, water treatment plants, and factories.

Traditional, passive defenses like firewalls are no longer enough. To find these advanced attackers, you have to actively hunt for them.

This guide provides a tactical framework for OT threat hunting. We’ll cover the mindset, methodologies, and practical “hunting plays” you can use to proactively identify and evict threats before they disrupt operations.

What Is OT Security?

OT security protects the systems that control industrial processes, physical equipment, and critical infrastructure. That includes:

• ICS (Industrial Control Systems): umbrella term for industrial automation systems.
• SCADA (Supervisory Control and Data Acquisition): long-range monitoring for power grids, pipelines, and utilities.
• DCS (Distributed Control Systems): localized control inside plants or refineries.
• PLCs (Programmable Logic Controllers): rugged computers that control motors, valves, and sensors.
• IIoT (Industrial Internet of Things): smart sensors and devices bringing IT connectivity into OT.

The IT vs. OT Divide

• IT cares about data — Confidentiality, Integrity, Availability.
• OT cares about uptime and safety — Availability, Reliability, Safety.

This culture clash creates weak spots. IT teams patch fast; OT engineers delay changes to avoid outages. Attackers exploit that gap to move from IT into OT.

The OT Security Chasm: Why It’s Not Just “IT for Factories”

Before we hunt, we must understand the hunting ground. OT is not IT. Applying IT security principles without modification is a recipe for failure. While IT security prioritizes the Confidentiality, Integrity, and Availability (CIA) of data, OT has a different mandate.

This fundamental difference creates unique challenges:

• Legacy Systems: OT networks often run on equipment that is decades old, unpatched, and was never designed with security in mind.
• Sensitive Processes: You can’t simply “scan a PLC” for vulnerabilities. An active scan could crash the controller and shut down a production line.
• Proprietary Protocols: Protocols like Modbus and DNP3 were built for efficiency, not security, and lack basic authentication or encryption.
• Physical Consequences: A successful attack doesn’t just crash a server; it can break equipment, spoil products, or endanger human lives.

Because of this, OT threat hunting must be done with surgical precision, deep process knowledge, and a “do no harm” philosophy.

Know Your Enemy: Lessons from Landmark OT Attacks 

To hunt APTs, you need to think like them. Studying past attacks reveals the tactics, techniques, and procedures (TTPs) they use.

• Stuxnet (2010): The first true cyber-physical weapon. It targeted Iranian nuclear enrichment facilities, subtly manipulating centrifuge speeds to cause physical damage. Key TTP: It directly modified PLC logic on Siemens S7 controllers, an audacious move that bypassed traditional security entirely.
• Industroyer (2016): This modular malware was custom-built to speak native industrial protocols (like IEC 61850). It was used to shut down a significant portion of Kyiv’s power grid by sending direct commands to circuit breakers. Key TTP: “Living off the land” by using the protocols the grid operators themselves used, making the malicious traffic look legitimate.
• TRITON/TRISIS (2017): Perhaps the most dangerous of all, this attack targeted the Safety Instrumented System (SIS) of a petrochemical plant—the last line of automated defense against a catastrophic failure. The goal was likely to cause a physical disaster. Key TTP: Targeting the “fail-safe” systems themselves, a domain previously thought to be off-limits.

These attacks prove that determined adversaries will go to great lengths to understand and manipulate physical processes. Our hunt must be equally sophisticated.

The OT Kill Chain

1. Infiltration – phishing, supply chain compromise, IT network foothold.
2. Lateral Movement – pivoting into OT via historians, jump hosts, or dual-homed servers.
3. Process Espionage – studying PLC logic, historian queries, safety parameters.
4. Impact – sabotage, disruption, or disabling safety systems.

The Threat Hunter’s Mindset: Methodologies for OT

Threat hunting is a proactive, iterative process of searching for threats that have evaded your existing security controls. It typically falls into three categories:

1. Intelligence-Led Hunting: You receive a threat intelligence report about an APT group targeting your industry. The report contains specific indicators of compromise (IOCs) like file hashes or IP addresses, or TTPs. You hunt for those specific indicators in your network.
2. Anomaly-Based Hunting: You establish a solid, well-defined baseline of “normal” activity in your OT network. You then hunt for any deviations from this baseline. This could be a new device communicating on the network, an HMI communicating with a PLC at an unusual time, or a user logging in from a strange location.
3. Hypothesis-Driven Hunting: This is the core of proactive threat hunting. You develop a plausible “what if” scenario based on known adversary TTPs and your knowledge of the environment. You then search for the data that would prove or disprove your hypothesis.

A good OT threat hunt often blends all three. You might start with a hypothesis based on threat intelligence and then look for anomalies to validate it.

Gearing Up: Essential Data Sources & Tools 

You can’t hunt what you can’t see. Effective OT threat hunting requires collecting and analyzing the right data.

Key Data Sources:

• Network Traffic: The single most valuable source. Using a network tap or SPAN port, you need to capture and analyze the traffic flowing through your control network. This requires deep packet inspection (DPI) that understands protocols like Modbus, DNP3, and S7.
• Control System Logs: Logs from Human-Machine Interfaces (HMIs), Engineering Workstations (EWs), and historians can reveal unauthorized logins, program downloads to PLCs, or alarm changes.
• Asset Inventory: A detailed inventory of every device on your OT network (PLCs, RTUs, servers, etc.) is foundational. You need to know what should be there to spot what shouldn’t.
• Windows Event Logs: Many HMIs and historian servers run on Windows. Their logs are a rich source of information for lateral movement and malware execution.

Essential Technologies:

• OT Network Security Monitoring (NSM): Passive monitoring platforms (e.g., Security Onion with OT-specific plugins, or commercial tools like Dragos, Nozomi, and Claroty) are critical. They listen to network traffic, identify assets, decode industrial protocols, and alert on suspicious activity without risking operational disruption.
• OT-Specific SIEM: A Security Information and Event Management (SIEM) tool that is tuned for OT can correlate events from multiple sources—a firewall block, an HMI login, and a PLC logic change—to paint a complete picture of an attack.

 Building the Foundation: Visibility Before Hunting

• Asset Inventory: Document every PLC, HMI, SCADA server, firmware version, and vulnerability. You can’t defend what you don’t know.
• Baseline Normal Behavior: Understand what “normal” looks like in Modbus, DNP3, and S7comm traffic.
• Data Sources That Matter:
  • Network packet captures & DPI for ICS protocols.
  • Logs from HMIs and engineering workstations.
  • PLC diagnostics (mode changes, downloads, restarts).
  • OT-specific SIEMs and IDS.

Pro tip: The best hunts correlate cyber signals with physical anomalies (e.g., unauthorized PLC write → pressure spike).

On the Hunt: 4 Actionable Plays for Your OT Environment

Let’s get tactical. Here are a few hypothesis-driven “hunting plays” you can adapt for your own environment.

Play 1: Unauthorized Controller Modification

• Hypothesis: An attacker is attempting to modify the logic or firmware on a PLC or RTU to manipulate the physical process, similar to Stuxnet.
• MITRE ATT&CK for ICS: T0831: Manipulation of Control, T0840: Modify Controller Tasking
• Data Sources: Network traffic, PLC logs, Engineering Workstation logs.
• What to Look For:
  • Network traffic showing a PLC logic/program download from any device other than the designated Engineering Workstation.
  • PLC changing to “Program” or “Remote” mode outside of a scheduled maintenance window.
  • Any firmware update commands sent to a PLC/RTU.
  • Unexpected reboots or faults in a controller.

Play 2: Living Off the Industrial Land

• Hypothesis: An attacker is using your own tools and protocols against you to remain hidden, just like in the Industroyer attack.
• MITRE ATT&CK for ICS: T0814: Denial of Control, T0855: Unauthorized Command Message
• Data Sources: Network traffic with deep packet inspection.
• What to Look For:
  • Industrial protocol commands (e.g., Modbus “Write Coil,” DNP3 “Select and Operate”) originating from an unexpected source (e.g., an HMI that should only have read-only access).
  • A high volume of diagnostic or testing commands sent to field devices.
  • Any device attempting to communicate using multiple industrial protocols when it should only use one.

Play 3: Hijacked Remote Access

• Hypothesis: An attacker has compromised a vendor’s remote connection or is misusing RDP/VNC to move from the IT network into the OT network.
• MITRE ATT&CK for ICS: T0886: Remote Services
• Data Sources: Firewall logs, VPN logs, Windows Event Logs on HMIs/EWs.
• What to Look For:
  • Remote access sessions (RDP, VNC, TeamViewer) occurring at unusual times (e.g., 2:00 AM).
  • Logins to an Engineering Workstation from an IP address that doesn’t belong to a known user or vendor.
  • Multiple failed login attempts followed by a success on a critical HMI or server.

Play 4: Probing the Safety System

• Hypothesis: An attacker is performing reconnaissance on or attempting to communicate with the Safety Instrumented System (SIS), inspired by the TRITON attack.
• MITRE ATT&CK for ICS: T0825: Inhibit Response Function, T0880: Spearphishing for Information
• Data Sources: Network traffic, SIS Engineering Workstation logs.
• What to Look For:
  • ANY network communication to the SIS from a device that is not the dedicated SIS Engineering Workstation. The SIS network should be isolated and silent.
  • The SIS controller being switched into “program” mode.
  • Attempts to upload or download logic to the safety controller.
  • Network scans (e.g., Nmap) detected on the SIS network segment.

Structuring the Hunt with MITRE ATT&CK® for ICS

Hunting can feel chaotic. The MITRE ATT&CK for ICS framework provides a structured way to think about adversary behavior in control systems. It’s a knowledge base of the tactics and techniques that adversaries use, from initial access to physical impact.

Use the framework to:

• Develop Hunting Hypotheses: Pick a technique (e.g., “T0886: Remote Services”) and build a hunting play around it.
• Map Your Defenses: Identify which techniques your current tools can and cannot detect, revealing visibility gaps.
• Communicate Findings: Use the common language of ATT&CK to explain the significance of a threat to both technical and non-technical stakeholders.

Conclusion: Start the Hunt Before They Start the Attack

OT threat hunting is a critical evolution beyond passive defense. It’s an active, continuous effort that requires a unique blend of cybersecurity expertise and deep process control knowledge. It’s not easy, but the alternative—waiting to discover an APT when a turbine overheats or a pipeline shuts down—is far worse.

You don’t need a massive team to get started. Begin with what you have. Form a simple hypothesis. Examine the logs you’re already collecting. The journey begins with a single question: “If an attacker was in my network, what would I expect to see?”