Attacks/Breaches

10/23/2018
03:55 PM
Connect Directly
Twitter
LinkedIn
RSS
E-Mail
50%
50%

Russian Research Institute Was Actively Involved In TRITON ICS Attack Activity

Data shows with a high degree of confidence that Moscow-based Central Scientific Research Institute of Chemistry and Mechanics helped develop and refine malware, FireEye says.

Late last year, a cyberattacker inadvertently shut down operations at a Saudi Arabian petrochemical plant while testing a highly sophisticated malware tool for manipulating its industrial safety systems.

In a new report this week, security vendor FireEye says it is now able to say with near certainty that a Russian government-backed research institute was involved in the attack, though the full extent of its involvement remains somewhat unclear.

The intrusion at the Middle East industrial facility attracted considerable attention for its use of TRITON, one of the few publicly known malware frameworks employed specifically for use against industrial control systems (ICS). TRITON, in fact, remains one of only three known instances of its type of malware. The other two are Stuxnet, which was used to destroy centrifuges at Iran's Natanz nuclear facility in 2010, and Industroyer, deployed in 2016 against Ukraine's power grid.

FireEye says its analysis shows that the Moscow-based Central Scientific Research Institute of Chemistry and Mechanics (CNIIHM) was involved in the activity that led to the deployment of TRITON on a Schneider Electric industrial safety system at the Saudi plant. The malware was designed to manipulate the behavior of the system in such a manner as to trigger conditions that could cause physical damage at the petrochemical plant in the same way Stuxnet did to Iran's nuclear processing facility. The attack came to light because something went awry and triggered an emergency shutdown at the Saudi plant.

FireEye says it has discovered several data points to support its assessment of CNIIHM's involvement in the intrusion with a high degree of confidence.

One of the biggest is an IP address registered to CNIIHM that was used for multiple purposes related to the attack, including network reconnaissance and specific malicious activity tied to  TRITON. Another clue is that a lot of the observed malicious behavior occurred during time periods consistent with the Moscow time zone, where CNIIHM is located. Significantly, CNIIHM also has the expertise and skill required to orchestrate and help execute the development and deployment of TRITON.

"The malware they used during the intrusion was being refined in a sort of testing environment that we could observe," says John Hultquist, director intelligence analysis at FireEye. Investigation of that activity shows direct ties to CNIIHM and a particular individual in Moscow with specific connections to the research institute.

One of CNIIHM's roles appears to have been to basically try and refine the malware to a point where it wasn't being caught by antimalware tools at the target organization, Hultquist notes. "While they were testing this stuff, we did see them go back and forth from the testing environment to the target, which basically indicated to us [CNIIHM's involvement]," he says.

There is little doubt that the Russian technical research institute supported the development and subsequent refinement of the TRITON malware, though it is possible that others were involved, as well, Hultquist says. "They were a lot less consistent with operational security and left a lot of artifacts that indicated their involvement," he explains.

While it is theoretically possible that someone within CNIIHM is involved in the TRITON activity without the knowledge or approval of the institute, that seems highly unlikely, FireEye said in its report.

Hultquist says FireEye's research confirms that Russian threat actors have the capability to target ICS systems with malware capable of causing physical damage. "We have seen Russian actors repeatedly demonstrating motive and intent," he says. "They have had a history of carrying out aggressive [cyber] activity." That means organizations have to be prepared.

Dave Weinstein, vice president of threat research at Claroty, says FireEye's report underscores the degree of complexity tied to the TRITON malware framework. Researchers have known for some time that only a highly resourced actor could have pulled off the attack; the FireEye analysis, if accurate, would validate that assumption, he says.

From a geopolitical standpoint, it will be interesting to see how the latest revelations play out, especially given the current relationship between the US and Russia.

For enterprises, this attribution doesn't change much, Weinstein says. "Organizations that operate ICS systems are less interested in the 'who' and more in the 'how' [of an attack]," he says.

Fortunately, for the moment at least, the barriers to entry remain high for those wanting to pull off TRITON-like attacks. And nation-states like Russia that have the ability to develop and execute such attacks are generally bound by some degree of deterrence. "It is not necessarily in the interest of a threat actor to actually execute these tools" given the potential for retaliation, Weinstein says.

Related Content:

 

Black Hat Europe returns to London Dec 3-6 2018  with hands-on technical Trainings, cutting-edge Briefings, Arsenal open-source tool demonstrations, top-tier security solutions and service providers in the Business Hall. Click for information on the conference and to register.

Jai Vijayan is a seasoned technology reporter with over 20 years of experience in IT trade journalism. He was most recently a Senior Editor at Computerworld, where he covered information security and data privacy issues for the publication. Over the course of his 20-year ... View Full Bio

Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
How the US Chooses Which Zero-Day Vulnerabilities to Stockpile
Ricardo Arroyo, Senior Technical Product Manager, Watchguard Technologies,  1/16/2019
Register for Dark Reading Newsletters
White Papers
Video
Cartoon Contest
Write a Caption, Win a Starbucks Card! Click Here
Latest Comment: "He just showed up at my doorstep one day without a geotag."
Current Issue
The Year in Security 2018
This Dark Reading Tech Digest explores the biggest news stories of 2018 that shaped the cybersecurity landscape.
Flash Poll
How Enterprises Are Attacking the Cybersecurity Problem
How Enterprises Are Attacking the Cybersecurity Problem
Data breach fears and the need to comply with regulations such as GDPR are two major drivers increased spending on security products and technologies. But other factors are contributing to the trend as well. Find out more about how enterprises are attacking the cybersecurity problem by reading our report today.
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2019-3906
PUBLISHED: 2019-01-18
Premisys Identicard version 3.1.190 contains hardcoded credentials in the WCF service on port 9003. An authenticated remote attacker can use these credentials to access the badge system database and modify its contents.
CVE-2019-3907
PUBLISHED: 2019-01-18
Premisys Identicard version 3.1.190 stores user credentials and other sensitive information with a known weak encryption method (MD5 hash of a salt and password).
CVE-2019-3908
PUBLISHED: 2019-01-18
Premisys Identicard version 3.1.190 stores backup files as encrypted zip files. The password to the zip is hard-coded and unchangeable. An attacker with access to these backups can decrypt them and obtain sensitive data.
CVE-2019-3909
PUBLISHED: 2019-01-18
Premisys Identicard version 3.1.190 database uses default credentials. Users are unable to change the credentials without vendor intervention.
CVE-2019-3910
PUBLISHED: 2019-01-18
Crestron AM-100 before firmware version 1.6.0.2 contains an authentication bypass in the web interface's return.cgi script. Unauthenticated remote users can use the bypass to access some administrator functionality such as configuring update sources and rebooting the device.