Forensics contest #5 Answer

Well 5/13/10 has come and gone now, so here are my answers for the latest contest. As noted later in my writeup, no new tools this time, just my writeup and approach to it.

Answer 1a: sdfg.jar
Answer 1b: q.jar
Answer 2: ADMINISTRATOR
Answer 3: http://nrtjo.eu/true.php
Answer 4: 5942BA36CF732097479C51986EEE91ED
Answer 5: UPX
Answer 6: 0F37839F48F7FC77E6D50E14657FB96E
Answer 7: 213.155.29.144

Description:
Up Front:
This is a writeup on how I did it, in a manual process, with no new tools, just an attempt to do the analysis in a controlled environment and not infect anything that I didn't want to.

Before doing any malware analysis there are a few things to know/understand.
1. Odds are whatever machine you are doing this on is going to get infected sooner or later.
2. While running in a VM env is a good way to test/work on these, there is the possiblity for the programs to determine they are in a VM and act differently because of it.

System Setup:
- XP VM
- Sandbox software - www.sandboxie.com
- Hashtab - beeblebrox.org
- NetworkMiner - networkminer.sourceforge.net
- wireshark
- exeinfope
- PEiD
- UPX - http://upx.sourceforge.net/
- NO AV software installed

Download and install all software, disconnect network, just in case.

Once Sandboxie is installed some quick initial tweaks for todays fun:
- Sandbox Settings > Recovery > Immediate Recovery > Uncheck 'Enable Immediate Recovery' May want to look at (I haven't played with these settings before):
Restrictions > Drop Rights > 'Drop rights from Administrators and Power Users group'

After installing all of the software above in my VM I snapshotted it so that I could role back to a known safe/uninfected machine as needed.

On to looking at the infected.pcap file:
First thing to do is launch NetworkMiner from within a Sandbox. Right click on the NetworkMiner.exe and say 'Run Sandboxed' (again we've already installed all software)

Lets first look at the different conversations/systems involved. We have 2 systems on the local network.
192.168.23.2 - appears to be the default gateway or proxy server for the network
192.168.23.129 - Windows XP ssystem with .Net 2.0, 3.0, 3.5 and Java 1.6.0.0_05 installed on it. And on a workgroup/domain called TICKLAB (need to check Satori and see why I didn't see this there?)

192.168.23.129 has 4 outgoing sessions:
59.53.91.102:80 [nrtjo.eu] - 6 sessions, downloading 7 files
65.55.195.250:443 - 1 session
212.252.32.20:80 [freeways.in] - 1 session, downloading 1 file
213.155.29.144:444 - 1 session

We can now safely look at the files that were extracted by NetworkMiner. Files Tab > Right click on first file > Open Folder. When you do this action from within a sandboxie env it will open up the file explorer also in that same sandboxed env. You can see this with the [#] Title [#] scenario in the title bar. While you can still infect yourself by running an infected exe this way, it will be, in theory at least, contained by the sandbox and go away when you close out and delete the sandbox.

The 7 files that were downloaded from 59.53.91.102 were: (filename as NetworkMiner saved it, may not be the name it was on the server)
true.php.html
xxx.xxx.txt
favicon.ico.html
sdfg.jar.x-java-archive
q.jar.x-java-archive
file.exe.octet-stream
file.exe[1].octet-stream

For proper analysis of what it is actually doing true.php should be run through a process to convert it to 100% readable text. It does a few different things trying to obscure what it is doing, I assume so as to try to evade different tests that a system may do to determine if it is malicious. 2 things you can see are the two jar files it does with document.write, sdfg.jar and q.jar. xxx.xxx will also need looked at because it calls .replace on the text in true.php (I think, need to dig more)

Anyway, we have an answer to #1 and #3 now, the two .jar files that got created and what file did it.

Conversation to 212.252.32.20 reveals a bit of interesting info. It requests the following:
/11111/gate.php?guid=ADMINISTRATOR!TICKLABS-LZ!1C7AE7C1&ver=10084&stat=ONLINE&ie=8.0.6001.18702&os=5.1.2600&ut=Admin&cpu=92&ccrc=5A4F4DF7&md5=5942ba36cf732097479c51986eee91ed

broken down we have:
guid=ADMINISTRATOR!TICKLABS-LZ!1C7AE7C1
Logged on user id, computer name, ? hash maybe ?

So now we have answer #2.

...

ie=8.0.6001.18702
version of IE on the infected system

os=5.1.2600
System OS which we already determined by passive means before, but good to see we have the same info here.

...

md5=5942ba36cf732097479c51986eee91ed
This is the MD5 of the packed file. Possibly a phone home feature to let it know what version is out there on each

system if ver above isn't that?

We can verify this is the MD5 on the file by right clicking on the file.exe.octet-stream and going to properties and then the File Hashes tab (this is what HashTab does)

Now we have answer #4.

Based on the MD5 and some of the other info it is doing, this appears to be a decent writeup on it:
http://www.threatexpert.com/report.aspx?md5=0f37839f48f7fc77e6d50e14657fb96e
http://autovin.pandasecurity.my/?p=4780
http://www.virustotal.com/analisis/9459b0d6f7cdec6860c458944386896f78cb60befdd04fbeab0df5b6661a3f81-1268644492
http://anubis.iseclab.org/?action=result&task_id=1c8c1f787d845a7941d93e37adce1be8b&format=txt

Ok, so now we need to determine how/if our .exe is packed.
Right click on exeinfope.exe and tell it to run sandboxed (needed, probably not, but...). Go to the directory where the file.exe.octet-stream file resides and open it.

Exeinfo PE ver 0.0.2.7 says it is:
UPX -> Markus & Laszlo ver. [ 3.04 ] <- info from file. ( sign like UPX packer )

Same idea, but with PEiD v0.95 (may be a newer version?)
UPX 0.89.6 - 1.02 / 1.05 - 2.90 -> Markus & Laszlo

So we now have answer #5

To get answer #6 we'll need to get UPX and run "upx -d" on the file and then compute the MD5 with HashTab again.

So just to be same, run a cmd.exe inside the sandbox also, go do the directory where the file is:
upx -d file.exe.octet-stream

This will expand the file out. Now go back to explorer, properties on file.exe.octet-stream, File Hashes and then new

MD5 is: 0F37839F48F7FC77E6D50E14657FB96E

Answer #6

For the last part, to know where it tries to go there are a few ways to look at this. We know it has to be one of the systems that our infected host tried to contact, we can look at the traffic there and try to determine it, we can dig around in the unpacked .exe and try to find the code (beyond my level) or we can purposely infect our VM and see what happens.

Based on other info we found on the MD5 we actually know from other peoples writeups where it was going and can verify that we also tried to go there in the packet capture. 213.155.29.144 port 444.

This malware appears to be SpyEye, a good writeup on it can be found here, which details some of what I had already figured out from the URL info:
http://blog.novirusthanks.org/2010/01/a-new-sophisticated-bot-named-spyeye-is-on-the-market/