{
	"id": "198b2019-cfe8-4e0c-bffc-f0cb481352a9",
	"created_at": "2026-04-06T00:22:00.087607Z",
	"updated_at": "2026-04-10T13:11:49.606701Z",
	"deleted_at": null,
	"sha1_hash": "3c056883d59f2a0d3cb17031adb935953170ff82",
	"title": "INDUSTROYER.V2: Old Malware Learns New Tricks | Mandiant",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 3288272,
	"plain_text": "INDUSTROYER.V2: Old Malware Learns New Tricks | Mandiant\r\nBy Mandiant\r\nPublished: 2022-04-25 · Archived: 2026-04-05 20:48:40 UTC\r\nWritten by: Daniel Kapellmann Zafra, Raymond Leong, Chris Sistrunk, Ken Proska, Corey Hildebrandt, Keith\r\nLunden, Nathan Brubaker\r\nOn April 12, 2022, CERT-UA and ESET reported that a cyber physical attack impacted operational technology\r\n(OT) supporting power grid operations in Ukraine. The attack leveraged different pieces of malware including a\r\nvariant of INDUSTROYER, a well-known piece of attack-oriented ICS malware originally deployed in December\r\n2016 to cause power outages in Ukraine.\r\nThe attack is significant not only because OT-targeted attacks are rare, but also because this is the first instance in\r\nwhich code from broadly known attack-oriented OT malware was redeployed against a new victim. Despite five\r\nyears of substantial analysis into INDUSTROYER from a variety of researchers, the actor still attempted to\r\nrepurpose the tool and customized it to reach new targets. INDUSTROYER.V2 (Mandiant’s name for the new\r\nvariant) reinforces the notion that OT malware can be tailored for use against multiple victims, which has serious\r\nimplications for other publicly known OT malware families like INCONTROLLER.\r\nWhile much of the story surrounding INDUSTROYER.V2’s deployment is already publicly available, Mandiant\r\nfurther analyzed the malware to share additional insights for defenders and the OT community. In this blog post\r\nwe document additional technical details of INDUSTROYER.V2 based on our analysis of two different samples.\r\nWe also provide detection rules to identify related activity.\r\nIf you need support responding to related activity, please contact Mandiant Consulting. Further analysis of related\r\nthreats—including additional malware that was deployed alongside INDUSTROYER.V2—is available as part of\r\nMandiant Advantage Threat Intelligence.\r\nINDUSTROYER.V2 In a Nutshell\r\nINDUSTROYER.V2 is similar to its predecessor, however this variant contains more targeted functionality.\r\nUnlike the original INDUSTROYER, which was a framework that leveraged external modules to implement four\r\ndifferent OT protocols, this variant is self-contained and only implements the IEC 60870-5-104 (IEC-104)\r\ncommunications protocol. IEC-104 is used for power system monitoring and control over TCP and is mainly\r\nimplemented in Europe and the Middle East.\r\nMost importantly, the new malware variant enables the actor to embed customized configurations that modify the\r\nmalware’s behavior to specific intelligent electronic devices (IEDs) (e.g., protection relays, merging units, etc.)\r\nwithin the target environment. The design change to embed custom configurations in INDUSTROYER.V2\r\nreduces the effort required by the actor to reproduce the attack against different victim environments and enables\r\nthe actor to contain the impact to specific targeted IEDs.\r\nhttps://www.mandiant.com/resources/blog/industroyer-v2-old-malware-new-tricks\r\nPage 1 of 13\n\nTwo Custom INDUSTROYER.V2 Samples Show the Breadth of the Attack\r\nTo fully understand the implications of the new customization capabilities in INDUSTROYER.V2, we analyzed\r\nand compared two different samples. The second sample, which is likely a recompiled version, is publicly\r\navailable and in online malware scanning platforms (MD5: 7c05da2e4612fca213430b6c93e76b06).\r\nWe believe both samples are related to the same operation. The compilation timestamps were within\r\nminutes of each other and about two weeks before the intended attack. It is possible the actor was\r\nmodifying the malware’s configuration to customize the payload for different targets.\r\nEach sample contains different configurations hardcoded within the binary. One sample contains eight\r\nunique hardcoded target IP addresses, whereas the other only contains three.\r\nIn both samples the malware terminated a specific process. However, the defined filepath used to\r\nconcatenate with the process differed between the two samples. This shows a nuanced understanding of the\r\nvictim environment.\r\nFigure 1 shows an example of INDUSTROYER.V2 configuration for the publicly available sample.\r\nFigure 1: Example INDUSTROYER.V2 configuration for publicly available sample\r\nBased on the slight differences between both samples, we can infer additional details about the scale of the attack,\r\nthe likely level of access that the actor had within the victim networks, and the reconnaissance likely performed by\r\nthe attacker prior to the deployment of the malware.\r\nAs shown by the details embedded in the malware configurations, the actor conducted at least some\r\ninternal network reconnaissance to identify specific IEDs in the victim environments and understand how\r\nto access them.\r\nThe malware configurations target devices across specific subnets, highlighting that the actor succeeded in\r\nidentifying and penetrating surrounding networks.\r\nThe actor’s successful implementation of IEC-104 to interact with the targeted devices indicates a robust\r\nunderstanding of the protocol and knowledge of the victim environment. For example, in the samples we\r\nhttps://www.mandiant.com/resources/blog/industroyer-v2-old-malware-new-tricks\r\nPage 2 of 13\n\nanalyzed the actor manipulated a selected list of Information Object Addresses (IOAs), which are used to\r\ninteract with power line switches or circuit breakers in a remote terminal unit (RTU) or relay configuration.\r\nConversely, the malware code itself shows some degree of carelessness or potential time constraints. For\r\nexample, the INDUSTROYER.V2 samples contain limited obfuscation and defense evasion methods. The\r\nlack of obfuscation in the binaries provides defenders with quick hints on its functionality and ability to\r\ntarget OT assets.\r\nOutlook\r\nExtensible frameworks, such as the original INDUSTROYER and INCONTROLLER, are often preferred by\r\nthreat actors due to the flexibility of their modular design, allowing deployment of specific payloads to target\r\ndifferent victim assets or communication protocols. However, in the case of INDUSTROYER.V2, the actor\r\nreimplemented only one of the original components from the earlier framework and created a new self-contained\r\nexecutable.\r\nIt is unclear why the threat actor made the particular modifications to INDUSTROYER.V2. Perhaps the actor\r\nwanted to develop a more streamlined version to target a very specific environment, or they did not want to\r\nexpose more valuable or capable tools, or they simply believed this approach would be efficient since it would not\r\nrequire additional resources to impact the target.\r\nRegardless of the motivations, the reuse of code from known OT malware highlights the value of hunting and\r\ndetections based on known indicators. For instance, some detections we built for the original INDUSTROYER\r\nsuccessfully identified INDUSTROYER.V2 in the wild. While it is often believed that OT malware is not likely to\r\nbe utilized in more than one environment, tools that take advantage of insecure by design OT features—such as\r\nINDUSTROYER.V2 does—can be employed multiple times to target multiple victims. The OT security\r\ncommunity should recognize these tools as frameworks or capabilities, and not merely features of isolated cyber\r\nsecurity incidents and one time use tools.\r\nTechnical Analysis of INDUSTROYER.V2\r\nINDUSTROYER.V2 is written in C++ and implements the IEC-104 protocol to modify the state of remote\r\nterminal units (RTUs) over TCP. IEC-104 protocol TCP clients are called control stations and the TCP servers are\r\ncalled remote stations. The malware crafts configurable IEC-104 Application Service Data Unit (ASDU)\r\nmessages, also known as telegrams, to change the state of a remote station’s Information Object Addresses (IOAs)\r\nto ON or OFF. IOAs identify a specific data element on a device and may correspond to power line switches or\r\ncircuit breakers in an RTU or relay configuration.\r\nThe malware is a self-contained executable where the operator can set up configuration parameters to target\r\nspecific remote stations, define execution options, and craft ASDU messages. It also accepts the optional\r\ncommand line arguments (-o) to print debug messages to an output file or (-t) to create a time delay before\r\nexecution.\r\nConfiguration Capabilities\r\nhttps://www.mandiant.com/resources/blog/industroyer-v2-old-malware-new-tricks\r\nPage 3 of 13\n\nAfter the command line interface arguments are parsed, INDUSTROYER.V2 iterates through embedded\r\nconfiguration entries. The execution of the program is highly configurable. Based on our analysis of two\r\nINDUSTROYER.V2 samples, the malware contains configuration entries structured as strings in the order shown\r\nin Table 1.\r\nPosition Configuration Entry Description\r\n1 Station IP Address\r\n2 Station Port\r\n3 Entry Index Value\r\n4 Enable Hard-Coded Telegrams with specified Range\r\n5 Enable Configuration Options 6 - 14\r\n5b If Entry 4 is Enabled, Telegram Start Range\r\n6 Enable Process Termination\r\n6b If entry 4 is Enabled, Telegram End Range\r\n7 Process Name to Terminate\r\n8 Enable File Rename\r\n9 Directory Path for File Rename\r\n10 Sleep Prior to IEC-104 functionality\r\n11 Sleep Duration Seed Value\r\n12 Execution Control\r\n13 Sleep Duration Seed Value\r\n14 Unused\r\n15 Command State – ON/OFF\r\n16 Change Option – Send Inverted ON/OFF commands\r\n17 Number of ASDU Data Entries\r\n18 First ASDU Data Entry\r\nTable 1: Configuration Structure\r\nAn example extracted configuration entry from sample 7c05da2e4612fca213430b6c93e76b06 is presented in\r\nFigure 2.\r\nhttps://www.mandiant.com/resources/blog/industroyer-v2-old-malware-new-tricks\r\nPage 4 of 13\n\n192.168.XXX.XXX 2404 2 0 1 1 Example StoppedProcess.exe 1 \"Example PATH\" 0 1 0 0 1 0 0 8 1104 0 0 0 1 1 1105 0\r\nFigure 2: Example configuration entry\r\nIf configuration entry #4 is enabled, the malware crafts ASDU telegrams to deliver Select and Execute commands\r\nand modify the state of a remote station's IOA to OFF. The IOA ranges which these telegrams are sent to are\r\nprovided by configuration entries #5 and #6. However, this option was not enabled in recovered samples. A\r\nconfiguration mapping against the example in Figure 2 is included in the Appendix.\r\nAll the configurations we examined had the following options enabled: process termination, file rename, and use\r\nof ASDU data entries. The ASDU data entries are used to craft specific ASDU messages to the remote station and\r\nthe data entry is structured in the format shown in Table 2.\r\nPosition ASDU Data Entry Description\r\n1 Station Information Object Address (IOA)\r\n2 Set Message Type – Single or Double Command\r\n3 Set Command Type – Select or Execute\r\n4 Invert Default ON/OFF State\r\n5 Execution Control\r\n6 ASDU Entry Index\r\nTable 2: ASDU Entry Structure\r\nAfter parsing each configuration entry, INDUSTROYER.V2 enumerates running processes to identify if a specific\r\nhard-coded process is running and terminates it. Once this process is stopped, the malware enumerates running\r\nprocesses again and terminates whichever process is specified by the operator in the configuration.\r\nIf the file rename option is enabled, the malware creates a file path using its configuration data and adds a .MZ\r\nextension to this file. This may be a technique to prevent the specified process terminated earlier from\r\nrelaunching.\r\nFor each configuration entry, a thread is created that implements IEC-104 communication with the controlled\r\nsystem. IEC-104 uses the Application Protocol Data Unit (APDU) specification.\r\nAn APDU frame can be composed of either just an Application Protocol Control Information (APCI) frame; or an\r\nAPCI header and a subsequent Application Service Data Unit (ASDU) frame.\r\nhttps://www.mandiant.com/resources/blog/industroyer-v2-old-malware-new-tricks\r\nPage 5 of 13\n\nExecution\r\nINDUSTROYER.V2 first sends control function messages, which are contained within an APCI frame. The first\r\ncontrol message is a Test Frame (TESTFR). The malware sends a TESTFR ACT to the remote station which\r\nverifies an established connection. If one exists, a remote station responds with a corresponding TESTFR CON.\r\nNext, the malware opens a data transfer channel with the remote station using a subsequent control message type\r\nof Start Data Transfer (STARTDT). By default, data transfer is not enabled on an active connection between a\r\ncontrol station and remote station. Therefore, the malware sends a STARTDT ACT to activate a data transfer\r\nchannel and a remote station sends a corresponding STARTDT CON, to confirm a successful activation.\r\nWith data transfer enabled, the malware utilizes an ASDU frame to send subsequent commands to the remote\r\nstation. ASDU messages, also known as telegrams, are a set of application functions defined by IEC-104 to\r\nmonitor and control remote stations. Further information describing the ASDU frame is available for reference.\r\nThe malware sends a General Interrogation command, which allows it to obtain the current status of monitored\r\ndigital and analog signals of the remote station. The malware then uses embedded ASDU data entries to craft a\r\nspecific command to modify the target’s IOA to either ON or OFF.\r\nThese commands are crafted using options defined within its configuration and the individual ASDU data entry.\r\nFor example, in the configuration we extracted from sample 7c05da2e4612fca213430b6c93e76b06 (presented in\r\nFigure 2) the first ASDU data entry is:\r\n1104 0 0 0 1 1\r\nhttps://www.mandiant.com/resources/blog/industroyer-v2-old-malware-new-tricks\r\nPage 6 of 13\n\nBased on configuration entry 15 (OFF state), entry 16 (Disable Change option), and its ASDU entry values\r\n(described in Table 2), the malware crafts an ASDU packet with the following characteristics:\r\nInformation Object Address: 1104\r\nASDU message type: C-DC_NA_1 (Double Command)\r\nASDU command type: Execute\r\nSet state value: OFF\r\nThe ASDU message is shown in decoded network traffic in Figure 4.\r\nFigure 4: Crafted ASDU message\r\nFor each targeted remote station in a configuration entry, the malware iterates through corresponding ASDU data\r\nentries, crafting specified telegrams, and sends it to the remote station. The malware’s configuration settings may\r\ndirect it to craft an additional ASDU message, which inverts the ON/OFF state in a command and sends this\r\nadditional message to the remote station’s IOA.\r\nA high-level description of the communication sequence is the following:\r\n1. Send Test Frame messages to verify an established connection\r\n2. Send Start Data Transfer messages to open a data transfer channel\r\n3. Send a General Interrogation command retrieving the status of the remote station\r\n4. Send crafted Single or Double command types to modify the state of the remote station’s IOA\r\nFigure 5 illustrates the described message sequence, captured between INDUSTROYER.V2 and a lab emulated\r\nIEC-104 remote station. It displays the initial TESTFR, STARTDT, and Interrogation commands, followed by the\r\ncrafted ASDU commands delivered to specific remote station IOAs.\r\nhttps://www.mandiant.com/resources/blog/industroyer-v2-old-malware-new-tricks\r\nPage 7 of 13\n\nFigure 5: INDUSTROYER.V2 message sequence with emulated IEC-104 Remote Station\r\nThe detailed nature of how a specific remote station is targeted, down to the unique IOAs and the state each IOA\r\nmust be modified to create an intended effect, demonstrates a comprehensive understanding of, or visibility into\r\nthe victim environment.\r\nWe note that although the IOAs targeted by the malware can provide important context to the actor's precise\r\nintent, IOA mappings often differ between manufacturers, devices, and even users. For this reason, accurate\r\ninterpretation of the actions intended by the actor requires additional knowledge about the targeted assets.\r\nWhile at this moment we do not have such information, we explored possible IOA matches based on publicly\r\navailable documentation about specific products. For example, knowing that ABB RTU's and relays are heavily\r\ndeployed in the targeted region we performed open source analysis. In our earlier example we observed an IOA\r\nequivalent to 1104, which we then mapped to public product documentation from an ABB Distribution Recloser\r\nRelay corresponding to \"50BFT:InStr status\".\r\nIn this status, 50 is the ANSI number for circuit breaker, which is how relay elements are numbered when setting a\r\nprotection relay. Then 50BFT stands for circuit breaker failure protection. We provide an appendix illustrating\r\nadditional mapping of IOAs extracted from the configuration of the public INDUSTROYER.V2 sample against\r\nthe same distribution recloser relay.\r\nOverlaps With Previous INDUSTROYER Variant\r\nThe two versions of INDUSTROYER contain overlaps in code and similarities in execution flow and\r\nfunctionality. We identified the following shared features in execution and functionality:\r\nBoth versions contain code that first terminates a specific process on the victim controller station, prior to\r\nestablishing IEC-104 communication.\r\nBoth versions craft specific ASDU messages according to provided configuration settings.\r\nBoth versions contain an ability to deliver pre-defined ASDU messages to a specified IOA range.\r\nhttps://www.mandiant.com/resources/blog/industroyer-v2-old-malware-new-tricks\r\nPage 8 of 13\n\nBoth versions contain an option to direct the malware to craft an additional ASDU message which inverts\r\nthe previous ON/OFF command and sends it to the target remote station.\r\nOne difference we identified between both variants is that, unlike its predecessor, INDUSTROYER.V2 contains\r\naltered debugging messages which obfuscate the meaning of the outputs. However, we note these debugging\r\nmessages are formatted and printed at similar execution points of key functions. Further, the obfuscation was not\r\nimplemented in key portions of IEC-104 code which are reused in both versions, which enables us to visualize the\r\noverlaps.\r\nFor example, both INDUSTROYER versions use very similar code to parse APDU traffic and print specific\r\nparsed fields. Figure 6 is a screenshot of INDUSTROYER.V2 on the left and on the right a screenshot of the\r\noriginal INDUSTROYER.\r\nFigure 6: APDU traffic handling in INDUSTROYER.V2 (Left) and INDUSTROYER.104 (Right)\r\nAdditional notable code overlaps between the two versions exist in implementation of ASDU frame creation,\r\nsending of APDU messages, change option execution, and thread setup for IEC-104 functionality.\r\nAppendix: YARA Rules\r\nrule MTI_Hunting_INDUSTROYERv2_Bytes {\r\n meta:\r\n author = \"Mandiant\"\r\n date = \"04-09-2022\"\r\n description = \"Searching for executables containing bytecode associated with the INDUSTROYER.V2 malware\r\n strings:\r\n $bytes = {8B [2] 89 [2] 8B 0D [4] 89 [2] 8B 15 [4] 89 [2] A1 [4] 89 [2] 8B 0D [4] 89 [2] 8A 15 [4] 88 [2\r\n condition:\r\n filesize \u003c 3MB and\r\n uint16(0) == 0x5A4D and uint32(uint32(0x3C)) == 0x00004550 and\r\nhttps://www.mandiant.com/resources/blog/industroyer-v2-old-malware-new-tricks\r\nPage 9 of 13\n\n$bytes\r\n}\r\nrule MTI_Hunting_INDUSTROYERv2_Strings {\r\n meta:\r\n author = \"Mandiant\"\r\n date = \"04-09-2022\"\r\n description = \"Searching for executables containing strings associated with the INDUSTROYER.V2 malware f\r\n strings:\r\n $a1 = \"M%X - %02d:%02d:%02d\" nocase ascii wide\r\n $a2 = \"%02hu:%02hu:%02hu:%04hu\" nocase ascii wide\r\n $a3 = \"%s M%X \" nocase ascii wide\r\n $a4 = \"%s: %d: %d\" nocase ascii wide\r\n $a5 = \"%s M%X %d (%s)\" nocase ascii wide\r\n $a6 = \"%s M%X SGCNT %d\" nocase ascii wide\r\n $a7 = \"%s ST%X %d\" nocase ascii wide\r\n $a8 = \"Current operation : %s\" nocase ascii wide\r\n $a9 = \"Sent=x%X | Received=x%X\" nocase ascii wide\r\n $a10 = \"ASDU:%u | OA:%u | IOA:%u | \" nocase ascii wide\r\n $a11 = \"Cause: %s (x%X) | Telegram type: %s (x%X\" nocase ascii wide\r\n $b1 = \"Length:%u bytes | \" nocase ascii wide\r\n $b2 = \"Unknown APDU format !!!\" nocase ascii wide\r\n $b3 = \"MSTR -\u003e\u003e SLV\" nocase ascii wide\r\n $b4 = \"MSTR \u003c\u003c- SLV\" nocase ascii wide\r\n condition:\r\n filesize \u003c 3MB and\r\n uint16(0) == 0x5A4D and uint32(uint32(0x3C)) == 0x00004550 and\r\n (1 of ($a*) and 1 of ($b*))\r\n}\r\nAppendix: Mapped Configuration Example\r\nTable 3: Mapped configuration example\r\nhttps://www.mandiant.com/resources/blog/industroyer-v2-old-malware-new-tricks\r\nPage 10 of 13\n\nAppendix: Example IOAs From Publicly Available Sample Mapping to An ABB\r\nDistribution Recloser Relay\r\nIOA Description\r\n1101 50BFT:InPosCIsA Status\r\n1102 50BFT:InPosCIsB Status\r\n1103 50BFT:InPosCIsC Status\r\n1104 50BFT:InStr status\r\n1105 50BFT:InStrA status\r\n1106 50BFT:InStrB status\r\n1107 50BFT:InStrC status\r\n1108 50BFT:general\r\n1201  \r\n1202  \r\n1203  \r\n1204  \r\n1250  \r\n1251  \r\n1252  \r\n1253  \r\n1254  \r\n1255  \r\n1256  \r\n1257  \r\n1258  \r\n1259  \r\n1260  \r\nhttps://www.mandiant.com/resources/blog/industroyer-v2-old-malware-new-tricks\r\nPage 11 of 13\n\n1261  \r\n1262  \r\n1263  \r\n1264  \r\n1265  \r\n1301  \r\n1302  \r\n1304  \r\n1401  \r\n1402  \r\n1403  \r\n1404  \r\n130202  \r\n160921  \r\n160923  \r\n160924  \r\n160925  \r\n160927  \r\n160928  \r\n190202  \r\n260202  \r\n260901  \r\n260902  \r\n260903  \r\n260904  \r\n260905  \r\n260906  \r\nhttps://www.mandiant.com/resources/blog/industroyer-v2-old-malware-new-tricks\r\nPage 12 of 13\n\n260907  \r\n260908  \r\n260909  \r\n260910  \r\n260911  \r\n260912  \r\n260914  \r\n260915  \r\n260916  \r\n260918  \r\n260920  \r\n290202  \r\n338501  \r\nAcknowledgements\r\nThis research was made possible thanks to the hard work of many people not listed on the byline. A huge thanks to\r\nCERT UA and ESET. Special thanks to Josh Triplett, Conor Quigley, and Wesley Mok.\r\nPosted in\r\nThreat Intelligence\r\nSecurity \u0026 Identity\r\nSource: https://www.mandiant.com/resources/blog/industroyer-v2-old-malware-new-tricks\r\nhttps://www.mandiant.com/resources/blog/industroyer-v2-old-malware-new-tricks\r\nPage 13 of 13\n\ncondition: filesize \u003c 3MB and  \nuint16(0) == 0x5A4D and uint32(uint32(0x3C)) == 0x00004550 and\n(1 of ($a*) and 1 of ($b*))  \n}   \nAppendix: Mapped Configuration Example \nTable 3: Mapped configuration example  \n   Page 10 of 13",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"MITRE"
	],
	"origins": [
		"web"
	],
	"references": [
		"https://www.mandiant.com/resources/blog/industroyer-v2-old-malware-new-tricks"
	],
	"report_names": [
		"industroyer-v2-old-malware-new-tricks"
	],
	"threat_actors": [],
	"ts_created_at": 1775434920,
	"ts_updated_at": 1775826709,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/3c056883d59f2a0d3cb17031adb935953170ff82.pdf",
		"text": "https://archive.orkl.eu/3c056883d59f2a0d3cb17031adb935953170ff82.txt",
		"img": "https://archive.orkl.eu/3c056883d59f2a0d3cb17031adb935953170ff82.jpg"
	}
}