Name: Ruben Recabarren 

Description: 
v2. Typos and added some clarifications.

The easiest way to determine web requests is with a simple grep command. The -A and -B switches made sure we get GET, POST, Host: strings that "correspond" to each other:

noone@bt:~/forensic-challenge$ strings -n 6 evidence06.pcap | egrep -A 3 -B 3 'GET |POST |Host: '
GET /index.php HTTP/1.1
Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, application/x-shockwave-flash, */*
Accept-Language: en-us
Accept-Encoding: gzip, deflate
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1)
Host: 10.10.10.10:8080
Connection: Keep-Alive
HTTP/1.1 200 OK
Content-Type: text/html
--
n></body></html>
</body>
</html>O
GET /index.phpmfKSxSANkeTeNrah.gif HTTP/1.1
Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, application/x-shockwave-flash, */*
Referer: http://10.10.10.10:8080/index.php
Accept-Language: en-us
Accept-Encoding: gzip, deflate
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1)
Host: 10.10.10.10:8080
Connection: Keep-Alive
HTTP/1.1 200 OK
Content-Type: image/gif
--
NtLockVirtualMemory
InitServerExtension
core_loadlib
GET /123456789 HTTP/1.0
ProcessIdToSessionId
kernel32.dll
DSA-SHA1-old
--
NtLockVirtualMemory
InitServerExtension
core_loadlib
GET /123456789 HTTP/1.0
ProcessIdToSessionId
kernel32.dll
DSA-SHA1-old
noone@bt:~/forensic-challenge$

The first two matches are obviously web requests from actual HTTP conversations, whereas the last two may be strings from binaries that look that they will try and make web requests once executed. The first match requests for index.php, whereas the second match requests for index.phpmfKSxSANkeTeNrah.gif. The Referer header from the second match assertains that this request was actually performed after the first GET request for index.php.

In order to create an inventory of all the artifacts exchanged in the packet capture, it is easy to use tcpflow:

noone@bt:~/forensic-challenge$ mkdir tcpflow
noone@bt:~/forensic-challenge$ cd tcpflow
noone@bt:~/forensic-challenge/tcpflow$ tcpflow -r ../evidence06.pcap
noone@bt:~/forensic-challenge/tcpflow$ ls -alh
total 2.2M
drwxr-xr-x 2 noone noone 4.0K May 26 18:46 .
drwxr-xr-x 3 noone noone 4.0K May 26 18:46 ..
-rw-r--r-- 1 noone noone 1.2M May 26 18:46 010.010.010.010.04444-010.010.010.070.01036
-rw-r--r-- 1 noone noone 1.4G May 26 18:46 010.010.010.010.04445-010.010.010.070.01044
-rw-r--r-- 1 noone noone 5.9K May 26 18:46 010.010.010.010.08080-010.010.010.070.01035
-rw-r--r-- 1 noone noone  658 May 26 18:46 010.010.010.070.01035-010.010.010.010.08080
-rw-r--r-- 1 noone noone  94K May 26 18:46 010.010.010.070.01036-010.010.010.010.04444
-rw-r--r-- 1 noone noone 1.1M May 26 18:46 010.010.010.070.01044-010.010.010.010.04445
noone@bt:~/forensic-challenge/tcpflow$

and then simply have foremost carve out the artifacts:

noone@bt:~/forensic-challenge/tcpflow$ foremost -i 010.010.010.0*
[AFTER A COUPLE OF MINUTES OF ANALYSIS]
noone@bt:~/forensic-challenge/tcpflow$cat output/audit.txt
[SNIPPING uninteresting parts of the OUTPUT]
Foremost version 1.5.4 by Jesse Kornblum, Kris Kendall, and Nick Mikus
File: 010.010.010.010.04444-010.010.010.070.01036
Length: 1 MB (1239098 bytes)
Num      Name (bs=512)         Size      File Offset     Comment
0:      00000000.dll         730 KB               4      04/03/2010 04:07:31
------------------------------------------------------------------
File: 010.010.010.010.04445-010.010.010.070.01044
Length: 1 GB (1437183436 bytes)
Num      Name (bs=512)         Size      File Offset     Comment
1:      02805371.dll         730 KB      1436350349      04/03/2010 04:07:31
Finish: Wed May 26 18:53:28 2010
------------------------------------------------------------------
File: 010.010.010.010.08080-010.010.010.070.01035
Length: 5 KB (6019 bytes)
Num      Name (bs=512)         Size      File Offset     Comment
2:      00000011.gif           43 B            5976       (1 x 1)
3:      00000000.htm           5 KB             174
------------------------------------------------------------------
4 FILES EXTRACTED
gif:= 1
htm:= 1
exe:= 2
------------------------------------------------------------------

So now, we have an nice inventory of artifacts from which we can answer several forensic questions. Notice the Comment output which gives interesting "absolute" time info.

1.- What was the full URI of Vick Timmes' original web request? (Please include the port in your URI.)

As per the first egrep match describe at the beginning of this document, the full URI of the original web request is:

http://10.10.10.10:8080/index.php

2.- In response, the malicious web server sent back obfuscated JavaScript. Near the beginning of this code, the attacker created an array with 1300 elements labeled "COMMENT", then filled their data element with a string. What was the value of this string?

We can try to extract the session where this took place and perform a very narrow manual analysis of the javascript exchanged. However, I rather use a more general approach that is usefull in cases where such an exchange could have happened more than once or in an unknown location in the capture file. A couple of grep commands is all it takes:

We start looking for the string "COMMENT":

noone@bt:~/forensic-challenge$ strings -n 6 evidence06.pcap | grep COMMENT
var UWnHADOfYHiHDDXj = "COMMENT";
noone@bt:~/forensic-challenge$ 

So we see there is only one occurence of the string "COMMENT" and is used to set the variable UWnHADOfYHiHDDXj. The strange variable name is supposed to be an attempt at obfuscating the javascript. Or so they think. So next, we search the variable name that holds our string:

noone@bt:~/forensic-challenge$ strings -n 6 evidence06.pcap | grep UWnHADOfYHiHDDXj
var UWnHADOfYHiHDDXj = "COMMENT";
  qSNgVkOrdIjaiFpPTfDjbPHQppHSGtzpmOOyqEbLEFxNqAxicRyZKKWiRWmUaDHFOuzHPHqLrRFSzQuPusTnQyqpQwVpARdlR[i] = document.createElement(UWnHADOfYHiHDDXj);
noone@bt:~/forensic-challenge$ 

So we see there is one additional occurrence of the variable UWnHADOfYHiHDDXj, using it as argument to the function document.createElement(). The element created is stored in the array qSNgVkOrdIjaiFpPTfDjbPHQppHSGtzpmOOyqEbLEFxNqAxicRyZKKWiRWmUaDHFOuzHPHqLrRFSzQuPusTnQyqpQwVpARdlR. This means we are getting closer to the object we are looking for. Looking for this array, we get:

noone@bt:~/forensic-challenge$ strings -n 6 evidence06.pcap | grep -B 2 qSNgVkOrdIjaiFpPTfDjbPHQppHSGtzpmOOyqEbLEFxNqAxicRyZKKWiRWmUaDHFOuzHPHqLrRFSzQuPusTnQyqpQwVpARdlR
<script>
var UWnHADOfYHiHDDXj = "COMMENT";
var qSNgVkOrdIjaiFpPTfDjbPHQppHSGtzpmOOyqEbLEFxNqAxicRyZKKWiRWmUaDHFOuzHPHqLrRFSzQuPusTnQyqpQwVpARdlR = new Array();
for (i = 0; i < 1300; i++)
  qSNgVkOrdIjaiFpPTfDjbPHQppHSGtzpmOOyqEbLEFxNqAxicRyZKKWiRWmUaDHFOuzHPHqLrRFSzQuPusTnQyqpQwVpARdlR[i] = document.createElement(UWnHADOfYHiHDDXj);
  qSNgVkOrdIjaiFpPTfDjbPHQppHSGtzpmOOyqEbLEFxNqAxicRyZKKWiRWmUaDHFOuzHPHqLrRFSzQuPusTnQyqpQwVpARdlR[i].data = "vEI";
--
function vldTpeimKzBERsNeByodkqCLvbmselSexjNZwNtHDaWDkZKQHlZIKIZtQqNeWtWcZzpDoMXcAjkyyhRONrLy()
  p = "\u0c0f\u0c0d\u0c0d\u0c0d\u0c0d\u0c0d\u0c0d\u0c0d\u0c0d\u0c0d\u0c0d\u0c0d\u0c0d\u0c0d\u0c0d\u0c0d\u0c0d\u0c0d\u0c0d\u0c0d\u0c0d\u0c0d\u0c0d\u0c0d\u0c0d\u0c0d\u0c0d\u0c0d\u0c0d\u0c0d\u0c0d\u0c0d\u0c0d\u0c0d\u0c0d\u0c0d\u0c0d\u0c0d\u0c0d\u0c0d\u0c0d\u0c0d";
  for (i = 0; i < qSNgVkOrdIjaiFpPTfDjbPHQppHSGtzpmOOyqEbLEFxNqAxicRyZKKWiRWmUaDHFOuzHPHqLrRFSzQuPusTnQyqpQwVpARdlR.length; i++)
    qSNgVkOrdIjaiFpPTfDjbPHQppHSGtzpmOOyqEbLEFxNqAxicRyZKKWiRWmUaDHFOuzHPHqLrRFSzQuPusTnQyqpQwVpARdlR[i].data = p;
noone@bt:~/forensic-challenge$

Where we see that the first occurrence shows the loop over 1300 iterations, where each created element is assigned the string: "vEI", which is the string we were looking for.

Note: The second occurrence provides evidence of the array data being overwritten with bytes which look like "nops". However, as it turns out, these bytes are not nops at all. They actually end up serving as a "valid landing address" where the code is to return after the heap spray previously prepared by the exploit.

3.- Vick's computer made a second HTTP request for an object.

   1. What was the filename of the object that was requested?

	As per the second egrep match performed at the beginning of this document, the object requested was: index.phpmfKSxSANkeTeNrah.gif. For which the server responded with a gif:

GET /index.phpmfKSxSANkeTeNrah.gif HTTP/1.1
Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, application/x-shockwave-flash, */*
Referer: http://10.10.10.10:8080/index.php
Accept-Language: en-us
Accept-Encoding: gzip, deflate
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1)
Host: 10.10.10.10:8080
Connection: Keep-Alive
HTTP/1.1 200 OK
Content-Type: image/gif


   2. What is the MD5sum of the object that was returned?

	We simply look at our inventory of artifacts for the answer:

noone@bt:~/forensic-challenge$ md5sum tcpflow/output/gif/00000011.gif
df3e567d6f16d040326c7a0ea29a4f41  tcpflow/output/gif/00000011.gif
noone@bt:~/forensic-challenge$

In order to make sure that this object was in fact the one that was returned by this second request, we take a look at the stream flow that produced such a gif file. Taking a look at the output of foremost, we find:

------------------------------------------------------------------
File: 010.010.010.010.08080-010.010.010.070.01035
Length: 5 KB (6019 bytes)
Num      Name (bs=512)         Size      File Offset     Comment
2:      00000011.gif           43 B            5976       (1 x 1)
3:      00000000.htm           5 KB             174
------------------------------------------------------------------

And so, taking a look at the exchange 010.010.010.010.08080-010.010.010.070.01035 and its corresponding reversed flow, we find:

noone@bt:~/forensic-challenge$ cat tcpflow/010.010.010.070.01035-010.010.010.010.08080
GET /index.php HTTP/1.1
Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, application/x-shockwave-flash, */*
Accept-Language: en-us
Accept-Encoding: gzip, deflate
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1)
Host: 10.10.10.10:8080
Connection: Keep-Alive

GET /index.phpmfKSxSANkeTeNrah.gif HTTP/1.1
Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, application/x-shockwave-flash, */*
Referer: http://10.10.10.10:8080/index.php
Accept-Language: en-us
Accept-Encoding: gzip, deflate
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1)
Host: 10.10.10.10:8080
Connection: Keep-Alive

noone@bt:~/forensic-challenge$

Where we clearly find the two requests, the second having as Referer the first. And then:

noone@bt:~/forensic-challenge$ hexdump -C tcpflow/010.010.010.010.08080-010.010.010.070.01035 | tail
00001700  0a 43 6f 6e 74 65 6e 74  2d 54 79 70 65 3a 20 69  |.Content-Type: i|
00001710  6d 61 67 65 2f 67 69 66  0d 0a 43 6f 6e 6e 65 63  |mage/gif..Connec|
00001720  74 69 6f 6e 3a 20 4b 65  65 70 2d 41 6c 69 76 65  |tion: Keep-Alive|
00001730  0d 0a 53 65 72 76 65 72  3a 20 41 70 61 63 68 65  |..Server: Apache|
00001740  0d 0a 43 6f 6e 74 65 6e  74 2d 4c 65 6e 67 74 68  |..Content-Length|
00001750  3a 20 34 33 0d 0a 0d 0a  47 49 46 38 39 61 01 00  |: 43....GIF89a..|
00001760  01 00 80 00 00 00 00 00  00 00 00 21 f9 04 01 00  |...........!....|
00001770  00 00 00 2c 00 00 00 00  01 00 01 00 00 02 02 44  |...,...........D|
00001780  01 00 3b                                          |..;|
00001783
noone@bt:~/forensic-challenge$ hexdump -C tcpflow/output/gif/00000011.gif
00000000  47 49 46 38 39 61 01 00  01 00 80 00 00 00 00 00  |GIF89a..........|
00000010  00 00 00 21 f9 04 01 00  00 00 00 2c 00 00 00 00  |...!.......,....|
00000020  01 00 01 00 00 02 02 44  01 00 3b                 |.......D..;|
0000002b
noone@bt:~/forensic-challenge$

So we see that in fact, our gif artifact is the one that resulted from that second web request.

	So the MD5sum of the object return by that second request is df3e567d6f16d040326c7a0ea29a4f41

4.- When was the TCP session on port 4444 opened? (Provide the number of seconds since the beginning of the packet capture, rounded to tenths of a second. ie, 49.5 seconds)

To determine when the TCP session was opened, we need to determine when the 3-way handshake took place. So we look for a packet with the [SYN,ACK] flags set, and with source port 4444:

noone@bt:~/forensic-challenge$ tshark -n -r evidence06.pcap 'tcp.flags == 0x12 and tcp.port == 4444'
 14   1.265922  10.10.10.10 -> 10.10.10.70  TCP 4444 > 1036 [SYN, ACK] Seq=0 Ack=1 Win=5840 Len=0 MSS=1460

noone@bt:~/forensic-challenge$

We consider the session to open when the 3-way handshake finishes, so we look for a packet that acks frame 14:

noone@bt:~/forensic-challenge$ tshark -n -r evidence06.pcap 'tcp.analysis.acks_frame == 14'
 15   1.266218  10.10.10.70 -> 10.10.10.10  TCP 1036 > 4444 [ACK] Seq=1 Ack=1 Win=65535 Len=0
noone@bt:~/forensic-challenge$

Thus, our session was opened 1.3 seconds after the beginning of the packet capture.

5.- When was the TCP session on port 4444 closed? (Provide the number of seconds since the beginning of the packet capture, rounded to tenths of a second. ie, 49.5 seconds)

We look for a packet with the [FIN,ACK] flag set and port 4444:

noone@bt:~/forensic-challenge$ tshark -r evidence06.pcap 'tcp.flags == 0x11 and tcp.port == 4444'
1562  87.587095  10.10.10.10 -> 10.10.10.70  TCP krb524 > nsstp [FIN, ACK] Seq=1239099 Ack=96139 Win=62780 Len=0
1563  87.587154  10.10.10.70 -> 10.10.10.10  TCP nsstp > krb524 [FIN, ACK] Seq=96139 Ack=1239099 Win=64773 Len=0
noone@bt:~/forensic-challenge$

And then we look for the ACK to those packets:

noone@bt:~/forensic-challenge$ tshark -n -r evidence06.pcap 'tcp.analysis.acks_frame == 1562 or tcp.analysis.acks_frame == 1563'
1564  87.587246  10.10.10.10 -> 10.10.10.70  TCP 4444 > 1036 [ACK] Seq=1239100 Ack=96140 Win=62780 Len=0
1565  87.587480  10.10.10.70 -> 10.10.10.10  TCP 1036 > 4444 [ACK] Seq=96140 Ack=1239100 Win=64773 Len=0
noone@bt:~/forensic-challenge$

We consider the session closed when the last ACK is received, so the session was closed 87.6 seconds since the beginning of the packet capture.

6.- In packet 17, the malicious server sent a file to the client.
         1. What type of file was it? Choose one:
                * Windows executable
                * GIF image
                * PHP script
                * Zip file
                * Encrypted data

In order to match frame 17 with our inventory of artifacts we do the following:

noone@bt:~/forensic-challenge$ tshark -n -r evidence06.pcap 'frame.number == 17'
 17   1.529777  10.10.10.10 -> 10.10.10.70  TCP 4444 > 1036 [ACK] Seq=5 Ack=1 Win=5840 Len=1460
noone@bt:~/forensic-challenge$

Which correspond to the conversation: 010.010.010.010.04444-010.010.010.070.01036 in tcpflow parlance. Therefore, we simply take a look at what foremost found:

noone@bt:~/forensic-challenge$ cat tcpflow/output/audit.txt | grep -A 6 'File: 010.010.010.010.04444-010.010.010.070.01036'
File: 010.010.010.010.04444-010.010.010.070.01036
Start: Wed May 26 18:48:15 2010
Length: 1 MB (1239098 bytes)

Num      Name (bs=512)         Size      File Offset     Comment

0:      00000000.dll         730 KB               4      04/03/2010 04:07:31
noone@bt:~/forensic-challenge$ file tcpflow/output/dll/00000000.dll
tcpflow/output/dll/00000000.dll: MS-DOS executable PE  for MS Windows (DLL) (GUI) Intel 80386 32-bit
noone@bt:~/forensic-challenge$

Which tells us the server sent a Windows Executable file to our victim.

         2. What was the MD5sum of the file?

Again, using our inventory of artifacts:

noone@bt:~/forensic-challenge$ md5sum tcpflow/output/dll/00000000.dll
b062cb8344cd3e296d8868fbef289c7c  tcpflow/output/dll/00000000.dll
noone@bt:~/forensic-challenge$

So the MD5sum of the malicious file sent is b062cb8344cd3e296d8868fbef289c7c.

We need to be a bit careful here, since foremost's success heavily relies on the file being intact. This may be a problem when dealing with network packet captures. In order verify foremost findings we manually analyze the windows PE file structure and make sure everything is in order.

noone@bt:~/forensic-challenge$ hexdump -C tcpflow/output/dll/00000000.dll | head -n 3
00000000  4d 5a e8 00 00 00 00 5b  52 45 55 89 e5 81 c3 cb  |MZ.....[REU.....|
00000010  11 00 00 ff d3 89 c3 57  68 04 00 00 00 50 ff d0  |.......Wh....P..|
00000020  68 f0 b5 a2 56 68 05 00  00 00 50 ff d3 00 00 00  |h...Vh....P.....|
noone@bt:~/forensic-challenge$

We inmediatly recongnize the 5a4d at the beginning of the file. Consistent with a Windows Executable. Next we try to find the PE headers and structure:

noone@bt:~/forensic-challenge$ hexdump -C tcpflow/output/dll/00000000.dll | grep -A 3 PE | head -n 3
000000d0  00 00 00 00 00 00 00 00  50 45 00 00 4c 01 04 00  |........PE..L...|
000000e0  03 bf b6 4b 00 00 00 00  00 00 00 00 e0 00 02 21  |...K...........!|
000000f0  0b 01 09 00 00 58 07 00  00 62 04 00 00 00 00 00  |.....X...b......|
noone@bt:~/forensic-challenge$

So we observe the PE signature at only 0xd8 offset. Again consistent with a Windows Executable. We also notice that offset 0xde tells us we should expect 4 section headers which we will be looking for shortly. Next, we look for the magic constant 0b01 which is at a fixed distance from the section headers:

noone@bt:~/forensic-challenge$ hexdump -C tcpflow/output/dll/00000000.dll | grep -A 3 '0b 01' | head -n 3
000000f0  0b 01 09 00 00 58 07 00  00 62 04 00 00 00 00 00  |.....X...b......|
00000100  c5 27 06 00 00 10 00 00  00 70 07 00 00 00 00 10  |.'.......p......|
00000110  00 10 00 00 00 02 00 00  05 00 00 00 00 00 00 00  |................|
noone@bt:~/forensic-challenge$

Thus we see the "optional header" starts at offset 0xf0, and so the first section header must be at 0xe0 distance from 0xf0. That is, 0x1d0.

noone@bt:~/forensic-challenge$ hexdump -C tcpflow/output/dll/00000000.dll | grep -A 10 '000001d0' | head -n 10
000001d0  2e 74 65 78 74 00 00 00  e8 57 07 00 00 10 00 00  |.text....W......|
000001e0  00 58 07 00 00 04 00 00  00 00 00 00 00 00 00 00  |.X..............|
000001f0  00 00 00 00 20 00 00 60  2e 72 64 61 74 61 00 00  |.... ..`.rdata..|
00000200  6c 5c 02 00 00 70 07 00  00 5e 02 00 00 5c 07 00  |l\...p...^...\..|
00000210  00 00 00 00 00 00 00 00  00 00 00 00 40 00 00 40  |............@..@|
00000220  2e 64 61 74 61 00 00 00  ec 66 01 00 00 d0 09 00  |.data....f......|
00000230  00 14 01 00 00 ba 09 00  00 00 00 00 00 00 00 00  |................|
00000240  00 00 00 00 40 00 00 c0  2e 72 65 6c 6f 63 00 00  |....@....reloc..|
00000250  b2 9a 00 00 00 40 0b 00  00 9c 00 00 00 ce 0a 00  |.....@..........|
00000260  00 00 00 00 00 00 00 00  00 00 00 00 40 00 00 42  |............@..B|
noone@bt:~/forensic-challenge$

Where we observe our 4 sections: .text, .rdata, .data and .reloc. Most importantly, at offset 0x258 we find the SizeOfRawData for section .reloc (0x9c00), and at offset 0x262 we find the PointerToRawData (offset 0x0ace00). Hence our file should finish at 0x0ace00 + 0x9c00 - 1 = 0xb69ff.

noone@bt:~/forensic-challenge$ hexdump -v -C tcpflow/output/dll/00000000.dll | tail
000b6970  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
000b6980  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
000b6990  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
000b69a0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
000b69b0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
000b69c0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
000b69d0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
000b69e0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
000b69f0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
000b6a00
noone@bt:~/forensic-challenge$

As expected. Therefore, we can be pretty confident that tcpflow took care of the problems that foremost could have encountered, and so the malware was extracted successfully. The rest of the data in this TCP stream that is being excluded from the malware could very well be overlay data. Thus, in order to get a full understanding of what the malware does, it is important to perform further analysis. The executable exchanged though, strictly speaking, ends at 000b69ff as we have done here.

7.-  Vick's computer repeatedly tried to connect back to the malicious server on port 4445, even after the original connection on port 4444 was closed. With respect to these repeated failed connection attempts:
         1. How often does the TCP initial sequence number (ISN) change? (Choose one.)
                * Every packet
                * Every third packet
                * Every 10-15 seconds
                * Every 30-35 seconds
                * Every 60 seconds

By default, tshark performs sequence number analysis, so in order to answer this question we need to add the -o tcp.analyze_sequence_numbers:FALSE switch. Using some simple tshark-foo to select SYN packets to port 4445:

noone@bt:~/forensic-challenge$ tshark -o tcp.analyze_sequence_numbers:FALSE -n -r evidence06.pcap 'tcp.dstport == 4445 and tcp.flags == 0x02' | head
1153  35.947030  10.10.10.70 -> 10.10.10.10  TCP 1037 > 4445 [SYN] Seq=553522758 Win=65535 Len=0 MSS=1460
1155  36.283659  10.10.10.70 -> 10.10.10.10  TCP 1037 > 4445 [SYN] Seq=553522758 Win=65535 Len=0 MSS=1460
1157  36.830543  10.10.10.70 -> 10.10.10.10  TCP 1037 > 4445 [SYN] Seq=553522758 Win=65535 Len=0 MSS=1460
1159  36.831187  10.10.10.70 -> 10.10.10.10  TCP 1037 > 4445 [SYN] Seq=553800369 Win=65535 Len=0 MSS=1460
1161  37.377416  10.10.10.70 -> 10.10.10.10  TCP 1037 > 4445 [SYN] Seq=553800369 Win=65535 Len=0 MSS=1460
1163  37.924270  10.10.10.70 -> 10.10.10.10  TCP 1037 > 4445 [SYN] Seq=553800369 Win=65535 Len=0 MSS=1460
1165  37.925236  10.10.10.70 -> 10.10.10.10  TCP 1037 > 4445 [SYN] Seq=554100968 Win=65535 Len=0 MSS=1460
1167  38.471172  10.10.10.70 -> 10.10.10.10  TCP 1037 > 4445 [SYN] Seq=554100968 Win=65535 Len=0 MSS=1460
1174  39.018031  10.10.10.70 -> 10.10.10.10  TCP 1037 > 4445 [SYN] Seq=554100968 Win=65535 Len=0 MSS=1460
1176  39.018689  10.10.10.70 -> 10.10.10.10  TCP 1037 > 4445 [SYN] Seq=554399680 Win=65535 Len=0 MSS=1460
noone@bt:~/forensic-challenge$

Which shows that Initial Sequence numbers change every third packet: packets 1,2,3: 553522758, packets 4,5,6: 553800369, etc.

         2. How often does the IP ID change? (Choose one.)
                * Every packet
                * Every third packet
                * Every 10-15 seconds
                * Every 30-35 seconds
                * Every 60 seconds

The way we approach this is first count the number of SYN packets sent, and then count the number of different IP ID values observed. We can do this very easily with the following commands:

noone@bt:~/forensic-challenge$ tshark -o tcp.analyze_sequence_numbers:FALSE -n -r evidence06.pcap 'tcp.dstport == 4445 and tcp.flags == 0x02' | wc -l
120
noone@bt:~/forensic-challenge$ tshark -V -o tcp.analyze_sequence_numbers:FALSE -n -r evidence06.pcap 'tcp.dstport == 4445 and tcp.flags == 0x02' | grep Identification: | sort -u | wc -l
120
noone@bt:~/forensic-challenge$

Which means we have 120 packets that attempted to start a connection, and 120 different IP ID numbers. That is, IP IDs change with every packet as expected. 

Note: Actually, the above commands are including the last SYN packet which resulted in a SYN-ACK from the server. Strictily, we shouldn't include this last packet as the question specifically refer to the ones that did not succeed. The answer however does not change, and this result is still perfectly good evidence about our claim. The reason for this is that even if some of those packets were answered with a SYN-ACK, the fact that ALL packets change IP ID, imply that the packets that did not get an unswer also have different IP IDs. This is obvoiusly due to the fact that a packet can not have more than one IP ID. Therefore, our unanswered packets do still change their IP IDs as we claim and as we expect them to.

         3. How often does the source port change? (Choose one.)
                * Every packet
                * Every third packet
                * Every 10-15 seconds
                * Every 30-35 seconds
                * Every 60 seconds

It is possible to simply eye-ball the packets to answer this question. However, I wanted to create a couple of commands that may be usefull to answer other questions as well. The following commands provide the seconds in which a different source port is used to send a SYN packet to port 4445:

noone@bt:~/forensic-challenge$ tshark -o tcp.analyze_sequence_numbers:FALSE -n -r evidence06.pcap 'tcp.dstport == 4445 and tcp.flags == 0x02' > syn_packets.txt
noone@bt:~/forensic-challenge$ cat syn_packets.txt | awk {'print $7'} | sort -u | xargs -I {} tshark -c 1 -n -r evidence06.pcap "tcp.dstport == 4445 and tcp.flags == 0x02 and tcp.srcport == {}" | awk {'print $2'}
35.947030
47.732517
59.462957
71.257992
82.993986
94.878166
106.838688
118.746261
noone@bt:~/forensic-challenge$ 

Thus our source ports change every 10-15 seconds. 

Note: It is possible to obtain this answer using only one invocation to tshark. However, I rather do it this way, because the second command is now a template to answer other questions regarding the amount of time it takes for different fields to change. One only needs to change the first and second awk, and modify the tshark command accordingly.

8.- Eventually, the malicious server responded and opened a new connection. When was the TCP connection on port 4445 first successfully completed? (Provide the number of seconds since the beginning of the packet capture, rounded to tenths of a second. ie, 49.5 seconds)

Using the same tshark-foo from previous questions:

noone@bt:~/forensic-challenge$ tshark -n -r evidence06.pcap 'tcp.flags == 0x12 and tcp.port == 4445'
1657 123.674296  10.10.10.10 -> 10.10.10.70  TCP 4445 > 1044 [SYN, ACK] Seq=1436350345 Ack=1 Win=5840 Len=0 MSS=1460
noone@bt:~/forensic-challenge$ tshark -n -r evidence06.pcap 'tcp.analysis.acks_frame == 1657'
1658 123.674586  10.10.10.70 -> 10.10.10.10  TCP 1044 > 4445 [ACK] Seq=1 Ack=1436350346 Win=65535 Len=0
noone@bt:~/forensic-challenge$

So the connection to port 4445 was finally opened 123.7 seconds since the beginning of the packet capture.

   9. Subsequently, the malicious server sent an executable file to the client on port 4445. What was the MD5 sum of this executable file?

Actually, the server sent the file to the client on port 1044, not 4445. It came from port 4445 though. In any case, there was no file sent *to* port 4445.

Again taking a look at our artifacts inventory:

noone@bt:~/forensic-challenge$ cat tcpflow/output/audit.txt | grep -A 6 'File: 010.010.010.010.04445-010.010.010.070.01044'
File: 010.010.010.010.04445-010.010.010.070.01044
Length: 1 GB (1437183436 bytes)
Num      Name (bs=512)         Size      File Offset     Comment
1:      02805371.dll         730 KB      1436350349      04/03/2010 04:07:31
noone@bt:~/forensic-challenge$

noone@bt:~/forensic-challenge$ md5sum tcpflow/output/dll/02805371.dll
b062cb8344cd3e296d8868fbef289c7c  tcpflow/output/dll/02805371.dll
noone@bt:~/forensic-challenge$

So the md5sum of the file sent to the client *from* port 4445 is b062cb8344cd3e296d8868fbef289c7c

We can perform the same PE analysis as before to verify that the executable was extracted successfully.

  10. When was the TCP connection on port 4445 closed? (Provide the number of seconds since the beginning of the packet capture, rounded to tenths of a second. ie, 49.5 seconds)

After one last performance of our tshark-foo:

noone@bt:~/forensic-challenge$ tshark -r evidence06.pcap 'tcp.flags == 0x11 and tcp.port == 4445'
2552 198.440669  10.10.10.70 -> 10.10.10.10  TCP dcutility > upnotifyp [FIN, ACK] Seq=11379 Ack=1437183437 Win=65232 Len=0
2553 198.441346  10.10.10.10 -> 10.10.10.70  TCP upnotifyp > dcutility [FIN, ACK] Seq=1437183437 Ack=11380 Win=62780 Len=0
noone@bt:~/forensic-challenge$ tshark -n -r evidence06.pcap 'tcp.analysis.acks_frame == 2552 or tcp.analysis.acks_frame == 2553'
2553 198.441346  10.10.10.10 -> 10.10.10.70  TCP 4445 > 1044 [FIN, ACK] Seq=1437183437 Ack=11380 Win=62780 Len=0
2554 198.441738  10.10.10.70 -> 10.10.10.10  TCP 1044 > 4445 [ACK] Seq=11380 Ack=1437183438 Win=65232 Len=0
noone@bt:~/forensic-challenge$

So the connection was finally closed after 198.4 seconds since the beginning of the capture file.

Additional Text: