NETRESEC Network Security Blog

Monday, 27 October 2014 11:11:00 (UTC/GMT)

Full Disclosure of Havex Trojans

I did a presentation at the 4SICS conference last week, where I disclosed the results from my analysis of the Havex RAT/backdoor (slides available here).

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

lib MESA SR Installer - SwissrangerSetup1.0.14.706.exe

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

Company:MESA Imaging
Product:Swiss Ranger version (libMesaSR)
Exposure:Six weeks in June and July 2013 (source: Symantec)
Backdoor:Sysmain RAT

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 had been compromised. A corrupted eCatcherSetup.exe file had been uploaded into the CMS (Content Management System) of 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.

eWON Talk2M eCatcher Installer - eCatcherSetup.exe

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

Product:Talk2M eCatcher version
Exposure:Ten days in January 2014, 250 copies downloaded (source: Symantec)
Backdoor:Havex 038

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

eWON eGrabIt Installer - egrabitsetup.exe

Image: Screenshot of trojanized eGrabIt installer from our sandbox execution

Product:eGrabIt (version 3.0 Build 82)
Backdoor:Havex RAT 038

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

MB Connect Line mbCONFTOOL setup - setup_1.0.1.exe

Image: Screenshot of trojanized mbCONFTOOL installer from our sandbox execution

Company:MB Connect Line GmbH
Product:mbCONFTOOL V 1.0.1
Exposure:April 16 to April 23, 2014 (source: MB Connect Line)
Backdoor:Havex RAT 044

MB Connect Line mbCHECK - mbCHECK.exe

Image: Screenshot of trojanized mbCHECK application from our sandbox execution

Company:MB Connect Line GmbH
Product:mbCHECK (EUROPE) V 1.1.1
Exposure:April 16 to April 23, 2014 (source: MB Connect Line)
Backdoor:Havex RAT 044

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.

MB Connect Line VCOM_LAN2 setup - setupvcom_lan2.exe

Image: Screenshot VCOM_LAN2 installer

Company:MB Connect Line GmbH
Exposure:April 16 to April 23, 2014 (source: MB Connect Line)

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

We're currently working on a follow-up blog post, which shows how to detect and analyze network traffic from ICS networks infected with Havex.

More... Share  |  Facebook   Twitter   Reddit   Hacker News Short URL:

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

Monday, 20 October 2014 13:35:00 (UTC/GMT)

Chinese MITM Attack on iCloud

Users in China are reporting a MITM attacks on SSL connections to iCloud., who monitor the Great Firewall of China (GFW), also published a blog post on their website earlier today saying:

This is clearly a malicious attack on Apple in an effort to gain access to usernames and passwords and consequently all data stored on iCloud such as iMessages, photos, contacts, etc.

Fake SSL Certificate

In their blog post GreatFire also linked a packet capture file, which we have analyzed in order to verify the MITM attack. We loaded the PcapNG file into NetworkMiner Professional and extracted the X.509 SSL certificate.

NetworkMiner with fake iCloud certificate

The extracted certificate can be downloaded from here. Also, here are a few details from this X.509 certificate:

$ openssl x509 -inform DER -in -noout -issuer -subject -startdate -enddate -fingerprint
issuer= /C=cn/
subject= /C=cn/
notBefore=Oct 4 10:35:47 2014 GMT
notAfter=Oct 4 10:35:47 2015 GMT
SHA1 Fingerprint=F4:68:B5:F3:FE:D8:07:97:44:76:A2:2B:32:EA:31:37:D9:24:F7:BA

As reported elsewhere, the certificate was self signed, which means that browsers and most iPhone apps will either inform the user about the connection being unsafe or simply close the connection. This use of self signed certificates is consistent with previous SSL MITM attacks performed in China against GitHub, Google, Yahoo and

Location of the MITM Attack

By looking at host the information provided by NetworkMiner for the fake iCloud SSL server we can see that it is just six router hops away from the client (having an IP TTL value of 58). This indicates that the MITM attack is being performed within China, since we'd expect to see at least three more router hops if the packets were coming from outside China.

NetworkMiner showing host details for MITM'ed iCloud server

The same PCAP file also contains packets from the same IP address on TCP port 80, which have traveled 11 hops (IP TTL 53). We therefore assume that only traffic to TCP port 443 is being MITM'ed.

This TTL analysis also matches various TCP traceroutes we've seen to the MITM'ed iCloud SSL service on

                        My traceroute [v0.85]
siyanmao-k29 (                        Sat Oct 18 19:26:07 2014

Host                          Loss% Snt  Last   Avg  Best  Wrst StDev
1.                0.0%   17   0.6   0.7   0.6   0.8   0.0
2. -------------              0.0%   16   2.8   2.6   1.7   3.3   0.3
3. -------------              0.0%   16   2.0   2.2   1.4   4.0   0.4
4. ???
5.              0.0%   16   6.4   7.7   4.3  27.0   5.2
6.               25.0%   16 168.5 171.4 166.8 201.3   9.4
mtr TCP 443 traceroute to (source:

bearice@Bearice-Mac-Air-Haswell ~
%tcptraceroute 443
Selected device en0, address, port 52406 for outgoing packets
Tracing the path to on TCP port 443 (https), 30 hops max
1 1.737 ms 0.793 ms 0.798 ms
2 2.893 ms 2.967 ms 2.422 ms
3 2.913 ms 2.893 ms 3.968 ms
4 4.824 ms 2.658 ms 3.902 ms
5 3.626 ms 6.532 ms 3.794 ms
6 27.539 ms 26.821 ms 27.661 ms
7 ( [open] 30.064 ms 29.899 ms 30.126 ms
tcptraceroute to 443 (source: bearice on GitHub)

Tcproute by @chenshaoju
Tcproute traceroute to on TCP 443 (source: @chenshaoju)

Judging from these TCP traceroutes the MITM attacks seem to be taking place at several different locations rather centrally in the Chinese Internet infrastructure. To be more specific, it appears as if the MITM attacks are being performed on backbone networks belonging to China Telecom (CHINANET) as well as China Unicom.

More... Share  |  Facebook   Twitter   Reddit   Hacker News Short URL:

Posted by Erik Hjelmvik on Monday, 20 October 2014 13:35:00 (UTC/GMT)

Wednesday, 01 October 2014 21:55:00 (UTC/GMT)

Verifying Chinese MITM of Yahoo

Yahoo Umbrella sent out a tweet yesterday saying that “Yahoo appears to under Man-in-the-middle attack in China. 3rd case of country-wide MITM, after Google, Github”.

Mashable later ran a story called “China Appears to Attack Yahoo in Latest Censorship of Hong Kong Protests”, where Lorenzo Franceschi-Bicchierai write:

In what's almost unprecedented, China appears to be targeting Yahoo with what's called a "man-in-the-middle attack." With such an attack, connections to, which are normally encrypted, would be vulnerable to snooping, and Chinese censors could also block search terms or specific Yahoo links with the goal of preventing Chinese netizens from accessing information about the protests in Hong Kong.

In this blog post we verify that there is an ongoing Man-in-the-Middle (MITM) attack by analyzing two different packet capture files.

Capture LocationCapture DateFilenameMD5
Wuxi, China 2014-09-30
10:15 (UTC)
Yahoo.pcapng5633a0cce5955b44 18189fe3fd27847d
Zhengzhou, China2014-09-30
11:35 (UTC)
YahooMITM.pcapng722ca9b7837416ef 2391b48edd20d24e

Both PCAP files were created with Wireshark/dumpcap using a capture filter of “host”, which is the IP address that was reported to be MITM'ed by the Great Firewall of China (GFW). This IP address is located in Hong Kong and is used by Yahoo to host, etc. for users in this part of Asia.

Time-To-Live (TTL) Analysis

We estimate the distance between the end users and the Yahoo server in Hong Kong to be at least 10 router hops. However, the IP packets coming back to the users have IP TTL values of 58 (Wuxi) and 57 (Zhengzhou). This implies that the MITM is performed somewhere in China, just 6 or 7 router hops away from the users. This is consistent with what we've observed in previous MITM attacks performed by China against GitHub and Google.

CapLoader 1.2 Hosts tab with
IMAGE: Hosts tab in CapLoader showing TTL 57 for

X.509 Certificate Analysis

We have extracted a X.509 certificate from one of the PcapNG files to a .cer file using NetworkMiner. This SSL certificate is available for download here.

$ openssl x509 -inform DER -in -noout -issuer -subject -startdate -enddate -fingerprint
issuer= /C=cn/
subject= /C=cn/
notBefore=Sep 23 11:30:17 2014 GMT
notAfter=Sep 23 11:30:17 2015 GMT
SHA1 Fingerprint=22:90:C3:11:EA:0F:3F:57:E0:6D:F4:5B:69:8E:18:E8:28:E5:9B:C3

The certificate is a self signed certificate for “”. The fact that the MITM uses a self signed certificate makes the attack easily detectable even for the non-technical user, since the web browser will typically display a warning about the site not being trusted.

Some may think it's odd that China can't forge a properly signed certificate for their SSL MITM attack. However, they've used very similar self signed certificates also in their previous MITM attacks against GitHub and Google. The purpose of GFW (a.k.a. “Golden Shield”) is to censor the Internet, so the primary goal with this MITM attack isn't to covertly spy on Chinese Yahoo searches. Regardless if the end users notice the MITM or not, a self signed X.509 cert is enough in order to see what they are searching for and “kill” their connection to Yahoo when queries like “Umbrella Revolution” and “Tiananmen Square Protests” are observed.

More... Share  |  Facebook   Twitter   Reddit   Hacker News Short URL:

Posted by Erik Hjelmvik on Wednesday, 01 October 2014 21:55:00 (UTC/GMT)

Thursday, 04 September 2014 23:55:00 (UTC/GMT)

Analysis of Chinese MITM on Google

The Chinese are running a MITM attack on SSL encrypted traffic between Chinese universities and Google. We've performed technical analysis of the attack, on request from, and can confirm that it is a real SSL MITM against and that it is being performed from within China.

We were contacted by yesterday (September 3) with a request to analyze two packet captures from suspected MITM-attacks before they finalized their blog post. The conclusions from our analysis is now published as part of's great blog post titled “Authorities launch man-in-the-middle attack on Google”.

In their blog post write:

From August 28, 2014 reports appeared on Weibo and Google Plus that users in China trying to access and via CERNET, the country’s education network, were receiving warning messages about invalid SSL certificates. The evidence, which we include later in this post, indicates that this was caused by a man-in-the-middle attack.

While the authorities have been blocking access to most things Google since June 4th, they have kept their hands off of CERNET, China’s nationwide education and research network. However, in the lead up to the new school year, the Chinese authorities launched a man-in-the-middle (MITM) attack against Google.

Our network forensic analysis was performed by investigating the following to packet capture files:

Capture LocationClient NetnameCapture DateFilenameMD5
Peking UniversityPKU6-CERNET2Aug 30, 7a8a7656cd670a93
Chongqing UniversityCQU6-CERNET2Sep 1, 2014google_fake.pcapng3bf943ea453f9afa 5c06b9c126d79557

Client and Server IP adresses

The analyzed capture files contain pure IPv6 traffic (CERNET is a IPv6 network) which made the analysis a bit different then usual. We do not disclose the client IP addresses for privacy reasons, but they both seem legit; one from Peking University (netname PKU6-CERNET2) and the other from Chongqing University (CQU6-CERNET2). Both IP addresses belong to AS23910, named "China Next Generation Internet CERNET2".

PekingUniversityPic6 by galaygobi
Peking University entrance, by galaygobi (Creative Commons Attribution 2.0)

CQUAQUGATE3 by Brooktse
Chongqing University gate, by Brooktse (Creative Commons Attribution-Share Alike 3.0)

The IP addresses received for were in both cases also legit, so the MITM wasn't carried out through DNS spoofing. The Peking University client connected to 2607:f8b0:4007:804::1013 (GOOGLE-IPV6 in United States) and the connection from Chongqing University went to 2404:6800:4005:805::1010 (GOOGLE_IPV6_AP-20080930 in Australia).

Time-To-Live (TTL) Analysis

The Time-To-Live (TTL) values received in the IP packets from were in both cases 248 or 249 (note: TTL is actually called ”Hop Limit” in IPv6 nomenclature, but we prefer to use the well established term ”TTL” anyway). The highest possible TTL value is 255, this means that the received packets haven't made more than 6 or 7 router hops before ending up at the client. However, the expected number of router hops between a server on GOOGLE-IPV6 and the client at Peking University is around 14. The low number of router hops is is a clear indication of an IP MITM taking place.

CapLoader 1.2, Hosts tab
Image: CapLoader with both capture files loaded, showing TTL values

Here is an IPv6 traceroute from AS25795 in Los Angeles towards the IP address at Peking University (generated with ARP Networks' tool):

#traceroute -6 2001:da8:201:[REDACTED]
 1  2607:f2f8:1600::1 (2607:f2f8:1600::1) 1.636 ms 1.573 ms 1.557 ms
 2  2001:504:13::1a (2001:504:13::1a) 40.381 ms 40.481 ms 40.565 ms
 3  * * *
 4  2001:252:0:302::1 (2001:252:0:302::1) 148.409 ms 148.501 ms 148.595 ms
 5  * * *
 6  2001:252:0:1::1 (2001:252:0:1::1) 148.273 ms 147.620 ms 147.596 ms
 7 (2001:da8:1:1b::2) 147.574 ms 147.619 ms 147.420 ms
 8  2001:da8:1:50d::2 (2001:da8:1:50d::2) 148.582 ms 148.670 ms 148.979 ms
 9 (2001:da8:ac:ffff::2) 147.963 ms 147.956 ms 147.988 ms
10  2001:da8:201:[REDACTED] 147.964 ms 148.035 ms 147.895 ms
11  2001:da8:201:[REDACTED] 147.832 ms 147.881 ms 147.836 ms
12  2001:da8:201:[REDACTED] 147.809 ms 147.707 ms 147.899 ms

As can be seen in the traceroute above, seven hops before the client we find the 2001:252::/32 network, which is called “CNGI International Gateway Network (CNGIIGN)”. This network is actually part of CERNET, but on AS23911, which is the network that connects CERNET with its external peers. A reasonable assumption is therefore that the MITM is carried out on the 2001:252::/32 network, or where AS23910 (2001:da8:1::2) connects to AS23911 (2001:252:0:1::1). This means that the MITM attack is being conducted from within China.

Response Time Analysis

The round-trip time between the client and server can be estimated by measuring the time from when the client sends it initial TCP SYN packet to when it receives a TCP SYN+ACK from the server. The expected round-trip time for connecting from CERNET to a Google server overseas would be around 150ms or more. However, in the captures we've analyzed the TCP SYN+ACK package was received in just 8ms (Peking) and 52ms (Chongqing) respectively. Again, this is a clear indication of an IP MITM taking place, since Google cannot possibly send a response from the US to CERNET within 8ms regardless of how fast they are. The fast response times also indicate that the machine performing the MITM is located fairly close to the network at Peking University.

Even though the machine performing the MITM was very quick at performing the TCP tree-way handshake we noticed that the application layer communication was terribly slow. The specification for the TLS handshake (RFC 2246) defines that a ClientHello message should be responded to with a ServerHello. Google typically send their ServerHello response almost instantly, i.e. the response is received after one round-trip time (150ms in this case). However, in the analyzed captures we noticed ServerHello response times of around 500ms.

X.509 Certificate Analysis

The X.509 certificates were extracted from the two PCAP files to .cer files using NetworkMiner. We noticed that both users received identical certificates, which were both self signed for “”. The fact that the MITM used a self signed certificate makes the attack easily detectable even for the non-technical user, since the web browser will typically display a warning about the site not being trusted. Additionally the X.509 certificate was created for ”” rather than ”*”. This is an obvious miss from the MITM'ers side since they were attempting to MITM traffic to ”” but not to ””.

NetworkMiner 1.6.1, Files tab
Image: NetworkMiner showing list of X.509 certificates extracted from the two PCAP files

Certificate SHA1 fingerprint: f6beadb9bc02e0a152d71c318739cdecfc1c085d
Certificate MD5 fingerprint: 66:D5:D5:6A:E9:28:51:7C:03:53:C5:E1:33:14:A8:3B

A copy of the fake certificate is available on Google drive thanks to


All evidence indicates that a MITM attack is being conducted against traffic between China’s nationwide education and research network CERNET and It looks as if the MITM is carried out on a network belonging to AS23911, which is the outer part of CERNET that peers with all external networks. This network is located in China, so we can conclude that the MITM was being done within the country.

It's difficult to say exactly how the MITM attack was carried out, but we can dismiss DNS spoofing as the used method. The evidence we've observed instead indicate that the MITM attack is performed either by performing IP hijacking or by simply reconfiguring a router to forward the HTTPS traffic to a transparent SSL proxy. An alternative to changing the router config would also be to add an in-line device that redirects the desired traffic to the SSL proxy. However, regardless of how they did it the attacker would be able to decrypt and inspect the traffic going to Google.

We can also conclude that the method used to perform the MITM attack was similar to the Chinese MITM on GitHub, but not identical.

More... Share  |  Facebook   Twitter   Reddit   Hacker News Short URL:

Posted by Erik Hjelmvik on Thursday, 04 September 2014 23:55:00 (UTC/GMT)

Tuesday, 24 June 2014 21:25:00 (UTC/GMT)

Running NetworkMiner on Mac OS X

Apple Logo

The following is a guest blog post written by Jonas Lejon from the Swedish IT security company Triop, which specialize in crypto, reverse engineering and penetration testing.

This guide describes how to get NetworkMiner running on Mac OS X Mavericks (version 10.9.3).

First of all, download NetworkMiner and then go to the Mono downloads page and get the latest version for Mac OS X:

Mono downloads page

After the download of “Mono MRE installer” has completed, just run the installer:

Mono Framework Installer

Press “Continue” to proceed installing the Mono Framework using the guided installer.

When the Mono Framework has been installed you can extract the downloaded NetworkMiner zip archive. Then start NetworkMiner from the terminal like this:

$ mono NetworkMiner.exe
NetworkMiner 1.6 on Mac OS X - Click To Enlarge

Live sniffing with NetworkMiner on Mac OS X

Live sniffing with WinPcap or Raw Sockets is only available when running NetworkMiner in Windows. However, live sniffing can still be achieved on Mac OSX (as well as in Linux) by using the PCAP-over-IP functionality. Simply select [File > Receive PCAP over IP] or press [Ctrl]+R and select a TCP port to listen on (TCP 57012 is the default port).

Pcap-over-IP in NetworkMiner 1.6 on Mac OS X

Press the “Start Receiving” button and then use tcpdump to do live sniffing and forward all captured packets to NetworkMiner like this:

$ sudo tcpdump -i en0 -s0 -U -w - | nc localhost 57012

The preferred way to use NetworkMiner is, however, to load previously captured packets in a PCAP file and let NetworkMiner dig out all interesting details like transmitted files, images, messages, SSL certificates etc.

For more info on how to run NetworkMiner on other operating systems, please see our previous blog posts HowTo install NetworkMiner in Ubuntu Fedora and Arch Linux and No more Wine - NetworkMiner in Linux with Mono.

More... Share  |  Facebook   Twitter   Reddit   Hacker News Short URL:

Posted by Jonas Lejon on Tuesday, 24 June 2014 21:25:00 (UTC/GMT)

Monday, 16 June 2014 11:00:00 (UTC/GMT)

NetworkMiner 1.6 Released

We've released version 1.6 of NetworkMiner today!

Confetti in Toronto by Winnie Surya Image credits: Confetti in Toronto by Winnie Surya

The new features in NetworkMiner 1.6 include:

  • Drag-and-Drop
    Reassembled files and images can be opened with external tools by drag-and-dropping items from NetworkMiner's Files or Images tabs onto your favorite editor or viewer.

  • Email extraction
    Improved extraction of emails and attachments sent over SMTP.

  • DNS analysis
    Failed DNS lookups that result in NXDOMAIN and SERVFAIL are displayed in the DNS tab along with the flags in the DNS response.

  • Live sniffing
    Improved live sniffing performance.

  • PCAP-over-IP
    Remote live sniffing enabled by bringing the PCAP-over-IP feature into the free open source version of NetworkMiner.

Identifying Malware DNS lookups

NetworkMiner Professional 1.6 with DNS traffic from the Contagio Kuluoz-Asprox

DNS traffic from the Kuluoz-Asprox botnet (PCAP file available via Contagio)

Note the NXDOMAIN responses and “No” in Alexa top 1 million column in the screenshot above; these domains are probably generated by a domain generation algorithm (DGA).

Live Sniffing with Pcap-over-IP

The PCAP-over-IP functionality enables live sniffing also on non-Windows machines, simply by running tcpdump (or dumpcap) and netcat like this:

# tcpdump -i eth0 -s0 -U -w - | nc localhost 57012
For more information about how to run NetworkMiner in Linux, please read our HowTo install NetworkMiner in Ubuntu Fedora and Arch Linux blog post.

To receive the Pcap-over-IP stream in NetworkMiner, simply press Ctrl+R and select a TCP port.

NetworkMiner Pcap-over-IP

For more information about this feature please see our previous blog post about the PCAP‑over‑IP feature.

NetworkMiner Professional

The professional version of NetworkMiner additionally contains the following improvements of the command line tool NetworkMinerCLI:

  • Enabled reading of PCAP and PcapNG data from standard input (STDIN)
  • Full support for PCAP-over-IP
  • More detailed DNS logging in NetworkMinerCLI's CSV export of DNS responses

The ability to read PCAP data from STDIN with NetworkMinerCLI makes it really simple to do live extraction of emails and email attachments. Here's an example showing how to do live SMTP extraction in Linux:

# tcpdump -i eth0 -s0 -w - port 25 or 587 | mono NetworkMinerCLI.exe -r - -w /var/log/smtp_extraction/

The syntax for extracting emails and attachments in Windows is very similar:

C:\>dumpcap.exe -i 1 -f "port 25 or 587" -w - | NetworkMinerCLI.exe -r -

The TCP ports 25 and 587, which are used in the capture filter above, are the standard port numbers for SMTP. In order to do live extraction of files sent over HTTP, simply use “port 80” as capture filter instead. Likewise, X.509 certificates can also be extracted from HTTPS sessions simply by using “port 443” as capture filter.

Download NetworkMiner 1.6

The most recent release of the free (open source) version of NetworkMiner can be downloaded from SourceForge or our NetworkMiner product page. Paying customers can download an update for NetworkMiner Professional from our customer portal.


We would like to thank Dan Eriksson (FM CERT) and Lenny Hansson (Danish GovCERT) for submitting bug reports and feature requests.

More... Share  |  Facebook   Twitter   Reddit   Hacker News Short URL:

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

Thursday, 01 May 2014 21:45:00 (UTC/GMT)

PCAP or it didn't happen

The phrase "PCAP or it didn't happen" is often used in the network security field when someone want proof that an attack or compromise has taken place. One such example is the recent OpenSSL heartbleed vulnerability, where some claim that the vulnerability was known and exploited even before it was discovered by Google's Neel Mehta and Codenomicon.

PCAP or it didn't happen pwnie, original by Nina on
Image: PCAP or it didn't happen pwnie, original by Nina

After the Heartbleed security advisory was published, EFF tweeted:

"Anyone reproduced observations of #Heartbleed attacks from 2013?"
and Liam Randall (of Bro fame) tweeted:
"If someone finds historical exploits of #Heartbleed I hope they can report it. Lot's of sites mining now."

Liam Randall (@Hectaman) tweeting about historical Heartbleed searchesHeartbleed

It is unfortunately not possible to identify Heartbleed attacks by analyzing log files, as stated by the following Q&A from the website:

Can I detect if someone has exploited this against me?

Exploitation of this bug does not leave any trace of anything abnormal happening to the logs.

Additionally, IDS  signatures  for detecting the Heartbleed attacks weren't available until after implementations of the exploit code were being actively used in the wild.

Hence, the only reliable way of detecting early heartbleed attacks (i.e. prior to April 7) is to analyze old captured network traffic from before April 7. In order to do this you should have had a full packet capture running, which was configured to capture and store all your traffic. Unfortunately many companies and organizations haven't yet realized the value that historical packet captures can provide.

Why Full Packet Capture Matters

Some argue that just storing netflow data is enough in order to do incident response. However, detecting events like the heartbleed attack is impossible to do with netflow since you need to verify the contents of the network traffic.

Not only is retaining historical full packet captures useful in order to detect attacks that have taken place in the past, it is also extremely valuable to have in order to do any of the following:

  • IDS Verification
    Investigate IDS alerts to see if they were false positives or real attacks.

  • Post Exploitation Analysis
    Analyze network traffic from a compromise to see what the attacker did after hacking into a system.

  • Exfiltration Analysis
    Assess what intellectual property that has been exfiltrated by an external attacker or insider.

  • Network Forensics
    Perform forensic analysis of a suspect's network traffic by extracting files, emails, chat messages, images etc.

Setting up a Full Packet Capture

netsniff-ng logo

The first step, when deploying a full packet capture (FPC) solution, is to install a network tap or configure a monitor port in order to get a copy of all packets going in and out from your networks. Then simply sniff the network traffic with a tool like dumpcap or netsniff-ng. Another alternative is to deploy a whole network security monitoring (NSM) infrastructure, preferably by installing the SecurityOnion Linux distro.

A network sniffer will eventually run out of disk, unless captured network traffic is written to disk in a rung buffer manner (use "-b files" switch in dumpcap) or there is a scheduled job in place to remove the oldest capture files. SecurityOnion, for example, normally runs its "cleandisk" cronjob when disk utilization reaches 90%.

The ratio between disk space and utilized bandwidth becomes the maximum retention period for full packet data. We recommend having a full packet capture retention period of at least 7 days, but many companies and organizations are able to store several month's worth of network traffic (disk is cheap).

Big Data PCAP Analysis

Okay, you've got a PCAP store with multiple terabytes of data. Then what? How do you go about analyzing such large volumes of captured full content network traffic? Well, tasks like indexing and analyzing PCAP data is more complex matters than what can be covered in this blog post. We've covered the big data PCAP analysis topic in previous  blog posts, and there is more to come. However, capturing the packets to disk is a crucial first step in order to utilize the powers of network forensics. Or as the saying goes “PCAP or it didn't happen”.

More... Share  |  Facebook   Twitter   Reddit   Hacker News Short URL:

Posted by Erik Hjelmvik on Thursday, 01 May 2014 21:45:00 (UTC/GMT)


NETRESEC on Twitter

Follow @netresec on twitter:


Recommended Books

» The Practice of Network Security Monitoring, Richard Bejtlich (2013)

» Applied Network Security Monitoring, Chris Sanders and Jason Smith (2013)

» Network Forensics, Sherri Davidoff and Jonathan Ham (2012)

» The Tao of Network Security Monitoring, Richard Bejtlich (2004)

» Practical Packet Analysis, Chris Sanders (2011)

» Windows Forensic Analysis, Harlan Carvey (2009)

» TCP/IP Illustrated, Volume 1, Kevin Fall and Richard Stevens (2011)