TRITON / TRISIS Safety-System Lab
In 2017, malware now called TRITON (also TRISIS / HatMan) became the first known code built specifically to attack a Safety Instrumented System — the Schneider Electric Triconex Tricon controllers that exist to trip a hazardous process to a safe state. This lab walks that real, published kill chain: the IT→OT pivot, the engineering workstation, the key-switch left in PROGRAM, the proprietary TriStation protocol on UDP/1502, and the download of modified safety logic. Read each event, tell a TRITON step from legitimate safety work, and pick the one right response. Keep the Triconex independent, monitored and provably able to trip — or the safety layer fails exactly when it is needed.
The real job. More noise, a tighter clock.
TRITON safety-system drill
Event 1 / 10
The reactor train runs under its DCS; the Schneider Electric Triconex Tricon (TriStation 1131) must independently trip it to a safe state at 560°C. Work each event — legitimate safety work or a step of the TRITON kill chain — and pick the one right response.
A dual-homed station is bridging the IT network to the DCS
An engineering host has one NIC on the business network and one on the plant DCS VLAN, giving an IT-side intruder a direct route onto OT — the pivot TRITON used before it ever saw the safety system.
Your response
Kill chain → the safety layer
395°CThe Triconex is armed and independent — it will trip the reactor to a safe state when the limit is reached.
Progress
0/10 events worked · 0 kill-chain advance(s) · 0 over-reaction(s).
Live arena
4 activeadversary staging…
What this lab is
- A free, browser-based lab that reconstructs the 2017 TRITON / TRISIS attack on a Schneider Electric Triconex Tricon Safety Instrumented System — the first malware built specifically to target a safety controller.
- You defend the real kill chain, step by step: the IT→OT pivot, the engineering workstation, the Tricon key-switch left in PROGRAM, the proprietary TriStation protocol (UDP/1502), and the download of modified safety logic.
- Each round is an event — hostile or legitimate — and you pick the one correct defender response, drawn from published post-incident analysis (Dragos, Mandiant, Schneider, CISA).
- Some wrong answers advance the kill chain and leave the Triconex unable to trip; when the safety demand arrives, a defeated SIS means the process reaches an unsafe state.
- Scored on preserving the safe-state trip, countering every TRITON step, and not over-reacting to sanctioned safety work — with difficulty tiers, a speed bonus and an S–D grade.
Why TRITON still matters
Most ICS incidents degrade or disrupt production. TRITON was different: it reached past the control system to the safetylayer — the independent system of last resort whose only job is to prevent loss of life and catastrophic loss when everything else has failed. Reprogramming that controller so its trip would not fire removes the final barrier between a process excursion and a disaster. That is why the attack reset how the ICS community thinks about safety-system cybersecurity.
The defences this lab drills are the ones named in the post-incident analysis and in IEC 61511 practice: keep the SIS independent of the process control system (separate controller, network and workstation); keep the key-switch in RUN outside controlled change windows; monitor the engineering protocol (TriStation / UDP 1502) because legitimate use is rare and scheduled; hold a signed master program and diff against it; proof-test the trip; and treat an unexplained safe-state trip as a possible intrusion to investigate, not a nuisance to reset.
Frequently asked questions
What was the TRITON / TRISIS attack?
TRITON (also called TRISIS or HatMan) was malware discovered in 2017 that targeted Schneider Electric Triconex Tricon safety controllers at a petrochemical facility. The attackers first compromised IT, pivoted to the OT/DCS network, reached the Triconex engineering workstation, and then used the proprietary TriStation protocol to download modified safety logic to the controller — which was possible because its physical key-switch had been left in PROGRAM mode. It is the first publicly known malware built specifically to attack a Safety Instrumented System. It was discovered when a flaw in the attacker's own code caused the controller to fail safe and trip the plant.
Why is the Triconex key-switch so important?
The Tricon has a physical key-switch with positions including RUN and PROGRAM. In RUN, the controller refuses remote changes to its safety program; in PROGRAM (remote), it accepts them. TRITON depended on the key being left in PROGRAM so logic could be downloaded over the network. Keeping the key in RUN outside documented, supervised change windows is a hardware interlock that the network cannot override — the single cheapest barrier against this class of attack.
What is TriStation and why does monitoring UDP/1502 matter?
TriStation 1131 is the proprietary engineering protocol used to program Triconex controllers, carried over UDP port 1502. It is undocumented; the TRITON actors reverse-engineered it to communicate with the Tricon. Because legitimate SIS engineering is rare and scheduled, any TriStation/1502 traffic to a safety controller outside a planned change window is a high-fidelity indicator of compromise — which is why monitoring for it is a core detection.
Is this a real safety controller or exploit?
No. It is an educational, defender-focused simulation of the TRITON kill chain and the controls that stop it — IT/OT segmentation, key-switch discipline, protocol monitoring, a signed master program, SIS independence under IEC 61511, proof-testing, and treating an unexplained trip as a possible intrusion. It contains no exploit code, no payloads and no attack instructions; everything is described at the published post-incident level so the defensive lesson is clear.