Showing blog posts from October 2016

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)


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)