{
	"id": "78f66d51-4c06-4729-a90a-0dd36f459ae6",
	"created_at": "2026-04-06T00:18:38.309733Z",
	"updated_at": "2026-04-10T13:12:18.631388Z",
	"deleted_at": null,
	"sha1_hash": "6e7d13508a23b799c83c18a2ee93cc9c127d7be8",
	"title": "Industroyer2 IEC-104 Analysis",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 452581,
	"plain_text": "Industroyer2 IEC-104 Analysis\r\nBy Erik Hjelmvik\r\nPublished: 2022-04-25 · Archived: 2026-04-05 21:33:13 UTC\r\n, \r\nMonday, 25 April 2022 10:35:00 (UTC/GMT)\r\nThe Industroyer2 malware was hardwired to attack a specific set of electric utility substations in Ukraine. It seems\r\nto have been custom built to open circuit breakers, which would effectively cut the power from the substation.\r\nAfter connecting to an RTU in a substation the malware would immediately start changing the outputs at specific\r\naddresses without first having to enumerate which IOAs that were available on the targeted device. This custom-built malware seems to know what IOAs to use at each station, as well as what type of output each specific IOA\r\ncontrols.\r\nUPDATE 2022-04-26\r\nUpon popular demand we've decided to release three PCAP files with IEC-104 traffic from our own sandbox\r\nexecution of the Industroyer2 malware. Please feel free to use these capture files to verify our findings using any\r\ntool of your choice. The capture files can be downloaded from here:\r\nhttps://www.netresec.com/files/Industroyer2-Netresec.zip\r\nThese PCAP files are shared under a CC BY 4.0 license, which allows you to redistribute them as long as you give\r\nappropriate credit.\r\nUPDATE 2022-04-29\r\nA PNG image in the original CERT-UA security alert #4435 turned out to actually include the IOAs targeted by\r\nthe non-public 108_100.exe Industroyer2 version. The IOAs disclosed in CERT-UAs alert have now been\r\nhttps://www.netresec.com/?page=Blog\u0026month=2022-04\u0026post=Industroyer2-IEC-104-Analysis\r\nPage 1 of 9\n\nincluded in this blog post as well.\r\nBackstory\r\nI was looking at a public sandbox execution of a presumed Industroyer2 malware sample two weeks ago. At first\r\nglance the malware sample, which was named “40_115.exe”, didn't do much. It just printed the text below to the\r\nconsole and then terminated the process.\r\n19:46:06:0106\u003e T281 00006800\r\n19:46:06:0247\u003e RNM 0015\r\n19:46:06:0294\u003e 10.82.40.105: 2404: 3\r\n19:46:06:0294\u003e T65 00006800\r\n19:46:06:0341\u003e 10.82.40.105 M68B0 SGCNT 44\r\n19:46:06:0497\u003e RNM 0015\r\n19:46:06:0544\u003e T113 00006800\r\n19:46:06:0544\u003e 192.168.122.2: 2404: 2\r\n19:46:06:0544\u003e 192.168.122.2 M68B0 SGCNT 8\r\n19:46:06:0591\u003e RNM 0015\r\n19:46:06:0653\u003e 192.168.121.2: 2404: 1\r\n19:46:06:0700\u003e 192.168.121.2 M68B0 SGCNT 16\r\n19:46:21:0747\u003e 192.168.122.2 M6812\r\n19:46:21:0747\u003e 10.82.40.105 M6812\r\n19:46:21:0794\u003e 192.168.121.2 M6812\r\nI later noticed that it also sent TCP SYN packets to three different RFC1918 addresses, but never received a\r\nresponse.\r\nImage: Wireshark showing Industroyer2 trying to reach TCP port 2404\r\nTCP port 2404 is used by the SCADA protocol IEC 60870-5-104, also known as IEC-104, which is primarily used\r\nto monitor and control electricity transmission and distribution systems. IEC-104 is also the only Industrial\r\nControl System (ICS) protocol implemented in Industroyer2 according to ESET. The previous version of\r\nIndustroyer, which was used to cut the power in Ukraine in 2016, additionally supported the IEC 61850 and OPC\r\nDA protocols according to the CRASHOVERRIDE report from Dragos.\r\nIndustroyer2's IEC-104 client didn't receive any SYN+ACK response in the sandbox execution I was looking at,\r\nso I couldn't tell what it was trying to do. I therefore decided to set up my own sandbox with a built-in IEC-104\r\nserver (also known as a slave, RTU or IED). My sandbox execution confirmed that Industroyer2 was indeed trying\r\nto communicate with these three IP addresses using IEC-104. I also noticed that it was very specific about which\r\noutputs (or IOAs) it wanted to access on those servers in order to turn these outputs either ON or OFF.\r\nhttps://www.netresec.com/?page=Blog\u0026month=2022-04\u0026post=Industroyer2-IEC-104-Analysis\r\nPage 2 of 9\n\nStation Address 1 at 192.168.121.2\r\nThe Industroyer2 malware spawned three separate threads when started, one thread for each IEC-104 server to\r\ncontact. The malware would communicate with all three servers in parallel if all of them were available. However,\r\nin order to simplify my analysis I decided to only respond to one of the IPs at a time, starting with IP address\r\n192.168.121.2.\r\nThe thread that connected to IP address 192.168.121.2 toggled all outputs between 1250 and 1265 to OFF at\r\nStation Address 1 (also known as “ASDU address” or “common address”). Judging from the command type used\r\n(ID 46 with short pulse duration) these outputs likely control circuit breakers, which are used to disconnect the\r\npower from an electric utility substation.\r\nImage: PCAP file with IEC-104 traffic to 192.168.121.2 in NetworkMiner\r\nStation Address 2 at 192.168.122.2\r\nOn 192.168.122.2 the malware targeted station address 2, where it toggled outputs between 1101 and 1108 to\r\nOFF.\r\nhttps://www.netresec.com/?page=Blog\u0026month=2022-04\u0026post=Industroyer2-IEC-104-Analysis\r\nPage 3 of 9\n\nImage: PCAP file with IEC-104 traffic to 192.168.122.2 in NetworkMiner\r\nStation Address 3 at 10.82.40.105\r\nThe malware toggled a great deal of outputs on 10.82.40.105, which had station address 3. But in contrast to the\r\nother stations, many of these outputs were toggled to the “ON” state rather than “OFF”.\r\nhttps://www.netresec.com/?page=Blog\u0026month=2022-04\u0026post=Industroyer2-IEC-104-Analysis\r\nPage 4 of 9\n\nImage: PCAP file with IEC-104 traffic to 10.82.40.105 in NetworkMiner\r\nYet, after setting those outputs to “ON” it proceeded with setting outputs to “OFF” for several other IOAs on\r\nstation address 3.\r\nhttps://www.netresec.com/?page=Blog\u0026month=2022-04\u0026post=Industroyer2-IEC-104-Analysis\r\nPage 5 of 9\n\nImage: PCAP file with IEC-104 traffic to 10.82.40.105 in NetworkMiner\r\nIn each thread Industroyer2 paused for approximately 3 seconds between each accessed IOA. This delay seems to\r\nhave been hard coded since the malware didn't seem to care whether or not the IEC-104 server responded with an\r\nOK message, such as ACT or ACTTERM, or an error message, like “unknown common address of ASDU”. Each\r\nthread would simply proceed with setting an IOA every 3 seconds no matter what the server responded.\r\nThe specific order in which the IOAs were accessed was also very deterministic, the exact same sequence of IOAs\r\nwas used every time. I verified this behavior by running the malware multiple times as well as by comparing my\r\nresults to an execution of the same sample on a different sandbox (thanks for the PCAP Joe and Dan).\r\nWhat Did the Attackers Know?\r\nThe fact that the malware toggled these specific outputs, rather than just randomly turning outputs ON or OFF,\r\nindicates that the threat actors had technical knowledge about the specific substation(s) they were attacking. Not\r\nonly did the attackers know the IP addresses, station addresses and IOAs of each targeted output. They also knew\r\nwhat ASDU Type ID to use for each respective output. For IOA 1101 to 1404 the Type ID 46 was used (also\r\nknown as \"double command\" or C_DC_NA_1) while for IOAs from 130202 and above it used Type ID 45 (also\r\nknown as “single command” or C_SC_NA_1).\r\nhttps://www.netresec.com/?page=Blog\u0026month=2022-04\u0026post=Industroyer2-IEC-104-Analysis\r\nPage 6 of 9\n\nAs you can see in the previous screenshots, NetworkMiner nicely parses and presents the IEC-104 commands\r\nissued by Industroyer2. But I noticed that the malware also printed all sent and received commands to the console\r\nwhen executed. For example, the following output was printed to the console by the Industroyer2 thread\r\ncommunicating with station address 2 on 192.168.122.2:\r\n11:51:56:0163\u003e T65 00006800\r\n11:51:56:0201\u003e RNM 0003\r\n11:51:56:0241\u003e 192.168.122.2: 2404: 2\r\n11:51:56:0267\u003e 192.168.122.2 M68B0 SGCNT 8\r\n11:51:56:0297\u003e 192.168.122.2 M6813\r\nThe string “192.168.122.2: 2404: 2” above reveals that “2404” is the target port and “2” is the station address. The\r\n“SGCNT 8” string additionally tells us that there were 8 outputs to be toggled on that station. The other two\r\nstations had SGCNT 16 and 44.\r\nThe malware also printed very detailed information about each sent and received IEC-104 command, such as in\r\nthe example below where the output at IOA 1104 was successfully turned off at station address 2 (here referred to\r\nas “ASDU:2”).\r\nMSTR -\u003e\u003e SLV 192.168.122.2:2404\r\n  x68 x0E x02 x00 x08 x00 x2E x01 x06 x00 x02 x00 x50 x04 x00 x05\r\n  I |Length:16 bytes | Sent=x1 | Received=x4\r\n  ASDU:2 | OA:0 | IOA:1104 |\r\n  Cause: (x6) | Telegram type: (x2E)\r\nMSTR \u003c\u003c- SLV 192.168.122.2:2404\r\n  x68 x0E x08 x00 x04 x00 x2E x01 x47 x00 x02 x00 x50 x04 x00 x05\r\n  I |Length:16 bytes | Sent=x4 | Received=x2\r\n  ASDU:2 | OA:0 | IOA:1104 |\r\n  Cause: (x47) | Telegram type: (x2E)\r\nNote that the Type ID values were also logged to the console by Industroyer2, but it used the term “Telegram\r\ntype” instead of “Type ID”.\r\nStatic Analysis\r\nThe following three Unicode strings can be found in the 40_115.exe binary:\r\n10.82.40.105 2404 3 0 1 1 PService_PPD.exe 1 \"D:\\OIK\\DevCounter\" 0 1 0 0 1 0 0 44 130202 1 0 1 1\r\n1 160921 1 0 1 1 2 160923 1 0 1 1 3 160924 1 0 1 1 4 160925 1 0 1 1 5 160927 1 0 1 1 6 160928 1 0 1\r\n1 7 190202 1 0 1 1 8 260202 1 0 1 1 9 260901 1 0 1 1 10 260902 1 0 1 1 11 260903 1 0 1 1 12 260904 1\r\n0 1 1 13 260905 1 0 1 1 14 260906 1 0 1 1 15 260907 1 0 1 1 16 260908 1 0 1 1 17 260909 1 0 1 1 18\r\n260910 1 0 1 1 19 260911 1 0 1 1 20 260912 1 0 1 1 21 260914 1 0 1 1 22 260915 1 0 1 1 23 260916 1\r\n0 1 1 24 260918 1 0 1 1 25 260920 1 0 1 1 26 290202 1 0 1 1 27 338501 1 0 1 1 28 1401 0 0 0 1 29\r\nhttps://www.netresec.com/?page=Blog\u0026month=2022-04\u0026post=Industroyer2-IEC-104-Analysis\r\nPage 7 of 9\n\n1402 0 0 0 1 30 1403 0 0 0 1 31 1404 0 0 0 1 32 1301 0 0 0 1 33 1302 0 0 0 1 34 1303 0 0 0 1 35 1304\r\n0 0 0 1 36 1201 0 0 0 1 37 1202 0 0 0 1 38 1203 0 0 0 1 39 1204 0 0 0 1 40 1101 0 0 0 1 41 1102 0 0 0 1\r\n42 1103 0 0 0 1 43 1104 0 0 0 1 44\r\n192.168.122.2 2404 2 0 1 1 PService_PPD.exe 1 \"D:\\OIK\\DevCounter\" 0 1 0 0 1 0 0 8 1104 0 0 0 1 1\r\n1105 0 0 0 1 2 1106 0 0 0 1 3 1107 0 0 0 1 4 1108 0 0 0 1 5 1101 0 0 0 1 6 1102 0 0 0 1 7 1103 0 0 0 1 8\r\n192.168.121.2 2404 1 0 1 1 PService_PPD.exe 1 \"D:\\OIK\\DevCounter\" 0 1 0 0 1 0 0 16 1258 0 0 0 1 1\r\n1259 0 0 0 1 2 1260 0 0 0 1 3 1261 0 0 0 1 4 1262 0 0 0 1 5 1265 0 0 0 1 6 1252 0 0 0 1 7 1253 0 0 0 1\r\n8 1254 0 0 0 1 9 1255 0 0 0 1 10 1256 0 0 0 1 11 1257 0 0 0 1 12 1263 0 0 0 1 13 1264 0 0 0 1 14 1250\r\n0 0 0 1 15 1251 0 0 0 1 16\r\nAfter having analyzed the IEC-104 traffic from the binary it's obvious that this is the IEC-104 configuration that\r\nhas been hard-coded into the binary. For example, the substring “10.82.40.105 2404 3” in the first Unicode string\r\nrefers to the IP, port and station number of the first target.\r\nThe “16 1258 [...]” section in the third Unicode string above tells us that there are 16 outputs configured for\r\nstation address 1, where the first one to be set is at IOA 1258. Thus, we can easily verify that all accessed IOAs on\r\nall three stations were hard-coded into the binary.\r\nAdditional Substations Targeted\r\nThe malware sample I've analyzed has the following properties:\r\nFilename: 40_115.exe\r\nMD5: 7c05da2e4612fca213430b6c93e76b06\r\nSHA1: fdeb96bc3d4ab32ef826e7e53f4fe1c72e580379\r\nSHA256: d69665f56ddef7ad4e71971f06432e59f1510a7194386e5f0e8926aea7b88e00\r\nCompiled: 2022-03-23 10:07:29 UTC\r\nBut there is an additional Industroyer2 sample called “108_100.exe” (MD5\r\n3229e8c4150b5e43f836643ec9428865), which has been mentioned by ESET as well as CERT-UA. I haven't been\r\nable to access that binary though, so I don't yet know which IP addresses it was designed to target. However, a few\r\nscreenshots [1] [2] [3] published by ESET reveal that the 108_100.exe malware sample was hard coded to access\r\n8 different station addresses, 5 of which were on the 10.0.0.0/8 network and 3 on the 192.168.0.0/16 net. An\r\nimage in CERT-UA's alert #4435 from April 12 reveals the targeted IOAs for these 8 stations.\r\nTargets hard-coded in 108_100.exe ordered by station address:\r\nSA#1, 192.x.x.x, 12 IOAs (1101-1104, 1201-1204, 1301-1304)\r\nSA#2, 10.x.x.x, 12 IOAs (1101-1104, 1201-1204, 1301-1304)\r\nSA#3, 192.x.x.x, 18 IOAs (1103-1104, 1201-1204, 1301-?, 38601-38607)\r\nSA#4, 10.x.x.x, 34 IOAs (16501, 16603, 26502, 38507-38513, 38519-38524 and more...)\r\nSA#5, 192.x.x.x, 10 IOAs (1101-1103, 1201-1204, 1301-1303)\r\nSA#6, 10.x.x.x, 8 IOAs (1101-1104, 1201-1204)\r\nSA#7, 10.x.x.x, 8 IOAs (1101-1104, 1201-1204)\r\nhttps://www.netresec.com/?page=Blog\u0026month=2022-04\u0026post=Industroyer2-IEC-104-Analysis\r\nPage 8 of 9\n\nSA#8, 10.x.x.x, 8 IOAs (1101-1104, 1201-1204)\r\nWe can compare those station addresses, IP addresses and IOAs to the ones targeted by the 40_115.exe sample,\r\nwhich was analyzed in this blog post.\r\nSA#1, 192.168.121.2, 16 IOAs (1250-1265)\r\nSA#2, 192.168.122.2, 8 IOAs (1101-1108)\r\nSA#3, 10.82.40.105, 44 IOAs (1101-1104, 1201-1204, 1301-1304, 1401-1404, 130202, 160921-160928,\r\n190202, 260202, 260901-260920, 290202, 338501)\r\nThere doesn't seem to be any overlap across the two sets (except for possibly station address 1 which is on the\r\n192.x.x.x network in both configs but has different IOAs). This indicates that the 108_100.exe Industroyer2\r\nversion was hard coded to attack a different set of targets than the 40_115.exe sample that I've analyzed.\r\nMore ICS blog posts from Netresec\r\nIf you'd like to find our earlier work in the field of ICS/SCADA security, then check out these (slightly older but\r\nstill very relevant) blog posts:\r\n2011: Monitor those Control System Networks!\r\n2012: SCADA Network Forensics with IEC-104\r\n2014: Full Disclosure of Havex Trojans\r\n2014: Observing the Havex RAT\r\n2015: From 4SICS with ICS PCAP Files\r\nPosted by Erik Hjelmvik on Monday, 25 April 2022 10:35:00 (UTC/GMT)\r\nTags: #IEC-104#60870-5-104#ICS#ICS#SCADA#PCAP#RFC1918\r\nSource: https://www.netresec.com/?page=Blog\u0026month=2022-04\u0026post=Industroyer2-IEC-104-Analysis\r\nhttps://www.netresec.com/?page=Blog\u0026month=2022-04\u0026post=Industroyer2-IEC-104-Analysis\r\nPage 9 of 9",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"Malpedia"
	],
	"origins": [
		"web"
	],
	"references": [
		"https://www.netresec.com/?page=Blog\u0026month=2022-04\u0026post=Industroyer2-IEC-104-Analysis"
	],
	"report_names": [
		"?page=Blog\u0026month=2022-04\u0026post=Industroyer2-IEC-104-Analysis"
	],
	"threat_actors": [
		{
			"id": "5cbf6c32-482d-4cd2-9d11-0d9311acdc28",
			"created_at": "2023-01-06T13:46:38.39927Z",
			"updated_at": "2026-04-10T02:00:02.958273Z",
			"deleted_at": null,
			"main_name": "ENERGETIC BEAR",
			"aliases": [
				"BERSERK BEAR",
				"ALLANITE",
				"Group 24",
				"Koala Team",
				"G0035",
				"ATK6",
				"ITG15",
				"DYMALLOY",
				"TG-4192",
				"Crouching Yeti",
				"Havex",
				"IRON LIBERTY",
				"Blue Kraken",
				"Ghost Blizzard"
			],
			"source_name": "MISPGALAXY:ENERGETIC BEAR",
			"tools": [],
			"source_id": "MISPGALAXY",
			"reports": null
		}
	],
	"ts_created_at": 1775434718,
	"ts_updated_at": 1775826738,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/6e7d13508a23b799c83c18a2ee93cc9c127d7be8.pdf",
		"text": "https://archive.orkl.eu/6e7d13508a23b799c83c18a2ee93cc9c127d7be8.txt",
		"img": "https://archive.orkl.eu/6e7d13508a23b799c83c18a2ee93cc9c127d7be8.jpg"
	}
}