Network Forensics Puzzle Contest| ================================ Challenge by Jonathan Ham Solution by Franck GUENICHOT (franck.guenichot[at]orange[dot]fr) Tools Used: _ tshark 1.0.7 (libpcap 1.0) _ whois 4.7.30 _ sort, uniq, awk _ oft-tsk.lua (home made OFT protocol Lua dissector) _ tcpflow 0.21 _ md5sum The Challenge ============= """ Anarchy-R-Us, Inc. suspects that one of their employees, Ann Dercover, is really a secret agent working for their competitor. Ann has access to the company's prize asset, the secret recipe. Security staff are worried that Ann may try to leak the company's secret recipe. Security staff have been monitoring Ann's activity for some time, but haven't found anything suspicious-- until now. Today an unexpected laptop briefly appeared on the company wireless network. Staff hypothesize it may have been someone in the parking lot, because no strangers were seen in the building. Ann's computer, (192.168.1.158) sent IMs over the wireless network to this computer. The rogue laptop disappeared shortly thereafter. "We have a packet capture of the activity," said security staff, "but we can't figure out what's going on. Can you help?" You are the forensic investigator. Your mission is to figure out who Ann was IM-ing, what she sent, and recover evidence including: 1. What is the name of Ann's IM buddy? 2. What was the first comment in the captured IM conversation? 3. What is the name of the file Ann transferred? 4. What is the magic number of the file you want to extract (first four bytes)? 5. What was the MD5sum of the file? 6. What is the secret recipe? Here is your evidence file: http://jhamcorp.com/contest_01/evidence.pcap MD5 (evidence.pcap) = d187d77e18c84f6d72f5845edca833f5 """ Quick Answers: ============== 1. What is the name of Ann's IM buddy? A: Sec558user1 2. What was the first comment in the captured IM conversation? A: Here's the secret recipe... I just downloaded it from the file server. Just copy to a thumb drive and you're good to go >:-) 3. What is the name of the file Ann transferred? A: recipe.docx 4. What is the magic number of the file you want to extract (first four bytes)? A: 0x504b0304 5. What was the MD5sum of the file? A: 0x8350582774e1d4dbe1d61d64c89e0ea1 6. What is the secret recipe? A: (see below) Recipe for Disaster: 1 serving Ingredients: 4 cups sugar 2 cups water In a medium saucepan, bring the water to a boil. Add sugar. Stir gently over low heat until sugar is fully dissolved. Remove the saucepan from heat. Allow to cool completely. Pour into gas tank. Repeat as necessary. Detailled Answers ================= Initial Analysis ---------------- Listing Ann's host ip communication: We know that Ann's ip address is 192.168.1.158, so we can filter the pcap file with tshark to view which are the hosts Ann has talked to. #################################################################################################### franck@ODIN:~/Analysis/Sources$ tshark -r evidence.pcap -R "ip.src==192.168.1.158" -T fields -e "ip.dst" |sort |uniq -c 1 192.168.1.10 15 192.168.1.159 2 239.255.255.250 20 64.12.24.50 #################################################################################################### This tshark output let us know that something happened between Ann and mostly 2 hosts : One local host 192.168.1.159 (the intruder ?) and one Internet host: 64.12.24.50. (The 2 other hosts are not interresting for our research, 239.255.255.250 is used by SSDP (UPnP), and Ann have only exchange 1 frame with 192.168.1.10, we could be pretty sure that this is not the intruder.) Let's try to know a bit more on this Internet Host with the whois command: #################################################################################################### franck@ODIN:~/Analysis/Sources$ whois 64.12.24.50 OrgName: America Online, Inc. <====================================== OrgID: AMERIC-158 Address: 10600 Infantry Ridge Road City: Manassas StateProv: VA PostalCode: 20109 Country: US NetRange: 64.12.0.0 - 64.12.255.255 CIDR: 64.12.0.0/16 NetName: AOL-MTC NetHandle: NET-64-12-0-0-1 Parent: NET-64-0-0-0-0 NetType: Direct Assignment NameServer: DNS-01.NS.AOL.COM NameServer: DNS-02.NS.AOL.COM Comment: RegDate: 1999-12-13 Updated: 1999-12-16 RTechHandle: AOL-NOC-ARIN RTechName: America Online, Inc. RTechPhone: +1-703-265-4670 RTechEmail: domains@aol.net # ARIN WHOIS database, last updated 2009-09-01 20:00 # Enter ? for additional hints on searching ARIN's WHOIS database. #################################################################################################### Ok, now we know that this host has something to do with AOL. We also know that Ann is suspected to have communicated with someone via an IM program. With this two evidences, we could make an hypothesis: the IM program is surely an AIM Client. Let's try to validate this point: Viewing conversation between Ann's host and 64.12.24.50 #################################################################################################### franck@ODIN:~/Analysis/Sources$ tshark -r evidence.pcap -R "ip.addr==192.168.1.158 && ip.addr==64.12.24.50" 23 18.870898 192.168.1.158 -> 64.12.24.50 SSL Continuation Data 24 18.871477 64.12.24.50 -> 192.168.1.158 TCP https > 51128 [ACK] Seq=1 Ack=7 Win=64240 Len=0 25 33.914966 192.168.1.158 -> 64.12.24.50 SSL Continuation Data 26 33.915486 64.12.24.50 -> 192.168.1.158 TCP https > 51128 [ACK] Seq=1 Ack=196 Win=64240 Len=0 27 34.006599 192.168.1.158 -> 64.12.24.50 SSL Continuation Data 28 34.006604 64.12.24.50 -> 192.168.1.158 TCP https > 51128 [ACK] Seq=1 Ack=236 Win=64240 Len=0 29 34.023247 64.12.24.50 -> 192.168.1.158 SSL Continuation Data 31 34.025537 64.12.24.50 -> 192.168.1.158 SSL Continuation Data 32 34.026804 192.168.1.158 -> 64.12.24.50 TCP 51128 > https [ACK] Seq=236 Ack=210 Win=62780 Len=0 33 34.026809 192.168.1.158 -> 64.12.24.50 TCP 51128 > https [ACK] Seq=236 Ack=248 Win=62742 Len=0 92 58.458768 192.168.1.158 -> 64.12.24.50 SSL Continuation Data 93 58.461856 64.12.24.50 -> 192.168.1.158 TCP https > 51128 [ACK] Seq=248 Ack=364 Win=64240 Len=0 94 58.568705 64.12.24.50 -> 192.168.1.158 SSL Continuation Data 96 58.569716 192.168.1.158 -> 64.12.24.50 TCP 51128 > https [ACK] Seq=364 Ack=457 Win=62742 Len=0 97 58.571268 64.12.24.50 -> 192.168.1.158 SSL Continuation Data 98 58.574447 192.168.1.158 -> 64.12.24.50 TCP 51128 > https [ACK] Seq=364 Ack=495 Win=62742 Len=0 136 61.287474 64.12.24.50 -> 192.168.1.158 SSL Continuation Data 137 61.288392 192.168.1.158 -> 64.12.24.50 TCP 51128 > https [ACK] Seq=364 Ack=624 Win=62742 Len=0 161 67.395187 64.12.24.50 -> 192.168.1.158 SSL Continuation Data 162 67.395540 192.168.1.158 -> 64.12.24.50 TCP 51128 > https [ACK] Seq=364 Ack=664 Win=62742 Len=0 167 69.578667 64.12.24.50 -> 192.168.1.158 SSL Continuation Data 168 69.579120 192.168.1.158 -> 64.12.24.50 TCP 51128 > https [ACK] Seq=364 Ack=890 Win=62742 Len=0 179 77.834511 64.12.24.50 -> 192.168.1.158 SSL Continuation Data 180 77.834516 192.168.1.158 -> 64.12.24.50 TCP 51128 > https [ACK] Seq=364 Ack=930 Win=62742 Len=0 184 83.489593 64.12.24.50 -> 192.168.1.158 SSL Continuation Data 185 83.489598 192.168.1.158 -> 64.12.24.50 TCP 51128 > https [ACK] Seq=364 Ack=1174 Win=62742 Len=0 190 83.906524 64.12.24.50 -> 192.168.1.158 SSL Continuation Data 191 83.907211 192.168.1.158 -> 64.12.24.50 TCP 51128 > https [ACK] Seq=364 Ack=1214 Win=62742 Len=0 196 84.995484 64.12.24.50 -> 192.168.1.158 SSL Continuation Data 197 84.995488 192.168.1.158 -> 64.12.24.50 TCP 51128 > https [ACK] Seq=364 Ack=1254 Win=62742 Len=0 200 87.726166 192.168.1.158 -> 64.12.24.50 SSL Continuation Data 201 87.726936 64.12.24.50 -> 192.168.1.158 TCP https > 51128 [ACK] Seq=1254 Ack=404 Win=64240 Len=0 210 90.788876 192.168.1.158 -> 64.12.24.50 SSL Continuation Data 211 90.789489 64.12.24.50 -> 192.168.1.158 TCP https > 51128 [ACK] Seq=1254 Ack=414 Win=64240 Len=0 212 90.816866 192.168.1.158 -> 64.12.24.50 SSL Continuation Data 213 90.817354 64.12.24.50 -> 192.168.1.158 TCP https > 51128 [ACK] Seq=1254 Ack=524 Win=64240 Len=0 214 91.003314 64.12.24.50 -> 192.168.1.158 SSL Continuation Data 216 91.004650 64.12.24.50 -> 192.168.1.158 SSL Continuation Data 217 91.033478 192.168.1.158 -> 64.12.24.50 TCP 51128 > https [ACK] Seq=524 Ack=1463 Win=62742 Len=0 218 91.033482 192.168.1.158 -> 64.12.24.50 TCP 51128 > https [ACK] Seq=524 Ack=1501 Win=62742 Len=0 #################################################################################################### Hum, SSL... (maybe we are going to be stucked) Or maybe not, it seems that some AIM clients use SSL only during the initial login process, port 443 is still used after the logon process but all trafic (chat for example) is transmitted unencrypted. To verify this point we have to tell tshark to not use SSL dissector for port 443/TCP, but the AIM dissector, we are going to use "-d" switch on the tshark command line: #################################################################################################### franck@ODIN:~/Analysis/Sources$ tshark -r evidence.pcap -R "ip.addr==192.168.1.158 && ip.addr==64.12.24.50" -d tcp.port==443,aim 23 18.870898 192.168.1.158 -> 64.12.24.50 AIM Keep Alive 24 18.871477 64.12.24.50 -> 192.168.1.158 TCP https > 51128 [ACK] Seq=1 Ack=7 Win=64240 Len=0 25 33.914966 192.168.1.158 -> 64.12.24.50 AIM Messaging AIM Messaging, Outgoing to: Sec558user1 26 33.915486 64.12.24.50 -> 192.168.1.158 TCP https > 51128 [ACK] Seq=1 Ack=196 Win=64240 Len=0 27 34.006599 192.168.1.158 -> 64.12.24.50 AIM Messaging AIM Messaging, Mini Typing Notifications (MTN) 28 34.006604 64.12.24.50 -> 192.168.1.158 TCP https > 51128 [ACK] Seq=1 Ack=236 Win=64240 Len=0 29 34.023247 64.12.24.50 -> 192.168.1.158 AIM Generic AIM Generic, Rate Change 31 34.025537 64.12.24.50 -> 192.168.1.158 AIM Messaging AIM Messaging, Acknowledge 32 34.026804 192.168.1.158 -> 64.12.24.50 TCP 51128 > https [ACK] Seq=236 Ack=210 Win=62780 Len=0 33 34.026809 192.168.1.158 -> 64.12.24.50 TCP 51128 > https [ACK] Seq=236 Ack=248 Win=62742 Len=0 92 58.458768 192.168.1.158 -> 64.12.24.50 AIM Messaging AIM Messaging, Outgoing to: Sec558user1[Malformed Packet] 93 58.461856 64.12.24.50 -> 192.168.1.158 TCP https > 51128 [ACK] Seq=248 Ack=364 Win=64240 Len=0 94 58.568705 64.12.24.50 -> 192.168.1.158 AIM Generic AIM Generic, Rate Change 96 58.569716 192.168.1.158 -> 64.12.24.50 TCP 51128 > https [ACK] Seq=364 Ack=457 Win=62742 Len=0 97 58.571268 64.12.24.50 -> 192.168.1.158 AIM Messaging AIM Messaging, Acknowledge 98 58.574447 192.168.1.158 -> 64.12.24.50 TCP 51128 > https [ACK] Seq=364 Ack=495 Win=62742 Len=0 136 61.287474 64.12.24.50 -> 192.168.1.158 AIM Messaging AIM Messaging, Incoming 137 61.288392 192.168.1.158 -> 64.12.24.50 TCP 51128 > https [ACK] Seq=364 Ack=624 Win=62742 Len=0 161 67.395187 64.12.24.50 -> 192.168.1.158 AIM Messaging AIM Messaging, Mini Typing Notifications (MTN) 162 67.395540 192.168.1.158 -> 64.12.24.50 TCP 51128 > https [ACK] Seq=364 Ack=664 Win=62742 Len=0 167 69.578667 64.12.24.50 -> 192.168.1.158 AIM Messaging AIM Messaging, Incoming 168 69.579120 192.168.1.158 -> 64.12.24.50 TCP 51128 > https [ACK] Seq=364 Ack=890 Win=62742 Len=0 179 77.834511 64.12.24.50 -> 192.168.1.158 AIM Messaging AIM Messaging, Mini Typing Notifications (MTN) 180 77.834516 192.168.1.158 -> 64.12.24.50 TCP 51128 > https [ACK] Seq=364 Ack=930 Win=62742 Len=0 184 83.489593 64.12.24.50 -> 192.168.1.158 AIM Messaging AIM Messaging, Incoming 185 83.489598 192.168.1.158 -> 64.12.24.50 TCP 51128 > https [ACK] Seq=364 Ack=1174 Win=62742 Len=0 190 83.906524 64.12.24.50 -> 192.168.1.158 AIM Messaging AIM Messaging, Mini Typing Notifications (MTN) 191 83.907211 192.168.1.158 -> 64.12.24.50 TCP 51128 > https [ACK] Seq=364 Ack=1214 Win=62742 Len=0 196 84.995484 64.12.24.50 -> 192.168.1.158 AIM Messaging AIM Messaging, Mini Typing Notifications (MTN) 197 84.995488 192.168.1.158 -> 64.12.24.50 TCP 51128 > https [ACK] Seq=364 Ack=1254 Win=62742 Len=0 200 87.726166 192.168.1.158 -> 64.12.24.50 AIM Messaging AIM Messaging, Mini Typing Notifications (MTN) 201 87.726936 64.12.24.50 -> 192.168.1.158 TCP https > 51128 [ACK] Seq=1254 Ack=404 Win=64240 Len=0 210 90.788876 192.168.1.158 -> 64.12.24.50 TCP [TCP segment of a reassembled PDU] 211 90.789489 64.12.24.50 -> 192.168.1.158 TCP https > 51128 [ACK] Seq=1254 Ack=414 Win=64240 Len=0 212 90.816866 192.168.1.158 -> 64.12.24.50 AIM Messaging AIM Messaging, Outgoing to: Sec558user1 213 90.817354 64.12.24.50 -> 192.168.1.158 TCP https > 51128 [ACK] Seq=1254 Ack=524 Win=64240 Len=0 214 91.003314 64.12.24.50 -> 192.168.1.158 AIM Generic AIM Generic, Rate Change 216 91.004650 64.12.24.50 -> 192.168.1.158 AIM Messaging AIM Messaging, Acknowledge 217 91.033478 192.168.1.158 -> 64.12.24.50 TCP 51128 > https [ACK] Seq=524 Ack=1463 Win=62742 Len=0 218 91.033482 192.168.1.158 -> 64.12.24.50 TCP 51128 > https [ACK] Seq=524 Ack=1501 Win=62742 Len=0 #################################################################################################### Nice ! It seems that this tcp stream is really an AIM conversation... With this fact, we can know begin to try answering some of the questions... 1. What is the name of Ann's IM buddy? --------------------------------------- We could use the command below to find the answer: Using AIM dissector and field aim.buddyname. #################################################################################################### franck@ODIN:~/Analysis/Sources$ tshark -r evidence.pcap -R "ip.addr==192.168.1.158 && ip.addr==64.12.24.50 && aim" -d tcp.port==443,aim -T fields -e "aim.buddyname" |sort |uniq -c 4 15 Sec558user1 #################################################################################################### Well it seems that Ann's IM buddy is: Sec558user1 2. What was the first comment in the captured IM conversation? --------------------------------------------------------------- With the tshark command below, we could find the answer: Using AIM dissector and field aim.messageblock.message. #################################################################################################### franck@ODIN:~/Analysis/Sources$ tshark -r evidence.pcap -R "ip.addr==192.168.1.158 && ip.addr==64.12.24.50 && aim_messaging" -d tcp.port==443,aim -T fields -e "ip.src" -e "aim.messageblock.message" 192.168.1.158 Here's the secret recipe... I just downloaded it from the file server. Just copy to a thumb drive and you're good to go >:-) 192.168.1.158 64.12.24.50 192.168.1.158 64.12.24.50 64.12.24.50 64.12.24.50 64.12.24.50 thanks dude 64.12.24.50 64.12.24.50 can't wait to sell it on ebay 64.12.24.50 64.12.24.50 192.168.1.158 192.168.1.158 see you in hawaii! 64.12.24.50 #################################################################################################### The first comment was from Ann and was: Here's the secret recipe... I just downloaded it from the file server. Just copy to a thumb drive and you're good to go >:-) 3. What is the name of the file Ann transferred? ------------------------------------------------ To answer this one, we have to dig a bit more into the AIM (OSCAR) protocol. To send a file to a buddy, an AIM client has to send a RENDEZVOUS request to the receiver through the AOL messaging server (here, 64.12.24.50). This request will be later accepted or declined by the intended receiver. (Again, through the server) After receiving the request, the RECEIVER will try to connect to the SENDER's ip and port announced in the previous rendezvous request. The initial request is sent in the form of an ICBM message with a special TLV (0x0005 Rendezvous) and a specific constant determining the capability of the client to send files. This constant is : 09461343-4C7F-11D1-8222-444553540000. (If we could find this "signature" in an AIM messaging packet then we will be sure that Ann has tried to send a file to Sec558user1.) Finally, when the receiver is connected to the sender, the sender transmits the file using the Oscar File Transfer Protocol (OFT). First, Let's try to find a rendezvous "send file" request sent by Ann in our evidence file: #################################################################################################### franck@ODIN:~/Analysis/Sources$ tshark -r evidence.pcap -R "ip.addr==192.168.1.158 && ip.addr==64.12.24.50 && (aim_messaging contains 09:46:13:43:4C:7F:11:D1:82:22:44:45:53:54:00:00) " -d tcp.port==443,aim 92 58.458768 192.168.1.158 -> 64.12.24.50 AIM Messaging AIM Messaging, Outgoing to: Sec558user1[Malformed Packet] 136 61.287474 64.12.24.50 -> 192.168.1.158 AIM Messaging AIM Messaging, Incoming #################################################################################################### Ok, we have 2 frames matching our filter, one outgoing (the request) and one incoming (the accept). My version of tshark doesn't have any filter to extract the TLV values from the OSCAR ICBM message so, we have to look at the detailled packet data to verify that frame 92 is really a rendezvous request: (Output was stripped for readability) #################################################################################################### franck@ODIN:~/Analysis/Sources$ tshark -r evidence.pcap -R "frame.number==92" -d tcp.port==443,aim -V ... AIM Messaging, Outgoing ICBM Cookie: 3731373436343700 Message Channel ID: 0x0002 Buddy: Sec558user1 Buddyname len: 11 Buddy Name: Sec558user1 TLV: Server Ack Requested Value ID: Server Ack Requested (0x0003) Length: 0 Value TLV: Rendez Vous Data Value ID: Rendez Vous Data (0x0005) Length: 82 Value Message Type: Request (0x0000) ICBM Cookie: 3731373436343700 Send File {09461343-4c7f-11d1-8222-444553540000} TLV: Unknown Value ID: Unknown (0x0002) Length: 4 Value TLV: Internal IP Value ID: Internal IP (0x0003) Length: 4 Value: 192.168.1.158 TLV: External Port Value ID: External Port (0x0005) Length: 2 Value: 5190 TLV: Unknown Value ID: Unknown (0x000a) Length: 2 Value TLV: Unknown Value ID: Unknown (0x000f) Length: 0 Value TLV: Extended Data Value ID: Extended Data (0x2711) Length: 20 Value Length: 256 Version: 256 Plugin: Unknown {00002ee8-7265-6369-7065-2e646f637800} Unknown [Malformed Packet: AIM] #################################################################################################### Ok, now we are sure. And this output let us know that the rendez-vous is fixed at 192.168.1.158 on tcp port 5190 (AOL) Now we have to verify one of our hypothesis : Is 192.168.1.159 the intruder ? If yes, it should have tried to connect to Ann's host on port 5190/TCP just after it received the "send file" rendezvous request. Let's see: the command below filters all tcp syn request received by Ann's host after frame 92 (the rendezvous request) #################################################################################################### franck@ODIN:~/Analysis/Sources$ tshark -r evidence.pcap -R "frame.number>=92 && ip.dst==192.168.1.158 && tcp.flags==0x02" -d tcp.port==443,aim -n 109 61.052925 192.168.1.159 -> 192.168.1.158 TCP 1272 > 5190 [SYN] Seq=0 Win=64240 Len=0 MSS=1460 #################################################################################################### Well, we are lucky ! Now, we are going to (finally) answer the 3rd question: what was the filename transferred by Ann. We are now pretty sure that the file transfer was done between Ann's host port 5190 and 192.168.1.159 port 1272, and surely using the OFT protocol. Well, my version of tshark doesn't seem to handle correctly OFT, so i've written a little OFT dissector in lua to find quickly what was done. My OFT dissector is bound to port 5190/TCP, let's try it: #################################################################################################### franck@ODIN:~/Analysis/Sources$ tshark -r evidence.pcap -X lua_script:oft-tsk.lua -R "oft" -d tcp.port==443,aim -n 112 61.054884 192.168.1.158 -> 192.168.1.159 OFT OFT2 Type: Prompt 117 61.155756 192.168.1.159 -> 192.168.1.158 OFT OFT2 Type: Acknowledge 119 61.270615 192.168.1.158 -> 192.168.1.159 OFT Raw Data 120 61.270620 192.168.1.158 -> 192.168.1.159 OFT Raw Data 122 61.270628 192.168.1.158 -> 192.168.1.159 OFT Raw Data 123 61.270632 192.168.1.158 -> 192.168.1.159 OFT Raw Data 124 61.270635 192.168.1.158 -> 192.168.1.159 OFT Raw Data 126 61.270641 192.168.1.158 -> 192.168.1.159 OFT Raw Data 127 61.270644 192.168.1.158 -> 192.168.1.159 OFT Raw Data 128 61.270647 192.168.1.158 -> 192.168.1.159 OFT Raw Data 129 61.270651 192.168.1.158 -> 192.168.1.159 OFT Raw Data 131 61.270658 192.168.1.158 -> 192.168.1.159 OFT Raw Data 133 61.270706 192.168.1.159 -> 192.168.1.158 OFT OFT2 Type: Done #################################################################################################### A file transfer using OFT between two hosts involves this step: 1. the sender sender an OFT Prompt (with some useful information, like the filename, the file size, etc...) 2. the receiver answer with an OFT Acknowledge 3. the file is transferred (Raw data) 4. the receiver send an OFT Done, When the transfer is finished. We want to know the filename, easy ! (with the dissector: filter oft.filename) #################################################################################################### franck@ODIN:~/Analysis/Sources$ tshark -r evidence.pcap -X lua_script:oft-tsk.lua -R "oft" -n -T fields -e "oft.filename" |sort -u | uniq -c 1 1 recipe.docx #################################################################################################### The filename was: recipe.docx 4. What is the magic number of the file you want to extract (first four bytes)? ------------------------------------------------------------------------------- We just have to read the first 4 bytes of payload of the first OFT Raw data frame (frame 119) #################################################################################################### franck@ODIN:~/Analysis/Sources$ tshark -r evidence.pcap -X lua_script:oft-tsk.lua -R "frame.number==119" -T fields -e "oft.data" |awk '{gsub(/:/,"");print("0x" substr($1,1,8))}' 0x504b0304 #################################################################################################### Magic number is 0x504b0304 5. What was the MD5sum of the file? ----------------------------------- Well to answer this one, we have to extract the file from the tcp stream. a.) Extracting the file ----------------------- To extract the transferred file from the tcp stream, i've used tshark and tcpflow. First, we filter out only OFT Raw data frames from the original evidence.pcap file and create a new pcap file containing only the frames we want. #################################################################################################### franck@ODIN:~/Analysis/Sources$ tshark -r evidence.pcap -X lua_script:oft-tsk.lua -R "oft.data" -w oft-data.pcap #################################################################################################### Now, we have a file: oft-data.pcap containing the filtered frame. We're going to use tcpflow to extract the payloads of all this frame and write it in a new binary file. Tcpflow will create a file named : 192.168.001.158.05190-192.168.001.159.01272 containing all the data we expect. #################################################################################################### franck@ODIN:~/Analysis/Sources$ tcpflow -r oft-data.pcap franck@ODIN:~/Analysis/Sources$ ls -l 1* -rw-r--r-- 1 franck franck 12008 2009-09-02 23:08 192.168.001.158.05190-192.168.001.159.01272 #################################################################################################### We have now a binary file with a size of 12008 o . We can validate that this size is the correct one, because the initial file size is sent by the sender (Ann) in the first frame of the OFT transfer (OFT Prompt). To do this, we could use two filter of the oft-tsk.lua dissector: oft.type==0x101 (OFT Prompt) and the field oft.size (Size of the file to send). #################################################################################################### franck@ODIN:~/Analysis/Sources$ tshark -r evidence.pcap -X lua_script:oft-tsk.lua -R "oft.type==0x101" -T fields -e "oft.size" 12008 #################################################################################################### Hey ! Seems to be good. We are now pretty sure that we have all the bytes of the transferred file between Ann and Sec558user1 We can now compute the md5sum, using md5sum for example: #################################################################################################### franck@ODIN:~/Analysis/Sources$ cp 192.168.001.158.05190-192.168.001.159.01272 recipe.docx franck@ODIN:~/Analysis/Sources$ md5sum recipe.docx 8350582774e1d4dbe1d61d64c89e0ea1 recipe.docx #################################################################################################### So the recipe.docx file md5 sum is : 8350582774e1d4dbe1d61d64c89e0ea1 6. What is the secret recipe? ----------------------------- Now, we just have to open the file, and read the secret recipe (see below) Recipe for Disaster: 1 serving Ingredients: 4 cups sugar 2 cups water In a medium saucepan, bring the water to a boil. Add sugar. Stir gently over low heat until sugar is fully dissolved. Remove the saucepan from heat. Allow to cool completely. Pour into gas tank. Repeat as necessary. Now, Ann is caught ! Conclusion ========== I found this challenge very entertaining, and it gave me the opportunity to write my first [wire|T]shark dissector in lua. I've tried to give the maximum detail level for all the steps i've taken to answer the questions. (Maybe, too much...) Honestly, finding some answers took me very less time than writing this document, but I enjoyed writing it Thanks to Jonathan Ham for his Network Forensics Puzzle. :-) References: =========== tshark : http://www.wireshark.org/docs/man-pages/tshark.html lua dissectors in wireshark: http://wiki.wireshark.org/Lua/Dissectors http://www.cacetech.com/sharkfest.09/DT06_Bjorlykke_Lua%20Scripting%20in%20Wireshark.pdf tcpflow: http://www.circlemud.org/~jelson/software/tcpflow/ Sending file via OSCAR: http://www.cs.cmu.edu/~jhclark/aim/On%20Sending%20Files%20via%20OSCAR.odt OSCAR Protocol ref: http://iserverd.khstu.ru/oscar http://dev.aol.com/aim/oscar/