Name: Erik Hjelmvik Description: Network Forensics Puzzle Contest - Puzzle #6: Ann's Aurora http://forensicscontest.com/2010/05/21/puzzle-6-anns-aurora http://computer-forensics.sans.org/challenges/ __CASE_BACKGROUND_______________________________________________ Ann Dercover is after SaucyCorp's Secret Sauce recipe. She's been trailing the lead developer, Vick Timmes, to figure out how she can remotely access SaucyCorp's servers. One night, while conducting reconnaissance, she sees him log into his laptop (10.10.10.70) and VPN into SaucyCorp's headquarters. Leveraging her connections with international hacking organizations, Ann obtains a 0-day exploit for Internet Explorer and launches a client-side spear phishing attack against Vick Timmes. Ann carefully crafts an email to Vick containing tips on how to improve secret sauce recipes and sends it. Seeing an opportunity that could get him that Vice President of Product Development title (and corner office) that he's been coveting, Vick clicks on the link. Ann is readyto strike... __SUBMISSION_DETAILS____________________________________________ Author: Erik Hjelmvik Used Tools (all open source): Wireshark http://www.wireshark.org/ NetworkMiner http://networkminer.sourceforge.net/ Foremost http://foremost.sourceforge.net/ __SOLUTION______________________________________________________ First I download the pcap file to my sandbox virtual machine and verified its integrity. erik@sandbox:~/Desktop/puzzle#6$ md5deep evidence06.pcap efac05c50c0ae92bf0818e98763920bd erik@sandbox:~/Desktop/puzzle#6$ sha256deep evidence06.pcap fa5fc1ffad525688626c301372b37e101efcbbbd124f9781f5701648e6a02be3 Looks allright, so let's continue. I start with opening up the pcap file in NetworkMiner, i.e my own network forensics tool. I've actually improved NetworkMiner slightly as a result of puzzle#6. When first opening evidence06.pcap in NetworkMiner version 0.91 I realized that it did not properly extract the HTTP file transfers at the beginning of the pcap file. The reason for this was because the TCP session containing the HTTP traffic wasn't complete; the initial TCP three way handshake was missing. NetworkMiner therefore didn't know which host was the server or client. With a 50% chance of doing a correct guess NetworkMiner 0.91 actually failed. This also caused NetworkMiner to be unable to understand the application layer data in this TCP session. What I did to solve this problem was simply to introduce some intelligence into NetworkMiner make better guesses of which host is the server and which is the client in a TCP session, where the tree-way handshake is missing. So as of version 0.92 of NetworkMiner you can trust it to correctly parse your cropped TCP sessions, like the one in puzzle#6. Looking at the "Hosts" tab of NetworkMiner I can see that there Has only been two hosts involved: * 10.10.10.70 – The laptop of Vick Timmes (the victim) * 10.10.10.10 – A rogue web server (hosting the exploit) NetworkMiner identifies Vick's laptop as a Windows machine. Looking closer at the OS fingerprinting details that I can see That it's probably running Win2k or WinXP. OS fingerprinting was one of the first functionalities I built into NetworkMiner. The fingerprinting is basically done by extracting several characteristic details from the TCP and IP headers of the hosts. These values are then compared to values for known operating systems. NetworkMiner uses databases with such known values provided by the applications Ettercap, p0f and Satori. Nowadays NetworkMiner also analyzes DHCP details to identify the OS passively by using the DHCP database from Satori. By expanding the "Host Details" node I can see that the user-agent of Vick's web browser is: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1) The string "Windows NT 5.1" reveals that it is an XP machine. We can also see that Vick was unfortunately running IE6, which was vulnerable to the Hydraq exploit used in Operation Aurora. Next step is to select the "Files" tab in NetworkMiner. There seems to have been two file transfers performed with HTTP GET. The transferred files are index.php and index.phpmfKSxSANkeTeNrah.gif. All files shown in this tab have automatically been extracted to disk by NetworkMiner, so we can have a closer look at index.php by right-clicking on it and selecting "Open folder". By examining index.php I can see that it does indeed contain the Hydraq exploit, but with a different payload than what was used in Aurora. The obfuscation provided in puzzle#6 was also more of a nuisance (hard to read) rather than something that would actually foil an analyst or anti- virus software. The purpose of the GIF file in the attack was just a placeholder in memory for where to inject a pointer to the exploit, so I will not analyze that file any further. By selecting the "Sessions" tab in NetworkMiner I can see that there has been three TCP sessions. The HTTP session we just looked at as well as one to TCP port 4444 and one to 4445. NetworkMiner was not able to parse the application layer Protocol for these sessions, so I therefore turn to Wireshark for answers. Wireshark shows that the 4444 session begins with 0x006a0b00, which then is followed by what looks like an MZ header (i.e. a Windows PE executable). I therefore do "Follow TCP Stream", select the direction from server to client, click "Raw" and then "Save As" to store the binary TCP payload data to a file. Next step is to run the file carving tool Foremost to extract the executable from within the assembled TCP payloads. Foremost performs nicely and gives me the executable binary and names it "00000000.dll". I then do the same thing for the 4445 session, but with some slight quirks to make Wireshark ignore the first failed attempts at establishing the TCP connection. The result file for TCP port 4445 is identical to that of port 4444. When uploading the extracted binary to Virustotal I see that many AV vendors classify it as being a Trojan. __FINISHING_WORDS_______________________________________________ It would be interesting to put some time into reverse egineering the protocol used in the TCP sessions to port 4444 and 4445, so that they could be properly parsed instead of just doing file carving with Foremost. That was, however, not part of the task for this puzzle so I won't spend any extra time doing so. This puzzle was a nice and fun one to solve, and I'd like to applaud the excellent effort of recreating the Aurora attacks! I also appreciate the Network Forensics Puzzle Contests since they often provide me with ideas for new functionalities or other improvements that I can to build into NetworkMiner.