Operational technology is the equipment that does the work. It steers a ship, trips a breaker at a substation, controls equipment in a manufacturing plant, or, in space, is the ground station and the spacecraft it commands. That creates a difficult problem for threat hunters because malicious activity in these environments may use the same systems, protocols, accounts, and commands as normal operations.
A valid command sent over the correct protocol from an authenticated account may look completely normal in network traffic. The problem may only become apparent when you understand where the command came from, whether that system was authorized to send it, and whether the command made sense at that particular point in the operation.
A network sensor can tell you what happened on the network. A threat hunter still needs the operational context to determine whether what happened belongs there.
Hunting in operational environments
A satellite ground station, a ship at sea, and a water treatment plant are very different environments, but they create several similar challenges for a threat hunter.
Many operational sites have limited connectivity, and some are intentionally disconnected. Sending large amounts of data back to a cloud platform or enterprise SOC may be difficult or impossible. The people at the site are also there to operate the system, not spend their shift supporting a hunt team.
The activity a hunter is looking for can also blend into normal operations. If an attacker has access to legitimate credentials or an authorized system, inspecting an individual packet may provide very little indication that something is wrong.
This is where operational context becomes important.
At a satellite ground station, the mission already knows when contacts with the spacecraft are scheduled and which systems are authorized to issue commands. A telecommand observed outside a scheduled contact window deserves investigation, as does one originating from a system that should never be commanding the spacecraft.
The same idea applies aboard a ship. Control of systems such as propulsion or ballast may move between stations during different phases of a voyage. A command from a station that does not currently hold control is useful information to a hunter, even when the command itself is valid.
An industrial facility has similar information in its operating limits, maintenance schedules, engineering documentation, and asset inventory. A change that occurs outside an approved maintenance window or pushes equipment beyond an expected operating range provides another place for the hunter to start looking.
This information already exists in most operational environments. The challenge is bringing it together with the network and host data available during the hunt.
Asset inventory is part of that picture. In August 2025, CISA, NSA, FBI, and international partners published joint guidance recommending that OT operators maintain authoritative asset inventories that include information such as protocols, ports, and asset criticality. For a threat hunter, that information can provide valuable context when deciding whether observed activity belongs in the environment.
Threat hunting alongside the SOC
A SOC and a threat hunt serve different purposes.
Traditional security monitoring is generally built around continuous detection. Rules, signatures, EDR telemetry, and other security products generate alerts that analysts investigate. That model works well when the necessary sensors are deployed, the relevant telemetry reaches the security platform, and the activity matches something the organization knows how to detect.
Threat hunting approaches the problem differently. The hunter develops a hypothesis about how an adversary might operate in the environment, identifies the data needed to test that hypothesis, and then determines whether that data can actually be collected.
MITRE formalized this approach for U.S. Cyber Command in its TTP-Based Hunting methodology. Splunk's PEAK framework takes a similar approach to developing and executing hunts.
Collection becomes especially important in OT environments. Before looking for a particular behavior, the hunter needs to know whether the available sensors can see it in the first place. That may mean understanding network topology, identifying where traffic crosses particular switches or segments, determining what logs are available from hosts, and finding gaps in existing visibility.
A successful hunt can also improve normal security operations. Once hunters identify useful behaviors and validate the data needed to detect them, those detections can be incorporated into the organization's existing monitoring and SOC processes.
OUTPOST: a deployable tool for OT threat hunters
We developed OUTPOST to give threat hunters a portable set of capabilities they can take into operational environments where their normal enterprise tooling may not be available.
The kit can be deployed at a remote or disconnected site and perform its analysis locally without requiring an internet or cloud connection. On the operational network, it can passively collect a copy of network traffic. With operator approval, host collection can provide additional logs and system state needed for an investigation.
This gives the hunt team a common place to work with packet captures, host logs, protocol activity, and operational information collected at the site.
OUTPOST does not independently interact with mission or operational systems. Actions that could affect those systems remain under operator control. At the end of a hunt, the collected evidence can be packaged for removal from the site, with files hashed into a signed manifest so their integrity can be verified later. Findings can also be exported into common formats for use with the organization's existing security processes.
The platform is designed so the operational knowledge is separate from the underlying hunt capability. A satellite ground segment has different protocols, assets, and operating constraints than a ship or industrial facility, so the information defining expected activity is loaded for the environment being assessed.
That allows the hunter to combine observed activity with information such as authorized systems, approved commands, scheduled operating windows, expected protocols, and other site-specific data. Findings can then be mapped to the framework appropriate for the environment, including SPARTA for space systems and MITRE ATT&CK for ICS.
What this looks like in a space environment
Space is the environment where we have done the most development and testing of OUTPOST so far, primarily using our CT3 SAT-SIM space cyber range.
A hunt team working in a ground segment might begin by looking for several types of activity.
A telecommand observed when there is no scheduled spacecraft contact is immediately worth investigating. The packet itself may be valid, but the timing conflicts with the mission's contact schedule. SPARTA addresses related activity through malicious commanding using a valid ground station (IA-0007.02) and command packet replay (EX-0001.01).
The hunter can also compare the source of each telecommand against the systems authorized to command the spacecraft. A valid command originating from another system on the network becomes a useful lead.
Command identifiers provide another source of context. If the mission operates with a defined command set, an identifier outside that set should be investigated regardless of whether the underlying packet is correctly formatted.
Space Link Extension traffic provides similar opportunities. A session originating from an unexpected peer, or a known peer requesting a service for which it was never provisioned, can indicate activity that warrants additional investigation. SPARTA addresses this type of behavior through the rogue ground station pattern (IA-0008.01).
Telemetry can help identify visibility problems as well. Gaps in sequence counts may indicate packet loss, but they can also tell the hunter that traffic is taking a path the sensor cannot currently observe. That makes telemetry useful not only for detecting suspicious behavior but also for validating sensor placement.
Finally, events become more useful when they can be correlated. An onboard alert may be ambiguous by itself, as may an unusual event on the ground network. If the two occur at the same time, the hunter has a much stronger lead to investigate.
The important part is that these hunts depend on more than packet inspection. Contact schedules, authorized hosts, approved command sets, system configuration, and other operational information give the network activity meaning.
Testing the detections
We have been testing OUTPOST against actual spacecraft software rather than relying solely on simulated packet data.
NASA's core Flight System (cFS) is open source, so we deployed cFS 7.0.1 in our test environment, generated spacecraft traffic, and compared OUTPOST's decoder against an independent reference decoder.
Across the test, both decoders agreed on all 115 packets by packet type, identifier, and sequence. The traffic included 20 telemetry identifiers with contiguous sequence counts and no false gaps. Of the 115 packets, 112 were telemetry and three were commands. The command detections identified all three commands without generating detections on the 112 telemetry packets.
More importantly, the test exposed problems in our own implementation.
Our original logic suppressed repeat alerts using the sender, target, and command identifier. During testing we found that two commands could share the same identifier while using different function codes, causing them to collapse into a single alert. We changed the key to include the function code.
We also discovered that we had carried a telemetry port forward from an older configuration even though the current cFS configuration sends that traffic elsewhere.
Those findings are exactly why we test against real implementations. Each time the kit is placed into a representative environment, we learn something about the assumptions we made when building it.
We saw the same thing when running OUTPOST against live CT3 SAT-SIM traffic while the range team conducted attacks. Sensor placement turned out to be critical. A hunter cannot detect a command from a collection point that never sees that command, regardless of how good the detection logic is.
As a result, understanding the network and collection points is now part of how we approach the hunt before developing or applying detections.
Using AI to support the hunt
A hunt can generate a large amount of information across network captures, host logs, telemetry, alerts, and other artifacts. Correlating those sources manually takes time, particularly for a small team working through an environment during a limited hunt window.
OUTPOST uses a local AI model to help the analyst work through that information.
The model can assist with the first pass through the collected evidence, summarize activity, correlate events across different data sources, and help the hunter identify records that deserve closer examination. For example, an analyst can ask for a summary of observed APIDs, SLE peers, or telecommands occurring outside scheduled contact windows and then work from the underlying records.
We designed this capability around evidence. Claims produced by the model are tied back to the records supporting them, and unsupported statements are identified rather than treated as findings.
The AI is there to reduce the amount of time the hunter spends sorting and correlating data. The analyst still evaluates the evidence, determines what is significant, and decides where the investigation goes next.
Giving the hunter visibility where it matters
Threat hunting in operational environments requires understanding more than what crossed the network. The hunter needs to understand the systems involved, what they are allowed to do, and what the operation was supposed to be doing at the time.
That becomes harder at remote and disconnected sites where enterprise security tools may have limited visibility or may not be available at all.
OUTPOST is intended to give threat hunters a portable way to bring collection and analysis capabilities into those environments, combine technical evidence with operational context, and take the results back into the organization's broader security program.
We will continue testing it against CT3 SAT-SIM and other representative operational environments as we develop the platform.
If you are interested in what this type of hunt could look like against your environment, let's talk.
