A few months ago, the world learned of a targeted cyberattack on a petrochemical facility in Saudi Arabia.
Now known as TRITON, the Stuxnet-like attack shut down the facility—and allowed the attackers to gain control of a critical safety system that provides emergency shutdown of plant processes.
These Safety Instrumented Systems (SIS) are designed to avoid catastrophic safety and environmental damage when certain thresholds are reached, such as an oil storage tank that reaches dangerous temperature or pressure levels.
Although TRITON was a targeted attack specifically designed to compromise a particular model and firmware revision level of Triconex SIS devices manufactured by Schneider Electric, the tradecraft exhibited by the attackers is now available to other adversaries who can quickly learn from it to design similar malware attacking a broader range of environments, controller types, and industrial automation manufacturers.
We speculate that the purpose of the attack was to disable the safety system in order to lay the groundwork for a 2nd cyberattack that would cause catastrophic damage to the facility itself, potentially causing large-scale environmental damage and loss of human life. We’re fortunate that the attack failed because the attackers made the mistake of testing buggy malware code in a production environment.
This caused a fair amount of disruption to the asset owner by shutting down the production facility but did not cause any further damage.
Sophisticated Multi-Stage Attack
The attack appears to have been carefully planned and occurred in a number of stages.
In the first phase, the attackers gained access to the industrial control system (ICS) network in order to perform cyber reconnaissance of the environment. We don’t know exactly how this occurred, but a common approach is to use an email phishing attack to compromise the credentials of a control engineer who has remote access to the ICS network, such as a 3rd-party contractor or industrial automation vendor that performs remote management and maintenance of the equipment.
The next step was to compromise a Windows-based engineering workstation in the environment. Again, we don’t know precisely how this occurred, but we can surmise that the attackers may have exploited an unpatched Windows vulnerability to gain control of the workstation. Windows-based systems are rarely patched in many ICS environments; to make matters worse, many are still running older versions of Windows for which security patches are no longer available.
In fact, in our “Global ICS & IIoT Risk Report,” which analyzed real-world network traffic from 375 production ICS networks worldwide, we found that 3 out of 4 industrial sites are still running older versions of Windows such as Windows XP and Windows 2000. (It’s also possible the attackers exploited a zero-day Windows vulnerability for which a patch has not yet been released.)
We surmise that the attackers then used the engineering workstation as a launching point for cyber reconnaissance operations in order to determine the exact manufacturer, model numbers, and firmware revision levels of the safety controllers. (Of course, this could also have been achieved using a compromised insider.)
The final step was compromising the safety controller itself.
Anatomy of the TRITON Malware
The attackers developed custom modules to communicate with the controller using the same protocol the TriStation TS311 software itself uses to communicate with the Triconex controllers from the engineering workstation.
Their principal achievement was to exploit a zero-day in the controller firmware in order to inject a Remote Access Trojan (RAT) into the firmware memory region of the controller without interrupting its normal operation and without being detected.
We believe the purpose of the RAT was to enable persistent access to the controller, even when the physical key was turned to RUN mode—which is designed to prevent unauthorized updates to the PLC code—rather than PROGRAM mode. This is why we believe that this attack was merely the first phase of a much larger planned attack.
In order to test the backdoor and the functionality of the injection—which required precise knowledge of the memory offsets in the firmware—the attackers must have had the exact same hardware and firmware (with the right revision level) available in their physical lab environment to test it.
This also demonstrates once again that extensive preparation was required, at a level which we’ve only previously seen associated with nation-state attacks such as Stuxnet and Industroyer (the targeted ICS malware used in the Ukrainian grid attack of 2016).
How to Defend Against Similar Attacks in the Future
There are a number of best practices that oil and gas organizations can implement to protect themselves from similar attacks in the future, including:
- Deploy safety controllers on isolated networks that can’t be reached from the production network. However, this isn’t always feasible due to practical considerations.
- Implement physical controls such as locked cabinets to prevent unauthorized personnel from having physical access to the controllers.
- Only switch the physical key to “PROGRAM” when necessary, such as during scheduled programming events.
- Scan all laptops and removable devices (USB drives, etc.) for malware before connecting them to the production or safety network.
- Identify the most likely attack paths to your most critical assets—and mitigate vulnerabilities enabling attackers to exploit them. (Some vendors offer automated threat modeling to accomplish this.)
- Implement continuous monitoring with behavioral anomaly detection to immediately alert on unusual activities such as:
- Unauthorized scanning of the network, which can indicate cyber reconnaissance operations.
- Unauthorized changes to controllers, such as uploading new firmware or ladder logic code.
- Protocol violations indicating malicious attempts to compromise devices, for example, by causing a buffer overflow condition, using unpermitted packet structures or field values.
- Known malware behaviors (TRITON, WannaCry, NotPetya, Havex, Industroyer, Conficker, etc.).
Fortunately, modern ICS cybersecurity systems have evolved to the point where we can now use passive network monitoring (which has zero impact on the ICS network) and detailed packet dissection of ICS protocols, combined with advanced self-learning algorithms, to detect this type of anomalous activity in real-time—without relying on rules, specialized skills, or prior knowledge of the environment.