SINGAPORE – The group behind the Triton malware, which first came to light after a disruptive critical-infrastructure attack on Saudi oil giant Petro Rabigh in 2017, has found a second victim.
According to researchers at FireEye, the cybercriminals behind Triton, also called Trisis, have once again targeted industrial control systems (ICS), this time at an undisclosed company in the Middle East. Further, FireEye has taken the additional step of linking Triton with high confidence to Russian state-sponsored hackers.
A Little Background
Triton takes its name from the fact that it targets Triconex safety instrumented system (SIS) controllers, which are sold by Schneider Electric. These are responsible for shutting down plant operations in the event of a problem and act as an automated safety defense for industrial facilities, designed to prevent equipment failure and catastrophic incidents such as explosions or fire.
According to FireEye, Triton masquerades as a legitimate Triconex Trilog application used for reviewing system logs. “The malware was delivered as a Py2EXE compiled python script dependent on a zip file containing standard Python libraries, open source libraries, as well as the attacker-developed Triconex attack framework for interacting with the Triconex controllers,” researchers wrote back in 2017.
Triton thus appears to have been developed to disable plant safety and failsafe mechanisms, opening the door to physical attacks on infrastructure and possibly loss of life. FireEye added that in a less disastrous scenario, the malware can also be used to shut down the Triconex SIS process that is in a safe state, thus disrupting plant operations and causing service downtime.
The ability to affect the physical process of critical infrastructure puts Triton in rarified company with Stuxnet and the Industroyer/Crash Override malware that affected the Ukraine energy grid. Fortunately, until now, there has only been the one 2017 incident, which resulted in other safety systems shutting down a refinery before real damage could be done.
The New Attack
In this second attack, which is still being actively remediated, the adversaries were lurking in the target network for almost a year before gaining access to a engineering workstation, according to FireEye research released at the Security Analyst Summit 2019 in this week. Throughout that period, the adversaries appeared to prioritize operational security, to remain off the radar screen, researchers said.
“[Often,] malware like Triton is deployed, and the adversaries … wait for the right time to use it,” according to the analysis. “During this time, the attacker must ensure continued access to the target environment.”
The Triton actors are following a common pattern seen in sophisticated ICS-related intrusions: Moving from corporate IT to operational technology (OT) networks, through systems that are accessible to both environments. FireEye’s analysis showed that in this second incident, after establishing an initial foothold on the corporate network, the Triton actors focused most of their efforts on gaining access to the OT network. The actor leveraged dozens of never-seen-before custom intrusion tools to do just that.
“The actor’s custom tools frequently mirrored the functionality of commodity tools and appear to be developed with a focus on anti-virus evasion,” according to the FireEye report, released Wednesday at the Security Analyst Summit (SAS) 2019 in Singapore and shared with Threatpost ahead of publication. “The group often leveraged custom tools when they appeared to be struggling with anti-virus detection, or were at a critical phase in the intrusion (e.g., they switched to custom backdoors in IT and OT DMZ right before gaining access to the engineering workstation).”
In some instances, the actor used a blend of both custom and commodity tools; for instance, FireEye observed the use of Mimikatz (public) and SecHack (custom) for credential harvesting; both tools provide a very similar output.
Some of these tools appear to date back to 2014 – an interesting breadcrumb in tracking Triton’s evolution – and where it’s going. “It is worth noting that FireEye had never before encountered any of the actor’s custom tools, despite the fact that many of them date to several years before the initial compromise,” according to the report. “This fact and the actor’s demonstrated interest in operational security suggests there may be other target environments.”
Across the board, the attackers avoided overt espionage activities such as using key loggers and screenshot grabbers, browsing files, and/or exfiltrating large amounts of information, FireEye noted.
“Most of the attack tools they used were focused on network reconnaissance, lateral movement and maintaining presence in the target environment,” according to the research. “The actor gained a foothold on the distributed control system (DCS) but did not leverage that access to learn about plant operations, exfiltrate sensitive information, tamper with the DCS controllers, or manipulate the process. They then gained access to an SIS engineering workstation. From this point forward, they focused most of their effort on delivering and refining a backdoor payload using the Triton attack framework.”
The analysis also shows that the attackers used multiple techniques to hide their activities, cover their tracks and deter forensic examination of their tools and activities. For instance, they renamed their files to make them look like legitimate files like Microsoft update files or a legitimate Schneider Electric application; they also routinely used standard tools that would mimic legitimate administrator activities, including the heavy use of RDP and PsExec/WinRM. And when planting web shells on the Outlook Exchange servers, they modified already existing legitimate flogon.js and logoff.aspx files.
“They [also] attempted to reduce the chance of being observed during higher-risk activities by interacting with target controllers during off-hour times,” the report said. “This would ensure fewer workers were on site to react to potential alarms caused by controller manipulation.”
The analysts have not revealed yet what, if any, damage was caused in the attack. And, they said that much remains unknown about the malware itself.
“The Triton intrusion is shrouded in mystery,” according to the report. “There has been some public discussion surrounding the Triton framework and its impact at the target site, yet little to no information has been shared on the tactics, techniques and procedures (TTPs) related to the intrusion lifecycle, or how the attack made it deep enough to impact the industrial processes.”
FireEye has previously attributed the intrusion activity to a Russian government-owned technical research institute in Moscow.
Don’t miss our free Threatpost webinar, “Data Security in the Cloud,” on April 24 at 2 p.m. ET.
A panel of experts will join Threatpost senior editor Tara Seals to discuss how to lock down data when the traditional network perimeter is no longer in place. They will discuss how the adoption of cloud services presents new security challenges, including ideas and best practices for locking down this new architecture; whether managed or in-house security is the way to go; and ancillary dimensions, like SD-WAN and IaaS.
