There was evidently a cybersecurity incident spotted yesterday. There was a report on FireEye quoted below. I also received this statement from CyberX. I am not primarily a cybersecurity writer, but this is significant.
“We have information that points to Saudi Arabia as the likely target of this attack, which would indicate Iran as the likely attacker. It’s widely believed that Iran was responsible for destructive attacks on Saudi Arabian IT networks in 2012 and more recently in 2017 with Shamoon, which destroyed ordinary PCs. This would definitely be an escalation of that threat because now we’re talking about critical infrastructure — but it’s also a logical next step for the adversary. Stuxnet and more recently Industroyer showed that modern industrial malware can be used to reprogram and manipulate critical devices such as industrial controllers, and TRITON appears to be simply an evolution of those approaches.” Phil Neray, VP of Industrial Cybersecurity for CyberX, a Boston-based industrial cybersecurity firm.
From the FireEye report (see complete analysis on its Website).
Mandiant recently responded to an incident at a critical infrastructure organization where an attacker deployed malware designed to manipulate industrial safety systems. The targeted systems provided emergency shutdown capability for industrial processes. We assess with moderate confidence that the attacker was developing the capability to cause physical damage and inadvertently shutdown operations. This malware, which we call TRITON, is an attack framework built to interact with Triconex Safety Instrumented System (SIS) controllers. We have not attributed the incident to a threat actor, though we believe the activity is consistent with a nation state preparing for an attack.
TRITON is one of a limited number of publicly identified malicious software families targeted at industrial control systems (ICS). It follows Stuxnet which was used against Iran in 2010 and Industroyer which we believe was deployed by Sandworm Team against Ukraine in 2016. TRITON is consistent with these attacks, in that it could prevent safety mechanisms from executing their intended function, resulting in a physical consequence.
The attacker gained remote access to an SIS engineering workstation and deployed the TRITON attack framework to reprogram the SIS controllers. During the incident, some SIS controllers entered a failed safe state, which automatically shutdown the industrial process and prompted the asset owner to initiate an investigation. The investigation found that the SIS controllers initiated a safe shutdown when application code between redundant processing units failed a validation check — resulting in an MP diagnostic failure message.
We assess with moderate confidence that the attacker inadvertently shutdown operations while developing the ability to cause physical damage for the following reasons:
Modifying the SIS could prevent it from functioning correctly, increasing the likelihood of a failure that would result in physical consequences.
TRITON was used to modify application memory on SIS controllers in the environment, which could have led to a failed validation check.
The failure occurred during the time period when TRITON was used.
It is not likely that existing or external conditions, in isolation, caused a fault during the time of the incident.
The TRITON attack tool was built with a number of features, including the ability to read and write programs, read and write individual functions and query the state of the SIS controller. However, only some of these capabilities were leveraged in the trilog.exe sample (e.g. the attacker did not leverage all of TRITON’s extensive reconnaissance capabilities).
The TRITON malware contained the capability to communicate with Triconex SIS controllers (e.g. send specific commands such as halt or read its memory content) and remotely reprogram them with an attacker-defined payload. The TRITON sample Mandiant analyzed added an attacker-provided program to the execution table of the Triconex controller. This sample left legitimate programs in place, expecting the controller to continue operating without a fault or exception. If the controller failed, TRITON would attempt to return it to a running state. If the controller did not recover within a defined time window, this sample would overwrite the malicious program with invalid data to cover its tracks.
Trackbacks/Pingbacks