{"id":3235,"date":"2020-11-14T13:22:39","date_gmt":"2020-11-14T18:22:39","guid":{"rendered":"http:\/\/osric.com\/chris\/accidental-developer\/?p=3235"},"modified":"2020-11-14T13:22:39","modified_gmt":"2020-11-14T18:22:39","slug":"combining-pcap-packet-capture-files","status":"publish","type":"post","link":"https:\/\/osric.com\/chris\/accidental-developer\/2020\/11\/combining-pcap-packet-capture-files\/","title":{"rendered":"Combining pcap (packet capture) files"},"content":{"rendered":"<p><strong>Motivation:<\/strong> I wanted to combine 2 or more packet capture, or pcap, files in order to create an example:<\/p>\n<ul>\n<li>One that contains just malicious (or simulated malicious) network traffic<\/li>\n<li>Another contains legitimate, non-malicious network traffic<\/li>\n<\/ul>\n<p>Many example packet capture files focus either specifically on malware, exploits, C2 traffic, etc. (like Security Onion&#8217;s list of <a href=\"https:\/\/docs.securityonion.net\/en\/16.04\/pcaps.html\">PCAPs for Testing<\/a>) or on examples of legitimate traffic (like Wireshark&#8217;s <a href=\"https:\/\/wiki.wireshark.org\/SampleCaptures\">Sample Captures<\/a>). I wanted to create an example that would interweave such sources and intersperse malicious and legitimate traffic, as they would typically occur concurrently.<\/p>\n<p>In addition to <code>tcpdump<\/code>, there are three CLI tools provided by Wireshark that I used to help accomplish this:<\/p>\n<ul>\n<li><a href=\"https:\/\/www.wireshark.org\/docs\/man-pages\/capinfos.html\">capinfos<\/a> &#8211; provides high-level data about a packet capture file<\/li>\n<li><a href=\"https:\/\/www.wireshark.org\/docs\/man-pages\/mergecap.html\">mergecap<\/a> &#8211; combines 2 or more packet capture files<\/li>\n<li><a href=\"https:\/\/www.wireshark.org\/docs\/man-pages\/editcap.html\">editcap<\/a> &#8211; modified packet details, such as timestamps, in a packet capture file<\/li>\n<\/ul>\n<p><!--more--><\/p>\n<p>At first I thought <code>mergecap<\/code> alone would be sufficient, but I wanted the packets from the various source pcaps to overlap so that malicious and legitimate network traffic would be intermingled. However, the <code>mergecap<\/code> documentation indicates that the timestamps will be preserved:<\/p>\n<blockquote><p>Packets from the input files are merged in chronological order based on each frame&#8217;s timestamp, unless the -a flag is specified.  Mergecap assumes that frames within a single capture file are already stored in chronological order.  When the -a flag is specified, packets are copied directly from each input file to the output file, independent of each frame&#8217;s timestamp.<\/p><\/blockquote>\n<p>To accomplish what I wanted, I needed to edit the timestamps in the pcap files. Fortunately, <code>editcap<\/code> can do this. As a proof-of-concept, I created 2 simple pcap files using <code>tcpdump<\/code>:<\/p>\n<p>First, I created <code>https.pcap<\/code>:<\/p>\n<p>In one terminal:<\/p>\n<pre><code>sudo tcpdump -i eth0 -nn -w https.pcap host 216.154.220.53<\/code><\/pre>\n<p>In another terminal:<\/p>\n<pre><code>curl https:\/\/osric.com\/chris\/accidental-developer\/<\/code><\/pre>\n<p>Next, I created <code>dns.pcap<\/code>:<\/p>\n<p>In one terminal:<\/p>\n<pre><code>sudo tcpdump -i eth0 -nn -w dns.pcap host 8.8.8.8<\/code><\/pre>\n<p>In another terminal:<\/p>\n<pre><code>dig @8.8.8.8 virustotal.com\r\ndig @8.8.8.8 hybrid-analysis.com\r\ndig @8.8.8.8 threatpost.com\r\ndig @8.8.8.8 sans.org<\/code><\/pre>\n<p>I examined the details of the 2 files using <code>capinfos<\/code>:<\/p>\n<pre><code>$ capinfos -ace https.pcap dns.pcap \r\nFile name:           https.pcap\r\nNumber of packets:   66\r\nFirst packet time:   2020-11-14 11:02:45.010686\r\nLast packet time:    2020-11-14 11:02:45.657428\r\n\r\nFile name:           dns.pcap\r\nNumber of packets:   8\r\nFirst packet time:   2020-11-14 11:03:13.113482\r\nLast packet time:    2020-11-14 11:03:38.526727<\/code><\/pre>\n<p>Using <code>mergecap<\/code> at this point worked, but since all the packets in <code>https.pcap<\/code> precede chronologically those in <code>dns.pcap<\/code>, <code>mergecap<\/code> will respect the timestamps and order them accordingly:<\/p>\n<pre><code>$ mergecap -F pcap -w merged.pcap https.pcap dns.pcap\r\n$ capinfos -ace merged.pcap \r\nFile name:           merged.pcap\r\nNumber of packets:   74\r\nFirst packet time:   2020-11-14 11:02:45.010686\r\nLast packet time:    2020-11-14 11:03:38.526727<\/code><\/pre>\n<p>Using the <code>-a<\/code> flag to <code>mergecap<\/code> ignores the timestamps and reverses the order, listing the packets in <code>dns.pcap<\/code> first:<\/p>\n<pre><code>$ mergecap -F pcap -a -w merged.pcap dns.pcap https.pcap \r\n$ capinfos -ace merged.pcap \r\nFile name:           merged.pcap\r\nNumber of packets:   74\r\nFirst packet time:   2020-11-14 11:02:45.010686\r\nLast packet time:    2020-11-14 11:03:38.526727<\/code><\/pre>\n<p>However, this didn&#8217;t change the timestamps at all. The packets from <code>dns.pcap<\/code> still had later timestamps, and the packets in the pcap were no longer listed in chronological order.<\/p>\n<p>Since I wanted the requests in <code>https.pcap<\/code>, spanning a fraction of a second, to appear somewhere in the midst of the 25 seconds of DNS requests in <code>dns.pcap<\/code>, I needed to adjust the timestamps in <code>https.pcap<\/code>. The <code>editcap<\/code> command has a <code>-t<\/code> flag that can be used to adjust the timestamps up or down by the specified number of seconds (including fractional seconds). In this case, I tried 40 seconds:<\/p>\n<pre><code>$ editcap -t 40 https.pcap https-modified.pcap\r\n$ capinfos -ace https-modified.pcap \r\nFile name:           https-modified.pcap\r\nNumber of packets:   66\r\nFirst packet time:   2020-11-14 11:03:25.010686\r\nLast packet time:    2020-11-14 11:03:25.657428<\/code><\/pre>\n<p>The packet times looked good: they would fall between the first packet time of <code>dns.pcap<\/code> and the last packet time of <code>dns.pcap<\/code>. Now merging them should be simple:<\/p>\n<pre><code>$ mergecap -F pcap -w merged.pcap https-modified.pcap dns.pcap \r\n$ capinfos -ace merged.pcap \r\nFile name:           merged.pcap\r\nNumber of packets:   74\r\nFirst packet time:   2020-11-14 11:03:13.113482\r\nLast packet time:    2020-11-14 11:03:38.526727<\/code><\/pre>\n<p>It worked! When I examined the resulting pcap file in Wireshark, the first 2 DNS requests and replies were listed, followed by the HTTPS requests and replies, followed by the remaining 2 DNS requests and replies.<\/p>\n","protected":false},"excerpt":{"rendered":"<p>Motivation: I wanted to combine 2 or more packet capture, or pcap, files in order to create an example: One that contains just malicious (or simulated malicious) network traffic Another contains legitimate, non-malicious network traffic Many example packet capture files focus either specifically on malware, exploits, C2 traffic, etc. (like Security Onion&#8217;s list of PCAPs &hellip; <a href=\"https:\/\/osric.com\/chris\/accidental-developer\/2020\/11\/combining-pcap-packet-capture-files\/\" class=\"more-link\">Continue reading <span class=\"screen-reader-text\">Combining pcap (packet capture) files<\/span><\/a><\/p>\n","protected":false},"author":2,"featured_media":0,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[232,1],"tags":[563,565,564,493,546],"class_list":["post-3235","post","type-post","status-publish","format-standard","hentry","category-tips-tricks","category-uncategorized","tag-capinfos","tag-editcap","tag-mergecap","tag-tcpdump","tag-wireshark"],"_links":{"self":[{"href":"https:\/\/osric.com\/chris\/accidental-developer\/wp-json\/wp\/v2\/posts\/3235","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/osric.com\/chris\/accidental-developer\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/osric.com\/chris\/accidental-developer\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/osric.com\/chris\/accidental-developer\/wp-json\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/osric.com\/chris\/accidental-developer\/wp-json\/wp\/v2\/comments?post=3235"}],"version-history":[{"count":11,"href":"https:\/\/osric.com\/chris\/accidental-developer\/wp-json\/wp\/v2\/posts\/3235\/revisions"}],"predecessor-version":[{"id":3380,"href":"https:\/\/osric.com\/chris\/accidental-developer\/wp-json\/wp\/v2\/posts\/3235\/revisions\/3380"}],"wp:attachment":[{"href":"https:\/\/osric.com\/chris\/accidental-developer\/wp-json\/wp\/v2\/media?parent=3235"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/osric.com\/chris\/accidental-developer\/wp-json\/wp\/v2\/categories?post=3235"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/osric.com\/chris\/accidental-developer\/wp-json\/wp\/v2\/tags?post=3235"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}