OT Threat Intelligence and Threat Hunting in Industrial Networks

01Key takeaways

1. 01

   OT threat intelligence is narrower than IT CTI: it tracks activity groups and techniques that specifically target ICS, safety systems and physical processes.

2. 02

   Indicators of compromise age quickly. Tactics, techniques and procedures (TTPs) mapped to MITRE ATT&CK for ICS are more durable and drive better hunts.

3. 03

   Useful intel sources are concrete: CISA ICS advisories, sector ISACs and ISAOs, national CERTs, and vendor reporting on tracked groups.

4. 04

   Threat hunting in OT should be hypothesis-driven and lean on passive data: span/tap captures, historian records, firewall and authentication logs, not intrusive scans.

5. 05

   Reducing bidirectional reachability shrinks the techniques an adversary can use, which makes both intelligence and hunting more tractable.

02What OT threat intelligence is

OT threat intelligence is cyber threat intelligence focused on the adversaries, campaigns and techniques that target operational technology: industrial control systems, SCADA, distributed control systems, safety instrumented systems and the field devices behind them. It is the difference between knowing that malware exists and knowing which groups deliberately reach for engineering workstations, PLC logic and process variables.

The discipline borrows the standard intelligence cycle: direction, collection, processing, analysis and dissemination. NIST SP 800-150 describes how organizations share and consume this kind of information. What makes it OT intelligence is the scope. It cares about a smaller set of actors and a smaller set of techniques, because the universe of adversaries willing to attack physical processes is far narrower than the universe attacking IT.

Short version: OT threat intelligence answers who would attack systems like ours, how they operate, and what their activity looks like in our data — not just which generic malware is trending this week.

03Why it matters in industrial environments

Most OT environments cannot patch on demand, cannot reimage a controller mid-shift, and cannot tolerate the downtime that aggressive IT response assumes. That constraint changes the value of intelligence. If you know in advance which techniques a relevant group uses, you can prioritize the few compensating controls that matter rather than chasing every CVE.

The threat is real and specific. Public reporting has documented ICS-aware malware families and intrusion sets that manipulate safety systems, abuse legitimate engineering protocols, and target electric, water and manufacturing operations. Intelligence turns those events into a defensible model: which assets, which protocols, which access paths an adversary would need.

• Patch cycles are slow, so knowing the likely technique beats reacting to every vulnerability.
• The set of capable OT adversaries is small enough to track by named activity group.
• Consequences are physical: safety, environmental release, and production loss, not just data theft.
• Many ICS techniques abuse legitimate functionality, so intelligence on behavior matters more than signatures.
• Regulators and ISACs increasingly expect operators to consume and act on sector threat reporting.

04Tracking ICS activity groups

OT intelligence organizes adversaries into activity groups (also called threat groups or intrusion sets): clusters of related behavior, infrastructure and tooling observed across intrusions. Because attribution to a specific government or person is hard and slow, defenders work from behavior. A group is defined by what it does, not by who it ultimately is.

Several vendors and CERTs publish named groups and the sectors they target, and MITRE ATT&CK for ICS maintains a Groups and Software catalog mapped to techniques. The practical use is matching: compare a group's documented behavior against your own sector, geography, equipment vendors and architecture. A group that only ever targets a protocol you do not run is lower priority than one that targets your exact controller family.

Activity group

A behavior-based cluster of intrusion activity tracked by tooling, infrastructure and technique, independent of formal attribution.

Capability

What the group can demonstrably do in ICS, such as manipulating PLC logic or interacting with a safety controller.

Targeting

The sectors, regions and equipment a group has shown interest in, used to rank relevance to your site.

Intent

Whether observed activity is reconnaissance, prepositioning, disruption or destruction, which shapes urgency.

05Indicators versus behaviors: IOCs and TTPs

Intelligence comes at different levels of durability. Indicators of compromise (IOCs) are concrete artifacts: file hashes, IP addresses, domains, certificates. They are easy to match but they age fast, because an adversary can change infrastructure between campaigns in minutes. Tactics, techniques and procedures (TTPs) describe behavior, which is far more expensive for an adversary to change.

David Bianco's Pyramid of Pain captures the trade-off: blocking a hash causes the adversary trivial pain, while denying a technique forces real rework. In OT this is sharpened by the environment. A water or power network may never see a known-bad hash, but it will see anomalous engineering connections, unexpected logic downloads or off-hours protocol traffic. Hunting on behavior catches what indicator matching misses.

Use IOCs for fast, cheap detection and retrospective sweeps. Build your durable hunts on TTPs mapped to ATT&CK for ICS, because behavior is what an adversary cannot easily discard.

06Hunting with ATT&CK for ICS

MITRE ATT&CK for ICS is a knowledge base of adversary tactics and techniques observed against industrial control systems. It is the framework; this article is about using it to hunt. Each technique becomes a testable hypothesis: if technique X occurred here, what evidence would exist in our passive data, and can we find it?

Strong OT hunts target techniques that abuse legitimate ICS functionality, because those are the ones that evade signatures. Examples worth a hypothesis include unauthorized command messages on a control protocol, program download or modification to a controller, manipulation of the engineering view (spoofed reporting), and unusual remote-services access into a control zone. Each maps cleanly to a data source you likely already have.

Hypothesis

A specific, falsifiable statement, e.g. an adversary downloaded new logic to a PLC outside a change window.

Data source

Where evidence would live: protocol-aware capture, historian, engineering server logs, authentication records.

Analytic

The query or pattern that confirms or refutes the hypothesis, such as logic-download function codes from an unexpected host.

Outcome

Confirm, refute, or refine; every hunt should also feed a detection rule or a documented gap.

07Where the intelligence comes from

OT intelligence is only as good as its sources, and the best ones for industrial defenders are concrete and often free. CISA publishes ICS advisories and alerts covering vulnerabilities in named products and ongoing campaigns against critical infrastructure. National CERTs and the IAEA add nuclear-sector context. These are authoritative, sector-relevant, and timestamped.

Sector sharing organizations add the operational layer. ISACs and ISAOs — for example the electricity, water and downstream natural gas communities — circulate member-only reporting, indicators and tradecraft that rarely appear in public advisories. Vendor threat-intelligence teams contribute deep technical analysis of tracked activity groups and ICS malware. The skill is correlating across all three so a single advisory becomes a prioritized action for your site.

• CISA ICS advisories and alerts for product vulnerabilities and active campaigns.
• Sector ISACs and ISAOs (E-ISAC, WaterISAC, and others) for member tradecraft and indicators.
• National CERTs and bodies such as ENISA and the IAEA for regional and nuclear-sector context.
• Vendor and independent reporting on named ICS activity groups and malware families.
• MITRE ATT&CK for ICS for the technique vocabulary that ties all sources together.

08Hypothesis-driven hunting on passive data

OT networks are sensitive to disruption, so hunting should favor data that already exists over anything that touches a controller. Passive collection — port mirrors, network taps, protocol-aware sensors — gives visibility without injecting traffic. Detection plumbing is a separate topic; here the point is what to do with that data once it flows to an analysis environment.

A disciplined hunt starts from intelligence, not from tooling. Pick a relevant activity group, choose one of its ATT&CK for ICS techniques, state the hypothesis, identify the passive data source, write the analytic, and record the result. Run it against historical capture first, then forward. The output is always one of three things: a confirmed incident, a new detection, or a documented visibility gap you can fix.

• Span/tap captures and protocol-aware sensors for control-protocol behavior.
• Process historian records for values that move when no legitimate command should have occurred.
• Engineering workstation and jump-host logs for off-window logic changes.
• Authentication and remote-access logs for unexpected sessions into a control zone.
• Firewall and conduit logs for flows that should not exist across a boundary.

09Standards mapping and common pitfalls

Threat intelligence and hunting are not freelance activities; they map to recognized frameworks. NIST SP 800-82 Rev. 3 covers OT security program elements including detection and response, and SP 800-150 sets out cyber threat information sharing. ISA/IEC 62443 frames the zones and conduits that hunting hypotheses test, and its security-level concepts help prioritize which adversary capabilities to defend against. On the regulatory side, electric utilities work under NERC CIP and many European operators of essential services fall under NIS2 with national CERT reporting duties — framing the program against these references makes the work auditable.

Most OT intelligence programs still fail in predictable ways. The biggest is treating IT CTI as if it were OT CTI: drowning in commodity-malware feeds while missing the handful of activity groups that matter. The second is indicator obsession, building everything around IOC matching with no behavioral hunts behind it. The third is operational: running intrusive scans against production controllers in the name of hunting, and causing the very outage you were trying to prevent.

• Consuming generic IT threat feeds with no ICS relevance filter.
• Relying on perishable IOCs instead of durable, mapped TTPs.
• Active scanning or polling of live controllers during a hunt.
• Intelligence that never converts into a detection or a documented gap.
• No feedback loop: hunts and advisories that do not update asset, segmentation or monitoring decisions.

10Where exposure reduction fits

Intelligence and hunting tell you what an adversary would try; architecture decides how much of it is even possible. Many high-consequence ICS techniques — remote command, logic download, interactive engineering access — depend on a network path into the control zone. Removing that path removes whole branches of the attack tree before a hunter ever has to look for them.

This is where reducing bidirectional reachability pays off. Strong segmentation, scheduled disconnection, and one-way data transfer let telemetry, logs and historian data flow out to a SOC or analytics platform without granting an inbound route back. A one-way path means the hunt for inbound command-and-control on that conduit has a structurally simpler answer, and the intelligence about inbound techniques becomes largely moot for that boundary.

Exposure reduction and intelligence are complementary, not competing. A control such as one-way data transfer shrinks the technique space; threat hunting then covers what remains. A data diode is one control among many — it does not replace monitoring, asset inventory or response.

11Building the capability: a roadmap

A workable OT intelligence and hunting capability is built in stages, not bought in a box. Start by knowing your environment well enough to judge relevance: asset inventory, protocols in use, equipment vendors and external connections. Without that, no feed can tell you what matters.

Then connect the sources, adopt ATT&CK for ICS as the shared vocabulary, and run a small number of well-documented hypothesis-driven hunts on passive data. Feed every result back into detection rules, segmentation decisions and the next round of collection. The goal is not a wall of dashboards; it is a short list of relevant adversaries, a tested set of hunts, and an architecture that keeps shrinking what those adversaries can reach.

• Establish asset inventory, protocol baseline and external-connection mapping first.
• Subscribe to CISA advisories and the ISAC for your sector; filter for ICS relevance.
• Adopt ATT&CK for ICS as the common language across intel and detection teams.
• Run a few documented, passive-data hunts; convert each into a rule or a gap.
• Use segmentation and one-way transfer to remove inbound paths the hunts keep finding.

FAQFrequently asked questions

SRCSources of record