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​ #ICS​ #ICS​ #SCADA​ #PCAP​

NetworkMiner 2.4 Released

We are proud to announce the release of NetworkMiner 2.4 today! The new version comes with several improvements, such as username extraction from Kerberos traffic, better OS fingerprinting and even better Linux support.

Protocol Updates

The Kerberos v5 implementation in NetworkMiner 2.4 can be used to to extract usernames, hostnames and realms (domains) from unencrypted Kerberos requests/responses on port 88. NetworkMiner also parses and extracts usernames etc. from HTTP auth headers and SMB security blobs when they use Kerberos for authentication.

NetworkMiner also automatically attempts to parse traffic to TCP port 11371 as HTTP in order to extract GPG keys sent using the HKP protocol.

MAC Address Magic

We’ve added two new features related to MAC addresses to this release. One of them is the “MAC Age” field (showing “2000-11-09” in the previous screenshot), which is a guesstimate of how hold a device/host is based on its MAC address. This functionality uses HD Moore’s mac-ages database, which contains approximate dates for when hardware address ranges were allocated by IEEE (original concept from DeepMac).

The second MAC feature is a simple yet useful feature that adds links between hosts that share the same MAC address. This feature is useful for linking a host's IPv6 and IPv4 addresses with each other, but it can also be used to track if a physical host has changed its IP address. The MAC address links can be accessed by expanding the MAC address node in NetworkMiner’s Hosts tab.

ICS Asset Inventory

We’ve put in some ground work in order to create OS fingerprinting signatures for several Industrial Control System (ICS) devices. Our signatures have been submitted and merged into Eric Kollmann’s Satori TCP database, which NetworkMiner uses to passively fingerprint hosts by examining various TCP and IP fields in the initial SYN/SYN+ACK packets of TCP sessions. The ICS devices we’ve added include PLCs, RTUs as well as rugged network equipment from vendors like ABB, Allen-Bradley, Modicon, Moxa, Phoenix Contact and Siemens. Some ICS vendors even got an icon showing their logo in the Hosts tab (see the Siemens/RUGGEDCOM device in the screenshot below) while the others got a yellow hard hat.

EternalBlue

NetworkMiner isn’t designed to be used as an IDS. Nevertheless we decided to add detection for the EternalBlue exploit to NetworkMiner 2.4. The fact that NetworkMiner parses NetBIOS and SMB makes it pretty straightforward to identify when an attacker is attempting to allocate a large non-paged pool in srvnet.sys by using a vulnerability in Microsoft’s SMB implementation (see MS17-010 for reference). This type of detection is difficult to perform using a standard IDS solution that cannot parse the NetBIOS and SMB protocols. Detected EternalBlue exploit attempts are listed in NetworkMiner's “Anomalies” tab. Example PCAP files with attackers/malware using the EternalBlue exploit can be found here:

• https://www.malware-traffic-analysis.net/2018/10/04/index.html
• https://www.malware-traffic-analysis.net/2018/08/17/index.html
• https://packettotal.com/app/analysis?id=c8850b1fe07572c82c6fac5db5aae0c9
• https://packettotal.com/app/analysis?id=8d2fdb7698c27e32e88bde809c89216f

NetworkMiner in Linux

NetworkMiner is a Windows tool, but it actually runs just fine also in other operating systems with help of the Mono Framework (see our guide “HowTo install NetworkMiner in Ubuntu Fedora and Arch Linux”). However, there are a few pitfalls that must be avoided to get the software running smoothly using Mono. With this release we’ve implemented workarounds for two bugs in Mono’s GUI implementation (System.Windows.Forms).

The first workaround handles a Mono bug that sometimes could be triggered by Drag-and-Dropping a file or image from NetworkMiner to another application, such as a browser, text editor or image viewer. Doing so would previously trigger a NullReferenceException in System.Windows.Forms.X11Dnd+TextConverter.SetData under certain conditions. We’re happy to report that you can now reliably drag and drop files extracted by NetworkMiner to other tools, even when running Linux.

The second workaround handles a bug in Mono’s GDIPlus implementation related to rendering of Unicode characters. We were unfortunately not able to reliably get Mono to render Unicode characters, NetworkMiner will therefore convert all Unicode MIME data to ASCII when using Mono (typically in Linux). Windows users will still get the proper Unicode representations of exotic characters and emojis in NetworkMiner though. ☺

NetworkMiner Professional

The commercial version of NetworkMiner, i.e. NetworkMiner Professional, comes with a few additional improvements. One of them is is that the following additional online sources have been added to the OSINT lookup feature:

• Wayback Machine (URL lookup)
• Alexa Rank (DNS lookup)
• Kaspersky Application Advisor (file hash lookup)

The CSV export from NetworkMinerCLI has been updated to use the ISO 8601 format with explicit time zone for timestamps. An exported timestamp now look something like this:

2019-01-08T13:37:00.4711000+02:00

NetworkMiner Professional 2.4 also identifies application layer protocols regardless of port number (a.k.a. PIPI) with much better precision than earlier versions. It also extracts audio from VoIP calls (SIP) more reliably than before.

Credits

I would like to thank Chris Sistrunk for requesting GUI support to link IPv4 and IPv6 hosts with the same MAC address and Jonas Lejon for the HKP GPG key extraction idea. I would also like to thank Phil Hagen for notifying us about the issue with Unicode in emails when running NetworkMiner under Mono and Ahmad Nawawi for notifying us about the protocol identification shortages in the previous version.

Upgrading to Version 2.4

Users who have purchased a license for NetworkMiner Professional 2.x can download a free update to version 2.4 from our customer portal. Those who instead prefer to use the free and open source version can grab the latest version of NetworkMiner from the official NetworkMiner page.

⛏ FOR GREAT JUSTICE! ⛏

Posted by Erik Hjelmvik on Thursday, 10 January 2019 14:20:00 (UTC/GMT)

Tags: #NetworkMiner​ #ICS​ #Kerberos​ #SIP​ #VoIP​ #IPv6​ #Mono​ #Linux​ #OSINT​ #PIPI​

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​ #Wireshark​ #Snort​

10 Years of NetworkMiner

I released the first version of NetworkMiner on February 16, 2007, which is exactly 10 years ago today.

One of the main uses of NetworkMiner today is to reassemble file transfers from PCAP files and save the extracted files to disk. However, as you can see in the screenshot above, the early versions of NetworkMiner didn’t even have a Files tab. In fact, the task that NetworkMiner was originally designed for was simply to provide an inventory of the hosts communicating on a network.

How it all started

So, why did I start designing a passive asset detection system when I could just as well have used a port scanner like Nmap to fingerprint the devices on a network? Well, I was working with IT security at the R&D department of a major European energy company at the time. As part of my job I occasionally performed IT security audits of power plants. During these audits I typically wanted to ensure that there were no rouge or unknown devices on the network. The normal way of verifying this would be to perform an Nmap scan of the network, but that wasn’t an option for me since I was dealing with live industrial control system networks. I knew from personal experience that a network scan could cause some of the industrial control system devices to drop their network connections or even crash, so active scanning wasn’t a viable option. Instead I chose to setup a SPAN port at a central point of the network, or even install a network TAP, and then capture network traffic to a PCAP file during a few hours. I found the PCAP files being a great source, not only for identifying the hosts present at a network, but also in order to discover misconfigured devices. However, I wasn’t really happy with the tools available for visualizing the devices on the network, which is why I stated developing NetworkMiner in my spare time.

Network Forensics

As I continued improving NetworkMiner I pretty soon ended up writing my own TCP reassembly engine as well as parsers for HTTP and the CIFS protocol (a.k.a SMB). With these protocols in place I was able to extract files downloaded through HTTP or SMB to disk with NetworkMiner, which turned out to be a killer feature.

With the ability to extract file transfers from PCAP files NetworkMiner steadily gained popularity as a valuable tool in the field of network forensics, which motivated me to make the tool even better. Throughout these past 10 years I have single-handedly implemented over 60 protocols in NetworkMiner, which has been a great learning experience for me.

NetworkMiner Milestones

• 2007-02-16 First release of NetworkMiner on SourceForge
• 2008-08-01 NetworkMiner is featured in Russ McRee’s toolsmith column for August 2008.
• 2008-09-01 Richard Bejtlich blogs about NetworkMiner 0.85 on the TaoSecurity blog
• 2011-03-04 First release of NetworkMiner Professional and the command line version NetworkMinerCLI.
• 2011-11-11 NetworkMiner ranked #85 among SecTools.Org’s “Top 125 Network Security Tools”
• 2011-11-19 Cross platform support (works in Linux, Mac OSX etc).
• 2011-12-16 REMnux Linux distro includes NetworkMiner
• 2011-12-27 Security Onion Linux distro includes NetworkMiner
• 2013-09-15 Support for PcapNG capture file format in NetworkMiner Professional 1.5
• 2016-02-19 Project hosting moved from SourceForge to netresec.com

Looking Forward

People sometimes ask me what I’m planning to add to the next version of NetworkMiner. To be honest; I never really know. In fact, I’ve realized that those with the best ideas for features or protocols to add to NetworkMiner are those who use NetworkMiner as part of their jobs, such as incident responders and digital forensics experts across the globe.

I therefore highly value feedback from users, so if you have requests for new features to be added to the next version, then please feel free to reach out and let me know!

Posted by Erik Hjelmvik on Thursday, 16 February 2017 09:11:00 (UTC/GMT)

Tags: #Netresec​ #NetworkMiner​ #NSM​ #ICS​

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​

Observing the Havex RAT

It has, so far, been publicly reported that three ICS vendors have spread the Havex Remote-Access-Tool (RAT) as part of their official downloads. We've covered the six pieces of software from these three vendors in our blog post ”Full Disclosure of Havex Trojans”. In this blog post we proceed by analyzing network traffic generated by Havex.

Indicators of Compromise

Before going into details of our analysis we'd like to recommend a few other resources that can be used to detect the Havex RAT. There are three Havex IDS signatures available via Emerging Threats. There are also Yara rules and OpenIOC signatures available for Havex. Additionally, the following domains are known to be used in the later versions (043 and 044) of Havex according to Kaspersky:

• disney.freesexycomics.com
• electroconf.xe0.ru
• rapidecharge.gigfa.com
• sinfulcelebs.freesexycomics.com
• www.iamnumber.com

HTTP Command-and-Control

The Havex RAT Command-and-Control (C2) protocol is based on HTTP POST requests, which typically look something like this:

POST /blogs/wp-content/plugins/buddypress/bp-settings/bpsettings-src.php?id=84651193834787196090098FD80-c8a7af419640516616c342b13efab&​v1=043&​v2=170393861&​q=45474bca5c3a10c8e94e56543c2bd

As you can see, four variables are sent in the QueryString of this HTTP POST request; namely id, v1, v2 and q. Let's take a closer look to see what data is actually sent to the C2 server in the QueryString.

Analyzing a Havex PCAP

I had the pleasure to discuss the Havex Malware with Joel Langill, when we met at the 4SICS conference in Stockholm last month. Joel was nice enough to provide me with a 800 MB PCAP file from when he executed the Havex malware in an Internet connected lab environment.

I used the command line tool NetworkMinerCLI (in Linux) to automatically extract all HTTP downloads from Joel's PCAP file to disk. This way I also got a CSV log file with some useful metadata about the extracted files. Let's have a closer look at what was extracted:

$ mono NetworkMinerCLI.exe -r new-round-09-setup.pcap
Closing file handles...
970167 frames parsed in 1337.807 seconds.

$ cut -d, -f 1,2,3,4,7,12 new-round-09-setup.pcap.FileInfos.csv | head

SourceIP   SourcePort  DestinationIP  DestinationPort  FileSize   Frame
185.27.134.100   TCP 80   192.168.1.121   TCP 1238   244 676 B       14
198.63.208.206   TCP 80   192.168.1.121   TCP 1261       150 B     1640
185.27.134.100   TCP 80   192.168.1.121   TCP 1286   359 508 B     3079
185.27.134.100   TCP 80   192.168.1.121   TCP 1311   236 648 B     4855
185.27.134.100   TCP 80   192.168.1.121   TCP 1329       150 B    22953
185.27.134.100   TCP 80   192.168.1.121   TCP 1338       150 B    94678
185.27.134.100   TCP 80   192.168.1.121   TCP 1346       150 B   112417
198.63.208.206   TCP 80   192.168.1.121   TCP 1353       150 B   130108
198.63.208.206   TCP 80   192.168.1.121   TCP 1365       150 B   147902

Files downloaded through Havex C2 communication are typically modules to be executed. However, these modules are downloaded in a somewhat obfuscated format; in order to extract them one need to do the following:

• Base64 decode
• Decompress (bzip2)
• XOR with ”1312312”

To be more specific, here's a crude one-liner that I used to calculate MD5 hashes of the downloaded modules:

$ tail -c +95 C2_download.html | base64 -d | bzcat -d | xortool-xor -s "1312312" -f - -n | tail -c +330 | md5sum

To summarize the output from this one-liner, here's a list of the downloaded modules in Joel's PCAP file:

All three extracted modules are known binaries associated with Havex. The third module is one of the Havex OPC scanner modules, let's have a look at what happens on the network after this module has been downloaded!

Analyzing Havex OPC Traffic

In Joel's PCAP file, the OPC module download finished at frame 5117. Less then a second later we see DCOM/MS RPC traffic. To understand this traffic we need to know how to interpret the UUID's used by MS RPC.

Marion Marschalek has listed 10 UUID's used by the Havex OPC module in order to enumerate OPC components. However, we've only observed four of these commands actually being used by the Havex OPC scanner module. These commands are:

Of these commands the ”IOPC Browse” is the ultimate goal for the Havex OPC scanner, since that's the command used to enumerate all OPC tags on an OPC server. Now, let's have a look at the PCAP file to see what OPC commands (i.e. UUID's) that have been issued.

$ tshark -r new-round-09-setup.first6000.pcap -n -Y 'dcerpc.cn_bind_to_uuid != 99fcfec4-5260-101b-bbcb-00aa0021347a' -T fields -e frame.number -e ip.dst -e dcerpc.cn_bind_to_uuid -Eoccurrence=f -Eheader=y

frame.nr  ip.dst      dcerpc.cn_bind_to_uuid
5140    192.168.1.97  000001a0-0000-0000-c000-000000000046
5145    192.168.1.11  000001a0-0000-0000-c000-000000000046
5172    192.168.1.97  000001a0-0000-0000-c000-000000000046
5185    192.168.1.11  9dd0b56c-ad9e-43ee-8305-487f3188bf7a
5193    192.168.1.97  000001a0-0000-0000-c000-000000000046
5198    192.168.1.11  55c382c8-21c7-4e88-96c1-becfb1e3f483
5212    192.168.1.11  00000143-0000-0000-c000-000000000046
5247    192.168.1.11  000001a0-0000-0000-c000-000000000046
5257    192.168.1.11  00000143-0000-0000-c000-000000000046
5269    192.168.1.11  00000143-0000-0000-c000-000000000046
5274    192.168.1.11  39c13a4d-011e-11d0-9675-0020afd8adb3
5280    192.168.1.11  39c13a4d-011e-11d0-9675-0020afd8adb3
5285    192.168.1.11  39227004-a18f-4b57-8b0a-5235670f4468
5286    192.168.1.11  39227004-a18f-4b57-8b0a-5235670f4468
[...]

We can thereby verify that the IOPCBrowse command was sent to one of Joel's OPC servers in frame 5285 and 5286. However, tshark/Wireshark is not able to parse the list of OPC items (tags) that are returned from this function call. Also, in order to find all IOPCBrowse commands in a more effective way we'd like to search for the binary representation of this command with tools like ngrep or CapLoader. It would even be possible to generate an IDS signature for IOPCBrowse if we'd know what to look for.

The first part of an MSRPC UUID is typically sent in little endian, which means that the IOPCBrowse command is actually sent over the wire as:

04 70 22 39 8f a1 57 4b 8b 0a 52 35 67 0f 44 68

Let's search for that value in Joel's PCAP file:

Image: Searching for IOPCBrowse byte sequence with CapLoader

Image: CapLoader with 169 extracted flows matching IOPCBrowse UUID

Apparently 169 flows contain one or several packets that match the IOPCBrowse UUID. Let's do a “Flow Transcript” and see if any OPC tags have been sent back to the Havex OPC scanner.

Image: CapLoader Transcript of OPC-DA session

Oh yes, the Havex OPC scanner sure received OPC tags from what appears to be a Waterfall unidirectional OPC gateway.

Another way to find scanned OPC tags is to search for a unique tag name, like “Bucket Brigade” in this example.

Posted by Erik Hjelmvik on Wednesday, 12 November 2014 21:09:00 (UTC/GMT)

Tags: #Havex​ #PCAP​ #NSM​ #ICS​ #C2​ #NetworkMinerCLI​ #CapLoader​

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​