A cyberattack leveraging a variant of the destructive Industroyer framework against a Ukrainian electricity provider was foiled on Friday. Researchers from ESET and CERT-UA, Ukraine's cyber emergency response team, have linked the malware to the Sandworm APT group, a Russian state-sponsored outfit charged with carrying out the 2016 attacks against Ukraine's power grid that left a portion of the country in the dark.
The variant, named Industroyer2, was purpose-built to target industrial equipment communicating over IEC-104 (IEC 60870-5-104), in this case, power system automation applications used in high voltage electrical substations. ESET and CERT-UA said the variant was built using the same source code as the original Industroyer, also known as CrashOverride.
This is the latest documented cyberattack carried out by Russia against Ukrainian critical infrastructure since Russia's invasion began on Feb. 24; the Russian military is alleged to be behind attacks against satellite communications devices in Ukraine. In the weeks preceding the war in Ukraine, Russia is also said to have carried out numerous wiper malware attacks against government entities in Ukraine. This is the first known attempt to combine cyber and kinetic tactics during a time of war.
ESET and CERT-UA published reports today describing the capabilities of the new Industroyer variant based on an investigation of an incident at a Ukrainian electricity provider. The malware, a Windows executable, was scheduled to launch last Friday; it was compiled on March 23, ESET said. While the original Industroyer was a modular platform and could interact over various industrial control system protocols, Industroyer2 had a much narrower focus in keeping to IEC-104.
"Industroyer2 is highly configurable. It contains a detailed configuration hardcoded in its body, driving the malware actions. This is different from Industroyer that stores configuration in a separate .INI file," ESET said in its report. "Thus, attackers need to recompile Industroyer2 for each new victim or environment. However, given that the Industroyer malware family has only been deployed twice, with a five year gap between each version, this is probably not a limitation for Sandworm operators."
Industroyer2 is capable of communicating with multiple ICS devices simultaneously, and analysis exposed several configuration values including the ASDU address, IOA, timeouts, and more. The malware terminates legitimate processes and renames applications in order to prevent automatic restarts of the targeted processes.
ESET believes the attackers are able to use Industroyer2 to control these processes and disconnect power to users in the country.
By contrast, the original Industroyer contained four payload components designed to target distribution substation switches and circuit breakers. Each component supported different communication protocols: IEC 60870-5-101, IEC 60870-5-104, IEC 61850, and OPC DA. The original malware's authors knew their targets well and used two backdoors for persistence, and a launcher to execute payloads for each protocol, and wiper malware.
Industroyer2 was also capable of launching wiper malware called CaddyWiper, used in cyberattacks against a Ukrainian bank. The wiper malware corrupts hardware on compromised machines, and ESET said it would slow down recovery and also impede forensic investigations into any incidents where Industroyer2 was used.
CaddyWiper was built to spread via Group Policy Objects, meaning the attackers had already gained an initial foothold on the bank and power provider's Active Directory deployments; a PowerShell script called POWERGAP was discovered that enumerated GPOs using the Active Directory Service Interface. The GPO would download file destructor components, according to CERT-UA, from a domain controller and create a scheduled task on a compromised machine.
Two other malicious components were also found on the Industroyer2 framework: first is a worm (file name sc.sh) that spread over SSH tunnels using a list of pre-obtained credentials that would eventually launch Linux and Solaris versions of CaddyWiper.
"It is known that the victim organization suffered two waves of attacks," CERT-UA wrote in its analysis. "The initial compromise took place no later than February 2022. The disconnection of electrical substations and the decommissioning of the company's infrastructure was scheduled for Friday evening, April 8, 2022. At the same time, the implementation of the malicious plan has so far been prevented."
CERT-UA published an extensive list of indicators of compromise, including hashes of files, a list of hosts and executables, malicious IP addresses, and more.
CWE-345 INSUFFICIENT VERIFICATION OF DATA AUTHENTICITY:
In 2N Access Commander versions 3.1.1.2 and prior, a local attacker can escalate their privileges in the system which could allow for arbitrary code execution with root permissions.
Update to Access Commander version 3.2.
CVSS v3: 4.7
CWE-345 INSUFFICIENT VERIFICATION OF DATA AUTHENTICITY:
In 2N Access Commander versions 3.1.1.2 and prior, an Insufficient Verification of Data Authenticity vulnerability could allow an attacker to escalate their privileges and gain root access to the system.
Update to Access Commander version 3.2.
CVSS v3: 6.3
CWE-22 IMPROPER LIMITATION OF A PATHNAME TO A RESTRICTED DIRECTORY ('PATH TRAVERSAL'):
In 2N Access Commander versions 3.1.1.2 and prior, a Path Traversal vulnerability could allow an attacker to write files on the filesystem to achieve arbitrary remote code execution.
Update to Access Commander version 3.2.
CVSS v3: 7.2
CWE-290: AUTHENTICATION BYPASS BY SPOOFING
Snap One OVRC cloud uses the MAC address as an identifier to provide information when requested. An attacker can impersonate other devices by supplying enumerated MAC addresses and receive sensitive information about the device.
Read more: "The Problem with IoT Cloud Connectivity and How it Exposed All OvrC Devices to Hijacking"
CVSS v3: 7.5
CWE-306: MISSING AUTHENTICATION FOR CRITICAL FUNCTION
A vulnerability exists in Snap One OVRC cloud where an attacker can impersonate a Hub device and send requests to claim and unclaimed devices. The attacker only needs to provide the MAC address of the targeted device and can make a request to unclaim it from its original connection and make a request to claim it.
OvrC Pro: All versions prior to 7.3 are affected.
Read more: "The Problem with IoT Cloud Connectivity and How it Exposed All OvrC Devices to Hijacking"
CVSS v3: 9.1