TRISIS was an interesting piece of malware to analyze and represents a lot of “firsts” regarding both ICS attacks and embedded systems exploitation. Likewise, it required a lot of “firsts” for us in terms of malware analysis – in our experience, it is the first malware reverse engineering effort to involve the use of a soldering iron.
In our talk, we cover the malware, how exactly we went about reverse engineering the interaction between TRISIS and the Triconex firmware, as well as how to achieve post-exploitation effects. It provides a technical discussion of not only how the attacker did what they did, but also what is required to unravel this new type of malware.
Our talk dives deeply into assembler language at various points, so we are providing a high-level set of takeaways as a companion to it.
TRISIS works unmodified to infect both V10.2 and V10.4 releases of the Triconex platform without modification. It seems likely that little to no modification is required to make the tool work against other firmware versions in the 10.0 to 10.4 range.
Defenders should implement program download detection and ensure that they keep the controller key in RUN or REMOTE modes. The SIS should only be placed in PROGRAM mode when actually being programmed to minimize the opportunity for an attacker to issue commands.
File carving from the proprietary protocol Dragos calls the TriStation 1131 protocol is fairly straightforward — it is possible to save all logic updates for later analysis. The protocol has no authentication and is UDP-based, so defense can be tricky if a system absolutely has to be left in PROGRAM mode. As an example, even if a defender uses the controller's built-in network ACLs and password mechanisms, an attacker can still achieve their goal. It is trivial to use packet spoofing to bypass any network ACLs, and the SIS does not enforce passwords.
TRISIS uses the TriStation 1131 protocol to deliver its payload and adds a new command to the protocol in order to implement its functionality: Tristation Command 29. While flagging this command via an IDS signature or active means is a good way of finding TRISIS as it was found in the wild, it would be simple for the attacker to switch commands. We found that 12 command function codes are easy to hook in the firmware, and we flag all of these as malicious.
Significant development effort from the attacker is not required to implement some evasion techniques, for instance adding a specific authentication code to the command, so only looking at TriStation commands is not a definitive way to determine if a safety controller is infected.
Limitations of the hardware make it impossible to tell for certain if a controller is infected with malware. The architecture of the controller places the attacker's code on the network command processor, so an attacker could overwrite any part of the system to hide themselves. The only way to uncover a permanent rootkit is to disassemble the controller, thereby voiding the warranty. Any of the interfaces exposed to a normal user could be intercepted by malware in order to hide the malicious code. Post-infection forensics is difficult since the malware is memory-resident only and will not be present once the controller has lost power.
TRISIS' main function is to allow an attacker to manipulate outputs, edit program code, and change and execute new logic, even after the keyswitch is placed into RUN or REMOTE modes. While those modes are effective at preventing an initial infection, they do nothing to stop the attacker if the SIS is compromised.
TRISIS is an access maintenance tool and is likely meant to be used in conjunction with an attack against the control systems network. It is unlikely a plant shutdown was the only goal of the attack, because that can be achieved with either a simple logic load (no need for installing a new network command), or direct control commands to the SIS.