Triton, also called Trisis and HatMan, is malware built to interact with Triconex safety instrumented system controllers, the devices meant to shut down an industrial process when conditions become unsafe. Public analysis appeared in December 2017. This post sets out the dated record from MITRE and leaves out what the sources do not confirm.
What is it?
MITRE ATT&CK describes Triton as an attack framework built to interact with Triconex safety controllers from Schneider Electric. It is a Python based framework that speaks the TriStation protocol over UDP port 1502. It can discover controllers by broadcast, read their operating mode and program and key state, and download programs.
MITRE also notes a previously unknown vulnerability in Tricon MP3008 firmware 10.010.4 that the malware exploited for privilege escalation. The listed impact techniques include changing the operating mode and reprogramming the safety system, which MITRE labels Loss of Safety.
What is the timeline?
- 13 and 14 December 2017. Dragos and FireEye publish initial analyses.
- 16 January 2018. Midnight Blue publishes an analysis of the malware.
- 23 January 2018. Schneider Electric publishes its analysis and disclosure.
- 7 June 2018. Reese and Miller publish a treatise on Triton and TriStation.
- 23 October 2018. FireEye attributes the activity to a Russian government owned lab. This is the vendor's attribution, as listed by MITRE.
- 18 December 2018. ICS-CERT advisory ICSA-18-107-02 covers the Triconex Tricon product.
- 27 February 2019. CISA publishes malware analysis report MAR-17-352-01 on HatMan, Update B.
- 26 March 2019. MITRE creates its ATT&CK entry.
MITRE assigns the activity to the group it names TEMP.Veles, which Dragos tracks as XENOTIME. We do not repeat details about the victim facility, since those are outside the sources we fetched.
What techniques did it use?
Defense evasion and persistence are the notable parts. MITRE lists disabling a firmware consistency check after injecting a payload, hooking a diagnostic command, masquerading as a Triconex program name and modifying controller tasking so the payload runs every cycle. It also attempted to remove traces by resetting the controller and writing a dummy program.
What should defenders learn?
Safety systems need their own protection. They are the last layer. Treat their networks, engineering workstations and firmware as high value assets.
The path in is usually IT or the engineering workstation. The framework talks to controllers over the network, so isolating that traffic matters more than hardening the controller alone.
Know your firmware. The attack leaned on a flaw in specific firmware. An inventory of controller models and versions, tied to vendor advisories, is a baseline.
Detect the strange protocol use. TriStation traffic from a host that is not an engineering station is a signal worth alerting on.
What to do
- Inventory safety controllers, firmware versions and engineering workstations.
- Apply vendor advisories, including those for Triconex, and track them by owner.
- Isolate the safety network and limit who can reach TriStation.
- Monitor for TriStation traffic from unexpected hosts.
- Keep known good copies of controller programs and compare them on a schedule.
- Review remote access paths for engineering tools.
- Rehearse a response that includes taking a process to a safe state manually.
Quick check
Is Triton the same as Trisis and HatMan?
Yes. MITRE lists HatMan as an associated name, and CISA's report is titled for HatMan, and the same malware is also called Triton and Trisis.
Was the attacker identified?
MITRE lists the group as TEMP.Veles and notes FireEye's October 2018 attribution to a Russian government owned lab. Treat attribution as a vendor assessment.
Sources
Last reviewed: 18 October 2026.
