I am currently working on the latest Malware traffic analysis exercise located here
Titled “2016-01-07 – TRAFFIC ANALYSIS EXERCISE – ALERTS ON 3 DIFFERENT HOSTS”
I used the command line to run TShark with this command to extract just the packets with the chosen IP Address.
tshark -2 -R ip.addr==192.168.122.130 -r 2016-01-07-traffic-analysis-exercise.pcap -w 192-168-122-130.pcap
What this command does is it launches tshark , with (-2) two pass analysis , (–R ) read filter of “ip.addr==192.168.122.130”, lower case (-r) for read input file ,input pcap file to read, lower case(-w) for write output file, output filename to write.
Note: the “–2” has to be there in the current version or it throws an error and tells you it needs to be in there, and remember to put double quotes around your file paths.
Using this method I was able to extract the the packets just for the IP Address that I wanted to a new pcap file to work on just that IP.
The problem came in when I tried to look for a converted timestamp from Epoch to to Hex like I have in the other post in the hex editor. I could not find the timestamp for the normal Wireshark converted timestamp but if you open the original Pcap file and the TShark extracted Pcap file in Wireshark and set the IP filter on the original file then they still line up with the date time stamps.
That tells me that it is still using a timestamp but how ?
If we take a packet in the original Pcap and find the exact bytes minus the 8 bytes for the time stamp then open them up in hex editor then we see this.
If we look at the bottom one that is the normal timestamp which converts to the Epoch time of “ 1452204366.756980 “ and the hex is “4E E1 8E 56 F4 8C 0B 00 “ in this time stamp the left 4 bytes is the “High Time” and the right 4 bytes is the “Low Time” or the milliseconds of the time.
This other timestamp of “C5 28 05 00 74 FC 6B AD” , and it is a timestamp, as it turns out after looking at it a bit, on this one the right 4bytes are the “High Time” and the left 4 bytes are the “Low Time” or the milliseconds portion of the time. Now this conversion works a little different than the normal type.
We first take this “C5 28 05 00 74 FC 6B AD” and swap the 4 byte sections 74 FC 6B AD C5 28 05 00 next we reverse the entire 8 bytes, “00 05 28 C5 AD 6B FC 74” then convert to decimal “1452204366756980” , add the decimal point in the 10’th position from the left “1452204366.756980” and presto we have the Epoch timestamp.
So now I have 2 timestamp converters.
The timestamp from the TShark one reminds me of another one that I worked with a while back but can’t quite place it right now.
One other thing I noticed while looking at the Pcap file that TShark created. In the hex editor we can see a stamp at the top of the file that tells us it was created by TShark, I don’t see that type of stamp in a file created by Wireshark.
Also remember that the Timestamps are at the beginning of each packet in a normal older Pcap file.
Now that I can use the timestamps again back to the exercise.
I hope this helps someone else.
Updated 1/10/2016 :
In my haste to complete this post and get back to the write-up the Malware traffic exercise found here I neglected to investigate the file format of the PcapNG (or Next Generation) file format. In a previous post we found that the original pcap file format found here on the Wireshark development page that the packets started with the timestamp.
That is not so with the PcapNG format. It is written in a block format and the timestamp is not the first item in the block.
Here is a screenshot of the original Pcap layout pulled from the specification page.
The explanation of the PcapNG file format can be found here with a link to the most current version of the format specification. The packets I’m looking at are from the TShark dump of a Pcap file with just traffic for 1 system. This traffic comes from the original downloaded Pcap file from the malware traffic exercise that I completed.
In the PcapNG format there are different blocks that make up the complete file. The very first block of the file will give us information about the file itself called “Section Header Block” and is described in section 3.1 of the specification .
One of the items it gives us is the “Byte-Order Magic:”. Magic number, whose value is the hexadecimal number 0x1A2B3C4D. This number can be used to distinguish sections that have been saved on little-endian machines from the ones saved on big-endian machines.
Which brings us to section “3.6. Data format.” that gives us information about whether it is saved in Big Endian or Little Endian.
Data contained in each section will always be saved according to the
characteristics (little endian / big endian) of the capturing
machine. This refers to all the fields that are saved as numbers and
that span over two or more octets.
There was also a line in an earlier draft that it is possible that data is in the file under both Endianness.
Ok so we have to observe that the byte order can change depending on what machine it was captured on.
Now that that is said lets move onto our packet block. This is a screenshot from the Draft page of the layout for the “Enhanced” Packet block which is what we will be looking at.
Here we see that the length of the block is in the second and last position of the block. So our block starts with (Depending on Endianness from what I read), looking at it in a hex editor, will either be 0x00000006 or 0x60000000 and ends on the second length value .
I will be using three packets from the exercise Pcap file and three from the extracted IP version I made using TShark.
Here is the Wireshark view of the Original 3 packets.
And from the extracted IP.
These 3 packets are short and consecutive so make a good compact example for what I am trying to show(how the data is split up).
Here are the frame numbers,timestamps(decimal epoch and hex ), and the file offsets where they can be found if anyone wants to follow along.
Packet 16355 Epoch Time: 1452204647.545424000 seconds Converted to Hex 67E28E56 90520800 Offset AF4017 (segment)
Packet 16356 Epoch Time: 1452204647.545734000 seconds Converted to Hex 67E28E56 C6530800 offset AF1CA (segment)
Packet 16357 Epoch Time: 1452204647.546110000 seconds Converted to Hex 67E28E56 3E550800 offset AF4290 (Complete Post request)
192-168-122-132192-168-122-132.pcap (Tshark / pcapng)
Packet 5436 Epoch Time: 1452204647.545424000 seconds Converted to Hex C5280500 507A28BE Offset 33571C (segment)
Packet 5437 Epoch Time: 1452204647.545734000 seconds Converted to Hex C5280500 867B28BE Offset 3358E0 (Segment)
Packet 5438 Epoch Time: 1452204647.546110000 seconds Converted to Hex C5280500 FE7C28BE offset 3359B8 (Complete Post Request)
(It looks better in notepad.)
Here is a look at the Original Pcap file opened up in Wireshark and in a hex editor with the data section highlighted. This section will contain the IP’s ,ports, request type the actual data transported Etc. .
Now lets take a closer look at just the hex.
Now lets take a look at the PcapNG in hex.
As we can see here there is allot more data packed in the new format. this one did not have options in it or that section would have been bigger.
My interest in these at the moment is to have the ability to travel back and forth from Wireshark to a hex editor checking out packets of interest or to investigate possible corrupted packets using the timestamps. Knowing the packet or block layout will be of great help.
Just 1 more thought. If we are dealing with malware in the capture is this packet really a malformed packet or was it intentional ?
I hope you learned something from reading this as I did trying to write it.
Thank you for reading.