A Triconex Industrial controller allows triple redundancy and 2/3 consensus vote based control and has its origins in the 80’s industrial needs for safety for industrial controllers. The Hatman/Triton ICS malware targetting this specific controller, came to light in 2017 and details were released slowly.
From the SchneiderElectric and Mandiant analysis of the malware, more technical details appeared recently. A summary is below.
Physical access to the controller network is necessary. The Triconex controller needs to be in Program mode. A program agent running on windows in the same network talks over a Tricon protocol to program the Triconex controller to install/deploy the control payload program. This latter program runs like a regular program on the controller, on every scan cycle. It runs in parallel in three controllers like any other Triconex program. It attempts to remove traces of itself after installation.
Once here, it is looking for a way to elevate it privilege level. It starts observing the runtime, including memory inspections. There is a memory backdoor attempted, but there is a probable error handling mistake which prevents this. Now to be able to access the firmware, it takes advantage of a zero-day vulnerability in the firmware. It is able to install itself in the firmware, overwriting a network function call. In the end it installs a Remote Access Terminal to allow remote access of the controller. This could have been a vector to download further payloads, but no evidence was found that this RAT was actually used.
Source code of the program is at https://github.com/ICSrepo/TRISIS-TRITON-HATMAN .
Zero day attacks are a continuing challenge as by definition they are not widely known before they are used for an attack. However a secure by design approach reduces the attack surface for exploits. There were opportunities to detect the malware on the network and the windows host.