ESSENTIALLY DIFFERENT
Triton, also called Trisis referring to the Triconex safety controller model that it targets, is a very different kind of malware. It isn’t the code so much—basically it’s a Trojan horse—but rather it’s the ultimate target of this threat. Unlike many other Trojans, worms, and viruses that are limited to individual targets, ones that demand ransoms, or destroy files, or just watch what you’re doing with a keystroke logger, Triton attacks mechanical safety devices rendering them useless for what they’re assigned to do—that is, protect the humans in the plant and in the vicinity as well as the equipment and the very building itself. Triton has an insidious antipersonnel component.
There are other malware programs that pose cyber-physical threats by targeting machinery or industrial systems. Stuxnet, developed in 2010 by America’s National Security Agency and Israeli intelligence, was a worm that attacked logic controllers in a uranium-enrichment plant in Iran, destroying essential centrifuges, and thereby shutting down operations.
In December 2015, Russian hackers used a Trojan called BlackEnergy to cause blackouts and gather intelligence within Ukranian power companies. The following year, also in December, the Russians attacked an electrical transmission station in Kiev with CrashOverride, malware also known as Industroyer, and that blacked out part of the city for a period of time.
Triton, however, is a Trojan horse of another color. Bradford Hegrat, a security specialist at Accenture points out, “Even with Stuxnet and other malware, there was never a blatant, flat-out intent to hurt people.” Joe Slowik of the security firm Dragos Inc. adds, “Targeting safety systems just seemed to be off limits morally, and really hard to do technically.” Difficult, perhaps, but the first Triton installation was discovered in an operational plant in August 2017.
SUCCESSFULLY EMBEDDED
In the summer of 2017, at a petrochemical plant in Saudi Arabia, malware was discovered that would allow remote control over the plant’s safety instrument systems. What allowed the plant’s security team to uncover the Triton installation was a second failure of the malware that exposed its presence. A first incident occurred in June 2017 when Triton inadvertently created a response that shut down the plant. That was misdiagnosed as a mechanical glitch, and a reset was initiated without anyone discovering the actual danger they were in.
A second incident happened two months later as systems tripped and shut down the plant again. This time, investigators were brought in, and they discovered the malware. Giles points out how fortunate they were that two sets of errors exposed the threat. He writes, “In a worst-case scenario, the rogue code could have led to the release of toxic hydrogen sulfide gas or caused explosions, putting lives at risk both at the facility and in the surrounding area.”
Triton is industrial malware at both ends. Possible targets include power plants, oil and gas companies, and transportation networks. From the hacker’s side of things, the security group FireEye offers this about its probable source: “FireEye has not connected this activity to any actor we currently track; however, we assess with moderate confidence that the actor is sponsored by a nation state. The targeting of critical infrastructure as well as the attacker’s persistence, lack of any clear monetary goal and the technical resources necessary to create the attack framework suggest a well-resourced nation state actor.” The malware is complicated, long in development, and deployed long term. Also, there are those who believe the infiltration of the Saudi plant had been in place since 2014.
BHOPAL
We have already witnessed the reach of cyber-physical malware attacks with centrifuges in Iran spinning out of control and self-destructing, and electric-grid disruptions in the middle of two Ukrainian winters. The threat discovered at the petrochemical plant in the Middle East revives memories of the worst industrial catastrophe ever recorded.
On the morning of December 3, 1984, about 40 tons of methyl isocyanate gas was released into the air at the Union Carbide pesticide plant in Bhopal, India, and into the slums surrounding the installation. The ultimate death toll was somewhere between 15,000-20,000 workers and local residents. The cause was poor management and lack of maintenance that allowed a backflow of water into a chemical tank that resulted in the deadly cloud. Union Carbide claimed the water that got into the tank was the result of sabotage.
Industrial disasters are on a different scale, sometimes with long-range effects that can last for decades or centuries. Chernobyl and Three Mile Island come to mind. If there are efforts now in play to recreate that kind of chaos with malware that disables fail-safe systems, in the cold assessment of the Dragos security engineers, “This capability, methodology, and tradecraft in this very specific event may now be replicated by other adversaries and thus represents an addition to industrial asset owner and operator’s threat models.”
QUESTIONS ARISE
Because we’re operating with limited knowledge about Triton, a number of serious lines of investigation remain wide open. The questions that need answers soon include:
- Triton was designed to work with Triconex safety controllers. Are there variations of the malware that are suited for other similar SIS (safety instrumented systems) controllers?
- How many other Triton installations are embedded elsewhere?
- If there are others, how long have they been in place, and what have the hackers learned from them?
- Industrial plants are now embedding connectivity in all kinds of equipment. Will this industrial internet of things make plants more vulnerable to malware like Triton?
- Who owns the Triton (Trisis) software?
You can download the Dragos white paper Trisis Malware: Analysis of Safety System Targeted Malware. It includes a 19-page summary of how Triton works, what plants are most at risk, and what you should do as a risk officer, CTO, or owner.
