TRITON/TRISIS: The Malware Designed to Kill

Introduction

In December 2017, a petrochemical facility in the Middle East—later identified as the Petro Rabigh plant in Saudi Arabia—experienced an unexpected shutdown of its Safety Instrumented System (SIS). Engineers investigating the failure discovered something unprecedented: malware that had been specifically designed to reach into a Schneider Electric Triconex safety controller, modify its program logic, and disable the safety functions that would have triggered an emergency shutdown in the event of a process failure.

The malware, named TRITON by Mandiant (also called TRISIS by Dragos and HatMan by CISA/ICS-CERT), represents a singular milestone in the history of industrial cyberattacks. It is the only publicly known malware engineered not to steal data, not to encrypt files for ransom, and not even to disrupt process operations directly—but to disable the safety systems that protect human life.

What Safety Instrumented Systems Do

To understand why TRITON is so alarming, it is necessary to understand what SIS systems exist to prevent. In petrochemical, oil and gas, and chemical manufacturing, industrial processes operate near their physical limits: high temperatures, extreme pressures, toxic and flammable materials. A process deviation—a pressure excursion, an over-temperature condition, a valve failing open—can result in explosion, fire, or toxic release.

Safety Instrumented Systems are the independent, last-resort layer designed to bring a process to a safe state when these excursions occur. A SIS is deliberately isolated from the process control system (DCS or SCADA): it has its own sensors, its own logic controllers (Safety PLCs or SIS controllers), and its own final elements (typically automatic shutdown valves). The SIS does not operate the process; it only acts to stop it when a dangerous condition is detected.

IEC 61511 and IEC 61508 define rigorous engineering requirements for SIS design, including Safety Integrity Levels (SIL) that specify the probability of dangerous failure per demand. A SIL 3 SIS, for example, must have a dangerous failure probability of between 10⁻⁴ and 10⁻³ per hour. These requirements assume the SIS is functioning correctly—they do not account for an adversary actively reprogramming the controller.

TRITON’s Architecture

TRITON was designed by highly capable developers with specific knowledge of the Triconex TriStation 1131 protocol—a proprietary, undocumented protocol used by Schneider Electric engineering workstations to communicate with Triconex controllers. The malware’s components reveal the level of reverse engineering investment made by the attackers:

trilog.exe

The main execution module. Disguised as a legitimate TriStation executable, it uses Python (bundled as a compiled executable) to communicate with Triconex controllers using the TriStation 1131 protocol. The use of Python indicates the attackers prioritized rapid development and portability over stealth.

TsHi.pyc and TsLow.pyc

Python modules implementing the TriStation 1131 protocol stack—essentially a fully functional implementation of the proprietary communication protocol, developed through reverse engineering. This level of protocol-specific implementation represents significant investment; the TS 1131 protocol was not publicly documented.

imain.bin

A custom payload written in ladder logic for the Triconex controller’s TRICON Main Processor. This is the component that runs on the safety controller itself. The payload was designed to allow remote code execution on the Triconex CPU—a capability that did not previously exist in any publicly known malware.

Execution Flow

TRITON was deployed on an engineering workstation that had been compromised in the facility’s IT network and used to pivot into the OT environment. The attack followed the Purdue model’s most dangerous path: from IT, across the IT/OT boundary, through the process control network, and finally reaching the SIS—which was architecturally isolated but still network-reachable from the engineering workstation subnet.

When TRITON attempted to reprogram the Triconex controllers, a defect in the payload caused the controllers to enter a fail-safe mode, triggering an unplanned shutdown. This is what alerted investigators. Had the payload executed as designed, the SIS would have been silently disabled—leaving the facility’s process running without its safety protections, vulnerable to any subsequent process excursion.

Attribution

Dragos (as Xenotime) and Mandiant attribute TRITON to a Russian nation-state actor with high confidence. In 2019, the US Department of Justice indicted a Russian Central Scientific Research Institute of Chemistry and Mechanics (TsNIIKhM) researcher in connection with the attack. TsNIIKhM is a Russian government research institution under the Ministry of Defense.

This attribution is significant: it places the development of malware designed to cause physical harm to humans within a recognized state military research institution—a level of state sponsorship not previously confirmed for any ICS attack.

Post-2017 Developments

Dragos has reported Xenotime continued capability development after the 2017 Petro Rabigh incident, with the group observed scanning OT environments at US electric utilities and other critical infrastructure sites in 2018 and 2019. The group’s continued activity after attribution suggests ongoing intent to use or re-deploy TRITON-class capabilities.

Schneider Electric released firmware updates for the Triconex TRICON (version 10.4.9 and later) that close the specific vulnerability exploited by TRITON—an undocumented TriStation service that allowed program downloads without authentication when the physical keyswitch was in PROGRAM mode. However, the broader threat of SIS-targeting malware persists.

Implications for SIS Security

TRITON changed the threat model for safety system cybersecurity. Before 2017, the OT security community broadly assumed that SIS security was primarily a physical problem—physical keyswitch controls, physical segregation of the SIS network, and procedural controls on who could access SIS engineering stations. TRITON demonstrated that a sufficiently capable adversary can navigate these controls entirely from software once they have network access.

Key takeaways:

1. SIS network isolation must be absolute. The Petro Rabigh SIS was on a separate network segment, but that segment was still reachable from an engineering workstation the attackers had compromised. No IP connectivity should exist between process control networks and SIS networks.

2. SIS engineering workstations require the strongest access controls in the facility. Physical keyswitch controls exist for a reason—ensure they are respected procedurally, and consider removing or disabling network-accessible TriStation service ports on production controllers when not in active use.

3. Behavioral monitoring for SIS communication is necessary. Any unexpected TriStation or equivalent safety protocol traffic on process networks should generate immediate alerts. SIS controllers should not receive engineering communication outside planned maintenance windows.

4. Threat modeling must include physical harm scenarios. Security risk assessments for OT environments that include safety systems must explicitly model the scenario of safety system compromise and the resulting process hazard.