{ "id": "8e629e4d-a17e-4512-a78b-4a7c39e8bfac", "created_at": "2026-04-06T00:12:13.182156Z", "updated_at": "2026-04-10T03:30:30.28305Z", "deleted_at": null, "sha1_hash": "3d39a49d3c3e0fdb3484998fb12c1319639166a7", "title": "Industroyer2: Industroyer reloaded", "llm_title": "", "authors": "", "file_creation_date": "0001-01-01T00:00:00Z", "file_modification_date": "0001-01-01T00:00:00Z", "file_size": 1244171, "plain_text": "Industroyer2: Industroyer reloaded\r\nPublished: 2022-04-12 · Archived: 2026-04-05 22:55:30 UTC\r\nThis ICS-capable malware targets a Ukrainian energy company.\r\nExecutive summary\r\nThe blogpost presents the analysis of a cyberattack against a Ukrainian energy provider.\r\nKey points:\r\nESET researchers collaborated with CERT-UA to analyze the attack against the Ukrainian energy company\r\nThe destructive actions were scheduled for 2022-04-08 but artefacts suggest that the attack had been\r\nplanned for at least two weeks\r\nThe attack used an ICS-capable malware and regular disk wipers for Windows, Linux and Solaris operating\r\nsystems\r\nWe assess with high confidence that the attackers used a new version of the Industroyer malware, which\r\nwas used in 2016 to cut power in Ukraine\r\nWe assess with high confidence that the APT group Sandworm is responsible for this new attack\r\nESET researchers responded to a cyber-incident affecting an energy provider in Ukraine. We worked closely\r\nwith CERT-UA in order to remediate and protect their network.\r\nhttps://blog.eset.ie/2022/04/12/industroyer2-industroyer-reloaded/\r\nPage 1 of 10\n\nThe collaboration resulted in the discovery of a new variant of Industroyer malware, which we together with\r\nCERT-UA named Industroyer2 – see CERT-UA publication here. Industroyer is an infamous piece of malware that\r\nwas used in 2016 by the Sandworm APT group to cut power in Ukraine.\r\nThe Sandworm attackers made an attempt to deploy the Industroyer2 malware against high-voltage electrical\r\nsubstations in Ukraine.\r\nIn addition to Industroyer2, Sandworm used several destructive malware families including CaddyWiper,\r\nORCSHRED, SOLOSHRED and AWFULSHRED. We first discovered CaddyWiper on 2022-03-14 when it was\r\nused against a Ukrainian bank – see our Twitter thread about CaddyWiper. A variant of CaddyWiper was used\r\nagain on 2022-04-08 14:58 against the Ukrainian energy provider previously mentioned.\r\nAt this point, we don’t know how attackers compromised the victim nor how they moved from the IT network to\r\nthe Industrial Control System (ICS) network. Figure 1 shows an overview of the different wipers used in this\r\nattack.\r\nFigure 1. Overview of the wiping components.\r\nFigure 2 summarizes the chain of events.\r\n2022-02-24: Beginning of the current Russian invasion in Ukraine\r\n2022-03-14: Deployment of CaddyWiper against a Ukrainian bank\r\n2022-04-01: Deployment of CaddyWiper against a Ukrainian governmental entity\r\nhttps://blog.eset.ie/2022/04/12/industroyer2-industroyer-reloaded/\r\nPage 2 of 10\n\n2022-04-08 14:58 UTC: Deployment of CaddyWiper on some Windows machines and of Linux and\r\nSolaris destructive malware at the energy provider\r\n2022-04-08 15:02:22 UTC: Sandworm operator creates the scheduled task to launch Industroyer2\r\n2022-04-08 16:10 UTC: Execution of Industroyer2 to cut power in an Ukrainian region\r\n2022-04-08 16:20 UTC: Execution of CaddyWiper on the same machine to erase Industroyer2 traces \r\nFigure 2. Timeline of events.\r\nIn 2017, ESET researchers revealed that a piece of malware called Industroyer was responsible for the power\r\nblackout that impacted Ukraine’s capital Kiev in December 2016.\r\nAs detailed in our detailed white paper Win32/Industroyer: A new threat for industrial control systems, it is\r\ncapable of interacting with industrial control systems typically found in electric power systems. This includes\r\nIEC-101, IEC-104, IEC 61850 and OPC DA.\r\nAt that time, we said that “it seems very unlikely anyone could write and test such malware without access to the\r\nspecialized equipment used in the specific, targeted industrial environment”. This was confirmed in 2020 by the\r\nUnited States government when six officers of the Russian Military Unit 74455 of the Main Intelligence\r\nDirectorate (GRU), were indicted for their role in multiple cyberattacks including Industroyer and NotPetya – see\r\nthe indictment on justice.gov and our historical overview of Sandworm’s operations.\r\nThe recently discovered malware is a new variant of Industroyer, hence the name Industroyer2.\r\nIndustroyer2\r\nIndustroyer2 was deployed as a single Windows executable named 108_100.exe and executed using a scheduled\r\ntask on 2022-04-08 at 16:10:00 UTC. It was compiled on 2022-03-23, according to the PE timestamp, suggesting\r\nthat attackers had planned their attack for more than two weeks.\r\nhttps://blog.eset.ie/2022/04/12/industroyer2-industroyer-reloaded/\r\nPage 3 of 10\n\nFigure 3. Timestamp and compiler information.\r\nIndustroyer2 only implements the IEC-104 (aka IEC 60870-5-104) protocol to communicate with industrial\r\nequipment. This includes protection relays, used in electrical substations. This is a slight change from the 2016\r\nIndustroyer that is a fully-modular platform with payloads for multiple ICS protocols.\r\nIndustroyer2 shares number of code similarities with the payload 104.dll of Industroyer. We assess with high\r\nconfidence that the new variant was built using the same source code.\r\nIndustroyer2 is highly configurable. It contains a detailed configuration hardcoded in its body, driving the\r\nmalware actions. This is different from Industroyer that stores configuration in a separate .INI file. Thus, attackers\r\nneed to recompile Industroyer2 for each new victim or environment. However, given that the Industroyer*\r\nmalware family was only deployed twice, with a five year gap between each version, this is probably not a\r\nlimitation for Sandworm operators.\r\nThe new configuration format is stored as a string which is then supplied to the IEC-104 communication routine\r\nof the malware. Industroyer2 is able to communicate with multiple devices at once. Specifically, the analyzed\r\nsample contains 8 different IP addresses of devices – see Figure 4.\r\nhttps://blog.eset.ie/2022/04/12/industroyer2-industroyer-reloaded/\r\nPage 4 of 10\n\nFigure 4 – Hardcoded configuration found in Industroyer2 sample\r\nThe configuration contains values that are used during communication via IEC-104 protocol, such as ASDU\r\n(Application Service Data Unit) address, Information Object Addresses (IOA), timeouts, etc.\r\nBefore connecting to the targeted devices, the malware terminates a legitimate process that is used in for standard\r\ndaily operations. In addition to that, it renames this application by adding .MZ to the filename. It does so in order\r\nto prevent automatic re-start of this legitimate process.\r\nThe analysis is still on-going in order to determine what are the exact actions taken for each device. We believe\r\nthat this component is able to control specific ICS systems in order to cut power.\r\nIndustroyer2 can produce a log file or output its progress to the console window. However, instead of meaningful\r\ntext messages as in previous version the malware writes various error codes – see Figure 5. We believe it is an\r\nobfuscation attempt by Sandworm developers to thwart analysis.\r\nFigure 5. Output produced by Industroyer2 malware\r\nCaddyWiper\r\nIn coordination with the deployment of Industroyer2 in the ICS network, the attackers deployed a new version of\r\nthe CaddyWiper destructive malware. We believe it was intended to slow down the recovery process and prevent\r\noperators of the energy company from regaining control of the ICS consoles. It was also deployed on the machine\r\nwhere Industroyer2 was executed, likely to cover their traces.\r\nThe first version of CaddyWiper was discovered by ESET researchers in Ukraine on 2022-03-14 when it was\r\ndeployed in the network of a bank. It was deployed via Group Policy Object (GPO), indicating the attackers had\r\nprior control of the target’s network beforehand. The wiper erases user data and partition information from\r\nattached drives, making the system inoperable and unrecoverable.\r\nNew CaddyWiper loading chain\r\nhttps://blog.eset.ie/2022/04/12/industroyer2-industroyer-reloaded/\r\nPage 5 of 10\n\nIn the network of the energy provider, attackers deployed a new version of CaddyWiper that uses a new loader,\r\nnamed ARGUEPATCH by CERT-UA. ARGUEPATCH is a patched version of a legitimate component of Hex-Rays IDA Pro software, specifically the remote IDA debugger server win32_remote.exe. IDA Pro is not supposed\r\nto be used in an ICS environment as its main purpose is for software reverse-engineering including malware\r\nanalysis. We don’t know why attackers choose to trojanized this piece of software, it might be a troll towards\r\ndefenders.\r\nARGUEPATCH was executed by a scheduled task that was intended to be launched once on 2022-04-08 14:58\r\nUTC on one machine and at 16:20 UTC on the machine where Industroyer2 was deployed.\r\nThe patched binary loads an encrypted shellcode from a file and decrypts it with a key, both are provided in\r\ncommand line. A single-byte XOR key is derived from the input key and used to decrypt the shellcode.\r\nThe decrypted shellcode is a slightly modified version of CaddyWiper. A comparison of their main routines is\r\nprovided in Figure 6 and Figure 7. Note that they do not wipe the domain controller, and they wipe C:\\Users\\ and\r\ndisks from D:\\ to [:\\. The wiping routine is also almost identical: it fills all files with 0.\r\nFigure 6. Main routine of the first sample of CaddyWiper.\r\nFigure 7. Main routine of the CaddyWiper sample deployed at the energy provider\r\nFinally, CaddyWiper calls DeviceIoControl with IOCTL_DISK_SET_DRIVE_LAYOUT_EX and a\r\nzeroed InputBuffer for all disks from \\\\PHYSICALDRIVE9 to \\\\PHYSICALDRIVE0. This erases extended\r\nhttps://blog.eset.ie/2022/04/12/industroyer2-industroyer-reloaded/\r\nPage 6 of 10\n\ninformation of drive’s partitions: the Master boot record (MBR) or the GUID Partition Table (GPT). The machine\r\nwon’t be able to boot again.\r\nActive directory enumeration\r\nAlongside CaddyWiper, a PowerShell script was found both in the energy provider network and in the bank that\r\nwas compromised earlier.\r\nThis script enumerates Group Policies Objects (GPO) using the Active Directory Service Interface (ADSI). The\r\nscript, shown in Figure 8, is almost identical to a snippet provided in a medium blogpost.\r\nWe believe that attackers deployed CaddyWiper via a GPO and used the script to check the existence of this GPO.\r\nFigure 8. PowerShell script to enumerate GPO (beautified)\r\nLinux and Solaris destructive malware (ORCSHRED, SOLOSHRED,\r\nAWFULSHRED)\r\nOn the network of the targeted energy company was found additional destructive malware for systems running\r\nLinux and Solaris. There are two main components to this attack: a worm and a wiper. The latter was found in two\r\nvariants, one for each of the targeted operating system. All malware was implemented in Bash.\r\nThe worm\r\nThe first component launched by the attacker was a worm, having its file named sc.sh. This Bash script starts by\r\nadding a scheduled task (cron job) to launch the wiper component at 2:58pm UTC (assuming the system is in the\r\nlocal time zone, UTC+3), unless it was launched with the “owner” argument. This is likely a way to avoid\r\nautodestructing the initial system used to launch the worm.\r\nhttps://blog.eset.ie/2022/04/12/industroyer2-industroyer-reloaded/\r\nPage 7 of 10\n\nFigure 9 Setting up the crob job to launch the wiper at 5:58pm. The correct wiper is picked\r\ndepending on the installed operating system.\r\nThe script then iterates over the networks accessible by the system by looking at the result of ip route or ifconfig -\r\na. It always assumes a class C network (/24) is reachable for each IP address it collects. It will try to connect to all\r\nhosts in those networks using SSH to TCP port 22, 2468, 24687 and 522. Once it finds a reachable SSH server, it\r\ntries credentials from a list provided with the malicious script. We believe the attacker had credentials prior to the\r\nattack to enable the spread of the wiper.\r\nIf the system is not already compromised, malware is copied to the new target, and the worm is launched. The\r\nworm is not launched with the “owner” argument, so the wiper is scheduled to launch at 2:58pm UTC and destroy\r\nall data. If those systems were set to the local time zone, the destruction must’ve started at the same time as the\r\nsystem compromised with CaddyWiper.\r\nThe Linux wiper\r\nThe Linux variant of the wiper is lightly obfuscated variables and function names were replaced with meaningless\r\n8-letter word. Most literal values were also replaced with variables at the beginning of the file.\r\nhttps://blog.eset.ie/2022/04/12/industroyer2-industroyer-reloaded/\r\nPage 8 of 10\n\nFigure 10 – Except from the obfuscated script (whitespace optimised).\r\nFigure 11 – Deobfuscation of the above obtained by renaming functions and variables and using\r\nliterals\r\nUltimately, the Linux wiper destroy the whole content of the disks attached to the system by using shred if\r\navailable or simply dd (with if=/dev/random) otherwise. If multiple disks are attached, data removal is done in\r\nparallel to speed up the process.\r\nDepending on the size, it may take hours for the full disk to be completely erased. To render the system inoperable\r\nfaster, it first tries to stop and disable HTTP and SSH services. Services are disabled both by\r\nusing systemctl disable. To ensure service isn’t reenabled, the systemd unit file responsible for loading the service\r\nis deleted from the disk.\r\nhttps://blog.eset.ie/2022/04/12/industroyer2-industroyer-reloaded/\r\nPage 9 of 10\n\nFiles from /boot, /home and /var/log are also removed before destroying the full drives. This makes the system\r\ninoperable faster, deletes user data and perhaps removes incriminating logs.\r\nThe malicious script’s last action is to forcibly initiate a reboot using SysRq. Since all drives are filled with\r\nrandom, no operating system will boot.\r\nThe Solaris wiper\r\nUnlike the Linux wiper, the Solaris variant is not obfuscated.\r\nLike the Linux variant, the malicious script iterates over all services to stop and disable them if they contain the\r\nkeyword ssh, http, apache and additionally ora_ or oracle. Those services are very likely used by applications used\r\nto control ICS systems. Wiping them would prevent the energy company’s operators from retaking control of the\r\nsubstations and roll back Industroyer2 actions.\r\nIt uses either systemctl or svcadm depending on what’s available. The latter is most likely since Solaris is not\r\nrunning systemd.\r\nFile destruction begins by deleting databases. It removes, using shred then rm, all files and directories contained in\r\nenvironment variables starting with ORA. Oracle Database uses the following variables to define location of\r\ndatabase files and software: ORACLE_BASE, ORACLE_HOME and ORACLE_PATH. Note that shred makes\r\nsure data recevery (without a backup) isn’t possible.\r\nLike the Linux variant, files in /boot, /home and /var/log are deleted in priority.\r\nThen the script iterates over disks connected to the system, found in /dev/dsk/. It ignores slices (partitions) and\r\nwork only on full disks. For each of them, the malicious script overwrites the full content using shred. To\r\nminimize the time required to perform the wipe, all disks are erased in parallel.\r\nLastly, the script self-destructs.\r\nConclusion\r\nUkraine is once again at the center of cyberattacks targeting their critical infrastructure. This new Industroyer\r\ncampaign follows multiple waves of wipers that have been targeting various sectors in Ukraine. ESET researchers\r\nwill continue to monitor the threat landscape in order to better protect organizations from these types of\r\ndestructive attacks.\r\nSource: https://blog.eset.ie/2022/04/12/industroyer2-industroyer-reloaded/\r\nhttps://blog.eset.ie/2022/04/12/industroyer2-industroyer-reloaded/\r\nPage 10 of 10", "extraction_quality": 1, "language": "EN", "sources": [ "Malpedia" ], "references": [ "https://blog.eset.ie/2022/04/12/industroyer2-industroyer-reloaded/" ], "report_names": [ "industroyer2-industroyer-reloaded" ], "threat_actors": [ { "id": "eb3f4e4d-2573-494d-9739-1be5141cf7b2", "created_at": "2022-10-25T16:07:24.471018Z", "updated_at": "2026-04-10T02:00:05.002374Z", "deleted_at": null, "main_name": "Cron", "aliases": [], "source_name": "ETDA:Cron", "tools": [ "Catelites", "Catelites Bot", "CronBot", "TinyZBot" ], "source_id": "ETDA", "reports": null }, { "id": "8941e146-3e7f-4b4e-9b66-c2da052ee6df", "created_at": "2023-01-06T13:46:38.402513Z", "updated_at": "2026-04-10T02:00:02.959797Z", "deleted_at": null, "main_name": "Sandworm", "aliases": [ "IRIDIUM", "Blue Echidna", "VOODOO BEAR", "FROZENBARENTS", "UAC-0113", "Seashell Blizzard", "UAC-0082", "APT44", "Quedagh", "TEMP.Noble", "IRON VIKING", "G0034", "ELECTRUM", "TeleBots" ], "source_name": "MISPGALAXY:Sandworm", "tools": [], "source_id": "MISPGALAXY", "reports": null }, { "id": "7bd810cb-d674-4763-86eb-2cc182d24ea0", "created_at": "2022-10-25T16:07:24.1537Z", "updated_at": "2026-04-10T02:00:04.883793Z", "deleted_at": null, "main_name": "Sandworm Team", "aliases": [ "APT 44", "ATK 14", "BE2", "Blue Echidna", "CTG-7263", "FROZENBARENTS", "G0034", "Grey Tornado", "IRIDIUM", "Iron Viking", "Quedagh", "Razing Ursa", "Sandworm", "Sandworm Team", "Seashell Blizzard", "TEMP.Noble", "UAC-0082", "UAC-0113", "UAC-0125", "UAC-0133", "Voodoo Bear" ], "source_name": "ETDA:Sandworm Team", "tools": [ "AWFULSHRED", "ArguePatch", "BIASBOAT", "Black Energy", "BlackEnergy", "CaddyWiper", "Colibri Loader", "Cyclops Blink", "CyclopsBlink", "DCRat", "DarkCrystal RAT", "Fobushell", "GOSSIPFLOW", "Gcat", "IcyWell", "Industroyer2", "JaguarBlade", "JuicyPotato", "Kapeka", "KillDisk.NCX", "LOADGRIP", "LOLBAS", "LOLBins", "Living off the Land", "ORCSHRED", "P.A.S.", "PassKillDisk", "Pitvotnacci", "PsList", "QUEUESEED", "RansomBoggs", "RottenPotato", "SOLOSHRED", "SwiftSlicer", "VPNFilter", "Warzone", "Warzone RAT", "Weevly" ], "source_id": "ETDA", "reports": null } ], "ts_created_at": 1775434333, "ts_updated_at": 1775791830, "ts_creation_date": 0, "ts_modification_date": 0, "files": { "pdf": "https://archive.orkl.eu/3d39a49d3c3e0fdb3484998fb12c1319639166a7.pdf", "text": "https://archive.orkl.eu/3d39a49d3c3e0fdb3484998fb12c1319639166a7.txt", "img": "https://archive.orkl.eu/3d39a49d3c3e0fdb3484998fb12c1319639166a7.jpg" } }