Mandiant recently conducted a security response to an attack on critical infrastructure of a company in the Middle East. The attackers deployed specialized malware to control the target industrial safety system. Given that industrial safety systems have emergency shutdown capabilities for industrial control systems, we are confident that this malware was developed by the attackers to cause hardware damage or sudden shutdowns of the control systems. We have named this malware TRITON. The attackers used the TRITON attack framework to communicate with Schneider Electric’s Triconex Safety Instrumented System (SIS) controllers. Although we have not yet traced the actual attackers, we are certain that the masterminds behind this attack are state-sponsored hackers.
Characteristics of TRITON
TRITON is one of the few publicly detectable industrial control system malware series, following Stuxnet in 2010 targeting Iran and Industroyer in 2016 targeting Ukraine. Similar to these attacks, TRITON can compromise the security mechanisms of industrial control systems and execute malicious functions, leading to severe physical damage as a result of the attack.
Overview of the Attack
The attackers gained remote access control over the Safety Instrumented System (SIS) workstation and recompiled the SIS controllers, subsequently deploying the TRITON attack framework within the SIS system.
During this attack, some SIS controllers entered a failed safe state, causing the industrial control processes to shut down automatically, which alerted the management and initiated an investigation. The investigation revealed that when application code failed verification between redundant processing units (which could trigger production diagnostic error messages), it caused the SIS controllers to enter a safe shutdown state.
We believe the attackers intended to covertly execute shutdown operations to cause physical damage to the industrial control systems, based on the following reasons:
Modifying the Safety Instrumented System (SIS) can lead to functional anomalies, increasing the likelihood of physical damage.
TRITON modifies the application memory within the SIS controllers, leading to verification failures.
Verification failure states occur while TRITON is operational.
Isolated or external conditions present in the industrial control network cannot cause such errors.
Attack Attribution
As for this attack, FireEye has not yet accurately traced the actual attackers, but it is certain that this is a state-sponsored hacking attack. The attack targets critical infrastructure, is persistent, and lacks a clear economic motive. Considering the substantial technical resources required to create the TRITON attack framework, it is evident that this is the behavior of state-sponsored hackers. This can be judged based on the following aspects:
The attackers targeted the SIS system, indicating their intent to cause severe physical damage, which is inconsistent with the behavior of cybercriminal groups.
The attackers deployed TRITON shortly after gaining access to the SIS system, indicating they had pre-built and tested the tools needed to access the hardware and software. TRITON was also designed to communicate using the proprietary TriStation protocol, which has not been publicly documented, suggesting that the adversary independently reverse-engineered this protocol.
The attackers deployed TRITON shortly after gaining control of the SIS system, clearly indicating they had pre-created and tested the operational environment for this malicious tool; additionally, the TRITON framework was set to communicate using the specially undisclosed TriStation protocol, indicating that the adversary could completely reverse-engineer this communication protocol independently.
This type of destructive, disruptive, or incapacitating attack targeting critical infrastructure aligns with the extensive cyberattacks and reconnaissance activities conducted globally by Russia, Iran, North Korea, the United States, and Israel. Such attacks do not immediately result in visible destruction; instead, they create a lingering presence for subsequent in-depth attacks.
Background on Process Control and Safety Instrumented Systems
Modern industrial process control and automation systems rely on various advanced control systems and safety functions, commonly referred to as Industrial Control Systems (ICS) or Operational Technology (OT).
Distributed Control Systems (DCS) provide operators with the ability to remotely monitor and control industrial processes. It is a computer control system composed of computers, software applications, and controllers. Engineering workstations are independent computers used to configure, maintain, and diagnose control system applications and other control system devices.
Safety Instrumented Systems (SIS) are independent control systems that monitor the state of controlled processes. If the process exceeds defined parameters indicating a hazardous state, the SIS attempts to restore the process to a safe state or automatically execute a safe shutdown of the process. If both SIS and DCS controls fail, only the safety design of the industrial facility, such as mechanical protection for equipment (e.g., explosion-proof panels), physical alarms, emergency procedures, and other hazard mitigation mechanisms, can provide safety.
Asset device managers employ various methods to connect the plant’s DCS with the SIS system, with traditional methods relying on the principle of isolation of communication infrastructure and control strategies. Over the past decade, there has been a trend towards integrated DCS and SIS designs based on low cost, ease of use, and information exchange purposes. The TRITON attack reflects the security risks of bidirectional communication in integrated DCS and SIS designs.
Threat Modeling and Attack Scenarios for Safety Instrumented Systems (SIS)
The lifecycle of destructive attacks on industrial control systems (ICS) is similar to that of other types of cyberattacks, but there are several key differences. First, the attackers’ goal is to disrupt business processes rather than steal data; second, the attackers must conduct OT reconnaissance and possess sufficient engineering knowledge to understand the target system’s industrial processes to successfully control and exploit them.
The above diagram illustrates the relationship between cybersecurity and safety controls in a process control environment. Even if cybersecurity measures fail, safety controls can prevent physical damage. To maximize physical damage, network attackers must also bypass some safety control measures.
The following Safety Instrumented System (SIS) threat model reveals various attack paths available to attackers:
Attack Path 1: Use the SIS system to shut down processes. Attackers recompile the SIS logic controllers to cause them to trip or shut down a control process that is in a safe state, in other words, they can also trigger false alarms.
Objective: Cause economic losses after shutdown or complicate the startup procedures after a halt.
Attack Path 2: Recompile the SIS to support unsafe states. Attackers recompile the SIS logic controllers to allow the existence of unsafe states.
Objective: Increased hazardous conditions due to the loss of SIS functionality can lead to severe physical consequences, such as impacts on equipment, products, the environment, and personnel safety.
Attack Path 3: Recompile the SIS controllers to support unsafe hazardous states when using DCS. Attackers can control DCS processes to create hazardous states and prevent the SIS system from functioning normally.
Objective: Cause damage to personal safety, the factory environment, or equipment, with the extent of impact depending on the physical limitations of the process and equipment design.
Analysis of Attack Intent
We believe the attackers’ long-term goal is to cause physical damage. Based on the fact that once the attackers have the ability to manipulate processes or shut down equipment, they will first establish a presence on the DCS system to opportunistically infiltrate the SIS system. Infiltration of both DCS and SIS systems will lead to maximum destruction of physical and mechanical safeguards.
Once they penetrate the SIS network, the attackers will immediately deploy the pre-built TRITON attack framework, using the TriStation protocol to communicate with the SIS controllers. The attackers can send stop commands to initiate process shutdowns or upload malicious code to the SIS controllers to cause protection failures. Unlike this, the attackers will repeatedly attempt to establish functional control logic within the SIS controllers over a period of time, even if the attack scripts encounter errors due to condition checks, the attackers will continue to try, indicating that their ultimate intent is to cause unexpected shutdowns of control processes.
It is worth noting that we have repeatedly discovered some long-term intrusions into industrial control systems (ICS) that did not result in system damage or disruption, such as the Russian Sandworm team, which has long infiltrated Western ICS but has not demonstrated clear capabilities for disruptive attacks.
Functions of TRITON Malware
The TRITON attack framework possesses various malicious functions, including program read/write, various functional read/write, and querying the status of SIS controllers, but the trilog.exe sample only possesses certain functions, excluding the full reconnaissance capabilities of TRITON.
TRITON malware has the ability to communicate with Triconex SIS controllers (e.g., sending specific commands to achieve shutdown or content reading) and can be remotely recompiled with attacker-defined payloads. The TRITON sample analyzed by Mandiant contained a program created by the attackers to run the Triconex controller execution table, which included a legitimate program that monitored the operational status of the controller. If the controller experienced a failure, TRITON would attempt to return a fabricated normal operational status; if the controller failed and did not recover to a safe state within a specified time, the sample would overwrite the malicious program in the SIS controller with invalid data to remain hidden.
Technical Analysis of TRITON Attacks
The TRITON attack framework is deployed on SIS engineering workstations running Windows operating systems, where the malware disguises itself as a legitimate application for viewing logs, the TriStation Triconex Trilog application, and is implanted through a Python script compiled with Py2EXE. This Python script relies on a zip file containing standard Python libraries and open-source libraries, as well as an attack framework developed by the attackers for interaction with Triconex controllers. Along with the executable malware, two binary files, inject.bin (malicious functional code) and imain.bin (malicious control logic), are generated as payloads for the attack controllers, and these filenames are hardcoded into the Py2EXE compiled Python script.
Trilog.exe selects the target Triconex device IP address as an attack option in the command line. It does not utilize the underlying TRITON library’s Triconex device discovery function but instead calls separate instances of trilog.exe for each target controller in the environment. Once invoked, trilog.exe checks the controller status and reads the configuration information exposed by the TriStation protocol. If the controller is operational, trilog.exe encodes the two payload files inject.bin and imain.bin and passes them to the communication library to attach them to the controller’s program memory and execution table.
Once the payload files are inserted into the Triconex controller memory, the script begins a countdown and performs periodic checks on the controller status. If a controller error is detected, the communication library’s method SafeAppendProgramMod attempts to reset the controller to its previous state using TriStation protocol commands. If a controller failure is detected, trilog.exe attempts to write a small “virtual” program into memory. We believe this is a form of anti-forensics technique used to hide the attack code within the Triconex controller.
Mandiant collaborated with the attacked enterprise and discovered a check condition in the malware that prevents payload files from persisting in the controller memory. After modifying the attack script to remove this check condition, the payload files would persist in the controller memory without affecting the controller’s operation.
TRITON can execute legitimate TriStation applications’ TriStation protocol and configure SIS controllers through this protocol.
Additionally, the attackers created a high-level interface named TsHi, which allows the execution of attack scripts using the TRITON framework. The TsHi interface exposes the reconnaissance and attack capabilities of the malware, and these functionalities typically require receiving binary data from the user, with a code “signature” and verification step performed before the data is serialized to the network in the process.
Another module written by the attackers, TsBase, contains TsHi calling functions that can translate the attackers’ intended operations into corresponding TriStation protocol functional codes. For certain functions, it can also package data into the appropriate format.
The TsLow attack module implements the TriStation UDP communication protocol. The TsBase library primarily relies on the ts_exec method, which takes functional codes and expected response codes and serializes payload commands via UDP. It also checks the controller’s response to expected values and returns the corresponding data structure representing the object upon success or failure of the check.
TsLow also includes a connection test method for checking the connectivity of target controllers. If the call does not find the target, it runs a device discovery function detect_ip, which uses IP broadcast packets to probe the controller by executing a “ping” message in the TriStation protocol.
Protection Recommendations
To avoid TRITON-like attacks, asset device managers can consider the following protective measures:
Technically feasible methods should be employed to isolate the safety system network from the process control and information system networks. Engineering workstations that can program SIS controllers should not form dual-host networks with any DCS process control or information systems;
Fully utilize the hardware functions for controlling programming of safety controllers, which typically use physical keys for control exchange. On Triconex controllers, except during scheduled programming events, the key should not be in programming mode;
Implement change management measures for key position changes and regularly audit the current key status;
For any applications relying on SIS systems for data, use unidirectional gateways instead of bidirectional networks for connections;
Implement strict access control and application whitelisting mechanisms on any servers or workstation terminals accessing SIS systems via TCP/IP;
Monitor abnormal network traffic in ICS systems.
The following image shows the key switch for the Triconex system mainframe:
IoC Threat Indicators
Indicators
Detection
rule TRITON_ICS_FRAMEWORK
{
meta:
author = "nicholas.carr @itsreallynick"
md5 = "0face841f7b2953e7c29c064d6886523"
description = "TRITON framework recovered during Mandiant ICS incident response"
strings:
$python_compiled = ".pyc" nocase ascii wide
$python_module_01 = "__module__" nocase ascii wide
$python_module_02 = "<module>" nocase ascii wide
$python_script_01 = "import Ts" nocase ascii wide
$python_script_02 = "def ts_" nocase ascii wide
$py_cnames_01 = "TS_cnames.py" nocase ascii wide
$py_cnames_02 = "TRICON" nocase ascii wide
$py_cnames_03 = "TriStation " nocase ascii wide
$py_cnames_04 = " chassis " nocase ascii wide
$py_tslibs_01 = "GetCpStatus" nocase ascii wide
$py_tslibs_02 = "ts_" ascii wide
$py_tslibs_03 = " sequence" nocase ascii wide
$py_tslibs_04 = /import Ts(Hi|Low|Base)[^:alpha:]/ nocase ascii wide
$py_tslibs_05 = /module\s?version/ nocase ascii wide
$py_tslibs_06 = "bad " nocase ascii wide
$py_tslibs_07 = "prog_cnt" nocase ascii wide
$py_tsbase_01 = "TsBase.py" nocase ascii wide
$py_tsbase_02 = ".TsBase(" nocase ascii wide
$py_tshi_01 = "TsHi.py" nocase ascii wide
$py_tshi_02 = "keystate" nocase ascii wide
$py_tshi_03 = "GetProjectInfo" nocase ascii wide
$py_tshi_04 = "GetProgramTable" nocase ascii wide
$py_tshi_05 = "SafeAppendProgramMod" nocase ascii wide
$py_tshi_06 = ".TsHi(" ascii nocase wide
$py_tslow_01 = "TsLow.py" nocase ascii wide
$py_tslow_02 = "print_last_error" ascii nocase wide
$py_tslow_03 = ".TsLow(" ascii nocase wide
$py_tslow_04 = "tcm_" ascii wide
$py_tslow_05 = " TCM found" nocase ascii wide
$py_crc_01 = "crc.pyc" nocase ascii wide
$py_crc_02 = "CRC16_MODBUS" ascii wide
$py_crc_03 = "Kotov Alaxander" nocase ascii wide
$py_crc_04 = "CRC_CCITT_XMODEM" ascii wide
$py_crc_05 = "crc16ret" ascii wide
$py_crc_06 = "CRC16_CCITT_x1D0F" ascii wide
$py_crc_07 = /CRC16_CCITT[^_]/ ascii wide
$py_sh_01 = "sh.pyc" nocase ascii wide
$py_keyword_01 = " FAILURE" ascii wide
$py_keyword_02 = "symbol table" nocase ascii wide
$py_TRIDENT_01 = "inject.bin" ascii wide
$py_TRIDENT_02 = "imain.bin" ascii wide
condition:
2 of ($python_*) and 7 of ($py_*) and filesize < 3MB
} *Source: FireEye, compiled by Freebuf editor clouds, please indicate the source from FreeBuf.COM when reprinting
