The Triton/Hatman Malware: Safety Systems Rendered Unsafe

21 December 2017

An alarming new cyber threat set the industrial control industry abuzz this month with the discovery of the Triton (or Trisis/Hatman) Malware. Similar in some ways to the Stuxnet worm of seven years ago, this new threat startled industry-watchers for its ability and intent to disable safety systems found in many oil, gas and nuclear plants. While no harm was done this time, far too little was, in my view, in place to prevent a catastrophic event. Let’s take a look at this most recent breach of an industrial control system (ICS) that was supposed to be protected by a solution in use at many ICS facilities.

The sophisticated piece of malware was first discovered and evaluated by cybersecurity firms Mandiant, a FireEye company and Dragos. Mandiant had been tasked by an operator in the Middle Eastern to investigate a concerning anomaly in its automated systems. At about the same time, Dragos performed its own analysis independently, dubbing the malware “Trisis.” Both companies discovered a complex threat to critical systems capable of modifying application memory on a Triconex safety instrumented system (SIS). The companies also discovered that the py2exe-compiled Python script afforded many other hackable opportunities, leading to the conclusion that this instance was more of a probe in its intent than a full-on incursion.

Triton infected a Windows computer connected to an SIS device and injected code that modified SIS-device behavior. SISs are designed to watch ICS operations and respond to any detected unsafe condition. In this case, with this malware, SIS readings can be altered to safe-state when a malfunction has occurred. The malware also can remove evidence that an intrusion has taken place. In short, FireEye and others warn that this new threat smacks of nation-state-caliber determination to ultimately inflict crippling damage to safety and critical systems.

My colleagues and I agree, and we would add another concern. Particularly scary to me is that Triton was not an attack that leveraged a specific vulnerability within the Triconex SIS itself. Instead, it exploited the inherent vulnerability in the network-architecture design that allowed attackers to send messages directly to the controllers themselves.

While Triconex SIS owners may not have to worry about hastily applying patches, they should be worried about overall system architecture and access control. Just because a workstation is part of the production network does not mean it should necessarily have direct access to safety-critical controllers.

Intrusion detection and malware defenses for these networks are limited to blocking known intrusions only for the PCs attached to the systems. The Triton malware calls for security methods that surpass basic firewall, perimeter and signature-based defense. Protections are needed that extend security to system endpoints using protocol-specific parsing and whitelisting that assure data integrity.

Seven years after Stuxnet shocked the utilities industry, operators have a renewed (and regrettably repeated) wake-up call to more deeply layer critical-system cybersecurity. Operators and governments must again reconsider the necessity of industrial firewalls and deep packet inspection (DPI) that allows for application whitelisting technologies that limit the commands that can penetrate a particular controller.

Solutions exist, but are not being widely enough applied, that can radically reduce the attack surface available to even the most persistent and well-resourced threat actor. We can start with a tougher standard that demands industrial, even military, grade solutions.

Learn more about application whitelisting technologies for industrial environments.


Article by Sunny DeMattio

Sign up for download access

Please submit your details below to access our downloads.

I'm happy for you to contact me

View our privacy policy
Not now