Dragos says CosmicEnergy malware is not ‘immediate threat’ to ICS, provides recommendations
Threat intelligence team at industrial cybersecurity company Dragos disclosed that CosmicEnergy is not an immediate threat to operational technology (OT), as the overall codebase of CosmicEnergy lacks maturity, contains errors and is far from being a full-fledged attack capability like Industroyer2 or CrashOverride. It added that there is no evidence that CosmicEnergy is being deployed in the wild, and analysis indicates that the tool is likely part of a training exercise or for use in detection development.
Following the reveal by Mandiant last month, Dragos said in a blog post that “this malware, designed to target IEC 104 devices, exploits existing Microsoft SQL (MS SQL) servers that are connected to remote terminal units (RTUs). Dragos Threat Intelligence independently analyzed the malware and, counter to media headlines claiming power disruption or grid crippling abilities, concluded that CosmicEnergy is not an immediate threat to operational technology.”
Dragos also said that operators should reach out to vendors to see if software packages include MS SQL. Additionally, operators should ensure they have network monitoring in place, watch for ‘xp cmdshell’ alerts, and out of an abundance of caution, audit their MS SQL Servers.
Addressing CosmicEnergy, Dragos found indications that it is a training tool with coding errors and a lack of development maturity to lessen its potential risk. Its discovery hints at a trend, also witnessed in Pipedream, towards developers leveraging known standard ICS protocols to achieve an effect and incorporating open-source projects like ‘lib60870-C’ to implement their tools.
Even though there’s no evidence that CosmicEnergy is being deployed, its existence should prompt all organizations to reassess their firewall rules and configurations and ensure they have visibility into the ICS protocols traversing their network, Dragos said in its post. “This is the third discovery of IEC104 targeted tooling, so organizations should take notice and implement good security posture to raise the probability of detecting and mitigating potential future attacks,” it added.
Dragos analyzed CosmicEnergy, which is composed of two malware samples, Piehop and Lightwork. Piehop is a PyInstaller binary. PyInstaller bundles a Python application and all its dependencies into a single package. The user can run the packaged app without installing a Python interpreter or any modules. Upon execution, like any PyInstaller binary, Piehop unpacks all the required files and dependencies for the main Python program’s execution, which in this case includes the Lightwork binary.
The post added that after Lightwork executes, Piehop can check the results to verify whether the execution was successful, delete Lightwork from the server, and then delete itself. Piehop’s MS SQL capabilities show some resemblance to a script on GitHub, and they may have been based on that.
Dragos said that Lightwork is a native Windows executable with IEC104 capabilities. It takes an IP address via the command line and another argument dictating whether to send on or off messages to IEC104 devices. It initiates an IEC104 connection with the IP address and sends an IEC104 Single Command with either ‘on’ or ‘off,’ depending on the command line argument, to a list of hard-coded Information Object Addresses (IOAs).
“The messages here lack configuration. It can only send Single Commands, and those messages have to be all ONs or all OFFs. It’s not configured per IOA,” the post said. “Further, the Common Address of ASDU (COA) or Application Service Data Unit (ASDU) address, is hard-coded to 1 for all messages. We know that’s a lot of IEC104 jargon, so the short summary is that Lightwork is hard-coded to affect a specific IEC104 network configuration.”
The team said that Lightwork is not a variant of the CrashOverride/Industroyer2 line of malware or any other ICS malware discovered to date. “Lightwork was compiled with symbol information which means Dragos recovered all function and argument names in the binary and produced an easy-to-read decompilation. The majority of the code is from a known 60870 open-source library, lib60870-C, maintained by MZ Automation GmbH, not a custom IEC104 library like the one in CrashOverride and Industroyer2.”
Furthermore, Dragos compared the code inside of Lightwork to a reference 60870 DLL provided by a related project, ‘nim_lib60870,’ that wraps ‘lib60870-C,’ and found that 98 percent of the functions in Lightwork are the same (or very similar) to those found in the reference DLL. “Of the remaining 2 percent that didn’t match, only 1 of those functions, main, is of any importance. That function amounts to about 68 lines of decompiled code, which isn’t much. A similar comparison of Lightwork to Industroyer2 yielded no significant overlap,” the post added.
After analyzing CosmicEnergy, Dragos concluded that it is not an immediate risk to OT environments. “The primary purpose of CosmicEnergy appears to have been for training scenarios rather than for deployment in real-world environments. There is currently no evidence to suggest that an adversary is actively deploying CosmicEnergy. This conclusion is further supported by the fact that Lightwork’s COA and IOAs are hard-coded to target a specific range of equipment. For reference, both CrashOverride and Industroyer2 had configuration formats that allowed both of these IEC104 fields to change, among other parameters, the post added.
Further, Dragos outlined that “Lightwork’s original file name is ‘OT_T8 5 5_ IEC104 _GR [dot]exe’ which appears to be a reference to MITRE ATT&CK for ICS, a catalog of malware tactics and techniques frequently used by defenders. Specifically, it references technique Code T08555 or Unauthorized Command Message, which is exactly the technique implemented by the Lightwork tool. If you look at the examples, you’ll see references to both CrashOverride/Industroyer and Industroyer2’s use of IEC104. This reference to MITRE ATT&CK is also an indication that this sample may be for training, education, or perhaps detection development and testing.”
Aside from indications that the tool may not be malicious, several coding errors in Piehop prevent the malware from running properly as discovered or limit its potential flexibility. Control flow problems mean it is unable to upload Lightwork properly to the server. “If that issue is fixed, it still requires multiple executions to both upload and execute Lightwork. If code execution reaches the portion that should execute Lightwork, the code will crash due to uninitialized variables being referenced,” the post added.
While Piehop fails to run without modification, Lightwork (surprisingly) executes without crashing, Dragos identified. “However, the tool lacks development maturity and requires more work before it’s a full-fledged IEC104 attack capability. Compared with CrashOverride and Industroyer2, it appears that Lightwork’s developers know even less than their predecessors about how to use IEC104 or were simply testing to see if they could reach IEC104 equipment.”
Further, Dragos said that Lightwork cannot be configured, affecting its ability to target multiple substation addresses, different IOAs, and different types of equipment. “In its current state, each execution of Lightwork can only affect a specific range of equipment since both the IOAs and COA are hard-coded.”
Dragos added that if the Lightwork developers wanted to target a range of equipment with different IOAs, they would have to at least consider if the IOAs share the same COA, if not, then some logic changes would need to be made to support addressing IOAs with different COAs; whether the IOAs all use the same information type (single point, double point, etc), if not, logic changes need to be made to support setting different information types; and lastly, are all the devices reachable from the same RTU, otherwise, logic needs to be changed to support multiple IP addresses and specifications of the corresponding IOAs.
The post said that the developers of CrashOverride and Industroyer2 understood these questions and more, and the result was their custom configuration format. “Lightwork is very limited by comparison and requires much more development time for it to be a realistic and flexible attack capability.”
Dragos recommends that organizations to safeguard against potential threats of this nature must restrict access to engineering workstations (EWS) and OT servers running MS SQL. Increase monitoring efforts for new connections probing MS SQL servers or enabling ‘xp cmdshell’ on servers communicating with IEC104 devices. They must also restrict access to port TCP/1443 on the MS SQL host. Restrict access to port TCP/2404 on the RTUs and other IEC104 equipment.
Additionally, asset owners are encouraged to stay abreast of emerging threat behaviors, identify IEC104 devices within their network, and ensure that access to these devices and any others that can communicate with RTUs is appropriately restricted. Furthermore, any attack of this nature will require dwell time to understand the OT network and derive the appropriate COAs and IOAs.
Last month, Dragos revealed that a known cybercriminal group attempted and failed at an extortion scheme against the company. It also disclosed that ‘no Dragos systems were breached, including anything related to the Dragos Platform,’ and that its investigation is ongoing, and ‘will reach out directly if we learn of additional effects on our customers.’
A complimentary guide to the who`s who in industrial cybersecurity tech & solutions
Free DownloadRelated
