NETRESEC Network Security Blog - Tag : sniffer

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!

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

Tags: #PacketCache #PCAP #NSM #forensics #Windows #sniffer #memory #DFIR

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

From 4SICS with ICS PCAP Files

I attended to the Swedish industrial cyber security conference 4SICS last month and brought back a bunch of PCAP files. Not just any PCAP files, but captured network traffic from the ICS lab that was set up in the Geek Lounge at 4SICS. These PCAP files are now made publicly available here, because captured network traffic from ICS/SCADA networks is a really scarce resource.

4SICS logo 4SICS is the the leading Industrial Control System (ICS) security conference in Europe, which brings in speakers and attendees from all around the world. I tought a one-day class on analyzing network traffic as part of the pre-conference training at 4SICS. In this class we analyzed PCAP files containing industrial protocols, such as Modbus/TCP and IEC-104. Unfortunately there aren't many capture files around that carry these protocols, so the ICS analysis part in my class wasn't as advanced as I wanted it to be.

I have been aware of this limited access to ICS traffic for some time now, which is why I decided to work with the 4SICS crew in order to set up a sniffer in the ICS lab at the 4SICS conference. This lab contained devices such as PLCs, RTUs, servers, industrial network equipment (switches, firewalls, etc), which were available for hands-on "testing" by 4SICS attendees.

4SICS ICS Lab. Image Credit: 4SICS

The network TAP vendor Garland were Technology Partners at 4SICS, so I didn't even have to bring a network TAP to the lab. I just connected my sniffer machine and let it record for three days. Chris Sistrunk also joined the sniffing party later in the conference by connecting his SEL-3355, which runs SecurityOnion, to the network TAP.

4SICS Network TAP and Sniffers Image Credit: Patrick Nixdorf

The 350MB of network traffic that was captured during the 4SICS conference is now publicly available here:


Posted by Erik Hjelmvik on Wednesday, 04 November 2015 15:45:00 (UTC/GMT)

Tags: #ICS #SCADA #PCAP #4SICS #Modbus #sniffer #PLC

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

PCAP or it didn't happen

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

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

After the Heartbleed security advisory was published, EFF tweeted:

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

Liam Randall (@Hectaman) tweeting about historical Heartbleed searches Heartbleed

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

Can I detect if someone has exploited this against me?

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

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

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

Why Full Packet Capture Matters

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

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

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

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

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

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

Setting up a Full Packet Capture

netsniff-ng logo

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

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

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

Big Data PCAP Analysis

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

UPDATE 2015-06-02

We now have T-shirts with "PCAP or it didn't happen" print for sale!

PCAP or it didn't happen T-shirt

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

Tags: #capture #sniffer #IDS #forensics

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)