Today I am thrilled to be part of a team speaking at Black Hat USA regarding the landmark TRITON malware attack. My co-presenters are industrial cyber security expert, Marina Krotofil, and my Nozomi Networks colleague, Younes Dragoni.
We are presenting new research on TRITON, releasing two tools to help defend against it and publishing a white paper summarizing our findings.
The TRITON malware attack went beyond other industrial cyber attacks by directly interacting with 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.
Not only did this attack successfully interact with the “crown jewels” of an industrial system, our research released today clearly shows that the effort, skills and financial resources needed to create the TRITON malware framework are not that high. Considering this, asset owners should act immediately to monitor their SIS and secure them against external attacks.
Let’s look at our new TRITON research and how the tools that we have freely released can help industrial organizations secure their operations.
Understanding the TRITON Malware and the Resources It Took to Create It
If you’re not familiar with the TRITON attack, I suggest downloading our white paper which has a short summary of it. From our point of view, we were determined to understand TRITON itself and the level of resources required to create it. We also wanted to gain insights that would help industrial operators defend their control systems from such attacks in the future.
That’s all well and good, but where should we start? First, we gave the “understand how to create TRITON” mandate to Alessandro Di Pinto and Younes Dragoni, members of our security research team. Younes is a recent university graduate and Alessandro has eight years of malware analysis experience. They decided on an approach of being smart about getting the required resources “the easy way” and focusing only on what was needed to create the malware framework.
Gathering Intelligence and Shopping for a SIS
To obtain the TRITON engineering toolset, the team used a combination of Internet sleuthing and asking the right people the right questions. Some of it came from Internet surfing, some from the vendor’s (Schneider Electric) website, and some from consultations with key experts. The best source of information was speaking to the operations and security staff of industrial organizations.
Their next hurdle was obtaining the Triconex controller. This is where “free” ended and the team had to spend some money, let’s say in the order of $5-10K USD. Using websites such as eBay and Alibaba, the team assembled the components needed to build a working environment. Things to keep in mind during this phase were that the systems had to be compatible for everything to work together, the Triconex had to be the same model that was targeted in the attack, and we planned for copies of the controller, in case one got bricked during analysis. (In the end, no bricks were created!)
Turning an “Undocumented Device” into Malicious Code
The team obtained the engineering workstation software, TriStation 1131 v4.9.0 (build 117), and did their analysis using that version. The software is well described in its file names, which helped to understand the software architecture and its general structure.
Reverse engineering the software, the team also found two undocumented power users with hard coded credentials. One of the power user’s login enabled a hidden menu, which from an attacker’s perspective, could be useful.
A couple of important comments about the undocumented users. First, our research found no connection between the TRITON malware and this hidden menu, and the malware did not leverage these undocumented users. Second, these undocumented users exist for TriStation 1131 v4.9.0 and earlier versions only, according to Schneider Electric.
The white paper explains how the team analyzed the file “tr1com.dll” to understand the TriStation proprietary protocol, used to communicate between an engineering workstation and the Triconex controller. They also reversed engineered the “TR1HWDEF.HWD” file (something not done by the threat actors) to parse hardware information and provide a hardware definition list. The “TS-cnames.pyc” file was decompiled and extracted to obtain an explanation of the function codes used by the network “TriStation Protocol”.
Combining the malware analysis with the reverse engineering activity performed with the workstation software, the team deeply dissected the TriStation protocol. This also enabled them to develop tools for helping industrial organizations and researchers understand SIS communications.
Defending Against TRITON: New Tools to Help
The TRITON analysis led the team to develop an extended Wireshark dissector using Lua script called the TriStation Protocol Plug-in for Wireshark. This was released on July 18, 2018 and described in an earlier blog.
It offers several useful features for engineers working with the TriStation protocol:
- Indication of the direction of communication
- Function codes translated as descriptive text
- Extraction of transmitted PLC programs
- Identification of connected hardware
- Detection of the TRITON malware in network communications
They also developed a tool that simulates a Triconex controller, called the Triconex Honeypot Tool, being released today. It can be used by defense teams to simulate SIS controllers with particular system configurations, using them like a honeypot to detect reconnaissance scans and capture malicious payloads. It can therefore play a useful role in detecting unknown traffic targeting a SIS network.
Both tools, along with a TriStation PCAP are freely available on Github. We encourage you to use it and to improve it, helping the ICS community improve its knowledge of SIS communications.
Demonstrating a Working TRITON Malicious Payload
During the research phase, the team recreated a fully working Triconex infrastructure, including connecting a field device to the controller. They attached a compressor and a balloon, like the set-up first used to demonstrate the Stuxnet ICS malware.
The program they created supervises the compressor executing an inflating and deflating process in a specific, synchronized and ongoing way. Then TRITON capabilities were used to inject a command that modified the behavior of the security supervisor, causing the balloon to overinflate and finally generate an explosion.
What TRITON Means for Securing Industrial Control Systems
Over the last twenty years it has become easier and easier for threat actors to launch ICS cyber attacks. More and more tools and examples are readily available, lowering the bar for the knowledge and skills needed by intruders.
For example, the TRITON malware framework and many other ICS malware frameworks discovered in the last two years are freely available on the Internet. You may need to know where to look, but they are not impossible to find. They can be adapted by people with relatively low programming skills to create sophisticated attacks.
Indeed, our research shows that the effort, skills and financial resources needed to create the TRITON malware framework, while not insignificant, are not that high – certainly not at the level where nation state-sponsored resources are required. While the level of difficulty of executing a cyber attack varies according to the cyber security defenses, networking architecture and equipment of each facility, the development of the malware itself does not require high levels of resources.
My belief is that we have not yet had cyber attacks causing major disruption to critical infrastructure services because of the risk of unknown consequences and retaliation. Attacks on oil and gas facilities, or the power grid, will be difficult to control and will undoubtedly lead to lots of collateral damage. This, combined with the risk of retaliation, may be keeping attackers at bay.
I encourage asset owners to act now to monitor their industrial network and SIS and secure them against external attacks. Our white paper and TRITON tools will help.
TRITON: The First ICS Cyber Attack on Safety Instrument Systems Understanding the Malware, Its Communications and Its OT Payload
Read this paper to learn:
- The innovative approach taken to reverse engineering TRITON
- How our team obtained the engineering toolset and controller
- The research findings, including undocumented users
- How two new tools help defend against TRITON
- How TRITON can be used to compromise SIS
- What TRITON means for securing ICS