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​

NetworkMiner 2.8 Released

I am happy to announce the release of NetworkMiner 2.8 today! This new version comes with an improved user interface, better parsing of IEC-104 traffic and decapsulation of CAPWAP traffic. The professional edition of NetworkMiner additionally adds port-independent detection of SMTP and SOCKS traffic, which enables extraction of emails and tunneled traffic even when non-standard ports are used.

User Interface Improvements

The first thing you see when starting NetworkMiner is the Hosts tab, which now has been updated to include a filter text box. This text box can be used to filter the displayed hosts based on the property fields they contain. By entering “Android” into the filter box NetworkMiner will show only the hosts having a property containing the string “Android”, for example in the OS classification or User-Agent string. Other properties you might find useful to filter on are hostname, JA3 hash and MAC address. If you’re running NetworkMiner Professional then you’ll also be able to filter on Country thanks to the MaxMind GeoLite2 feature included in the Pro edition.

It’s now also possible to copy text from most tabs in NetworkMiner with Ctrl+C or by right-clicking and selecting “Copy selected rows”. A maximum of 10 rows can be copied at a time using the free version of NetworkMiner, while the Professional version allows all rows to be copied in one go.

The content based file type identification introduced in NetworkMiner 2.7 has been improved to also differentiate between EXE and DLL files as of version 2.8.

• Matanbuchus malware DLL disguised as PNG
• MD5: d733d96a25fd14f4494f6d76f9ff9892
• Source: 2022-06-17-Matanbuchus-with-Cobalt-Strike.pcap

• AutoIt EXE disguised as ZIP file
• MD5: c56b5f0201a3b3de53e561fe76912bfd
• Source: 2022-08-19-Astaroth-Guildma-infection-traffic.pcap

IEC 60870-5-104

NetworkMiner’s parser for the SCADA protocol IEC 60870-5-104 (IEC-104) has been significantly improved in version 2.8. NetworkMiner now supports more IEC-104 commands and the commands are presented on the Parameters tab in a clearer way than before.

Image: IEC-104 commands sent by the Industroyer2 malware

I’m also proud to announce that NetworkMiner 2.8 now extracts files transferred over the IEC-104 protocol. More details about that particular feature is available in our IEC-104 File Transfer Extraction blog post.

CAPWAP Decapsulation

NetworkMiner 2.8 can read IEEE 802.11 packets inside CAPWAP tunnels between WLAN Controllers and Access Points. This feature allows WiFi traffic to be analyzed without having to capture packets in the air.

Reading PCAP from a Named Pipe

NetworkMiner previously allowed packets to be read from PacketCache over a named pipe. This feature has been upgraded to allow a PCAP stream to be read from any named pipe, not just from PacketCache. Here’s an example showing how to capture packets from localhost for 10 seconds with RawCap and make those packets available via a named pipe called “RawCap”:

RawCap will start capturing packets once a PCAP reader connects to the “RawCap” named pipe, which now can be done with NetworkMiner by clicking “Read from Named Pipe” on the File menu.

Bug Fixes

NetworkMiner previously produced incorrect JA3S signatures for TLS servers if they sent Session ID values in Server Hello messages or listed only one supported TLS version using the Supported Versions extension. These bugs have now been fixed in NetworkMiner 2.8.

NetworkMiner’s live sniffing feature has been improved to better handle huge packets caused by Large Send Offload (LSO). NetworkMiner previously crashed with an error message saying that the received packet was “larger than the internal message buffer” when attempting to capture a too large packet.

TCP sessions occasionally didn’t show up in NetworkMiner’s Sessions tab previously if the application layer protocol was unknown. This bug has now been fixed in version 2.8.

New Features in NetworkMiner Professional

NetworkMiner Professional includes a feature for port independent protocol detection of protocols like FTP, HTTP, IRC, Meterpreter, SSH and TLS, which enables extraction of artifacts from those protocols even though the service is running on a non-standard port. This new release adds two additional protocols to the collection of identified protocols, namely SMTP and SOCKS. This allows analysts to extract emails from spam runs sent to ports other than 25 or 587, as well as to see what goes on inside covert SOCKS tunnels running on non-standard ports.

Image: SMTP credentials extracted from spam run to non-standard SMTP port

In addition to allowing hosts to be filtered using string and regex matching, NetworkMiner Professional also allows the discovered hosts to be filtered on IP address using CIDR notation, such as “192.168.1.0/24” or “10.0.0.0/8”.

Image: NetworkMiner Professional with CIDR filter 192.168.88.0/24

Here are some IPv4 and IPv6 CIDR filters that you might find useful:

• 224.0.0.0/4 = IPv4 multicast (224/4 is also supported)
• 127.0.0.0/8 = IPv4 loopback (127/8 is also supported)
• fe80::/10 = IPv6 link-local addresses
• ff00::/8 = IPv6 multicast
• 0.0.0.0/0 = IPv4 hosts (0/0 is also supported)
• 0::/0 = IPv6 hosts

Credits

We’d like to thank René Perraux, Matt Smith and Anand Kumar Singh for reporting bugs that have been fixed in this new release.

Upgrading to Version 2.8

Users who have purchased NetworkMiner Professional can download a free update to version 2.8 from our customer portal, or use the “Check for Updates” feature from NetworkMiner's Help menu. Those who instead prefer to use the free and open source version can grab the latest version of NetworkMiner from the official NetworkMiner page.

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

Tags: #NetworkMiner​ #IEC-104​ #SMTP​ #SOCKS​ #PIPI​ #CIDR​

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​

CapLoader 1.9 Released

A new version of the PCAP filtering tool CapLoader has been released today. The new CapLoader version 1.9 is now even better at identifying protocols and periodic beacons than before. The user interface has also been improved to make it easier to filter and drill down in network traffic to extract interesting, malicious or unusual traffic.

More Protocols Identified

We’ve added port-independent protocol detection for over 20 new protocols since the last release. The newly added protocols include some that are used by malicious tools and backdoors such as hTran, RevengeRAT, Tofsee and Winsecsrv, as well as legitimate protocols like WireGuard (VPN) and RemoteFX (UDP based remote desktop). We’ve also improved our support for ICS traffic analysis by adding protocol identification of SCADA protocols DNP3 and IEC 60870-5-104.

CapLoader also detects what we call “sub-protocols”, which are communication protocols that use other L7 protocols as transport. We have extended the sub-protocol detection in CapLoader 1.9 to include traffic like Anchor_DNS and dnscat traffic, which both run on top of DNS. We have also added detection of Cobalt Strike beacons over HTTP and HTTPS, even though the latter is quite difficult to detect due to the application data being encrypted.

Improved Usability

CapLoader 1.9 comes with several user interface improvements that help you solve the “needle in the haystack” problem even more efficiently than before.

The context menus in the Flows, Services and Hosts tabs can now be used to select rows based on values in any column, such as “Select all flows where Duration > 10 minutes” (when right-clicking a 10 minute flow).

The “Keyword Filter” is now called “Row Filter” in order to avoid getting it mixed up with the “Find Keyword” feature. The Row Filter has also been enhanced with a new filtering mode, to complement the Contains / All Words / Any Words / RegEx options, which is called “Column Criteria”. The Column Criteria can be used to filter the displayed rows based on the values in a user-specified column. The Column Criteria “Duration > 00:10:00” will, for example, only show flows that are 10 minutes or longer, while “ASN = 3301” shows the flows going to Telia’s AS3301.

Image: CapLoader with Row Filter Column Criteria "Duration > 00:10:00"

We have also extended CapLoader's BPF implementation to support VLAN id’s, so that you can use expressions like “vlan 100” as input filter as well as display filter. The BPF implementation also supports logic operators, so that more advanced filters like “(tcp port 80 or port 443) and not net 149.154.172.0/22” can be used.

CapLoader has a method for detecting periodic connection patterns, which was introduced in CapLoader 1.4. This feature can be used to detect clients that connect to a service at regular intervals, such as a beacon used for command-and-control or email client connecting to a mail server. We have improved the periodicity detection in CapLoader 1.9 so that it now detects periodic services more accurately.

The Initial Round Trip Time (iRRT) in the Flows and Services tabs is now measured in milliseconds instead of seconds in order to avoid “bulky numbers” (h/t Eddi).

There was previously a significant delay when selecting many flows at once (like 100.000). We’ve improved the performance of this feature in CapLoader 1.9, so that you can now select several hundred thousands flows at once without having to wait for an unresponsive GUI to update.

More OSINT Lookup Services

A feature in CapLoader that often comes in handy is the ability to right-click a flow, service or host and open a website with OSINT information about the clicked IP address or domain name. We have now replaced some of the OSINT services with new better ones.

The new services we’ve added to CapLoader 1.9 for performing online OSINT lookups of IP addresses, network services and domain names are:

• CIRCL BGP Ranking
• Hacker Target Reverse Lookup
• IPAddress.com
• OpenDNS
• RIPEstat
• RiskIQ
• Scamalytics
• Spur
• Spyse
• ThreatFox
• URLhaus
• ZoomEye

Bug fixes and Credits

Several bugs have been fixed in this new release of CapLoader, much thanks to feedback we’ve received from our users. We’d like to thank Anders Regert and Mandy van Oosterhout for reporting bugs in CapLoaders “Save As” feature. We’d also like to thank Hyun Dowon for reporting a snap length corruption bug that previously appeared when exporting flows from Pcap-NG files We have also fixed an issue where capture files were previously not always merged in chronological order when being aggregated.

Updating to the Latest Release

Users who have purchased a license for CapLoader can download a free update to version 1.9 from our customer portal. All others can download a free 30 day trial from the CapLoader product page (no registration required).

Posted by Erik Hjelmvik on Tuesday, 25 May 2021 12:20:00 (UTC/GMT)

Tags: #Netresec​ #CapLoader​ #PCAP​ #Pcap-NG​ #IEC-104​ #CobaltStrike​ #BPF​ #periodicity​ #OSINT​

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​