Malware in the engine room: Detecting deviations from normal operation

Critical infrastructure such as water, heating, electricity, and public transport faces a real threat. — Risk 2025, Norwegian National Security Authority (Norwegian only).

And we as individuals must also be prepared to go without essential resources. — Plan your personal preparedness.

How can those of us working with operational technology know if the environment is experiencing or has been exposed to abnormal digital activity?

• We need to map out what normal operation looks like in the network.

• We must search for and be alerted to deviations from the baseline.

If we don’t look for something, we won’t find it!

OT Environment – Overview

To make this concrete and connect it to reality, I have set up a simple simulated operation. The operation consists of three different tanks where water supply and drainage are controlled by a controller (PLC).

Here is also a simplified diagram of the environment. For reference, the protocol between the PLC and HMI is “Modbus TCP.” Modbus is one of the oldest and most widely used protocols for serial communication.

What can go wrong?

That is a fundamental question to ask.

From a digital perspective, there may be network disruptions between the HMI and Switch, or Switch and PLC. Data corruption can also occur in the communication channel, but here a CRC mechanism typically verifies incoming data.

What if function codes and values are sent to the PLC that are beyond programmed behavior?

You might see where I’m going—there is a risk that the environment could be exposed to malicious activity, digitally. There are several historical examples and reports of threat actors attacking infrastructure and damaging equipment, in addition to affecting people’s lives in one way or another.

Baseline

What does the baseline look like?

It’s unique for each environment, so here we need to collect traffic logs and review the statistics.

For reference: In my test environment, I have a server with a “Polling Period” of 100 milliseconds.

A detailed graph shows packets per second.

• Here we see that the maximum number of packets does not exceed 170 per second.

• No function code is sent for “Write Single Register.”

• Each unique “Write” instruction does not exceed 25 packets per second.

Here we can set up alarms to notify us if the environment deviates from this state.

Either if the number of network packets exceeds 170 per second, or if the number of packets with “Write Multiple ...” exceeds 25 per second. I have visualized this in the following image with two colored lines.

Simulated attack

Now it’s time to simulate an attack to see if we detect deviations.

In this scenario, I have downloaded a version of FrostyGoop malware. This malware has been used to turn off heating in over 600 homes in Ukraine. [Detailed report here: Dragos-FrostyGoop-ICS-Malware-Intel-Brief-0724_r2.pdf](#)

After downloading the malware, I create the necessary configuration file, “task_test.json,” which contains the IP address for the PLC and the Modbus function to be executed. Finally, I execute the file with the configuration, targeting the environment.

The image shows the malware running in the command window, and to the right, we can see a simple control station. If visible in the image, the display at the control station shows a value of “9999.” It is also visible in the terminal window, where the Register address being modified can be seen with the specified value.

To simulate damage with repeated function calls, I also used a modified FrostyGoop “malware” coded in Golang.

Detection

First, let’s look at the network traffic during the attack. Here we see that something abnormal definitely occurred.

For one, “Write Single Register” is suddenly being sent, something that did not occur in the baseline. The green dots appeared when I executed the FrostyGoop malware downloaded from MalwareBazar.

Other elements are also clearly visible: There is a spike in the number of packets sent, and an increase in the “Write Multiple Coils” function. These came from a tailored, custom-compiled version of FrostyGoop.

Additionally, during the attack (not visible in the picture), there were some “TCP Errors.” This is also worth detecting and alerting on if it is unusual in the environment.

But we can’t have someone watching graphs like this all the time to see if the state remains normal. We need a system that can monitor the traffic over time, not just individual network packets. Zeek is a free tool with this capability.

With a customized Zeek configuration, we can generate alerts on such activity:

The image shows an example where Zeek analyzes network traffic with a custom configuration file adapted to the environment. This results in relevant alerts visible at the bottom of the image.

Summary

I have focused on a small area within a complex and technically advanced field. Here, there are multiple risks that must be prioritized.

We must be prepared, both personally and organizationally, for the fact that essential services may be exposed to attack. Therefore, we should have a plan for how to handle situations where services may be down.

I’ll end by quoting some key points from “Risk 2025 – Norwegian National Security Authority”:

It is important to monitor systems for critical infrastructure to detect unusual or suspicious activity.

• Ensure monitoring of digital systems for critical infrastructure and reduce digital vulnerabilities wherever possible.

• Review contingency routines and practice handling the loss of critical resources.

• Establish alert routines with a low threshold for notifying about suspicious or unwanted incidents, both internally and to the police and other authorities.

In the next article, "When the normal is disrupted: How digital threats in OT networks are exposed," you will learn the technical details of how the attack was carried out and how you can create your own customized alerts.