When investigators establish that a system has been breached, they do it by finding evidence, and the individual pieces of that evidence are called indicators of compromise. Each one is a forensic breadcrumb, an observable artifact that, if you see it in your environment, suggests an attacker has been there. In IT these breadcrumbs are famously file-based, a malicious file's hash or a domain a piece of malware called home to. In OT the most valuable indicators are often behavioral instead, because the clearest sign of an industrial intrusion is not a file on a disk but an action that should never have happened, like a program being loaded into a controller when no engineer was working.
Indicator of Compromise (IOC) in one line: An indicator of compromise is an observable forensic artifact that suggests a system has been breached, such as the hash of a known malicious file, an IP address or domain used for command and control, or a suspicious registry change. In OT, alongside these file-based indicators, defenders rely heavily on behavioral indicators - actions that reveal an intrusion by what happened rather than what was left behind, like an unexpected PLC program upload or a controller reaching out to the internet. OT hunting leans on these behavioral signs because industrial devices rarely yield the file artifacts IT investigations depend on.
The traditional indicators of compromise are atomic, checkable facts about files and network endpoints. A file hash uniquely identifies a specific piece of malware, so finding a file with a known-bad hash anywhere in the environment is direct evidence that a particular malicious program is present. A command-and-control domain or IP address identifies where malware phones home, so seeing traffic to that destination suggests an infected host is talking to its operator. Other classic indicators include specific file names an implant drops, registry keys it creates for persistence, and mutex names it uses to avoid running twice.
These indicators are prized because they are precise and shareable. When one organization analyzes an attack, it can publish the hashes, domains, and other artifacts it found, and every other organization can immediately search their own environment for those exact strings. This is the basis of threat intelligence feeds, which distribute lists of known-bad indicators so defenders can detect the tools and infrastructure of attacks seen elsewhere before those same attacks reach them. A hash or a domain is unambiguous: either it is present or it is not.
The limitation of file-based indicators is that they are also brittle and easy for an attacker to change. A single recompilation produces a completely new hash, a new server gives a new command-and-control address, and a slightly altered implant drops a different file name. This means file-based indicators are excellent for catching the reuse of known tooling but poor at catching a careful adversary who changes their artifacts for each target. They tell you when you have been hit by something already catalogued, which is valuable, but they are only the most fragile layer of the evidence an intrusion leaves.
Behavioral indicators describe an intrusion by what an attacker does rather than by what they leave lying around. Instead of a file hash, a behavioral indicator might be a controller being reprogrammed outside a maintenance window, an engineering tool connecting from a device that has never run it before, a burst of scanning across a control subnet, or a PLC establishing an outbound connection to an internet address it has no reason to reach. These are indicators because such actions are strong signs of malicious activity even when no known-bad file is anywhere in sight.
OT environments lean on these behavioral signs out of necessity as much as preference. Embedded controllers, PLCs, and RTUs are not general-purpose computers you can easily scan for files and hashes; many run closed firmware with no way to inspect a filesystem, and dropping an antivirus agent onto a safety controller is neither possible nor wise. The file-based evidence that IT investigations depend on frequently simply does not exist on these devices, so the observable evidence that remains is what they do on the network and to the process. In OT, behavior is often the only forensic surface available.
Behavioral indicators are also harder for an attacker to avoid, which makes them more durable. An adversary can trivially recompile malware to change its hash, but if their objective is to reprogram a controller, they cannot avoid performing a program upload, because that upload is the goal. The behavior tied to the attacker's actual intent - manipulating the process, moving between control devices, disabling a safety function - is intrinsic to the attack in a way an artifact never is. This is why mature OT detection is written around suspicious actions and sequences rather than around lists of bad strings: the behavior is the part the attacker cannot easily disguise.
Detecting behavioral indicators requires visibility into what devices and processes are actually doing, which is exactly what operational monitoring provides. To know that a program upload happened outside a maintenance window, you have to be recording program-change events and correlating them with the maintenance schedule. To know that a value moved in a way the process cannot explain, you have to be historizing that value. The observable behaviors that constitute OT indicators live in the operational telemetry, so the ability to hunt for them depends on capturing that telemetry in the first place.
This is where the operational layer earns its place in the security picture. A cloud SCADA platform such as Merobix continuously records process values, device activity, and communications across a fleet of sites, which gives defenders both the baseline of normal behavior and the running record needed to spot a behavioral indicator when it appears. An unexpected controller reprogram, a device suddenly talking to an address it never has, or a setpoint changed at an impossible hour all show up against that continuous record, and having a single historized view across remote sites means these signs are visible even for assets no one is physically standing near.
The practical model that follows is to combine both kinds of indicator. File-based indicators from threat intelligence feeds catch the reuse of known tooling and infrastructure at the edges of the OT environment, on the IT-facing hosts where files and hashes still exist, while behavioral indicators drawn from operational monitoring catch the actions a careful attacker cannot hide once they reach the control layer. Watching for a suspicious hash at the perimeter and an impossible process action at the core are complementary, and an OT program that ignores the behavioral half is blind to precisely the evidence its unusual environment is best positioned to see.
A file-based indicator is a static artifact an attacker leaves behind, such as a malware file's hash, a command-and-control domain, or a registry key, and it is checked by looking for that exact string. A behavioral indicator describes an action that reveals an intrusion, such as a controller being reprogrammed outside a maintenance window or a device reaching an internet address it should never contact. File-based indicators are precise but easy to change, while behavioral indicators are harder for an attacker to avoid because they are tied to what the attacker actually does.
Because industrial devices rarely offer the file artifacts that IT investigations depend on. Embedded controllers, PLCs, and RTUs often run closed firmware with no accessible filesystem and cannot host security agents, so hashes and dropped file names frequently do not exist to find. What remains observable is behavior on the network and against the process, and that behavior is also harder for an attacker to disguise, since actions like reprogramming a controller are the attacker's actual goal and cannot simply be recompiled away.
Common examples include a PLC program being uploaded or changed outside any maintenance window, an engineering tool connecting from a device that has never run it before, a controller establishing an outbound connection to an internet address, a burst of scanning across a control subnet, or a process value changing at a time no operator was present. Each is a strong sign of malicious activity based on what happened rather than on any known-bad file, which is why OT detection is often written around these actions.
Merobix reads your field devices into a cloud SCADA - the real thing behind these terms, live in days from any browser.