Network forensic is the art of discovering and analyzing security incidents relying on network evidences.

Network Evidences

A lot of security devices include packet capture capabilities including NIDS (Network Intrusion Detection System), network proxies or even servers.

Collecting Network Evidences

Network evidences like packet captures are at the root of a good analysis. If your evidences are partial or incorrect, you’ll produce incorrect or partial analysis. The coll ection of network evidences is often underestimated and seen as a simple process.

Factors to check while performing a network capture:

  • Time reference (Is your system time synchronized? or What to do with network packet capture using an incorrect time-stamp?)

  • Is a passive network collection always passive? (e.g. Are you doing name resolution? Do you have internet access from your network collection system? Can my network collec tion system be exploited?)

  • Do you loose packets during the capture (or before?)? (e.g. Using netbeacon? Do you have any statistics from your network packet capture device?)

  • Do you capture the correct size? (e.g. jumbo frame?)

  • How large will be my packet capture? Should I have small file or large network capture files? Is my disk large enough to store the network capture? Is my disk fast enough to write capture files?

  • Which format should I use to store my network capture? (pcap, pcap-ng?)

Time References

It’s not uncommon to receive network capture files where the capture system was not time synchronized. To recover the original time, you can dig into the capture to find add itional elements like HTTP headers, NTP packets or other time references.

editcap -t can be used to adjust time difference. The value is expressed in seconds (with even the fractional seconds).

If you know that you have 30 seconds of difference from a reference time, editcap can adjust the time in your network packet capture file:

editcap -t 30 original.pcap updated.pcap
editcap will only change the time-stamp from the network capture header. Time information in the payload won’t be updated (e.g. HTTP headers).

Passive Network Collection

Usually, you don’t want to tell everyone (especially the adversaries) that a network capture is performed. If the attacker knows where and how the network capture is perform ed, he will tend to evade the network capture process.

If you want to ensure if your network collection is passive, external dependencies need to be reviewed. The most common example is the use of external name resolvers. If the external resolver is enabled, it will generate two major issues:

  • The resolver time will be added to the overall process (e.g. tcpdump -r myfile.cap versus tcpdump -n -r myfile.cap)

  • If the adversary controls a name server (especially reverse PTR records), the information will flow back to the adversary (e.g. leaking the presence of a network capture o r NIDS, verifying which packets are intercepted…​)

Size of Frame Captured

When configuring a network capture software, you must take into consideration the length of packet to capture (also called the snaplen). If you need the whole packet (includ ing payload), you have to capture the maximum transmission unit of the link layer. If you have specific constraints like space or privacy, you can limit the capture to the h eaders of the packets.

An example of packet capture limited to 100 bytes (-s in tcpdump):

tcpdump -w mycapture.cap -s 100

Another factor is the time to process captured packets. If the packets are bigger, it tends to take more time to process the packets and fill the buffers faster. You might l ost some packets during the capture.

tshark (part of Wireshark Network Analyzer) has the -s option but can be more granular regarding the buffer size to process the captured packets. -B option permits to incre ase the buffer size of the capture interface (as long as the capture library supports it).

tshark -B 4 -w mycapture.cap -s 100

If you want to know the frame size capture from a pcap file, you can use the 'file' command:

[adulau:/home/adulau/dess]↥ $ file capture.cap
capture.cap: tcpdump capture file (little-endian) - version 2.4 (Ethernet, capture length 1500)
[adulau:/home/adulau/dess]↥ $ file vibrowa.cap
vibrowa.cap: tcpdump capture file (little-endian) - version 2.4 (Ethernet, capture length 65535)

Before starting the analysis of network capture files, the capture length needs to be reviewed.

Analysis Tools

  • capinfos (Wireshark)

  • mergecap (Wireshark)

  • editcap (Wireshar)

  • tcpdump

  • ipsumdump

  • tshark

  • tcpflow (1) and tcpflow (2)

  • ngrep

  • yaf

Data-set

tcpdump

tcpdump -tttt -n -r chp-circlnet22-1-20191120004014.cap | cut -d" " -f7 | sort | uniq -c | sort -n ---

ipsumpdump payload occurences

ipsumdump --payload -r chp-circlnet22-1-20191120004014.cap | sort | uniq -c | sort -nr | head -10 ---

ipsumdump

ipsumdump --ip-ttl -r chp-circlnet22-1-20191120004014.cap | grep -v "^!" | sort | uniq -c | sort -nr | sort -n ---

tshark extracting ISN

tshark -n -T fields -e frame.time_epoch -r chp-circlnet22-1-20191120004014.cap -T fields -e tcp.seq ---

tshark + gnuplot

tshark -n -T fields -e frame.time_epoch -r chp-circlnet22-1-20191120004014.cap -T fields -e tcp.seq -o tcp.relative_sequence_numbers:FALSE | awk -e '{print $1"\t"$2}' | gnu plot -p -e 'set title "ISN"; plot "/dev/stdin" using :2 with points pointtype 0' ---

tshart + gnuplot

ls -1 *.cap| parallel 'tshark -n -r {1} -T fields -e frame.time_epoch -T fields -e tcp.seq -o tcp.relative_sequence_numbers:FALSE -Y 'tcp.port==26'' | awk -e '{print $1"\t" $2}' | gnuplot -p -e 'set title "ISN"; plot "/dev/stdin" using :2 with points pointtype 0' ---

payload per port

ls -1 | parallel 'tcpdump -s0 -A -r {1} -n port 53413' | grep http ---