Safeguard
Industry Analysis•

HatMan (TRITON) malware explained: why attacking a safety system matters

CISA's analysis of HatMan, also called TRITON or TRISIS, covers malware built to reach a safety controller. What it does and what owners should take.

Safeguard Security Team
3 min read

HatMan, also reported as TRITON or TRISIS, is malware that modifies the in-memory firmware of Triconex safety controllers so an attacker can read memory and run code on demand. CISA called the ability to interact with a safety system nearly unprecedented, because safety systems exist to shut a process down safely.

What a safety system is

CISA's malware analysis report MAR-17-352-01 explains that safety systems are specialized hardware similar to ordinary PLCs, but built with an emphasis on reliability and predictable failure. They often have redundant processors, watchdog functions and strong failure detection. They normally give a process a way to shut down safely when conditions turn unsafe.

They do not run the process day to day. A degraded safety system will not make a healthy process misbehave. The danger comes if it is combined with something that does disturb the process, because then the last line of defense might not respond.

What the report says HatMan does

The report, dated 18 December 2017, describes two parts: a PC-based component that talks to the safety controller, and a malicious binary that is downloaded to it. The modification lives in memory, and the report notes the persistent firmware copy is immutable.

The communication used the TriStation network protocol over UDP port 1502. The report says this protocol does not require authentication or encryption, though ACLs may be configured on the controller. It also says IP-based ACLs are not an effective mitigation, because an attacker could still use the programming workstation.

The report treats the malware as fully functional as a worst case, while noting that bugs may have stopped it from working as intended.

What owners can take from it

The report points to a general lesson: protect the paths to the engineering workstation and the safety network, because that is where trust sits. The steps below are general OT practice, not quotations from the report:

  • Keep safety networks separate from process and enterprise networks.
  • Treat engineering workstations as high value systems. Limit who can log on and what software runs on them.
  • Know which controllers have programming enabled and under what physical conditions.
  • Monitor for unexpected use of programming protocols.

Check the vendor guidance for your own safety controllers, since the right settings depend on the product.

Why it still matters

The report places HatMan after Stuxnet and Industroyer in a line of malware aimed at industrial systems, and says it goes further by directly reaching a safety system. The report also notes that bugs may have kept the malware from working as intended, though it analyzes it as a worst case. Our post on engineering limits covers the design idea that makes such attacks less dangerous, which is not relying on software alone.

Quick check

Did HatMan control the process directly?

According to CISA, safety systems do not directly control the process. HatMan targeted the safety controller, which is the layer that provides a safe shutdown.

Are TRITON, TRISIS and HatMan different malware?

CISA says media reports use TRITON and TRISIS for the same malware it calls HatMan.

Safeguard works on the software supply chain side, for example dependency scanning and SBOMs for the applications you build, and does not analyze safety controller firmware.

Sources

Last reviewed: 19 October 2026.

Never miss an update

Weekly insights on software supply chain security, delivered to your inbox.

Self-healing security runs on Safeguard.

Your first fix PR is minutes away.

No sales call required, even your agent can complete the purchase over MCP.