IEC-104 File Transfer Extraction

Did you know that the SCADA protocol IEC 60870-5-104 (IEC-104) can be used to transfer files? This file transfer feature is primarily used for retrieving disturbance data from electric grid protection devices, such as protective relays, but can in practice be used to transfer any type of data.

In this video I demonstrate how IEC-104 file transfers can be extracted from network traffic with NetworkMiner.

The network traffic that was captured with NetworkMiner in this video can be downloaded here: NM_2022-12-13T14-16-00.pcap

The IEC-104 software used in the video was the IEC 104 RTU Server Simulator and IEC 104 Client Simulator from FreyrSCADA.

Posted by Erik Hjelmvik on Monday, 09 January 2023 09:00:00 (UTC/GMT)

Tags: #IEC-104​ #SCADA​ #NetworkMiner​ #ICS​ #PCAP​

Industroyer2 IEC-104 Analysis

The Industroyer2 malware was hardwired to attack a specific set of electric utility substations in Ukraine. It seems to have been custom built to open circuit breakers, which would effectively cut the power from the substation.

After connecting to an RTU in a substation the malware would immediately start changing the outputs at specific addresses 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 controls.

UPDATE 2022-04-26

Upon popular demand we've decided to release three PCAP files with IEC-104 traffic from our own sandbox execution of the Industroyer2 malware. Please feel free to use these capture files to verify our findings using any tool of your choice. The capture files can be downloaded from here:
https://www.netresec.com/files/Industroyer2-Netresec.zip

These PCAP files are shared under a CC BY 4.0 license, which allows you to redistribute them as long as you give appropriate credit.

UPDATE 2022-04-29

A PNG image in the original CERT-UA security alert #4435 turned out to actually include the IOAs targeted by the non-public 108_100.exe Industroyer2 version. The IOAs disclosed in CERT-UAs alert have now been included in this blog post as well.

Backstory

I was looking at a public sandbox execution of a presumed Industroyer2 malware sample two weeks ago. At first glance the malware sample, which was named “40_115.exe”, didn't do much. It just printed the text below to the console and then terminated the process.

I later noticed that it also sent TCP SYN packets to three different RFC1918 addresses, but never received a response.

Image: Wireshark showing Industroyer2 trying to reach TCP port 2404

TCP port 2404 is used by the SCADA protocol IEC 60870-5-104, also known as IEC-104, which is primarily used to monitor and control electricity transmission and distribution systems. IEC-104 is also the only Industrial Control System (ICS) protocol implemented in Industroyer2 according to ESET. The previous version of Industroyer, which was used to cut the power in Ukraine in 2016, additionally supported the IEC 61850 and OPC DA protocols according to the CRASHOVERRIDE report from Dragos.

Industroyer2's IEC-104 client didn't receive any SYN+ACK response in the sandbox execution I was looking at, so 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 server (also known as a slave, RTU or IED). My sandbox execution confirmed that Industroyer2 was indeed trying to communicate with these three IP addresses using IEC-104. I also noticed that it was very specific about which outputs (or IOAs) it wanted to access on those servers in order to turn these outputs either ON or OFF.

Station Address 1 at 192.168.121.2

The Industroyer2 malware spawned three separate threads when started, one thread for each IEC-104 server to contact. The malware would communicate with all three servers in parallel if all of them were available. However, in order to simplify my analysis I decided to only respond to one of the IPs at a time, starting with IP address 192.168.121.2.

The thread that connected to IP address 192.168.121.2 toggled all outputs between 1250 and 1265 to OFF at Station Address 1 (also known as “ASDU address” or “common address”). Judging from the command type used (ID 46 with short pulse duration) these outputs likely control circuit breakers, which are used to disconnect the power from an electric utility substation.

Image: PCAP file with IEC-104 traffic to 192.168.121.2 in NetworkMiner

Station Address 2 at 192.168.122.2

On 192.168.122.2 the malware targeted station address 2, where it toggled outputs between 1101 and 1108 to OFF.

Image: PCAP file with IEC-104 traffic to 192.168.122.2 in NetworkMiner

Station Address 3 at 10.82.40.105

The malware toggled a great deal of outputs on 10.82.40.105, which had station address 3. But in contrast to the other stations, many of these outputs were toggled to the “ON” state rather than “OFF”.

Image: PCAP file with IEC-104 traffic to 10.82.40.105 in NetworkMiner

Yet, after setting those outputs to “ON” it proceeded with setting outputs to “OFF” for several other IOAs on station address 3.

Image: PCAP file with IEC-104 traffic to 10.82.40.105 in NetworkMiner

In each thread Industroyer2 paused for approximately 3 seconds between each accessed IOA. This delay seems to have been hard coded since the malware didn't seem to care whether or not the IEC-104 server responded with an OK message, such as ACT or ACTTERM, or an error message, like “unknown common address of ASDU”. Each thread would simply proceed with setting an IOA every 3 seconds no matter what the server responded.

The specific order in which the IOAs were accessed was also very deterministic, the exact same sequence of IOAs was used every time. I verified this behavior by running the malware multiple times as well as by comparing my results to an execution of the same sample on a different sandbox (thanks for the PCAP Joe and Dan).

What Did the Attackers Know?

The fact that the malware toggled these specific outputs, rather than just randomly turning outputs ON or OFF, indicates that the threat actors had technical knowledge about the specific substation(s) they were attacking. Not only did the attackers know the IP addresses, station addresses and IOAs of each targeted output. They also knew what ASDU Type ID to use for each respective output. For IOA 1101 to 1404 the Type ID 46 was used (also known as "double command" or C_DC_NA_1) while for IOAs from 130202 and above it used Type ID 45 (also known as “single command” or C_SC_NA_1).

As you can see in the previous screenshots, NetworkMiner nicely parses and presents the IEC-104 commands issued by Industroyer2. But I noticed that the malware also printed all sent and received commands to the console when executed. For example, the following output was printed to the console by the Industroyer2 thread communicating with station address 2 on 192.168.122.2:

The string “192.168.122.2: 2404: 2” above reveals that “2404” is the target port and “2” is the station address. The “SGCNT 8” string additionally tells us that there were 8 outputs to be toggled on that station. The other two stations had SGCNT 16 and 44.

The malware also printed very detailed information about each sent and received IEC-104 command, such as in the example below where the output at IOA 1104 was successfully turned off at station address 2 (here referred to as “ASDU:2”).

Note that the Type ID values were also logged to the console by Industroyer2, but it used the term “Telegram type” instead of “Type ID”.

Static Analysis

The following three Unicode strings can be found in the 40_115.exe binary:

10.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 1 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 1 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 0 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 260910 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 0 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 1402 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 0 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 42 1103 0 0 0 1 43 1104 0 0 0 1 44

192.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 1105 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

192.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 1259 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 8 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 0 0 0 1 15 1251 0 0 0 1 16

After having analyzed the IEC-104 traffic from the binary it's obvious that this is the IEC-104 configuration that has been hard-coded into the binary. For example, the substring “10.82.40.105 2404 3” in the first Unicode string refers to the IP, port and station number of the first target.

The “16 1258 [...]” section in the third Unicode string above tells us that there are 16 outputs configured for station address 1, where the first one to be set is at IOA 1258. Thus, we can easily verify that all accessed IOAs on all three stations were hard-coded into the binary.

Additional Substations Targeted

The malware sample I've analyzed has the following properties:

• Filename: 40_115.exe
• MD5: 7c05da2e4612fca213430b6c93e76b06
• SHA1: fdeb96bc3d4ab32ef826e7e53f4fe1c72e580379
• SHA256: d69665f56ddef7ad4e71971f06432e59f1510a7194386e5f0e8926aea7b88e00
• Compiled: 2022-03-23 10:07:29 UTC

But there is an additional Industroyer2 sample called “108_100.exe” (MD5 3229e8c4150b5e43f836643ec9428865), which has been mentioned by ESET as well as CERT-UA. I haven't been able to access that binary though, so I don't yet know which IP addresses it was designed to target. However, a few screenshots [1] [2] [3] published by ESET reveal that the 108_100.exe malware sample was hard coded to access 8 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 image in CERT-UA's alert #4435 from April 12 reveals the targeted IOAs for these 8 stations.

Targets hard-coded in 108_100.exe ordered by station address:

• SA#1, 192.x.x.x, 12 IOAs (1101-1104, 1201-1204, 1301-1304)
• SA#2, 10.x.x.x, 12 IOAs (1101-1104, 1201-1204, 1301-1304)
• SA#3, 192.x.x.x, 18 IOAs (1103-1104, 1201-1204, 1301-?, 38601-38607)
• SA#4, 10.x.x.x, 34 IOAs (16501, 16603, 26502, 38507-38513, 38519-38524 and more...)
• SA#5, 192.x.x.x, 10 IOAs (1101-1103, 1201-1204, 1301-1303)
• SA#6, 10.x.x.x, 8 IOAs (1101-1104, 1201-1204)
• SA#7, 10.x.x.x, 8 IOAs (1101-1104, 1201-1204)
• SA#8, 10.x.x.x, 8 IOAs (1101-1104, 1201-1204)

We can compare those station addresses, IP addresses and IOAs to the ones targeted by the 40_115.exe sample, which was analyzed in this blog post.

• SA#1, 192.168.121.2, 16 IOAs (1250-1265)
• SA#2, 192.168.122.2, 8 IOAs (1101-1108)
• SA#3, 10.82.40.105, 44 IOAs (1101-1104, 1201-1204, 1301-1304, 1401-1404, 130202, 160921-160928, 190202, 260202, 260901-260920, 290202, 338501)

There doesn't seem to be any overlap across the two sets (except for possibly station address 1 which is on the 192.x.x.x network in both configs but has different IOAs). This indicates that the 108_100.exe Industroyer2 version was hard coded to attack a different set of targets than the 40_115.exe sample that I've analyzed.

More ICS blog posts from Netresec

If you'd like to find our earlier work in the field of ICS/SCADA security, then check out these (slightly older but still very relevant) blog posts:

• 2011: Monitor those Control System Networks!
• 2012: SCADA Network Forensics with IEC-104
• 2014: Full Disclosure of Havex Trojans
• 2014: Observing the Havex RAT
• 2015: From 4SICS with ICS PCAP Files

Posted by Erik Hjelmvik on Monday, 25 April 2022 10:35:00 (UTC/GMT)

Tags: #IEC-104​ #60870-5-104​ #ICS​ #ICS​ #SCADA​ #PCAP​

Reverse Engineering Proprietary ICS Protocols

One of the highlights at this year’s SEC-T conference in Stockholm was Steve Miller’s talk titled "Reversing the TriStation Network Protocol". In this talk Steve covered his quest to better understand the TRITON malware, which had been used in a targeted attack of an industrial control system (ICS). Steve didn’t disclose the type or location of the plant, saying “Don’t ask me who it was, ‘cause I can’t say” when the Q&A started. However, an article in the Wall Street Journal points out that it was a petrochemical plant in Saudi Arabia that had been hacked.

Targeting Safety Instrumented System

The TRITON malware (also called TRISIS) was used to target a safety instrumented system (SIS) from Schneider Electric called Triconex. A SIS is typically not used to control the process of a plant, but rather to detect abnormal operating conditions and safely shut down the industrial process if needed.

I could elaborate a lot regarding the consequences of attacking the SIS, but the good guys from Dragos have already done a great job explaining this in their “TRISIS Malware” report.

Reverse Engineering the ICS Protocol

The communication protocol used by the Triconex controllers is called TriStation, which is a proprietary protocol. This means that there were no publicly available specifications available for the protocol at that time. There was also no Wireshark dissector that could parse TriStation traffic. Nevertheless, Steve’s initial reaction to this was “Awesome, undocumented things are my favorite things!”

Unfortunately Steve wasn’t able to get hold of a single PCAP file with the TriStation network protocol, which made it really difficult to reverse engineer the protocol implementation in the TRITON malware. The only piece of actual TriStation network traffic he was able to get hold of was a hex dump of a TriStation packet in an academic paper.

Armed with only the hexdump and Wireshark’s text2pcap Steve managed to piece together an actual PCAP file containing a single frame with a TriStation packet inside.

As you can see in the image above, Wireshark doesn’t decode any of the application layer data coming from TCP port 1502 (which TriStation uses). He therefore implemented a Wireshark Lua dissector for the TriStation protocol. And some time later the people from Nozomi Networks even implemented a proper Wireshark dissector for the TriStation protocol.

BSI’s ICS-SEC team have now also created Snort IDS rules specifically for the TriStation protocol. These IDS rules trigger on events like:

• Packets sent to the controller from an unauthorized host
• Malicious commands used by the TRITON malware to read and write to the RAM of the SIS controller as well as to execute code

The Importance of Sniffing ICS Traffic

I’ve been trying to convince asset owners, who use ICS in their power plants, factories, water treatment facilities etc, to start capturing the network traffic and storing it as PCAP files for many years now. However, asset owners sometimes try to argue that there is no point in capturing their traffic since it is using a proprietary protocol. Even Ralph Langner has opposed to the idea of capturing ICS network traffic in a blog post, which I have criticized. So, how difficult is it to write a parser for a proprietary protocol?

I have personally implemented support for over 30 application layer protocols in NetworkMiner, but unlike Steve I’ve always had access to at least one PCAP file and some form of documentation of the protocol. However, I’ve found that many real-world protocol implementations don’t follow specifications properly. In these cases I’ve found that having access to PCAP files with real-world network traffic is more important than having a full protocol specification.

Even complex proprietary protocols like the old proprietary Skype protocol has been reverse engineered, so with access to network traffic of a protocol combined with a binary that uses this protocol I’d say that pretty much any network protocol can be reverse engineered.

Steve’s SEC-T talk also proves that ICS protocols are no different, since they too can be reverse engineered without having a protocol specification or RFC.

Capturing network traffic in ICS networks is never wrong. There might not be parsers available today for all the protocols you’re using. But once a parser or IDS signature becomes available for the protocol you’re using, you can simply use that to analyze previously captured network traffic from your ICS network. Also, in the wake of an incident you might actually end up writing a parser (as in the TRITON case) or a custom IDS rule, in which case having historical network traffic from your plant in invaluable!

For more information on this topic I’d suggest reading my blog post titled “Monitor those Control System Networks!” from 2011, which still is highly relevant.

I’m also happy to announce that two PCAP files containing TriStation network traffic have been linked from our list of publicly accessible PCAP files today (see the “SCADA/ICS Network Captures” section).

And remember: PCAP or it didn’t happen!

Posted by Erik Hjelmvik on Friday, 21 September 2018 14:20:00 (UTC/GMT)

Tags: #ICS​ #PCAP​ #SCADA​ #SEC-T​ #protocol​ #Wireshark​ #Snort​

From 4SICS with ICS PCAP Files

4SICS is the the leading Industrial Control System (ICS) security conference in Europe, which brings in speakers and attendees from all around the world. I tought a one-day class on analyzing network traffic as part of the pre-conference training at 4SICS. In this class we analyzed PCAP files containing industrial protocols, such as Modbus/TCP and IEC-104. Unfortunately there aren't many capture files around that carry these protocols, so the ICS analysis part in my class wasn't as advanced as I wanted it to be.

I have been aware of this limited access to ICS traffic for some time now, which is why I decided to work with the 4SICS crew in order to set up a sniffer in the ICS lab at the 4SICS conference. This lab contained devices such as PLCs, RTUs, servers, industrial network equipment (switches, firewalls, etc), which were available for hands-on "testing" by 4SICS attendees.

The network TAP vendor Garland were Technology Partners at 4SICS, so I didn't even have to bring a network TAP to the lab. I just connected my sniffer machine and let it record for three days. Chris Sistrunk also joined the sniffing party later in the conference by connecting his SEL-3355, which runs SecurityOnion, to the network TAP.

The 350MB of network traffic that was captured during the 4SICS conference is now publicly available here:
https://www.netresec.com/?page=PCAP4SICS

Enjoy!

Posted by Erik Hjelmvik on Wednesday, 04 November 2015 15:45:00 (UTC/GMT)

Tags: #ICS​ #SCADA​ #PCAP​ #4SICS​ #IEC-104​ #Modbus​ #sniffer​ #PLC​

Full Disclosure of Havex Trojans

I did a talk on "SCADA Network Forensics" at the 4SICS conference last week, where I disclosed the results from my analysis of the Havex RAT/backdoor.

The Havex backdoor is developed and used by a hacker group called Dragonfly, who are also known as "Energetic Bear" and "Crouching Yeti". Dragonfly is an APT hacker group, who have been reported to specifically target organizations in the energy sector as well as companies in other ICS sectors such as industrial/machinery, manufacturing and pharmaceutical.

In my 4SICS talk I disclosed a previously unpublished comprehensive view of ICS software that has been trojanized with the Havex backdoor, complete with screenshots, version numbers and checksums.

Dale Petersen, founder of Digital Bond, expressed the following request regarding the lack of public information about the software trojanized with Havex:

If the names of the vendors that unwittingly spread Havex were made public, the wide coverage would likely reach most of the affected asset owners.

Following Dale's request we decided to publish the information presented at 4SICS also in this blog post, in order to reach as many affected asset owners as possible. The information published here is based on our own sandbox executions of Havex malware samples, which we have obtained via CodeAndSec and malwr.com. In addition to what I presented at 4SICS, this blog post also includes new findings published by Joel "scadahacker" Langill in version 2.0 of his Dragonfly white paper, which was released just a couple of hours after my talk.

In Symantec's blog post about Havex they write:

Three different ICS equipment providers were targeted and malware was inserted into the software bundles

Trojanized MESA Imaging driver

The first vendor known to have their software trojanized by the Dragonfly group was the Swiss company MESA Imaging, who manufacture industrial grade cameras for range measurements.

Image: Screenshot of trojanized MESA Imaging driver installer from our sandbox execution

eWON / Talk2M

The second vendor to have their software trojanized was the Belgian company eWON, who provide a remote maintenance service for industrial control systems called “Talk2M”.

eWon published an incident report in January 2014 and then a follow-up report in July 2014 saying:

Back in January 2014, the eWON commercial web site www.ewon.biz had been compromised. A corrupted eCatcherSetup.exe file had been uploaded into the CMS (Content Management System) of www.ewon.biz web site. eCatcher download hyperlinks were rerouted to this corrupted file. The corrupted eCatcherSetup.exe contained a malware which could, under restricted conditions, compromise the Talk2M login of the infected user.

Image: Screenshot of trojanized Talk2M eCatcher installer from our sandbox execution

Prior to version 2.0 of Joel's Dragonfly report, eCatcher was the only product from eWON known to be infected with the Havex backdoor. However, Joel's report also listed a product called “eGrabit”, which we managed to obtain a malware sample for via malwr.com.

Image: Screenshot of trojanized eGrabIt installer from our sandbox execution

MB Connect Line

The most recent company known to have their software infected with the Havex backdoor was the German company MB Connect Line GmbH, who are known for their industrial router mbNET and VPN service mbCONNECT24.

MB Connect Line published a report about the Dragonfly intrusion in September 2014, where they write:

On 16th of April 2014 our website www.mbconnectline.com has been attacked by hackers. The files mbCHECK (Europe), VCOM_LAN2 and mbCONFTOOL have been replaced with infected files. These files were available from 16th of April 2014 to 23th of April 2014 for download from our website. All of these files were infected with the known Trojan Virus Havex Rat.

Image: Screenshot of trojanized mbCONFTOOL installer from our sandbox execution

Image: Screenshot of trojanized mbCHECK application from our sandbox execution

Notice how only mbCHECK for users in Europe was trojanized, there has been no report of the USA/CAN version of mbCHECK being infected with Havex.

We have not been able to get hold of a malware sample for the trojanized version of VCOM_LAN2. The screenshot below is therefore from a clean version of this software.

Image: Screenshot VCOM_LAN2 installer

Conclusions on Havex Trojans

The vendors who have gotten their software trojanized by Dragonfly are all European ICS companies (Switzerland, Belgium and Germany). Additionally, only the mbCHECK version for users in Europe was infected with Havex, but not the one for US / Canada. These facts indicate that the Dragonfly / Energetic Bear threat actor seems to primarily target ICS companies in Europe.

Next: Detecting Havex with NSM

Read our follow-up blog post Observing the Havex RAT, which shows how to detect and analyze network traffic from ICS networks infected with Havex.

Posted by Erik Hjelmvik on Monday, 27 October 2014 11:11:00 (UTC/GMT)

Tags: #Havex​ #ICS​ #SCADA​ #Trojan​ #4SICS​