Welcome to the May 2022 SCYTHE #ThreatThursday! This month we are featuring the recent Industroyer2 operation observed in Ukraine with a new campaign. Per the reporting from ESET, the Sandworm threat actor group was most likely responsible for deploying the Industroyer2 malware. For more information on the Sandworm group (in an easily digestible format), see Andy Greenberg’s book Sandworm linked here.
There have been several attempts to disrupt Ukraine’s power grid since conflict began in its Eastern region early 20141. Russian-attributed threat actors deployed wiper malware against Ukrainian utilities in December 2015, targeting multiple power distribution substations. In December 2016, another cyberattack attributed to Russia used the original Industroyer malware (aka Crashoverride) to target utility transmission networks. ESET researchers who analyzed the original Industroyer malware assessed that the malware discovered by UA-CERT in 2022 has many of the same toolmarks. Although ESET has not shared the malware publicly, based on ESET’s historically reliable reporting we assert with high confidence that the Industroyer2 malware shares a common lineage with Industroyer.
This adversarial emulation campaign does not attempt to communicate with any Operational Technology (OT) or Industrial Control Systems (ICS) equipment. The campaign creates various artifacts on systems that were seen used by the Sandworm threat actor during deployment of Industroyer2 (as reported by UA-CERT).
Industroyer2 is a malware variant that is a more targeted version of Industroyer and its use has been linked to the threat actor known as Sandworm. Malpedia reports that Sandworm has been known to target ICS networks, including those associated with electricity and power generation2. This group has previously been linked to attacks on the Ukraine power grid in 2015 and 20163 and association with a Russian cyber military unit of the GRU.
Unit 74455, Black Energy,Voodoo Bear, Iron Viking
Industroyer2 is slightly more narrowly scoped than the original Industroyer. The original malware had 4 distinct modules targeting specific ICS communication protocols (IEC 60870-5-101, IEC 60870-5-104, IEC 61850, and OLE for Process Control Data Access (OPC DA))4. Industroyer2, by contrast, is a standalone executable targeting IEC-104 controllers exclusively5. IEC-104 is used for power system monitoring and control over TCP and is mainly implemented in Europe and the Middle East.
We assess that a nation-state level threat actor (Sandworm) is leveraging Industroyer2 in an attempt to disrupt Ukraine’s critical infrastructure in support of Russia’s ongoing military operations. Per reporting by UA-CERT, the intrusion was discovered before destructive payloads were deployed against utility infrastructure.
Industroyer 2 is highly configurable. Notable changes include the ability for the threat actor to embed customized configurations within the malware6. Unlike its predecessor, detailed configurations are hardcoded in its body rather than stored in a separate .INI file.
Industroyer2 also features process termination capability. Prior to connecting to targeted devices it will terminate a legitimate process, and append .MZ to the file name to prevent a re-start of said process7.
Once connected, Industroyer2 can craft various IEC-104 Application Service Data Unit (ADSU) messages to change the state of a remote device’s Information Object Addresses (IOAs) to ON or OFF. The level of detail in configuration, down to specific IOAs for a remote station, provide perspective into the comprehensive understanding of and potential visibility into a victim environment6.
Note: Because SCYTHE campaigns are crafted to be safe to execute in production environments, this campaign does not attempt to communicate with any ICS or OT devices. The capabilities discussed above are for reference only, as identified in the cited reports.
The table below summarizes the actions taken by the Industroyer2 campaign. Per ESET reporting, the ARGUEPATCH binary loads obfuscated shellcode specified by a filename argument into memory. This version of the SCYTHE campaign does not simulate this behavior. Instead, the SCYTHE platform is used to create a random file consistent with the filenames in the UA CERT reporting and uses these filenames parameters to the benign executable used for testing.
Depending on your audit configuration, you may see event ID 4698 (new scheduled task creation) in the Security event log.
If the TaskScheduler/Operational log is enabled, additional logs showing the creation and execution of the scheduled tasks may also be present.
If Process Auditing is configured, event ID 4688 will track processes created (including those created by the scheduled tasks). If Sysmon is installed, process creation may also be logged in the Sysmon/Operational event log using event ID 1.
If file creation is monitored (e.g. object access) in the C:\windows\system32\tasks directory, the three scheduled tasks created (Nezla, 40115, and vatt) files should be detected. Additionally, the registry saved hives and lsass memory dump are all written into C:\users\public and might be logged with file creation monitoring.
PowerShell logging may capture the PowerShell creation of scheduled tasks and the attempts to reach the suspected C2 IPs. Detection engineers should not focus on any PowerShell detections since we do not have sufficient information from UA-CERT that PowerShell was the method used to create the scheduled tasks.
The following SIGMA rules can be used for detection of actions taken in this campaign:
Additionally, this pattern can be used in command execution logs to discover executables running from an odd location (in this case C:\users\public):
Note: the campaign performs a directory listing of the C:\ before any directories are created. This allows the operator to confidently remove C:\dell and/or C:\temp knowing they were created exclusively by the SCYTHE campaign.
We have created a separate clean-up campaign with the above steps. You may run this separately or combine with the Industroyer2 campaign.
If any of the alerts are detected in the environment, the response team should determine the depth of the Kill Chain, collect artifacts, and answer the following questions:
Once it has been determined how deep the intrusion goes, containment, eradication, and recovery should begin. After recovery, lessons learned should drive additional courses of action (COAs) to thwart the threat should it return, such as implementing additional security controls. As always, please follow your organization's response plan and evidence retention policies. We also recommend leveraging NIST SP 800-61 Rev. 2.
This Threat Thursday post discusses active research by SCYTHE and other cited third parties into an ongoing threat. The information in this post should be considered preliminary and may be updated as research continues. This information is provided “as-is” without any warranty or condition of any kind, either express or implied.
The SCYTHE CTI team, including Jake Williams, Kristen Cotten, and Nathali Cano contributed to this report. Christopher Peacock assisted with QA and performed detection engineering.
SCYTHE provides an advanced attack emulation platform for the enterprise and cybersecurity consulting market. The SCYTHE platform enables Red, Blue, and Purple teams to build and emulate real-world adversarial campaigns in a matter of minutes. Customers are in turn enabled to validate the risk posture and exposure of their business and employees and the performance of enterprise security teams and existing security solutions. Based in Arlington, VA, the company is privately held and is funded by Gula Tech Adventures, Paladin Capital, Evolution Equity, and private industry investors.