TRITON Malware

Security researchers have uncovered another nasty piece of malware designed specifically to target industrial control systems (ICS) with a potential to cause health and life-threatening accidents.

Dubbed Triton, also known as Trisis, the ICS malware has been designed to target Triconex Safety Instrumented System (SIS) controllers made by Schneider Electric—an autonomous control system that independently monitors the performance of critical systems and takes immediate actions automatically, if a dangerous state is detected.

Researchers from the Mandiant division of security firm FireEye published a report on Thursday, suggesting state-sponsored attackers used the Triton malware to cause physical damage to an organization.

Neither the targeted organization name has been disclosed by the researchers nor have they linked the attack to any known nation-state hacking group.

According to separate research conducted by ICS cybersecurity firm Dragos, which calls this malware "TRISIS," the attack was launched against an industrial organization. The location of the plant or the nature of its operations was not disclosed, although Reuters reports that the security company Dragos said it was a plant in the Middle East, while another firm, CyberX, believed the target was in Saudi Arabia.

How it worked:

Triton leverages the proprietary TriStation protocol, which is an engineering and maintenance tool used by Triconex SIS products and is not publicly documented, suggesting that the attackers reverse engineered it when creating their malware.

The hackers deployed Triton on an SIS engineering workstation running Windows operating system by masquerading it as the legitimate Triconex Trilog application.

The current version of TRITON malware that researchers analyzed was built with many features, “including the ability to read and write programs, read and write individual functions and query the state of the SIS controller.”

Using TRITON, an attacker can typically reprogram the SIS logic to falsely shut down a process that is actuality in a safe state. Though such scenario would not cause any physical damage, organizations can face financial losses due to process downtime.

Besides this, attackers can also cause severe life-threatening damages by reprogramming the SIS logic to allow unsafe conditions to persist or by intentionally manipulating the processes to achieve unsafe state first.

Cybersecurity firm Symantec says the Triton program has been around since August, and it targets a specific type of safety instrumental system (SIS) and reprograms them. The malware could cause the SIS to shut down plant operations or, with a sophisticated enough attack, nullify the SIS and allow an unsafe condition to escalate, leading to a widespread industrial accident.

In this particular case, when Triton attempted to reprogram the SIS controllers, some instead entered a safe shutdown mode, which halted plant operations and alerted the operators about the rogue software. FireEye believes the hackers accidentally triggered the shutdown while probing the plant’s security systems.

The security company noted that the attacker could have easily shut down the plant, but instead continued with repeated attempts to gain control of the SIS. This suggests the attacker was intent on causing a specific outcome beyond a process shutdown.

Incident Summary

The attacker gained remote access to an SIS engineering workstation and deployed the TRITON attack framework to reprogram the SIS controllers. During the incident, some SIS controllers entered a failed safe state, which automatically shutdown the industrial process and prompted the asset owner to initiate an investigation. 

The investigation found that the SIS controllers initiated a safe shutdown when application code between redundant processing units failed a validation check -- resulting in an MP diagnostic failure message.

We assess with moderate confidence that the attacker inadvertently shutdown operations while developing the ability to cause physical damage for the following reasons:

·        Modifying the SIS could prevent it from functioning correctly, increasing the likelihood of a failure that would result in physical consequences.

·        TRITON was used to modify application memory on SIS controllers in the environment, which could have led to a failed validation check.

·        The failure occurred during the time period when TRITON was used.

·        It is not likely that existing or external conditions, in isolation, caused a fault during the time of the incident.

TRITON implements the TriStation protocol, which is the protocol used by the legitimate TriStation application, to configure controllers.

·        TsHi is the high-level interface created by the malware’s authors that allows the threat actor’s operators to implement attack scripts using the TRITON framework. It exposes functions for both reconnaissance and attack. The functions generally accept binary data from the user, and handle the code ‘signing’ and check sums prior to passing the data to lower level libraries for serialization on to the network.

·        TsBase, another attacker-written module, contains the functions called by TsHi, which translate the attacker’s intended action to the appropriate TriStation protocol function code. For certain functions, it also packs and pads the data in to the appropriate format.

·        TsLow is an additional attacker module that implements the TriStation UDP wire protocol. The TsBase library primarily depends on the ts_exec method. This method takes the function code and expected response code, and serializes the commands payload over UDP. It checks the response from the controller against the expected value and returns a result data structure indicating success or a Falseobject representing failure.

·        TsLow also exposes the connect method used to check connectivity to the target controller. If invoked with no targets, it runs the device discovery function detect_ip. This leverages a "ping" message over the TriStation protocol using IP broadcast to find controllers that are reachable via a router from where the script is invoked.

Summary of Malware Capabilities

The TRITON attack tool was built with a number of features, including the ability to read and write programs, read and write individual functions and query the state of the SIS controller. However, only some of these capabilities were leveraged in the trilog.exe sample (e.g. the attacker did not leverage all of TRITON’s extensive reconnaissance capabilities).

The TRITON malware contained the capability to communicate with Triconex SIS controllers (e.g. send specific commands such as halt or read its memory content) and remotely reprogram them with an attacker-defined payload. The TRITON sample Mandiant analyzed added an attacker-provided program to the execution table of the Triconex controller. This sample left legitimate programs in place, expecting the controller to continue operating without a fault or exception. If the controller failed, TRITON would attempt to return it to a running state. If the controller did not recover within a defined time window, this sample would overwrite the malicious program with invalid data to cover its tracks.

Detection (Python code)

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 nocase wide
$py_TRIDENT_02 = "imain.bin" ascii nocase wide

condition:
2 of ($python_*) and 7 of ($py_*) and filesize < 3MB
}