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.