Busy times for OT analysts.
Last month the number of known OT (operational technology) malware increased from five to seven. First malware discovered is Industroyer2 which was caught in the Ukraine. As nowadays popular, security companies name the malware they discover. That is why for the second malware two names were assigned, Incontroller or Pipedream. This malware was discovered before it was deployed.
Industroyer2 [1] is an evolution of Industroyer1, first seen in 2014. Both variants are targeting the electrical energy sector, specifically in Ukraine. As the malware is using commands out of the industrial protocol IEC-60870-5-104, traffic looks like legit communication as during normal operation.
Incontroller [2] is a new set of malware components, targeting the LNG sector in the US. Similar to Industroyer2, pipedream is using popular industrial protocols like OPC-UA and ModbusTCP. Further more it uses build in functionality from engineering tools made to interact with OT devices like PLCs (process logic controller).
Both malware show clearly that the criminals behind have evolved and do understand OT protocols and are able to use build in functionality of legit software engineering tools like CODESYS.
What has not changed over the last years, is that SCADA systems still control like “fire and forget”. A command is sent from the control system server to the client in the field. The client translates the event into a physical action, like open or close a circuit breaker. The command source is not verified by the client. Translated back to the network traffic, it means that one packet containing a command is enough to disrupt the complete industrial process or power distribution.
Industroyer2 uses IEC-104, the short version for IEC 60870-5-104. IEC-104 is widely used in European energy sector and as well in utilities sector like water or waste water treatment.
A characteristic of many industrial protocol is, that even though the protocol is standardised, its implementation can vary between manufacturers or even system integrators. Meaning IEC-104 implemented by Hitachy Energy differs from how it is implemented by Siemens. Operators are familiar with it, but for network security monitoring it can be a challenge.
Further difficulty for monitoring is, that one packet transporting the IEC-104 payload can have multiple IEC-104 data messages, called APDU’s. Therefore traditional signature based detection on the TCP payload does not work. The payload needs to be parsed in order to understand what type of command each APDU contains:
Since the discovery of Industroyer2 in early of April 2022 until now, several reports analysing the malware were published. They contain information how the malware is working, captured network data and most of them contain recommendation how to deal with such type of malware. Having a closer look at the recommendations, or nowadays called actionable items, they are high level items. Example:
- “Use anomaly detection tools to detect any irregular activity occurring in OT environments“
- “Employing network segmentation to separate sensitive applications (e.g. PCN) from other network parts via firewalls“
- “Monitor East-West ICS networks with ICS protocol aware technologies“
Not much actionable in my point of view or a whole set of commercial products need to be in place. Products which for most SMEs are not suitable to operate. I am therefore looking for ways how to detect the malware with minimal effort.
Let’s have a look at the environment. SCADA networks are highly deterministic. Means who is talking to whom and how, i.e. command and control patterns, is repeatable. For IEC-104 it means the same type and sequence of IEC-104 commands can be found in normal operation in time periods over a day or over weekdays and weekend days.
Example 1, time period 2 working days and one night, 36 hours:
|
TypeID |
Type | Description | Number of Occurrences |
| 13 |
M_ME_NC_1 |
Measured value, short floating point number |
1’184’834 |
| 30 |
M_SP_TB_1 |
Single-point information witd time tag CP56Time2a |
2 |
| 103 |
C_CS_NA_1 |
Clock synchronisation command |
1 |
The only command sent was for time synchronisation of the client.
Comparing operations data with the available malware data, the different behaviour of the malware becomes visible:
The malware is sending command after command to the client device (ASDU=3), iterating through the IOAs. Kind of similar like checking different ports on a host and trying to login.
|
TypeID |
Type | Description |
| 100 |
C_IC_NA_1 |
Interrogation command
|
| 45 |
C_SC_NA_1 |
Single command |
| 46 |
C_DC_NA_1 |
Double command |
From defender point of view, we obviously can not block port 2404, neither the commands used by the malware, as one or all commands are used for normal operation by the control system itself.
But looking at the TypeID transition, the malware differentiates from legitimate traffic:
|
Transitions |
Normal Operations Traffic |
Malware |
|
M_ to M_ |
> 1000 |
0
|
|
M_ to C_ or C_ to M_ |
> 0 && < 10 |
0 |
|
C_ to C_ |
0 |
> 10 |
In ntopng, three detection mechanism are build in:
- IEC Unexpected TypeID. As used TypeIDs are known by the operator, this check monitors for unknown or not allowed TypeIDs and alerts them.
- IEC Invalid Transition. In this check TypeID transitions are recorded over a predefined time period, the IEC60870 Learning Period, found under Settings / Preferences / Behaviour Analysis. An alert is generated, if a unknown TypeID transition is detected.
- IEC Invalid Command Transition is as well checking for transitions, but specifically transitions of commands. If the amount of command to command transition exceeds a threshold, an alert is generated.
All three Check can be found in the Flow Checks.
For “IEC Invalid Transition” ntopng needs a learning period in order to track transitions. Default is set to 6 hours, but most likely a longer learning period is necessary, e.g. 2 days.
Sources:
- https://www.welivesecurity.com/2022/04/12/industroyer2-industroyer-reloaded/
- https://www.cisa.gov/uscert/ncas/alerts/aa22-103a
All ntopng versions include IEC support, so you can enjoy monitoring your network using ntop tools.
Enjoy !
ntop acknowledges Martin Scheu from switch.ch for having assisted throughout this IEC work and blog post.