Industroyer2: Industroyer reloaded | WeLiveSecurity

This can be a creating story and the blogpost will probably be up to date as new info turns into obtainable.

Government abstract

The blogpost presents the evaluation of a cyberattack towards a Ukrainian vitality supplier.

Industroyer2: Industroyer reloaded

ESET researchers responded to a cyber-incident affecting an vitality supplier in Ukraine. We labored carefully with CERT-UA so as to remediate and defend this vital infrastructure community.

The collaboration resulted within the discovery of a brand new variant of Industroyer malware, which we along with CERT-UA named Industroyer2 – see CERT-UA publication here. Industroyer is an notorious piece of malware that was utilized in 2016 by the Sandworm APT group to chop energy in Ukraine.

On this case, the Sandworm attackers made an try and deploy the Industroyer2 malware towards high-voltage electrical substations in Ukraine.

Along with Industroyer2, Sandworm used a number of damaging malware households together with CaddyWiper, ORCSHRED, SOLOSHRED and AWFULSHRED. We first found CaddyWiper on 2022-03-14 when it was used towards a Ukrainian financial institution – see our Twitter thread about CaddyWiper. A variant of CaddyWiper was used once more on 2022-04-08 14:58 towards the Ukrainian vitality supplier beforehand talked about.

At this level, we don’t understand how attackers compromised the preliminary sufferer nor how they moved from the IT community to the Industrial Management System (ICS) community. Determine 1 reveals an outline of the completely different malware used on this assault.

Determine 2 summarizes the chain of occasions.

Determine 2. Timeline of occasions

In 2017, ESET researchers revealed {that a} piece of malware that we named Industroyer was chargeable for the facility blackout that impacted Ukraine’s capital Kiev in December 2016.

As detailed in our white paper Win32/Industroyer: A new threat for industrial control systems, it’s able to interacting with industrial management techniques sometimes present in electrical energy techniques. This consists of IEC-101, IEC-104, IEC 61850 and OPC DA units.

At the moment, we stated that “it appears most unlikely anybody may write and check such malware with out entry to the specialised gear used within the particular, focused industrial setting”. This was confirmed in 2020 by the USA authorities when six officers of the Russian Army Unit 74455 of the Principal Intelligence Directorate (GRU), have been indicted for his or her function in a number of cyberattacks together with Industroyer and NotPetya – see the indictment on justice.gov and our historical overview of Sandworm’s operations.

The lately found malware is a brand new variant of Industroyer, therefore the title Industroyer2.

Industroyer2

Industroyer2 was deployed as a single Home windows executable named 108_100.exe and executed utilizing a scheduled process on 2022-04-08 at 16:10:00 UTC. It was compiled on 2022-03-23, in line with the PE timestamp, suggesting that attackers had deliberate their assault for greater than two weeks.

Determine 3. Timestamp and compiler info

Industroyer2 solely implements the IEC-104 (aka IEC 60870-5-104) protocol to speak with industrial gear. This consists of safety relays, utilized in electrical substations. This can be a slight change from the 2016 Industroyer variant that could be a fully-modular platform with payloads for a number of ICS protocols.

Industroyer2 shares variety of code similarities with the payload 104.dll of Industroyer. We assess with excessive confidence that the brand new variant was constructed utilizing the identical supply code.

Industroyer2 is extremely configurable. It accommodates an in depth configuration hardcoded in its physique, driving the malware actions. That is completely different from Industroyer, shops configuration in a separate .INI file. Thus, attackers must recompile Industroyer2 for every new sufferer or setting. Nonetheless, on condition that the Industroyer* malware household has solely been deployed twice, with a 5 12 months hole between every model, that is in all probability not a limitation for Sandworm operators.

The brand new configuration format is saved as a string which is then provided to the IEC-104 communication routine of the malware. Industroyer2 is ready to talk with a number of units without delay. Particularly, the analyzed pattern accommodates eight completely different IP addresses of units – see Determine 4.

Determine 4. Hardcoded configuration present in Industroyer2 pattern

The configuration accommodates values which might be used throughout communication by way of IEC-104 protocol, comparable to ASDU (Utility Service Knowledge Unit) handle, Info Object Addresses (IOA), timeouts, and many others.

Earlier than connecting to the focused units, the malware terminates a legit course of that’s utilized in commonplace each day operations. Along with that, it renames this software by including .MZ to the filename. It does so so as to stop computerized re-start of this legit course of.

The evaluation remains to be ongoing so as to decide what are the precise actions taken for every gadget. We consider that this part is ready to management particular ICS techniques so as to reduce energy.

Industroyer2 can produce a log file or output its progress to the console window. Nonetheless, as an alternative of significant textual content messages as within the earlier model, the malware writes varied error codes – see Determine 5. We consider it’s an obfuscation try by Sandworm builders to hamper evaluation.

Determine 5. Output produced by Industroyer2 malware (IP addresses redacted by ESET)

CaddyWiper

In coordination with the deployment of Industroyer2 within the ICS community, the attackers deployed a brand new model of the CaddyWiper damaging malware. We consider it was meant to decelerate the restoration course of and stop operators of the vitality firm from regaining management of the ICS consoles. It was additionally deployed on the machine the place Industroyer2 was executed, prone to cowl their tracks.

The primary model of CaddyWiper was discovered by ESET researchers in Ukraine on 2022-03-14 when it was deployed within the community of a financial institution. It was deployed by way of Group Coverage Object (GPO), indicating the attackers had prior management of the goal’s community beforehand. The wiper erases person information and partition info from connected drives, making the system inoperable and unrecoverable.

New CaddyWiper loading chain

Within the community of the vitality supplier, attackers deployed a brand new model of CaddyWiper that makes use of a brand new loader, named ARGUEPATCH by CERT-UA. ARGUEPATCH is a patched model of a legit part of Hex-Rays IDA Pro software, particularly the distant IDA debugger server win32_remote.exe. IDA Professional will not be meant for use in an ICS setting, as its predominant goal is for software program reverse-engineering together with malware evaluation. We don’t know why attackers selected to trojanize this piece of software program; it could be a troll in direction of defenders.

ARGUEPATCH was executed by a scheduled process that was meant to be launched as soon as on 2022-04-08 14:58 UTC on one machine and at 16:20 UTC on the machine the place Industroyer2 was deployed.

The patched binary masses encrypted shellcode from a file and decrypts it with a key, each are supplied on command line. A single-byte XOR secret is derived from the enter key and used to decrypt the shellcode.

The decrypted shellcode is a barely modified model of CaddyWiper. A comparability of their predominant routines is supplied in Determine 6 and Determine 7. Be aware that they don’t wipe the area controller, and so they wipe C:Customers and disks from D: to [:. The wiping routine is also almost identical: it fills all files with 0.

Figure 6. Main routine of the first sample of CaddyWiper.

Figure 7. Main routine of the CaddyWiper sample deployed at the energy provider

Finally, CaddyWiper calls DeviceIoControl with IOCTL_DISK_SET_DRIVE_LAYOUT_EX and a zeroed InputBuffer for all disks from PHYSICALDRIVE9 to PHYSICALDRIVE0. This erases extended information of the drive’s partitions: the Master boot record (MBR) or the GUID Partition Table (GPT). This renders the machine unbootable.

Active Directory enumeration

Alongside CaddyWiper, a PowerShell script was found both in the energy provider network and in the bank that was compromised earlier.

This script enumerates Group Policies Objects (GPO) using the Active Directory Service Interface (ADSI). The script, shown in Figure 8, is almost identical to a snippet provided in a Medium blogpost.

We believe that attackers deployed CaddyWiper via a GPO and used the script to check the existence of this GPO.

Figure 8. PowerShell script to enumerate GPO (beautified)

Linux and Solaris destructive malware (ORCSHRED, SOLOSHRED, AWFULSHRED)

Additional destructive malware for systems running Linux and Solaris was also found on the network of the targeted energy company. There are two main components to this attack: a worm and a wiper. The latter was found in two variants, one for each of the targeted operating system. All malware was implemented in Bash.

The worm

The first component launched by the attacker was a worm, having its file named sc.sh. This Bash script starts by adding a scheduled task (cron job) to launch the wiper component at 2:58pm UTC (assuming the system is in the local time zone, UTC+3), unless it was launched with the “owner” argument. This is likely a way to avoid the initial system used to launch the worm auto-destructing.

Figure 9. Setting up the cron job to launch the wiper at 5:58pm. The correct wiper is picked depending on the installed operating system.

The script then iterates over the networks accessible by the system by looking at the result of ip route or ifconfig -a. It always assumes a class C network (/24) is reachable for each IP address it collects. It will try to connect to all hosts in those networks using SSH to TCP port 22, 2468, 24687 and 522. Once it finds a reachable SSH server, it tries credentials from a list provided with the malicious script. We believe the attacker had credentials prior to the attack to enable the spread of the wiper.

If the system is not already compromised, malware is copied to the new target, and the worm is launched. The worm is not launched with the owner argument, so the wiper is scheduled to launch at 2:58pm UTC and destroy all data. If those systems were set to the local time zone, the destruction must’ve started at the same time as the system compromised with CaddyWiper.

The Linux wiper

The Linux variant of the wiper is lightly obfuscated: variables and function names have been replaced with meaningless 8-letter words. Most literal values were also replaced with variables at the beginning of the file.

Figure 10. Except from the obfuscated script (whitespace optimized).

Figure 11. Deobfuscation of the above obtained by renaming functions and variables and using literals

Ultimately, the Linux wiper destroys the whole content of the disks attached to the system by using shred if available or simply dd (with if=/dev/random) otherwise. If multiple disks are attached, data removal is done in parallel to speed up the process.

Depending on the size, it may take hours for the full disk to be completely erased. To render the system inoperable faster, it first tries to stop and disable HTTP and SSH services. Both services are disabled by using systemctl disable. To ensure service isn’t reenabled, the systemd unit file responsible for loading the service is deleted from the disk.

Files from /boot, /home and /var/log are also removed before destroying the full drives. This makes the system inoperable faster, deletes user data and perhaps removes incriminating logs.

The malicious script’s last action is to forcibly initiate a reboot using SysRq. Since all drives are filled with random, no operating system will boot.

The Solaris wiper

Unlike the Linux wiper, the Solaris variant is not obfuscated.

Like the Linux variant, the malicious script iterates over all services to stop and disable them if they contain the keyword ssh, http, apache and additionally ora_ or oracle. Those services are very likely used by applications used to control ICS systems. Wiping them would prevent the energy company’s operators from retaking control of the substations and roll back Industroyer2 actions.

It uses either systemctl or svcadm depending on what’s available. The latter is most likely since Solaris is not running systemd.

File destruction begins by deleting databases. It removes, using shred then rm, all files and directories contained in environment variables starting with ORA. Oracle Database uses the following variables to define location of database files and software: ORACLE_BASE, ORACLE_HOME and ORACLE_PATH. Note that shred makes sure data recovery (without a backup) isn’t possible.

Like the Linux variant, files in /boot, /home and /var/log are deleted with priority.

Then the script iterates over disks connected to the system, found in /dev/dsk/. It ignores slices (partitions) and work only on full disks. For each of them, the malicious script overwrites the full content using shred. To minimize the time required to perform the wipe, all disks are erased in parallel.

Lastly, the script self-destructs.

Conclusion

Ukraine is once again at the center of cyberattacks targeting their critical infrastructure. This new Industroyer campaign follows multiple waves of wipers that have been targeting various sectors in Ukraine. ESET researchers will continue to monitor the threat landscape in order to better protect organizations from these types of destructive attacks.

And a big thanks to @_CERT_UA who worked with us on this case and provided samples. You can read their advisory on this campaign here.

Indicators of Compromise