Threat hunting in operational technology environments is not the same as hunting in IT networks. The stakes are different, the traffic patterns are different, and the tools attackers use are different. But one thing that does carry over from IT security is this: relying solely on indicator-based hunting will leave gaps in your coverage. Big ones.
In OT and ICS environments, those gaps can mean the difference between catching an intrusion during reconnaissance and discovering it after a process disruption. This post breaks down the difference between indicator-based and behavioral threat hunting, walks through both approaches using a proven framework, and explains how combining them builds a far more resilient program, whether you’re protecting a substation, a water treatment plant, or a manufacturing floor.
Indicator-based hunting means searching your environment for known bad artifacts: malicious file hashes, suspicious IP addresses, known command-and-control domains, specific registry keys, or signatures from threat intelligence feeds.
If a government advisory or threat intel report says “this IP was used in attacks against energy sector targets,” you sweep your logs. That’s indicator-based hunting.
It’s fast, it’s concrete, and it works well for catching known threats. The problem is that it’s inherently reactive. You can only find what someone has already documented and shared. In OT environments where threat actors often move slowly and quietly over weeks or months, that lag matters.
Behavioral threat hunting focuses on how threats act, not just what they look like. Instead of searching for a specific malicious IP, you ask: Does this traffic pattern make sense for a SCADA network? Instead of matching a file hash, you ask: Why is an engineering workstation making outbound connections it has never made before?
Behavioral hunting requires a solid baseline of what “normal” looks like in your environment, which is one reason it’s harder to get started with. But once that baseline exists, it catches things that no indicator list ever will: novel malware, living-off-the-land techniques, and slow-burn intrusions that never trigger a single signature.
David Bianco’s Pyramid of Pain is a useful model for understanding where these two hunting styles operate and how they complement each other.
The pyramid layers, from base to peak:
The higher up the pyramid you detect, the more work an attacker has to do to evade you. Changing a file hash takes seconds. Changing fundamental attack behavior takes significant effort and resources. Both hunting approaches apply across all levels, but behavioral hunting becomes increasingly powerful as you move toward the top.
Indicator approach: You have a list of known malicious hashes, say for a remote access tool commonly abused in ICS attacks. You sweep your endpoints for any file matching those hashes.
The limitation: Attackers recompile. Slightly modified binaries produce entirely different hashes. If they tweak the tool, your hash-only hunt comes up empty.
Behavioral approach: Establish a hash baseline for every executable that belongs in your OT environment. Then hunt for deviations. An unexpected executable on a historian server or an engineering workstation that does not match your approved baseline is worth investigating, regardless of whether its hash appears on any threat feed.
In OT specifically, Many OT environments run a small, relatively static set of software. This actually makes hash-based baselining more practical here than in enterprise IT. Use that to your advantage.
Why combine them: Known-bad hashes provide quick, high-confidence hits. Behavioral deviations from your expected baseline catch the variants and the custom tooling that never make it onto a threat feed.
Indicator approach: A CISA advisory flags a specific IP address used in attacks against industrial control system operators. You search logs for any traffic to or from that IP.
The limitation: Attackers rotate infrastructure constantly. VPNs, Tor exit nodes, and compromised third-party systems mean the IP in an advisory may be cold within days of publication.
Behavioral approach: Enrich the indicator. Who owns that IP block? What ASN is it associated with? If that IP belongs to a telecom provider in a country your OT network has no business reason to communicate with, that context matters more than the specific address.
In OT specifically, Legitimate OT traffic is often highly predictable. A PLC communicating with an engineering workstation should not be making connections to external IP ranges under almost any circumstance. Behavioral anomaly detection on egress traffic from OT segments catches a category of threat that IP blacklists never will.
Why combine them: The specific indicator gives you a starting point. The behavioral analysis tells you whether the broader traffic pattern makes sense and helps surface other suspicious destinations that share similar characteristics but do not appear on any list yet.
Indicator approach: A threat report identifies a domain used for command-and-control by a group known to target energy sector OT environments. You search DNS logs and proxy logs for any resolution of or connection to that domain.
The limitation: Malicious domains can be abandoned and replaced within hours. Domain generation algorithms mean there may be thousands of candidate domains, only a fraction of which end up documented in threat reports.
Behavioral approach: Look past the domain name itself. Where does it resolve? When was it registered? Does the registration look like a legitimate business or a throwaway account? Who inside your network is querying it, and does that make any operational sense?
In OT specifically, Most OT assets have no reason to be making DNS queries to external domains at all. If a device in your control network is resolving unfamiliar external hostnames, that is a behavioral signal worth investigating immediately, regardless of whether the domain appears on a threat feed.
Why combine them: Known-bad domain indicators are concrete leads. Behavioral analysis of DNS query patterns from OT assets can surface C2 and exfiltration channels that no one has written up yet.
Indicator approach: Search network captures, flow data, and endpoint logs for known bad indicators: specific user-agent strings, known malicious registry keys, or default scanner signatures.
The limitation: Experienced attackers customize everything. Default Nmap strings, obvious user agents, and textbook registry persistence locations are cleaned up or avoided entirely by anyone who has done this before.
Behavioral approach: Instead of hunting for the specific artifact, hunt for the behavior the artifact produces. In an OT environment, that means asking questions like:
In OT specifically, OT protocols like Modbus, DNP3, EtherNet/IP, and PROFINET have well-defined communication patterns in a healthy environment. Anomalies in those patterns are one of the clearest behavioral signals available to OT defenders.
Why combine them: Indicators give you sharp, specific alerts. Behavioral pattern analysis gives you the broader picture, and in OT environments where protocol behavior is highly predictable, that context is extremely powerful.
Indicator approach: A known threat group uses a specific remote access tool to move laterally in ICS environments. YARA rules exist for it. You run them across your environment.
The limitation: Good threat actors know what YARA rules exist for their tooling. They modify, repack, or replace tools specifically to evade known signatures. Legitimate software can also trigger false positives on tool-based signatures.
Behavioral approach: Understand what the tool does, not just what it looks like. How does it establish persistence? What protocol does it use for communication? Does it attempt to interact with OT-specific software like a human-machine interface or a historian?
In OT specifically, Tools designed for IT lateral movement behave strangely in OT environments. They generate unexpected traffic, interact with unusual ports, and sometimes trigger protocol errors on OT devices not designed to handle unexpected connection attempts. Those behavioral anomalies are detectable even when the tool itself evades signature detection.
Why combine them: A YARA or signature hit gives you a potential lead. Behavioral analysis of what the tool is actually doing, and whether that behavior fits known attack patterns, separates true positives from noise and catches variants that evade the signature.
Behavioral approach: At this level, hunting becomes entirely about understanding the attacker’s methodology. Regardless of the specific hash, IP, domain, or tool, how does this threat actor typically establish a foothold in OT environments? How do they move from the IT network into the OT network? How do they interact with control system assets once they are in?
Mapping observed activity to MITRE ATT&CK for ICS provides a structured way to answer those questions and to understand what techniques are being used even when none of the lower-level indicators match anything known.
In OT specifically, ICS-targeted threat actors follow recognizable playbooks. They tend to spend significant time in passive reconnaissance before taking any action on objectives. They learn the process before they touch it. Behavioral hunting at the TTP level, looking for the slow, quiet patterns of reconnaissance and learning rather than noisy exploitation, is where OT-specific threat hunting really pays off.
Why combine them: Lower-level indicators and behavioral observations become data points that, assembled together, map to TTPs. That complete picture is the most resilient to attacker adaptation and the most useful for understanding what an adversary is actually trying to accomplish.
A mature OT threat hunting program uses both approaches as part of a continuous cycle:
The tools and visibility you need to run this program have to be purpose-built for OT environments. Standard IT security monitoring tools do not understand OT protocols, do not have context for what normal looks like in a control network, and often generate enough noise in OT environments to make behavioral analysis impractical.
Valkyrie is built specifically for OT environments. It provides the protocol-aware visibility and behavioral monitoring that makes this kind of hunting practical, with an understanding of Modbus, DNP3, EtherNet/IP, and other ICS protocols baked in rather than bolted on.
For environments where you need portable, air-gapped assessment capability, Cygnet brings the same Valkyrie functionality in a flyaway kit that operates without cloud connectivity or internet access. That matters a lot for remote sites, air-gapped networks, or short-duration assessments where standing up a permanent monitoring infrastructure is not practical.
Our professional services team also works with organizations to build and mature OT threat hunting programs from the ground up, including establishing behavioral baselines, developing site-specific hunt playbooks, and running hands-on assessments using Cygnet at locations that have never had this level of OT visibility before.
If you want to talk through where your program stands today and what a realistic path forward looks like, we are happy to have that conversation.
Indicator-based hunting is not optional. IOC feeds, threat intelligence, and signature-based detection are foundational. Do not abandon them.
But in OT environments especially, where attackers move slowly, where the stakes of a missed intrusion are high, and where legitimate traffic is predictable enough to make behavioral analysis genuinely practical, stopping at indicators leaves too much on the table.
Combine both approaches. Build the baseline. Hunt the behavior. And use tools that actually understand the environment you are defending.
Insane Cyber builds OT security monitoring and assessment tools for the environments most people treat as too hard to monitor. Learn more about Valkyrie and Cygnet at insanecyber.com.
Our products are designed to work with
you and keep your network protected.