Triton, also called Trisis or HatMan, is malware found in 2017 at a Saudi Arabian petrochemical plant. It targeted the plant's Schneider Electric Triconex safety instrumented system, the layer meant to shut a process down safely. A plant trip led to its discovery, and no human harm resulted.
What happened
The first signs came in June 2017, when the plant's safety system shut the plant down. It was first thought to be a mechanical fault. A second shutdown in August 2017 led to an investigation that found the malware, and the attack was publicly reported in December 2017.
The malware could disable the safety systems, which could have let a process run into unsafe conditions without the last protection layer acting. That is why it drew so much attention.
How the attackers got there
Reporting summarised in the source says the attackers used a zero day flaw in Microsoft Windows to reach a computer connected to the Triconex controllers and create a backdoor. Several physical keys had also been left in a position that allowed access to the Triconex systems, which is described as a major contributing factor.
That detail is worth pausing on. A hardware key switch exists to keep programming locked out in normal operation. Leaving it in program mode turned a physical safeguard into an open door.
Attribution
Symantec described the malware. In 2018 FireEye reported it most likely came from a Russian research institute known as CNIIHM, and the attack is believed to be state sponsored. Attribution of this kind rests on the vendors' analysis, so treat it as a reported assessment.
Lessons for operators
Put safety systems on their own network segment. Separation from the control network and the corporate network limits how far a Windows foothold can reach. See our explainer on safety systems and control systems.
Treat the engineering workstation as critical. It is the path to the controller.
Return key switches to run mode. Audit the physical state, not only the configuration.
Investigate unexplained trips. The first shutdown was blamed on a mechanical fault. A trip with no clear cause deserves a security look as well as an engineering one.
Monitor for unexpected changes to safety logic. Compare controller programs with trusted backups.
Where software supply chain fits
Triton was a targeted attack, not a dependency issue, but the patching lesson applies. Keeping the software on workstations that touch safety controllers inventoried and patched shrinks the entry points. Safeguard's dependency scanning and SBOM tools cover software you build and ship, and they do not monitor plant networks or controllers.
Quick check
Did anyone get hurt?
The source reviewed states that no human harm resulted.
Was the safety system itself hacked through a firmware bug?
The source describes a Windows zero day to reach a connected machine and a left open key position, rather than a firmware flaw. Verify with the primary vendor analyses if you need detail.
Sources
A secondary summary; read vendor and government analyses for technical detail.
Last reviewed: 19 October 2026.
