How Does Triton Attack Triconex Industrial Safety Systems? – Cisco Blogs

Triton is malware developed to affect industrial systems, particularly the Triconex safety system from Schneider. This is deployed at over 15,000 sites across the world, but the malware allegedly only targeted a critical energy industrial site in the Middle East in 2017.

The attack, also known by the names of Trisis and Hatman, is broken down into different phases:

1. Intrusion into the IT network, then move to the OT network using standard techniques (IT malware, Mimikatz, RDP sessions, etc.). This move enabled an engineering station within the safety system to be compromised (SIS: Safety Instrument Systems). An example of industrial network architecture including safety systems is shown in figure 3.
2. The purpose of this compromise was to launch the dropper (trilog.exe) with the aim of delivering backdoor files to the PLC.
3. The backdoor consists of two files, one makes use of a 0-day exploit to insert the contents of the second file into the memory, enabling total control of the target.
4. The final phase corresponds to taking control of the device with concrete effects on the safety systems of the physical installation. This phase did not take place and the associated sources were not identified. A handling error in the target forced it into fail-mode, which stopped production. The attack was identified following this shut-down.

In order to carry out this attack, the attackers reverse-engineered the proprietary TriStation Protocol used to program the system. The first analysis published in December 2017 identified that Triconex MP3008 models with software versions between 10.0 and 10.4, inclusive, were vulnerable.

Until very recently, this analysis, and that published subsequently, did not succeed in formally identifying the attacker or their intent. The initial analysis identified an attacker with resources comparable to those of a State. FireEye even attributed the attack to a research institute managed by the Russian government, the CNIIHM. This attribution was based on various factors: use of a specific IP address, malware testing activities connected to a natural person, and timestamps on the files that were compatible with the Russian time zone.

The attackers obtained remote access to a workstation used to control and program the SIS machines, they then used a customized implementation of the TriStation protocol to download the code to the Triconex controller.

The dropper used was script_test.py, compiled in trilog.exe via the program Py2Exe. This program uses the reverse-engineered version of the TriStation protocol. The use of default settings by Py2Exe enabled all of the files related to this implementation to be found easily. Using this implementation, the script then connects to the target to download the injector and the implant, which are then executed by the machine. The dropper then regularly scans the target to establish whether the injection is complete.

However, at this stage, there are two significant weaknesses for the attackers:

• The Triconex machine only accepts program downloads when in “PROGRAM” mode, whereas other modes (such as “RUN”) prevent it. These modes are changed manually using a physical system.
• The injected code is not durable, for example, it is deleted when downloading a new program (“download all”).

It is also of interest to note that, in the case of Triton, the target’s IP address was included within the source code. The attacker may not have made use of the network discovery options available in the malware. This also shows that the attacker made use of an in-depth network reconnaissance phase.

Backdoor

First, the injector checks whether the controller is vulnerable to the exploit used. If the tests are conclusive, the exploit is used to raise privileges. These new permissions allow the content of the implant to be written in the system memory area. Because the safety systems are critical components, they are almost never restarted. Therefore, the risk of the implant being deleted is low.

This memory area is not wiped when downloading new programs. Once this payload is in the memory, the original program is patched to include a conditional break to the address of the payload. A RAM integrity verification feature is also patched to avoid detection.

The implant allows specific commands to be listened to without restricting the operating mode (modes changed using a physical mechanism). More precisely, it analyzes the messages that are usually used for debugging processes (GetMPStatus messages) then executes the expected command (read, write, or execute). This communication allows, for example, the memory of the machine to be edited even if it is in a mode that prevents the standard download of a program (“RUN” mode).

0-day exploit

The injector used a poorly secured system call to obtain a 2 byte write ability, which it then used to increase its privileges. In particular, this system call read from an unverified user memory area, the pointers used could be modified during execution with causing an exception, the values sent to settings could be designed so that the value written in the memory is the same as that sent to settings. Finally, no verification prevented the value from being written in a protected memory area.

Redundancy functions

Among the files discovered during the first analysis, the file CRC.pyc implemented the cyclical redundancy control functions. These functions use redundant data to verify that all data was sent without error. The use of such functions is normal and is found in many protocols, which does not necessarily mean that all protocols use the same function.

Moreover, various functions related to different protocols (such as Modbus or XMODEM) were identified when analyzing the file, although they were not useful for this attack. This means that the attackers could target other types of machines or industrial systems.

Detection of the attack

At this stage, the attackers were in a position to control the target remotely, regardless of its mode of operation. However, before any potential physical consequences were observed, the system went into a safe mode (failed safe state). This behavior resulted in a shutdown of the production line and the discovery of the attack. However, the published analysis has not determined the ultimate aim of the attackers.

The triggering of this safe mode was probably linked to a handling error in the machine, for example, writing in the incorrect memory area. Various analysis showed that the attackers had difficulty implementing and handling the TriStation protocol and the associated features.

Detection measures

The tools used in the attack were posted on the Internet which significantly increases the possibility of other installations with the same equipment becoming targets. Therefore, implementing the ability to detect and protect against the Triton malware is a priority for any industrial network manager.

To detect the behavior of the Triton malware, Cisco Talos published Snort rules that can be activated in a next generation firewall, such as Cisco Firepower firewalls and, in particular the ISA 3000 Industrial Security Appliance.

However, these rules might fail detecting another Triconex attack as attackers would probably not use the exact same components. Therefore, it is necessary to analyze the UDP communications on port 1502. Various industrial security products such as Cisco Cyber Vision can analyze the communications using the Triconex protocol to detect anomalies and to identify potential attacks.

more technical reports on IoT/OT Security

Subscribe to the Cisco IoT Security Newsletter.

Share: