To make matters worse, Aaron (the forensic investigator) is on vacation on a remote tropical island. Network access is via a slow public wifi hotspot with a small 9 inch netbook. Since the packet capture potentially contains company secrets, removing the file from the network is out of the question. Aaron figures the quickest and safest way to analyze this file will be on his linux workstation at work. Since he is in a hurry to get back to the beach, the last thing he wants to do is deal with the lag of a full blown VPN connection with remote desktop and pretty GUIs. Instead, he makes a quick SSH connection into work and fires up tshark to get a glance at what is going on. Step one, run: tshark –r evidence.pcap | more A couple quick observations to get our bearings shows that we are dealing with 240 packets, it looks like someone already filtered out non relevant hosts for us (this should be quick and easy!). It looks like we know the following: 1. 192.168.1.158 is Ann’s computer 2. 192.168.1.159 looks like the thief’s IP 3. Ann is talking to 64.12.24.50 which is an AOL owned IP. It looks like we are dealing with AIM traffic. Since we aren’t dealing with a lot of data, we can quickly break the pcap out into flows of raw data. My next step is to run: tcpflow –r evidence.pcap Immediately after running this command, one flow dump catches my attention: 192.168.001.158.05190-192.168.001.159.01272 I see that Ann’s computer is communicating with the suspicious host on port 5190 (an AIM port). To get an idea of what is going on, I fire up xxd from the command line: xxd 192.168.001.158.05190-192.168.001.159.01272 | more The first few lines are a dead giveaway: 0000000: 4f46 5432 0100 0101 0000 0000 0000 0000 OFT2............ 0000010: 0000 0000 0001 0001 0001 0001 0000 2ee8 ................ 0000020: 0000 2ee8 0000 0000 b164 0000 ffff 0000 .........d...... 0000030: 0000 0000 0000 0000 ffff 0000 0000 0000 ................ 0000040: ffff 0000 436f 6f6c 2046 696c 6558 6665 ....Cool FileXfe 0000050: 7200 0000 0000 0000 0000 0000 0000 0000 r............... 0000060: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0000070: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0000080: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0000090: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 00000a0: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 00000b0: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 00000c0: 7265 6369 7065 2e64 6f63 7800 0000 0000 recipe.docx.... It looks like we are dealing with a protocol called OFT2 to transmit a file called recipe.docx. I slip back to the browser on my netbook and a quick google search confirms OFT2 is “Oscar File Transfer 2”. I find ample documentation at: http://www.cs.cmu.edu/~jhclark/aim/On%20Sending%20Files%20via%20OSCAR.odt Pg 12 indicates the packet should contain a header of length 0x0100 (256 bytes) and that recipe.docx is indeed in the correct position in the header for the file name. Perfect, we have the file that is being transferred, I just need to remove the 256 byte header! xxd -s +256 192.168.001.158.05190-192.168.001.159.01272 | xxd -s -256 -r > recipe.docx And now we have the file that was transmitted. Finding the md5sum and magic number are trivial. I can find the sum by running: md5sum recipe.docx 8350582774e1d4dbe1d61d64c89e0ea1 To find the magic number, I simply run: xxd -l 4 -ps recipe.docx 504b0304 The other interesting flow from Ann’s PC appears to be to an AIM server: 192.168.001.158.51128-064.012.024.050.00443 We can take a quick and dirty look into that dump by running: xxd 192.168.001.158.51128-064.012.024.050.00443 What we find looks like half of a conversation with user Sec558user1 where Ann is offering up the recipe.docx file. I have the screenname of Ann’s partner as well as the first line of the conversation in the previous dump, but now I’m curious. Sure, that is what the boss asked for, but I could throw together a quick ruby script to extract the full conversation. I could try to reverse engineer the specifics of the AIM protocol, but a quick google search gives me ample documentation. I find exactly what I need at: http://dev.aol.com/aim/oscar/#SENDIM I throw together a quick and dirty script in about 40 lines that will reassemble packets into an AIM payload message. Then using the information I find in the documentation, I dump the message text to the screen for analysis. My script gives me the complete conversation (see output below) with HTML markup which is easily human readable. I also have one more tool to add to my packet analysis arsenal! From Sender: 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 >:-) From Sec558user1: +1n+OJaXthanks dude+1n+O From Sec558user1: +1n+OJsjcan't wait to sell it on ebay+1n+O From Sender: see you in hawaii! I have also included the following files: aim.rb - The ruby script used to extract the AIM conversation, complete with comments. extractfile.sh - A simple bash script that uses the commands from this narrative to extract the file, MD5sum and Magic Number answers.txt - The answers to the questions for the SANS contest