{ "id": "3d10cf68-d308-4a95-aa7c-66ccc4d38149", "created_at": "2026-04-06T01:32:14.661413Z", "updated_at": "2026-04-10T03:30:30.246889Z", "deleted_at": null, "sha1_hash": "e494ce68d6e058f7b1148bd908aa17caae0e5224", "title": "Industroyer2 in Perspective", "llm_title": "", "authors": "", "file_creation_date": "0001-01-01T00:00:00Z", "file_modification_date": "0001-01-01T00:00:00Z", "file_size": 480004, "plain_text": "Industroyer2 in Perspective\r\nPublished: 2022-04-23 · Archived: 2026-04-06 00:43:16 UTC\r\nBackground\r\nOn 12 April 2022, the Ukrainian CERT and ESET disclosed the existence of Industroyer2, a successor to the\r\nmalware targeting Ukrainian electric distribution and transmission operations in 2016. Industroyer2 arrived after\r\nmultiple disruptive cyber incidents of varying degrees of success surrounding Russia’s brutal invasion of Ukraine,\r\nas presented in the following timeline:\r\nOverall, cyber operations targeting Ukraine have ranged from the “merely annoying” (DDoS) to “quite\r\nconcerning” (Industroyer2). Fully contextualizing events will take time and the release of additional information,\r\nevidence, and technical background, although some preliminary observations are possible. In the case of\r\nhttps://pylos.co/2022/04/23/industroyer2-in-perspective/\r\nPage 1 of 9\n\nIndustroyer, we have several mysteries to contend with:\r\nLeaked reporting indicating potentially successful disruptive events in mid-March, prior to the known\r\nIndustroyer2 compilation date, across multiple substations.\r\nThe overall timing of Industroyer2 events, well after the start of hostilities (and as Russian performance\r\ncontinued to deteriorate across its invasion).\r\nhttps://pylos.co/2022/04/23/industroyer2-in-perspective/\r\nPage 2 of 9\n\nReporting from Ukrainian authorities indicating attempted disruptive operations are quite widespread and\r\nmay even be ongoing after the Industroyer2 disclosure.\r\nThere are many threads to pull to evaluate the Industroyer2 incident, given limited reporting but also the existence\r\nof samples in commercial malware repositories. While much remains to be uncovered with events, sufficient\r\ninformation is available at this time to draw some preliminary conclusions and set events in context with the\r\ncurrent situation in Ukraine, as well as previous operations.\r\nIndustroyer2 and Past Events\r\nIndustroyer2 represents the third (but presumably unsuccessful) electric power event targeting Ukrainian civilian\r\ninfrastructure. The first such event took place in 2015, when three distribution substations were targeted through a\r\ncombination of direct interaction with operator control systems and a “SCADA hijack” scenario to open breakers\r\nto disrupt the flow of electricity. The disruption was quickly followed by a wiper deployed to operator\r\nworkstations, as well as disruption to control center Uninterrupted Power Supply (UPS) systems and deploying a\r\nmalicious firmware update to serial-to-ethernet devices to effectively “brick” the systems. This also coincided\r\nwith a DoS to utility telephone lines inhibiting the ability of customers to report outages to operators.\r\nThe event resulted in an outage lasting several hours impacting over 200,000 customers. Overall, the 2015 event\r\nappears to be a “success,” in terms of the capabilities deployed resulting in an impact scenario commensurate with\r\ntools used. While Ukrainian operators were able to restore operations relatively quickly by manually reclosing\r\nbreakers, anecdotal evidence indicates the system wiping and effective destruction of serial-to-ethernet converters\r\nproduced damage taking years to effectively correct.\r\nThe 2015 event was followed roughly a year later by another incident, this time using power system-specific\r\nmalware referred to as Industroyer or CRASHOVERRIDE. In 2016, a transmission substation was targeted,\r\nproviding for a potentially larger impact scenario than the 2015 event. However, as detailed in analysis in 2019,\r\nthe first Industroyer event appears to have been very ambitious as an integrity- and protection-targeting industrial\r\nincident, but also a failure due to various mistakes in designing and deploying tools for the (attempted) disruption.\r\nThus the 2016 event resulted in relatively less-significant impact than 2015, largely due to errors on the part of the\r\nattackers.\r\nIndustroyer2 appears to have learned some lessons from the 2016 incident. As detailed in public presentations, the\r\nIEC-104 manipulation module for the original Industroyer failed due to programmatic errors and ignoring proper\r\nstate change requirements for proper protocol communication. Shown in the following packet capture,\r\nIndustroyer2 appears to properly implement the IEC-104 protocol in following appropriate state transitions. While\r\nfindings are preliminary and complete assessment would require testing on equipment similar to what was\r\ntargeted in victim environments, preliminary analysis would indicate the attackers paid attention to past failures\r\nhttps://pylos.co/2022/04/23/industroyer2-in-perspective/\r\nPage 3 of 9\n\nand implemented corrections in their code.\r\nHowever, other aspects of Industroyer2 are significantly different than past incidents. While several wipers are\r\nassociated with Industroyer2’s deployment, preliminary analysis from ESET and CERT-UA assesses this was\r\nlikely for destroying intrusion artifacts and evidence, with limited targeting of non-Windows systems that has not\r\nyet been thoroughly evaluated in terms of impact and likely adversary intent. Lacking from this event are the sort\r\nof physically destructive applications, such as the serial-to-ethernet converter targeting or the attempted removal\r\nof line protection in 2016. \r\nGiven currently-available evidence, it would appear that the 2022 attempt, although potentially of much wider\r\nscope (up to two million potentially impacted customers, based on Ukrainian assessment), was also potentially\r\nless destructive than prior activity. Precisely why this is the case is unknown. Some possibilities include:\r\n1. Desire on the part of Russian decision-makers to enable relatively quick restoration of the impacted sites as\r\npart of an invasion plan.\r\n2. Inability to develop a suitable physical destruction capability for the targeted substations in time for\r\ndeployment because of a “rushed” decision-making process.\r\n3. Failure to deploy a destructive capability because the attack was interrupted by Ukrainian defenders before\r\nan impact could occur.\r\nEach of these possibilities require more evidence to evaluate, although the first might be possible to examine if the\r\ntargeted sites were disclosed. For example, if the sites were tightly correlated with Russian invasion lines of\r\n(attempted) advance, having a way to restore electricity service but disrupting it during operations might make\r\nsense. The other two possibilities will require information not likely to be available for some time in order to\r\nproperly assess.\r\nIn any case, Industroyer2 appears to represent both an advance from earlier operations, in that industrial\r\ncommunication seems to be properly implemented, and a step back in terms of hard-coded configurations (making\r\neach sample unique to its victim site) and lack of a post-disruption destructive element.\r\nhttps://pylos.co/2022/04/23/industroyer2-in-perspective/\r\nPage 4 of 9\n\nBlackEnergy3 Connections\r\nOne curious aspect of Industroyer2 concerns service names used during execution in deployment. In analysis of\r\nnon-public samples published by ESET and analysis of different (but apparently functionally equivalent) samples\r\nin commercial malware repositories, the following set of strings are present for targeting purposes:\r\nWhile seemingly innocuous, those with good memories (or a bit of search engine skill) can rapidly identify where\r\nthis name – PService_PPD.exe – previously appeared: in past reporting on BlackEnergy3 use in connection with\r\nthe 2015 Ukraine power event.\r\nWhile BlackEnergy3 is not “industrial-specific” in the same sense as either Industroyer variant or other items such\r\nas Triton, it did serve a critical enabling function as part of the overall attack sequence leading up to power\r\nhttps://pylos.co/2022/04/23/industroyer2-in-perspective/\r\nPage 5 of 9\n\ndisruption. The name has no other significance or notable observations beyond this context.\r\nBoth ESET and CERT-UA link Industroyer2 (as well as the original Industroyer and at least some of the wiper\r\nevents in Ukraine in 2022) to the Sandworm actor, linked to GRU post 74455. Previous reporting and government\r\ndisclosures also linked Sandworm to the 2015 power event, and the use of BlackEnergy3 malware. Re-use of a\r\nspecific process name or string would therefore appear to be a very strange mistake in operational security – or it\r\ncould represent some degree of “victim trolling” by threat actors.\r\nhttps://pylos.co/2022/04/23/industroyer2-in-perspective/\r\nPage 6 of 9\n\nThe name itself has no significance or function beyond the BlackEnergy3-Industroyer2 connection. Why this\r\nappears is an open question, and likely one that will never be satisfactorily resolved. However, this instance may\r\nbe an interesting cyber threat intelligence counter-example of where indicator-like alerting (e.g., on specific\r\nfilenames or references to specific processes) may actually be a reasonable defensive measure for identifying\r\ncertain adversaries.\r\nRelationship to Wider Operations and Events\r\nWhen Russia initiated its terrible invasion of Ukraine in late February 2022, commentators and analysis\r\nanticipated early operations to feature significant cyber components. While some effects certainly were observed\r\nand others discovered after collection of more evidence, many expected to observe critical infrastructure\r\ndisruption along the lines of the 2015 and 2016 power events. That such an impact was attempted but only over a\r\nmonth into the conflict seems exceptionally strange, and defies expectations and assumptions around when to\r\ndeploy such capabilities in conjunction with more traditional military operations.\r\nFirst, while we cannot say this with complete confidence, it does appear that initial Russian plans for invading\r\nUkraine envisioned a relatively quick decapitation of national leadership and centers of gravity, centered around\r\nthe sack of Kyiv. As part of this operation, one can assume that leaving critical infrastructure largely intact was\r\nprobably an initial requirement to facilitate occupation and subsequent installation of a puppet regime. As Russia’s\r\nincompetence and Ukraine’s bravery stymied these plans, a noticeable shift to indiscriminate attacks on population\r\ncenters and infrastructure was observed. That a latent capability such as power system-targeting malware would\r\nbe unleashed after such initial aims failed may therefore make sense, along the lines of similar questionable\r\nRussian decisions such as using sophisticated anti-ship cruise missiles to target stationary targets on land.\r\nChanging war aims aside, at the start of the conflict Ukraine’s electric sector remained linked to Russian grid\r\noperations. Coinciding with the start of Russia’s invasion, Ukrainian operators initiated an isolation test from\r\nRussian grid operations, and subsequently decided to not reconnect. While separating Ukraine from Russian grid\r\noperations, this also left Ukraine’s grid isolated and thus more easily susceptible to disruption. Russian operations\r\nto capture electric infrastructure, such as events in Chernobyl and Zaporizhzhia, could thus give Russia ready\r\ncontrol over Ukrainian electric operations, or at least significant influence over them.\r\nThis changed in mid-March, when Ukraine (and Moldova) successfully connected to the European electric grid\r\nunder ENTSO-E. As stated previously, this timing is interesting as some suspected disruptive events appeared to\r\ntake place immediately after this switchover. But with Ukraine now part of the wider European electric system,\r\nunilateral options for Russia to control or manipulate Ukrainian electric operations were removed, or significantly\r\nreduced. Thus the timing of Industroyer2 after not just the start of the conflict, but also after integration with\r\nENTSO-E, makes more sense in light of these changes.\r\nConclusions\r\nMany details surrounding Industroyer2 and related (attempted) attacks on Ukrainian electric infrastructure are\r\nunavailable, but sufficient information has emerged to allow for the preliminary observations above. Overall, the\r\nevolution of operations in Russia’s invasion of Ukraine show that many assumptions surrounding the use of cyber\r\ncapabilities as part of a conventional conflict require revision – but at the same time, we should also note that\r\nhttps://pylos.co/2022/04/23/industroyer2-in-perspective/\r\nPage 7 of 9\n\ncyber has been far from absent as part of hostilities. While paling in comparison to Russia’s physical brutality,\r\ncyber operations appear to form a continuing area of interest and investment for Russia in attempting to achieve\r\nits goals in Ukraine.\r\nWith time and additional data, the items above can be revisited and improved. I would caution anyone reading\r\nthis, or any other, analysis that in the case of both the 2015 and especially the 2016 power incidents in Ukraine,\r\nreasonably complete understanding of these events did not occur until years after the events in question.\r\nEspecially given the difficulties of network defense, forensics, and electric system operations in the middle of an\r\ninvasion, researchers would do well to be patient with matters such as this, and maintain a willingness to revise\r\nconclusions appropriately as more information emerges.\r\nOverall, Industroyer2 represents an interesting and important development surrounding the broader violence\r\nRussia is inflicting upon Ukraine. Given that the malware did not result in a disruption of service, other asset\r\nowners and operators should take note that robust, alert operations are critical in maintaining sufficient defense\r\nand resilience in the face of critical infrastructure threats. We can learn much from Ukraine’s efforts in this\r\nconflict, not the least of which being how to maintain fundamental civilian services even in the face of a brutal,\r\nall-out assault.\r\nTechnical Details\r\nWhile CERT-UA and ESET published some indicators related to Industroyer2, some other samples appeared with\r\nequivalent functionality that were not previously identified in original reports. The following table provides a list\r\nof known Industroyer2 samples and potential variants.\r\nFile Name SHA1 Note\r\n108_100.exe FD9C17C35A68FC505235E20C6E50C622AED8DEA0\r\nIndustroyer2\r\nvariant listed by\r\nESET, CERT-UA.\r\n40_115.exe FDEB96BC3D4AB32EF826E7E53F4FE1C72E580379\r\nIndustroyer2\r\nvariant discovered\r\non VirusTotal.\r\nN/A 39B27DE81915B748EC56D1C5DF7E017B4A20323B\r\nPossible researcher\r\nmodification of\r\navailable sample.\r\nN/A 1574A402E5604F17BC0068F196D8BCDCB05286E7\r\nPossible researcher\r\nmodification of\r\navailable sample.\r\nAcknowledgments\r\nhttps://pylos.co/2022/04/23/industroyer2-in-perspective/\r\nPage 8 of 9\n\nHuge thanks to the teams at ESET and CERT-UA for disclosing information for defenders and enabling this\r\nanalysis, as well as the team at MSTIC for their continued support of Ukrainian defenders. Special thanks to Dan\r\nGunter and InsaneForensics for enabling protocol analysis of available Industroyer2 samples in a functioning lab\r\nenvironment.\r\nSource: https://pylos.co/2022/04/23/industroyer2-in-perspective/\r\nhttps://pylos.co/2022/04/23/industroyer2-in-perspective/\r\nPage 9 of 9", "extraction_quality": 1, "language": "EN", "sources": [ "Malpedia" ], "references": [ "https://pylos.co/2022/04/23/industroyer2-in-perspective/" ], "report_names": [ "industroyer2-in-perspective" ], "threat_actors": [ { "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": 1775439134, "ts_updated_at": 1775791830, "ts_creation_date": 0, "ts_modification_date": 0, "files": { "pdf": "https://archive.orkl.eu/e494ce68d6e058f7b1148bd908aa17caae0e5224.pdf", "text": "https://archive.orkl.eu/e494ce68d6e058f7b1148bd908aa17caae0e5224.txt", "img": "https://archive.orkl.eu/e494ce68d6e058f7b1148bd908aa17caae0e5224.jpg" } }