NETRESEC Network Security Blog

10 Years of NetworkMiner

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

NetworkMiner 0.79 in Windows XP

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

How it all started

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

Network Forensics

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

Monthly downloads of NetworkMiner from SourceForge
Image: Monthly downloads of NetworkMiner from SourceForge

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

NetworkMiner Milestones

Looking Forward

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

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

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

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

Network Forensics Training at TROOPERS 2017

Troopers logo with Network Forensics Training

I will come back to the awesome TROOPERS conference in Germany this spring to teach my two-day network forensics class on March 20-21.

The training will touch upon topics relevant for law enforcement as well as incident response, such as investigating a defacement, finding backdoors and dealing with a machine infected with real malware. We will also be carving lots of files, emails and other artifacts from the PCAP dataset as well as perform Rinse-Repeat Intrusion Detection in order to detect covert malicious traffic.

Day 1 - March 20, 2017

The first training day will focus on open source tools that can be used for doing network forensics. We will be using the Security Onion linux distro for this part, since it contains pretty much all the open source tools you need in order to do network forensics.

Day 2 - March 21, 2017

We will spend the second day mainly using NetworkMiner Professional and CapLoader, i.e. the commercial tools from Netresec. Each student will be provided with a free 6 month license for the latest version of NetworkMiner Professional (see our recent release of version 2.1) and CapLaoder. This is a unique chance to learn all the great features of these tools directly from the guy who develops them (me!).

NetworkMiner   CapLoader

The Venue

The Troopers conference and training will be held at the Print Media Academy (PMA) in Heidelberg, Germany.

PMA Early Morning by Alex Hauk
Print Media Academy, image credit: Alex Hauk

Keeping the class small

The number of seats in the training will be limited in order to provide a high-quality interactive training. However, keep in mind that this means that the we might run out of seats for the network forensics class!

I would like to recommend those who wanna take the training to also attend the Troopers conference on March 22-24. The conference will have some great talks, like these ones:

However, my greatest takeaway from last year's Troopers was the awesome hallway track, i.e. all the great conversations I had with all the smart people who came to Troopers.

Please note that the tickets to the Troopers conference are also limited, and they seem to sell out quite early each year. So if you are planning to attend the network forensics training, then I recommend that you buy an “All Inclusive” ticket, which includes a two-day training and a conference ticket.

You can read more about the network forensics training at the Troopers website.

UPDATE 2017-02-15

The network forensics training at Troopers is now sold out. However, there are still free seats available in our network forensics class at 44CON in London in September.

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

Posted by Erik Hjelmvik on Tuesday, 24 January 2017 07:20:00 (UTC/GMT)

NetworkMiner 2.1 Released

NetworkMiner 2.1 Logo

We are releasing a new version of NetworkMiner today. The latest and greatest version of NetworkMiner is now 2.1.

Yay! /throws confetti in the air

Better Email Parsing

I have spent some time during 2016 talking to digital forensics experts at various law enforcement agencies. I learned that from time to time criminals still fail to use encryption when reading their email. This new release of NetworkMiner therefore comes with parsers for POP3 and IMAP as well as an improved SMTP parser. These are the de facto protocols used for sending and receiving emails, and have been so since way back in the 90’s.

Messages tab in NetworkMiner 2.1 showing extracted emails
Messages tab in NetworkMiner 2.1 showing extracted emails

Not only does NetworkMiner show the contents of emails within the tool, it also extracts all attachments to disk and even saves each email as an .eml file that can be opened in an external email reader in order to view it as the suspect would.

Extracted email Get_free_s.eml opened in Mozilla Thunderbird
Extracted email ”Get_free_s.eml” opened in Mozilla Thunderbird

Encapsulation Protocols

There are several protocols that can be used to provide logical separation of network traffic, in order to avoid using multiple physical networks to keep various network segments, security domains or users apart. Some of these techniques for logical separation rely on tagging or labeling, while others are tunneling the encapsulated traffic. Nevertheless, it’s all pretty much the same thing; an encapsulation protocol is used in order to wrap protocol X inside protocol Y, usually while adding some metadata in the process.

NetworkMiner has been able to parse the classic encapsulation protocols 802.1Q, GRE and PPPoE since 2011, but we now see an increased use of protocols that provide logical separation for virtualization and cloud computing environments. We have therefore added parsers in NetworkMiner 2.1 for VXLAN and OpenFlow, which are the two most widely used protocols for logical separation of traffic in virtualized environments. We have also added decapsulation of MPLS and EoMPLS (Ethernet-over-MPLS) to NetworkMiner 2.1.

Encapsulation examples for MPLS GRE and VXLAN

The new release additionally comes with support for the SOCKS protocol, which is an old school encapsulation protocol used by administrators as well as hackers in order to bypass firewalls or provide anonymous Internet access. The SOCKS parser in NetworkMiner can even be used to read network traffic from Tor in cleartext before it enters the Tor network. However, in order to capture Tor’s SOCKS traffic you’ll have to sniff traffic from the Tor client’s localhost interface on TCP port 9150.

PacketCache Logo


NetworkMiner 2.1 can read packets directly from a local PacketCache service by clicking ”File > Read from PacketCache”. This eliminates the need to run a PowerShell script in order to dump a PCAP file with packets recently captured by PacketCache.

HTTP Partial Content / Range Requests

Byte serving is a feature in HTTP that makes it possible to retrieve only a segment of a file, rather than the complete file, by using the “Range” HTTP header. This feature is often used by BITS in order to download updates for Windows. But we have also seen malware use byte serving, for example malware droppers that attempt to download malicious payloads in a stealthy manner. See Ursnif and Dridex for examples of malware that utilize this technique.

NetworkMiner has previously only reassembled the individual segments of a partial content download. But as of version 2.1 NetworkMiner has the ability to piece together the respective parts into a complete file.

SSL/TLS and X.509 Certificates

NetworkMiner has been able to extract X.509 certificates to disk for many years now, simply by opening a PCAP file with SSL traffic. However, in the 2.1 release we’ve added support for parsing out the SSL details also from FTP’s “AUTH TLS” (a.k.a explicit TLS or explicit SSL) and STARTTLS in SMTP.

NetworkMiner now also extracts details from the SSL handshake and X.509 certificate to the Parameters tab, such as the requested SNI hostname and the Subject CN from the certificate.

SSL and certificate information extracted by NetworkMiner from PCAP
SSL handshake details and certificate info passively extracted from captured HTTPS session to

NetworkMiner Professional

The new features mentioned so far are all part of the free open source version of NetworkMiner. But we have also added a few additional features to the Professional edition of NetworkMiner as part of the 2.1 release.

The “Browsers” tab of NetworkMiner Professional has been extended with a feature for tracking online ads and web trackers. We are using EasyList and EasyPrivacy from in order to provide an up-to-date tracking of ads and trackers. HTTP requests related to ads are colored red, while web tracker requests are blue. These colors also apply to the Files tab and can be modified in the Settings menu (Tools > Settings).

NetworkMiner Professional 2.1 showing Advertisments (red) and Trackers (blue)
NetworkMiner Professional 2.1 showing advertisments (red) and Internet trackers (blue).

The reason why NetworkMiner Pro now tracks ads and trackers is because these types of requests can make up almost half of the HTTP requests that a normal user makes while surfing the web today. Doing forensics on network traffic from a suspect criminal can be a very time consuming task, we therefore hope that being able to differentiate between what traffic that is initiated by the user rather than being triggered by an online advertisement service or internet tracker can save time for investigators.

The RIPE database previously contained a bug that prevented NetworkMiner Professional from properly leveraging netname info from RIPE. This bug has now been fixed, so that the Host Details can be enriched with details from RIPE for IP addresses in Europe. To enable the RIPE database you’ll first have to download the raw data by clicking Tools > Download RIPE DB.

Host Details with RIPE netname Host Details enriched with RIPE description and netname

We have also extended the exported details about the hosts in the CSV and XML files from NetworkMiner Professional and the command line tool NetworkMinerCLI. The exported information now contains details such as IP Time-to-Live and open ports.

Upgrading to version 2.1

Users who have purchased a license for NetworkMiner Professional 2.0 can download a free update to version 2.1 from our customer portal.

Those who instead prefer to use the free and open source version can grab the latest version of NetworkMiner from the official NetworkMiner page.


There are several persons I would like to thank for contributing with feature requests and bug reports that have been used to improve NetworkMiner. I would like to thank Dietrich Hasselhorn, Christian Reusch, Jasper Bongertz, Eddi Blenkers and Daniel Spiekermann for their feedback that have helped improve the SMB, SMB2 and HTTP parsers as well as implementing various encapsulation protocols. I would also like to thank several investigators at the Swedish, German and Dutch police as well as EUROPOL for the valuable feedback provided by them.

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

Posted by Erik Hjelmvik on Wednesday, 11 January 2017 14:30:00 (UTC/GMT)

BlackNurse Denial of Service Attack

Remember the days back in the 90s when you could cripple someones Internet connection simply by issuing a few PING command like “ping -t [target]”? This type of attack was only successful if the victim was on a dial-up modem connection. However, it turns out that a similar form of ICMP flooding can still be used to perform a denial of service attack; even when the victim is on a gigabit network.

The 90's called and wanted their ICMP flood attack back

BlackNurse logo

Analysts at TDC-SOC-CERT (Security Operations Center of the Danish telecom operator TDC) noticed how a certain type of distributed denial-of-service (DDoS) attacks were more effective than others. The analysts found that a special type of ICMP flooding attack could disrupt the network throughput for some customers, even if the attack was just using a modest bandwidth (less than 20Mbit/s). It turned out that Destination Unreachable ICMP messages (ICMP type 3), such as “port unreachable” (code 3) was consuming significantly more resources on some firewalls compared to the more common ICMP Echo messages associated with the Ping command. The TDC team have dubbed this particular ICMP flooding attack method “BlackNurse”.

TDC's own report about BlackNurse says:

“The BlackNurse attack attracted our attention, because in our anti-DDoS solution we experienced that even though traffic speed and packets per second were very low, this attack could keep our customers' operations down. This even applied to customers with large internet uplinks and large enterprise firewalls in place.”

Cisco ASA firewalls is one product line that can be flooded using the BlackNurse attack. Cisco were informed about the BlackNurse attack in June this year, but they decided to not classify this vulnerability as a security issue. Because of this there is no CVE or other vulnerability number associated with BlackNurse.

Evaluation of BlackNurse Denial-of-Service Attacks

Members of the TDC-SOC-CERT set up a lab network to evaluate how effective ICMP type 3 attacks were compared to other ICMP flooding methods. In this setup they used hping3 to send ICMP floods like this:

  • ICMP net unreachable (ICMP type 3, code 0):
    hping3 --icmp -C 3 -K 0 --flood [target]
  • ICMP port unreachable (ICMP type 3, code 3) a.k.a. “BlackNurse”:
    hping3 --icmp -C 3 -K 3 --flood [target]
  • ICMP Echo (Ping):
    hping3 --icmp -C 8 -K 0 --flood [target]
  • ICMP Echo with code 3:
    hping3 --icmp -C 8 -K 3 --flood [target]

The tests showed that Cisco ASA devices used more CPU resources to process the destination unreachable flood attacks (type 3) compared to the ICMP Echo traffic. As a result of this the firewalls start dropping packets, which should otherwise have been forwarded by the firewall, when hit by a BlackNurse attack. When the packet drops become significant the customer behind the firewall basically drops off the internet.

The tests also showed that a single attacking machine running hping3 could, on its own, produce enough ICMP type 3 code 3 packets to consume pretty much all the firewall's resources. Members of the TDC-SOC-CERT shared a few PCAP files from their tests with me, so that their results could be verified. One set of these PCAP files contained only the attack traffic, where the first part was generated using the following command:

hping3 --icmp -C 3 -K 3 -i u200 [target]

The “-i u200” in the command above instructs hping3 to send one packet every 200 microseconds. This packet rate can be verified simply by reading the PCAP file with a command like this:

tshark -c 10 -r attack_record_00001.pcapng -T fields -e frame.time_relative -e frame.time_delta -e frame.len -e icmp.type -e icmp.code
0.000000000   0.000000000   72   3   3
0.000207000   0.000207000   72   3   3
0.000415000   0.000208000   72   3   3
0.000623000   0.000208000   72   3   3
0.000830000   0.000207000   72   3   3
0.001038000   0.000208000   72   3   3
0.001246000   0.000208000   72   3   3
0.001454000   0.000208000   72   3   3
0.001661000   0.000207000   72   3   3
0.001869000   0.000208000   72   3   3

The tshark output confirms that hping3 sent an ICMP type 3 code 3 (a.k.a. “port unreachable”) packet every 208 microseconds, which amounts to rougly 5000 packets per second (pps) or 2.7 Mbit/s. We can also use the capinfos tool from the wireshark/tshark suite to confirm the packet rate and bandwidth like this:

capinfos attack_record_00001.pcapng
Number of packets:   48 k
File size:           5000 kB
Data size:           3461 kB
Capture duration:    9.999656 seconds
First packet time:   2016-06-08 12:25:19.811508
Last packet time:    2016-06-08 12:25:29.811164
Data byte rate:      346 kBps
Data bit rate:       2769 kbps
Average packet size: 72.00 bytes
Average packet rate: 4808 packets/s

A few minutes later they upped the packet rate, by using the “--flood” argument, instead of the 200 microsecond inter-packet delay, like this:

hping3 --icmp -C 3 -K 3 --flood [target]
capinfos attack_record_00007.pcapng
Number of packets:   3037 k
File size:           315 MB
Data size:           218 MB
Capture duration:    9.999996 seconds
First packet time:   2016-06-08 12:26:19.811324
Last packet time:    2016-06-08 12:26:29.811320
Data byte rate:      21 MBps
Data bit rate:       174 Mbps
Average packet size: 72.00 bytes
Average packet rate: 303 kpackets/s

The capinfos output reveals that hping3 was able to push a whopping 303.000 packets per second (174 Mbit/s), which is way more than what is needed to overload a network device vulnerable to the BlackNurse attack. Unfortunately the PCAP files I got did not contain enough normal Internet background traffic to reliably measure the degradation of the throughput during the denial of service attack, so I had to resort to alternative methods. The approach I found most useful for detecting disruptions in the network traffic was to look at the roundtrip times of TCP packets over time.

BlackNurse RTT Wireshark

The graph above measures the time between a TCP data packet and the ACK response of that data segment (called “tcp.analysis.ack_rtt” in Wireshark). The graph shows that the round trip time only rippled a little due to the 5000 pps BlackNurse attack, but then skyrocketed as a result of the 303 kpps flood. This essentially means that “normal” traffic was was prevented from getting though the firewall until the 303 kpps ICMP flood was stopped. However, also notice that even a sustained attack of just 37 kpps (21 Mbit/s or 27 μs inter-packet delay) can be enough to take a gigabit firewall offline.

Detecting BlackNurse Attacks

TDC-SOC-CERT have released the following SNORT IDS rules for detecting the BlackNurse attack:

alert icmp $EXTERNAL_NET any -> $HOME_NET any (msg:"TDC-SOC - Possible BlackNurse attack from external source "; itype:3; icode:3; detection_filter:track by_dst, count 250, seconds 1; reference:url,; metadata:TDC-SOC-CERT,18032016; priority:3; sid:88000012; rev:1;)

alert icmp $HOME_NET any -> $EXTERNAL_NET any (msg:"TDC-SOC - Possible BlackNurse attack from internal source"; itype:3; icode:3; detection_filter:track by_dst, count 250, seconds 1; reference:url,; metadata:TDC-SOC-CERT,18032016; priority:3; sid:88000013; rev:1;)

Protecting against BlackNurse Attacks

The recommendation from TDC is to deny ICMP type 3 messages sent to the WAN interface of Cisco ASA firewalls in order to prevent the BlackNurse attack. However, before doing so, please read the following excerpt from the Cisco ASA 5500 Series Command Reference:

“We recommend that you grant permission for the ICMP unreachable message type (type 3). Denying ICMP unreachable messages disables ICMP Path MTU discovery, which can halt IPSec and PPTP traffic. See RFC 1195 and RFC 1435 for details about Path MTU Discovery.”

In order to allow Path MTU discovery to function you will need to allow at least ICMP type 3 code 4 packets (fragmentation needed) to be received by the firewall. Unfortunately filtering or rate-limiting on a Cisco ASA does not seem to have an affect against the BlackNurse attack, the CPU max out anyway. Our best recommendation for protecting a Cisco ASA firewall against the BlackNurse attack is therefore to rate-limit incoming ICMP traffic on an upstream router.

Another alternative is to upgrade the Cisco ASA to a more high-end one with multiple CPU cores, since the BlackNurse attack seems to not be as effective on muti-core ASA's. A third mitigation option is to use a firewall from a different vendor than Cisco. However, please note that it's likely that other vendors also have products that are vulnerable to the BlackNurse attack.

To learn more about the BlackNurse attack, visit or download the full BlackNurse report from TDC.

Update November 12, 2016

Devices verified by TDC to be vulnerable to the BlackNurse attack:

  • Cisco ASA 5505, 5506, 5515, 5525 and 5540 (default settings)
  • Cisco ASA 5550 (Legacy) and 5515-X (latest generation)
  • Cisco 897 router
  • Cisco 6500 router (with SUP2T and Netflow v9 on the inbound interface)
  • Fortigate 60c and 100D (even with drop ICMP on). See response from Fortinet.
  • Fortinet v5.4.1 (one CPU consumed)
  • Palo Alto (unless ICMP Flood DoS protection is activated). See advisory from Palo Alto.
  • SonicWall (if misconfigured)
  • Zyxel NWA3560-N (wireless attack from LAN Side)
  • Zyxel Zywall USG50

Update November 17, 2016

There seems to be some confusion/amusement/discussion going on regarding why this attack is called the “BlackNurse”. Also, googling “black nurse” might not be 100 percent safe-for-work, since you risk getting search results with inappropriate videos that have nothing to do with this attack.

The term “BlackNurse”, which has been used within the TDC SOC for some time to denote the “ICMP 3,3” attack, is actually referring to the two guys at the SOC who noticed how surprisingly effective this attack was. One of these guys is a former blacksmith and the other a nurse, which was why a college of theirs jokingly came up with the name “BlackNurse”. However, although it was first intended as a joke, the team decided to call the attack “BlackNurse” even when going public about it.

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

Posted by Erik Hjelmvik on Thursday, 10 November 2016 07:40:00 (UTC/GMT)

Reading cached packets with Wireshark

Would you like to sniff packets that were sent/received some minutes, hours or even days ago in Wireshark? Can't afford to buy a time machine? Then your best chance is to install PacketCache, which allows you to read OLD packets with Wireshark. Wireshark reading from PacketCache

We recently released a free tool for keeping a cache of recently sent/received network traffic in Windows. The tool, called PacketCache, is actually a Windows service that saves a copy of recent packets in RAM. The cached packets can be read simply by connecting to a named pipe called “PacketCache”, for example by using a PowerShell script as shown on the PacketCache page.

After talking to some Wireshark core developers at SharkFest Europe last week we managed to get Wireshark to read packets from PacketCache's named pipe stream. However, you will need to use Wireshark 2.3 or later to properly read from a named pipe. Unfortunately version 2.3 isn't scheduled for release until next summer (2017), so until then you'll have to use one of the automated builds instead. I usually go for the latest WiresharkPortable build, since it doesn't require installation. You can download the portable version of Wireshark 2.3 here:

Look for a file called “WiresharkPortable_2.3.[something].paf.exe”.

Follow these steps in order to read packets captured by PacketCache:

  1. Make sure you have Wireshark 2.3.0 (or later)
  2. Start Wireshark with admin rights (right-click > “Run as administrator”)
  3. Run Wireshark as administrator
  4. Press: Capture > Options
  5. Click “Manage Interfaces...”
  6. Select the “Pipes” tab
  7. Press the “+” button to add a named pipe
  8. Name the pipe “\\.\pipe\PacketCache” and press ENTER to save it
  9. PacketCache pipe interface added in Wireshark
  10. Press “OK” in the Manage Interface window.
  11. Wireshark with a PacketCache pipe interface
  12. Press “Start” to read the packets from PacketCache

Wireshark reading from PacketCache

The status field in Wireshark will say “Live capture in progress”, which is somewhat true. Wireshark will be updating the GUI live as packets are read from PacketCache, but the packets displayed can be several hours or even days old depending on when they were captured by PacketCache. The “live” capture will stop once all packets have been read from the PacketCache.

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

Posted by Erik Hjelmvik on Friday, 28 October 2016 14:50:00 (UTC/GMT)

Detect TCP content injection attacks with findject

findject logo

NSA's QUANTUM INSERT attack is probably the most well-known TCP packet injection attack due to the Snowden revelations regarding how GCHQ used this method to hack into Belgacom. However, the “Five Eyes” are not the only ones who perform this type of attack on the Internet. We now release a tool to help incident responders to find these types of packet injection attacks.

Photo by Jasper Bongertz at SharkFest EU 2016

I had the opportunity to attend and present at SharkFest Europe last week. My presentation, titled “Dissecting Man-on-the-Side Attacks”, showed how TCP packet injection attacks can be analyzed if they have been recorded in a packet capture. In my talk I used a python script called “”, which reads PCAP files to find TCP packets with duplicate sequence numbers but different content. This script has previously only been shared with vetted parties, but as of my SharkFest presentation findject is now freely available for everyone.

Findject is not the first tool made available to detect TCP content injection attacks. Other detection methods include Suricata's reassembly_overlap_different_data alert, Fox-IT's Bro policy to check for inconsistencies in the first packet with payload, David Stainton's HoneyBadger and Martin Bruse's qisniff. Even though these are all great solutions we found that some of them didn't detect all TCP content injection attacks while others gave too many false positives. We also wanted to have a tool that was fast, portable and simple to use. This led us to create our own TCP injection detection tool.

python /nsm/pcap/live/*
opening /nsm/pcap/live/ppp0.150922_192034.pcap - no injections
opening /nsm/pcap/live/ppp0.150923_081337.pcap
'HTTP/1.1 403 Forbidden\r\nServer: Beaver\r\nCache-Control: no-cache\r\nContent-Type: text/html\r\nContent-Length: 594\r\nConnection: close\r\n\r\n<html>\n<head>\n<meta http-equiv="Content-Type" content="textml;charset=UTF-8" />\n <style>body{background-color:#FFFFFF}</style> \n<title>TestPage</title>\n <script language="javascript" type="text/javascript">\n window.onload = function () { \n document.getElementById("mainFrame").src= ""; \n }\n</script> \n</head>\n <body>\n <iframe style="width:860px; height:500px;position:absolute;margin-left:-430px;margin-top:-250px;top:50%;left:50%;" id="mainFrame" src="" frameborder="0" scrolling="no"></iframe>\n </body>\n </html>\n\n'
'HTTP/1.1 200 OK\r\nContent-Type: text/html\r\nContent-Length: 87\r\nConnection: close\r\n\r\n<html><head><meta http-equiv="refresh" content="0; url=\'\'"></head></html>'

opening /nsm/pcap/live/ppp0.150923_115034.pcap - no injections
opening /nsm/pcap/live/ppp0.150924_071617.pcap - no injections

In the example execution above we can see that detected an injected TCP packet in the file ppp0.150923_081337.pcap, while the other analyzed files contained no injections. The application layer data of the two conflicting TCP segments are printed to standard output with a header indicating whether the segment was the FIRST or LAST one. To find out which segment is the real one and which was the injected one we need to open the PCAP file in either Wireshark, tshark or CapLoader.

tshark -r /nsm/pcap/live/ppp0.150923_083317.pcap -Y "ip.src eq and tcp.port eq 59320" -T fields -e frame.number -e ip.src -e ip.dst -e tcp.seq -e tcp.len -e -e ip.ttl -o "tcp.relative_sequence_numbers: false"
14 402877219 0   0x00002e36 94
25 402877220 726 0x00000d05 70
27 402877220 726 0x00000d05 69
28 402877220 170 0x00002e3e 94

The tshark execution above reveals that three packets sent from the web server's IP ( are carrying data and have the same sequence number (402877220). Packet 25 and 27 are actually identical, while packet 28 is smaller (170 bytes) and has a different payload. The first displayed frame in the tshark output above is the SYN+ACK packet from the TCP 3-way handshake.

So how can we determine which of packets 25, 27 and 28 are real verses injected? Look at the IP-ID and IP-TTL values! Frame 28 has IP-ID and TTL values in line with what we see in the TCP 3-way handshake (TTL=94, IP-ID=0x00002e3e), which implies that this packet is probably authentic. Frames 25 and 27 on the other hand deviate from what we would expect from the server, which tells us that these packets were likely injected (spoofed) into the TCP session through a “man-on-the-side” attack.

findject logo

To learn more about and download the tool, please visit:

Example captures containing TCP content injection attacks can be found on our Publicly Available PCAP Files page under the “Packet Injection Attacks / Man-on-the-Side Attacks” section.

You can also read our blog posts Covert Man-on-the-Side Attacks and Packet Injection Attacks in the Wild to learn more about TCP packet injection attacks.

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

Posted by Erik Hjelmvik on Tuesday, 25 October 2016 08:45:00 (UTC/GMT)

PacketCache lets you Go Back in Time

PacketCache logo

Have you ever wanted to go back in time to get a PCAP of something strange that just happened on a PC?
I sure have, many times, which is why we are now releasing a new tool called PacketCache. PacketCache maintains a hive of the most important and recent packets, so that they can be retrieved later on, if there is a need.

Network forensics and incident response is performed post-event, but requires that packet have already been captured during the event to be analyzed. Starting a network sniffer after a suspected intrusion might provide useful insight on what the intruders are up to, but it is much better to be able to go back in time to observe how they gained access to the network and what they did prior to being detected. Many companies and organizations combat this problem by setting up one or several solutions for centralized network packet capturing. These sniffers are typically installed at choke-points on the network, such as in-line with a firewall. However, this prevents the sniffers from capturing network traffic going between hosts on the same local network. Intruders can therefore often perform lateral movement on a compromised network without risk getting their steps captured by a packet sniffer.

Logo for Back to the Future series logo - public domain

USB broadband modem - Copyright Prolineserver 2010 (cc-by-sa-3.0) We're now trying to improve the situation for the defenders by releasing PacketCache, which is a free (Creative Commons licensed) Windows service that is designed to continuously monitor the network interfaces of a computer and store the captured packets in memory (RAM). PacketCache monitors all IPv4 interfaces, not just the one connected to the corporate network. This way traffic will be captured even on public WiFi networks and Internet connections provided through USB broadband modems (3G/4G).

By default PacketCache reserves 1% of a computer's total physical memory for storing packets. A computer with 4 GB of RAM will thereby allow up to 40 MB of packets to be kept in memory. This might not seem like much, but PacketCache relies on a clever technique that allows it to store only the most important packets. With this technique just 40 MB of storage can be enough to store several days worth of “important” packets.

The “clever technique” we refer to is actually a simple way of removing packets from TCP and UDP sessions as they get older. This way recent communication can be retained in full, while older data us truncated at the end (i.e. only the last packets are removed from a session).

PacketCache services in services.msc

To download PacketCache or learn more about this new tool, please visit the official PacketCache page:

PCAP or it didn't happen!

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

Posted by Erik Hjelmvik on Wednesday, 28 September 2016 11:45:00 (UTC/GMT)

Bug Bounty PCAP T-shirts

As of today we officially launch the 'Netresec Bug Bounty Program'. Unfortunately we don't have the financial muscles of Microsoft, Facebook or Google, so instead of money we'll be giving away t-shirts.

PCAP or it didn't happen t-shirt
Image: PCAP or it didn't happen t-shirt

To be awarded with one of our 'PCAP or it didn't happen' t-shirts you will have to:

  • Be able to reliably crash the latest version of NetworkMiner or CapLoader, or at least make the tool misbehave in some exceptional way.
  • Send a PCAP file that can be used to trigger the bug to info[at]

Those who find bugs will also receive an honorable mention in our blog post covering the release of the new version containing the bug fix.

Additionally, submissions that play a key-role in mitigating high-severity security vulnerabilities or addressing very important bugs will be awarded with a free license of either NetworkMiner Professional or the full commercial version of CapLoader.

Happy BugBounty Hunting!

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

Posted by Erik Hjelmvik on Tuesday, 27 September 2016 09:27:00 (UTC/GMT)


NETRESEC on Twitter

Follow @netresec on twitter:


Recommended Books

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

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

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

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

» Practical Packet Analysis, Chris Sanders (2011)

» Windows Forensic Analysis, Harlan Carvey (2009)

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

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