Triton maware

In this article the Sentryo Security team presents you with an analysis of a malware specially designed to cripple the security of industrial systems. Read on for an in-depth look at how the Triton industrial malware works and the measures to implement to ensure protection.

Triton industrial malware: operational summary

The Triton malware, also called Trisis and Hatman, was detected in November 2017 in the Middle East and initial analyses were released in mid-December of that same year. This was the first malware to specifically target a Safety Instrument System (SIS) and be activated (an initial dormant version of Stuxnet had already targeted this type of programmable logic controller but seemed to never have been activated). In this case, the SIS targeted was Triconex product by Schneider Electric.

Initial analyses carried out by FireEye and Dragos and responses from the new international conference S4x18 indicate that the goal of this malware was to install a Remote Access Trojan (RAT). This RAT enables attackers to take remote control of systems and thus inflict material and human damage. The attacker, whose identity is still unknown, seems to have had substantial technical and financial means similar to those of a nation state. The malware was most likely only used for this targeted attack campaign.

The Triconex system is deployed in over 15,000 sites in various countries. Schneider Electric worked on a patch for the models affected as well as a detection tool.

Place, date, target and aim of the attack

The attack was analyzed in mid-November but it seems to have started back in August 2017: a local team associated with Schneider Electric carried out the first analyses during an intermediary stage. As of today, only one target is known although its identity has not been confirmed. This target could possibly be a Saudi Arabian infrastructure (some sources cite the company Aramco).

The target of the Triton malware
In the case of the Saudi Arabian infrastructure, the target was a specific model of Schneider Electric’s security system which activates different safety measures in the event of errors on the production system.

For now, we cannot know for certain what the attacker’s real intentions were because the final stage of the attack never unfolded. However, according to the different analyses, the attackers could have easily stopped production although this was probably not their final motive.

The stages of the attack

The different files comprising the Triton malware (most notably the installation files for the RAT) are available online which explains why it was possible to perform various analyses. The attack was carried out in multiple stages.

First stage: code distribution

The attackers obtained remote access to a workstation used for the control and programming of PLCs in the SIS. They then used the TriStation protocol to download the code onto the Triconex controller. The program used was an executable called trilog.exe delivered in a Py2Exe compiled script which made it easy for the attackers to do reverse engineering. As for Triton, the IP address of the target was directly indicated in the source code and the industrial malware did not invoke its network discovery function with which it was equipped.

Two obstacles for hackers
The hackers had to neutralize 2 main weaknesses:

  • The Triconex controller only accepts program downloads in “PROGRAM” mode while other modes (such as “RUN”) block them. These modes were manually changed via a physical system.
  • The code injected is not persistent and is erased when a new program is downloaded (“download all”).

Second stage: persistence and communication

In order to exploit these weaknesses, the attackers used a Zero-Day vulnerability to cause a privilege escalation and to write code in the firmware memory area rather than in the user memory area (because of the importance of SIS, controllers are rarely rebooted which reduces the risk of this memory being erased). This memory area is not erased when new programs are downloaded.

In order to communicate between the controller and the workstation, the malware was programmed to listen to messages normally used for debugging (“GetMPStatus” messages) then execute the desired command (“read”, “write” or “execute”). By hooking into the network communications process, the malware was able to modify the memory of the controller even if the controller was in “RUN” mode and thus block regular program downloads.

Once the payload was injected, the malware regularly verified that operations run without errors. If an error was detected an initial method (“SafeAppendProgramMod”) attempts to go back to a previously stable state. If this method fails, a fake payload overwrites the malicious payload, most likely to make future forensic analyses more complicated.

Third stage: use of a RAT

At this stage, the attackers are capable of remotely controlling security controllers with a RAT: they managed to block controllers from reacting to abnormal production operations and even to directly activate harmful procedures.

Did a bug thwart the attack?

Before the final attacks could be carried out, the industrial processes governed by the SIS were shut down when the controllers went into failed safe state. This behavior could have been caused by a bug in the attackers’ program.

In order to inject code into the controllers, the attackers first used a function that allows them to test writing to the memory before overwriting with a benign program. This might have been the function that caused a bug and thus limited the impact of the attack.

Protect yourself against the Triton industrial malware

In order to detect malware, you can use the YARA rules published by FireEye and the US CERT. You can also monitor the presence of flows on specific ports (use of port 1502 in UDP). However, given the level of sophistication of the attack and the attackers’ means, these static rules will probably soon become obsolete.

Although the Triton malware did not have serious consequences this time, once again we are reminded of the potential of powerful actors to develop malicious tools targeting industrial systems. These tools do not aim to simply stop production but to sabotage and damage systems (like Stuxnet). However, unlike Stuxnet, Triton enables attackers to have complete remote communication with the controllers of the security system and this is what makes it even more worrisome.

However, with active surveillance of your industrial network you will be able to the detect the suspicious behavior of malware. An untimely reprogramming of controllers, the use of uncommon functions (debug) and external communication (control server) are all elements that an analysis based on the capacity of an industrial DPI can detect. Stay up-to-date with the Sentryo magazine and be informed of the latest developments in the Triton malware!