In December 2017 it was reported that a Middle Eastern oil and gas petrochemical facility had undergone a safety system shutdown as the result of a malware attack. The malware, named TRITON (also TRISIS or HatMan) exceeded other industrial cyberattacks because it directly interacted with and controlled a Safety Instrumented System (SIS). SIS are the last line of automated safety defense for industrial facilities, designed to prevent equipment failure and catastrophic incidents such as explosions or fire.
Only a handful of malware, such as the infamous Stuxnet and Industroyer/Crash Override malware, have the ability to impact the physical process of an industrial control system. The TRITON attack framework became an unprecedented milestone in the history of cyberwarfare, as it is the first publicly observed malware that specifically targets protection functions meant to safeguard human lives. Over time it became clear that the TRITON malware framework was much easier to create than originally thought. And, most worrying, most experts agree an attack like TRITON could easily happen again in the near future.
While the attack was discovered before its ultimate goal – disruption of the physical process – was achieved, the TRITON malware framework is now readily available on the internet. You may need to know where to look, but it is not impossible to find. It can be adapted – by people with relatively low programming skills – to create sophisticated attacks. The Nozomi Networks security research team has studied this milestone attack to understand how it was developed, the resources it took to create it and why it ultimately failed.
We presented our findings at Black Hat USA and in this article will offer a brief explanation of the steps our research team took to reverse engineer the attack. Our research found that the time, effort, financial resources and skill level needed to create the TRITON malware framework is not that high – certainly not at the level requiring nation state-sponsored resources. Any motivated hacker, equipped with reverse engineering skills and some understanding of industrial systems could create a TRITON-like malware framework.
Understanding TRITON Through Reverse Engineering
Previous research found that the TRITON attack began with penetration of the IT network using well-documented, easily-detected attack methods. The attackers moved to the OT (operational technology) network through systems that were accessible to both environments. Once in the OT network, the threat actors were able to infect the engineering workstation for the SIS system. The infection probably used a social engineering technique whereby the engineer received or downloaded a file with a legitimate file name, in this case “trilog.exe”. The name suggests that the dropper file is a clean executable dealing with something related with Triconex and its logging capabilities (TRIconex LOGging filename).
The main purpose of the dropper was to deliver the malicious payload into the target, in this case the SIS controller. Soon after the execution, the dropper connected to the targeted Triconex, injecting the real malware payload inside its memory. The malware payload was contained in two separate binary files called inject.bin and imain.bin. One of the actions taken by the dropper was to read, inject and execute these files into the memory of the Triconex. The dropper was developed in Python and compiled inside the trilog.exe executable. It contains the implementation of the TriStation protocol reverse-engineered by the threat actors and used to interact with the targeted device.
To study TRITON ourselves, we needed to recreate the targeted SIS in our lab environment and obtain as much documented information as we could about how it functioned and communicated. Obtaining both the Triconex hardware and software related to it was essential for recreating the full working environment needed for experimenting and writing malicious code. To do this we took the following steps:
Obtaining the TRITON Engineering Toolset: Through a combination of internet sleuthing and asking the right people the right questions, we were able to obtain a great deal of the information we needed. We went through multiple channels, including vendor websites like the Schneider Electric site, and found free information available online including installation CDs sold on e-commerce sites, loose executables and archives on forum sites, open directories and FTP servers.
Obtaining the Triconex Controller: The key item we needed was a Triconex controller. This is where “free” ended and we had to spend some money. ICS equipment is expensive – in the $5-$10K range. And it was important to consider that we might need multiple copies of the controller for teardown purposes.
Reverse Engineering the TriStation Suite: The software installed on the engineering workstation is valuable for threat actors because it contains all the information needed to interact with the controller, including how to recognize different statuses and attached modules. TriStation 1131 v4.9.0 (build 117) is able to connect with the hardware version targeted by the malware, and all of our analysis was performed on that version.
The TriStation suite files are nicely identified
Undocumented power users: Our research identified two undocumented power users with access to password-protected project files. These files contain key information about the Triconex program, configuration and behavior. Furthermore, when logged in as one of the undocumented users, a hidden menu becomes available that exposes internal information about the linking/compilation phases of the system logic. These users were likely used by the product support team to help customers with technical issues. While having operational value, these users can also be abused by threat actors.
It should be noted that these undocumented users exist for TriStation 1131 v4.9.0 and earlier versions only, according to Schneider Electric.
Understanding the TriStation Protocol: In accordance with the file descriptions, the code delegated to manage the network communication is located inside the DLL “tr1com.dll”. By analyzing this file, we extracted a wealth of information about the protocol’s definition that documents its behavior.
Decompiled code showing low-level packet management
Parsing the Triconex Hardware Definition: The Low-Density and High-Density chassis used by the Triconex hardware supports several different modules which are described inside a proprietary file called “TR1HWDEF.HWD”. The malware does not contain any information related to the hardware definition, probably because the threat actors did not invest time to reverse engineer that part. However, the definition file contains useful information for network traffic analysis that identifies what modules are attached to the remote Triconex hardware. We invested the time and successfully parsed the hardware information.
Automatic parsing of the file that describes Triconex hardware information
TriStation Protocol Stack Implementation: TriStation is not only the software suite used inside the engineering workstation. There is also a proprietary network protocol called “TriStation Protocol” operating on UDP/IP over port 1502. All the protocol definitions are contained inside the Python-compiled file TS_cnames.pyc and can be easily decompiled and extracted as shown in the image below. The code contained in the file is a great explanation of the function codes implemented by the TriStation protocol showing how deep the threat actors went during reverse engineering. Combining the malware analysis with reverse engineering activity performed with the workstation software, we were able to deeply dissect the TriStation protocol. It allows for communications between engineering workstations (master) and Triconex controllers (slave), equipped with specific network modules (NCM).
The Missing Final Stage of the Attack
TRITON provided the threat actor with the capabilities to read, write and execute code directly inside the TriStation’s memory. The main advantage of this architecture was its modularity, providing the attackers with the means to dynamically send a specific payload inside the memory and execute it. In the case of TRITON, the final stage of the attack is missing. Soon after the targeted Triconex was implanted with the malware, one of the main processors triggered a redundancy alarm. This forced all three main processors to start the safety shutdown protocol. It is unclear whether the issue was triggered by the dropper injecting the malware in memory, or by an unexpected fault generated while executing the OT payload. One of the more likely assumptions is that the attacker injected a specific OT payload containing an invalid memory access which resulted in a crash.
During our research, we recreated fully working Triconex infrastructure, including connecting a field device to the controller (a compressor and a balloon). The program run by the controller supervises the compressor executing an inflating and deflating process in a specific, synchronized and ongoing way. Then we used the TRITON capabilities to inject a command that modified the behavior of the security supervisor, causing the balloon to overinflate and finally generate an explosion.
This achieved the final goal of our research, showing how we were able to use the knowledge we obtained through reverse engineering TRITON to successfully execute the attack payload and compromise the safe functioning of the Triconex controller.
To help with our analysis, we developed two new tools, which we’ve also made available as free download on GitHub to help the ICS community secure Triconex SIS. The first tool, the TriStation Protocol Plug-in for Wireshark, allows an engineer to visually see and comprehend TriStation communications. It also identifies hardware connected to the safety controller and passively detects TRITON activity in network communications. Our second tool, the Triconex Honeypot Tool, can be used by defense teams to simulate SIS controllers on the network, using them like a honeypot to detect reconnaissance scans and capture malicious payloads.
What TRITON Means for Securing Industrial Control Systems
Over the last twenty years it has become easier and easier for threat actors to create ICS cyber security attacks. More and more tools and examples are readily available, lowering the bar for the knowledge and skills needed by intruders. For example, before Stuxnet (2010), there were no example ICS malware frameworks available over the Internet. Now, there are many, including TRITON.
TRITION failed. However, now, with a deeper understanding of the attack, we know it was more easily created than previously believed. We know the attackers could have succeeded in injecting the final payload. We also know that the TRITON malware framework is freely available on the internet and that a growing number of hackers have critical infrastructure in their sights That is why we as a community must move quickly on all fronts to strengthen the security posture of industrial networks, particularly safety systems.
Industrial asset owners should act immediately to monitor their SIS and secure them against external attacks. We also urge SIS equipment makers to provide more robust built-in security for these vitally important systems.
(Andrea Carcano is founder and chief product officer at Nozomi Networks)
