Triton, the malware that became known publicly in December for its attack on what has since been revealed was a Saudi oil and gas refinery, has been back in the news lately. Reports released by FireEye and Dragos last month detailed how the malware—referred to also as Trisis/Hatman—directly targeted the critical facility’s safety instrumented system (SIS). As it turns out, some files from the malware have been publicly available on the Internet for others to copy since late December, about a week after the reports went public.
The attack, which took place in August, targeted the facility’s Triconex safety system supplied by Schneider Electric. Set to reprogram the SIS controllers, the malware triggered a safe shutdown of the industrial process, which was an appropriate response for the safety system. Upon publication of the reports from FireEye and Dragos, Schneider Electric issued a security notification to its customers to provide awareness of the attack and to reiterate best safety practices (The attack was made possible not through a vulnerability in Schneider Electric’s system, but rather neglect by the customer facility.).
What Schneider Electric also did, however, was to upload a sensitive file containing the backbone of the Triton framework to VirusTotal, a public malware repository. Although Schneider Electric received a request to remove the file from the site, and it did so quickly, the file had already been copied and made available at other public sites, such as GitHub. The Library.zip file that Schneider Electric gathered during its evidence collection could be combined with another publicly available file called Trilog.exe (uploaded to VirusTotal by the victim company) to recreate the Triton malware.
Owned by Google, VirusTotal is a free online service that enables anyone to upload a file to be scanned for viruses, worms, trojans and other malware. It also serves as a malware repository. Although what Schneider Electric did was in line with industry protocol—done proactively in the interest of enabling the cyber community to analyze and respond to new malware—it might not always be advisable. According to a discussion I had early last year with Ben Miller, director of threat operations for Dragos, it’s not uncommon for files to be uploaded to VirusTotal that would be better left unshared on a public database. During Dragos’s study of mostly publicly available data geared toward developing a quantifiable metric of cybersecurity threats on industrial controls systems (ICSs), Miller found Nuclear Regulatory Commission reports with non-public names, for example, and a substation maintenance report with detailed spreadsheets and drawings.
Miller recommended using VirusTotal as a data source but not to upload files. “When you start uploading to it, that’s when things can become more interesting,” he said. “There are some dos and don’ts that haven’t been communicated.”
Triton unchained
With parts of Triton out the in the wild now, the concern is that it could be easier for variants of the malware to strike again, and perhaps even be rewritten for safety systems from other industrial automation suppliers.
Schneider Electric contends, however, that Triton is not exactly out in the wild. “The complexity of the attack and the malware and how the attack was conducted, means there is no likely imminent threat to our other customers,” the company told me, clarifying that the malware could be successfully loaded only if all the following conditions are present:
- The site must be using a legacy Triconex Tricon controller configured with the model 3008 Main Processor and firmware versions 10.0 to 10.4.
- The safety network must be accessible either locally or remotely.
- The attackers must have access to the TriStation terminal or another machine connected to that safety network.
- The Tricon memory protection keyswitch must be in Program mode.
- The keyswitch must be left in Program mode long enough for the attack to take place.
Many of these points reiterate the fact that the attack was able to happen in the first place because of mistakes made on the customer’s end. To review those circumstances, read my original report on the attack.
Nonetheless, the malware is potentially very dangerous because it’s an advancement of a known attack vector, says Bryan Singer, director of security services and sales at IOActive. He adds that it’s doing exactly what his team predicted could happen almost eight years ago when working on an ICS security project that studied the cyber impact on safety systems for the oil and gas industry. “We said back then that you could impact the firmware of the device and impact the safety instrumented function (SIF), too,” he says. “The Triconex malware is doing what we said nearly eight years ago.”
“A successful Trisis-like attack, under certain circumstances, can lead to a catastrophic accident,” says Eddie Habibi, founder and CEO of PAS Global. “The Triconex triple modular redundant (TMR) system is a safety-critical layer of protection designed to gracefully and safely take down a unit during an emergency when the operator is no longer able to contain the process. Consider a scenario where a skilled malicious attacker breaches a Triconex system, which is designed to safely shut down a reactor in a fluid cat cracking unit in a refinery, by bypassing the trip function. This simple change could act as a time bomb and remove the failsafe that ultimately protects the plant—a catastrophic event.”
The bottom line is that companies need to act to protect their operations. But it would seem that some are still lax about taking action.
“Unfortunately, all these wake-up calls haven't actually woken anybody up yet,” Singer says. “In watershed moments such as the Equifax and Target breaches, and now with Triconex, everyone freaks out but doesn’t do anything. We’ll see a lot of the same here: People will dismiss the threat and think it won’t happen to them because they’re not being targeted. This will prove to be completely untrue. There are far too many attack mechanisms to say it won’t happen to us.”
As Habibi notes, “There are two speeds in ICS cybersecurity—industry speed and hacker speed. Hackers can move much more quickly than industry. Industry may not patch a system for months or ever, depending on assessed risk. Although this may sound ominous, industry does have safeguards in place that protect reliability and safety. The problem is that hackers are learning more about these systems and how to manipulate them, as we saw in the Trisis attack.”
Patching is often easier said than done in operational environments, however, comments Emily S. Miller, director of national security and critical infrastructure programs at Mocana. “Remember, in OT, we’re talking about devices that control physical processes that can impact lives, not just bits and bytes of data,” she says. “Quickly patching devices, as you would expect to see in an IT environment, can have real, catastrophic consequences in an operational environment.”
Good cyber defenses
Instead, the Triton attack serves to indicate that a new approach to the cybersecurity problem is needed, Miller explains. “Rather than continuing to chase vulnerabilities and trying to implement an IT approach to OT security, we should instead think about how we can make critical devices inherently secure and more difficult for hackers to gain access,” she says. “Without access to an ICS device, hackers cannot begin to take advantage of a vulnerability. Certainly, defense-in-depth methodologies and good cyber hygiene are a part of the solution, but what happens when those techniques fail, and the actors can remotely access a device and potentially manipulate it?”
The biggest finding from the study that Singer and his team did eight years ago was that cybersecurity must be factored in as a key component of good engineering design. “The good news is we learned that good engineering design works,” he says.
If you are following good engineering practices, the malware should not be a big threat—as long as your safety systems are isolated from your network, Singer notes. (HIMA, which specializes in safety-related automation systems for process industries, also recently emphasized the importance of keeping safety and security systems physically separate from process control systems.)
Singer provides more guidance: “The regular control system should be watching the normal state of operations, but when those go bad, you should rely on digital protective systems (such as safety instrumented systems like Triconex devices or machine overfeed protecting devices used in large-scale turbines for power generation),” he says. “These are important processes to ensure it doesn’t go down. The last line of defense should be controls that are unhackable—such as emergency release valves and mechanical overfeed detection devices and valve checks.”
