Reading cached packets with Wireshark

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:
https://www.wireshark.org/download/automated/win32/

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. Press: Capture > Options
4. Click “Manage Interfaces...”
5. Select the “Pipes” tab
6. Press the “+” button to add a named pipe
7. Name the pipe “\\.\pipe\PacketCache” and press ENTER to save it

8. Press “OK” in the Manage Interface window.

9. Press “Start” to read the packets 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.

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

Tags: #Netresec​ #PCAP​ #PacketCache​ #Wireshark​ #named pipe​ #SharkFest​

Detect TCP content injection attacks with findject

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.

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 “finject.py”, 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.

In the example execution above we can see that findject.py 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.

The tshark execution above reveals that three packets sent from the web server's IP (42.96.141.35) 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.

To learn more about findject.py and download the tool, please visit: https://www.netresec.com/?page=findject

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.

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

Tags: #Netresec​ #PCAP​ #packet injection​ #find​ #python​ #SharkFest​