Saturday, May 22, 2010

Forensics Contest #6 Ann's Aurora

Hi! Recently we were challenged by SANS Fellow Rob Lee (author of “Computer Forensics” 508) to create a puzzle based on an Advanced Persistent Threat (APT). We thought this was a great idea! So this month we are doing a special release through the SANS Institute based on APT. SANS is sponsoring some especially cool prizes– check out the full puzzle and writeup here:

The contest is a client-side attack based on Operation Aurora. This packet capture contains a full recording of a real Windows system getting exploited via the same mechanism that was used to exploit Google. Ann spear-phishes a developer, who clicks on a link and connects to her malicious web server. Then she configures the victim to make outbound persistent connection attempts to her server so that she can retain access and reconnect in the future.


A bit different than the first 4, uses ideas you may have come up with in #5, but has some new twists to be sure! One other twist is you have to have a SANS portal account to grab the evidence file. Not sure what is required to get an account, I already have one since I hold a few certs from there already.

On top of that they are pushing the upcoming Forensics Summit in DC, more info can be found here:

Looking over the agenda here is some interesting info:

On Thursday July 8th (end of the first day)
6:30pm - 7:30pm
SANS Forensic Challenge Winners Presentation
Winners of the 2010 Forensic Challenge "Ann's Aurora" to be announced and presented with their awards via this live and internet broadcasted event!
Prizes: 2 netbook and free passes to the 2011 Forensics/IR Summit

Or directly from the writeup:

2 Lenovo Ideapad SNIFT Configured Netbooks for first and second place teams.

In addition, each team that places in the top three will be awarded free passes to the 2011 Incident Response and Forensic Summit (One pass per entry)

You have a little over a month, good luck! (deadline 6/27/2010)

Wednesday, May 19, 2010

Detecting x86 buffer overflow shellcode attacks at the network level

Interesting article. A bit outside of my comfort level/understanding on things since I don't play much with memory, but interesting none the less. Not sure how accurate the article is, but for your reading enjoyment.

Maybe it will all make more sense ones I go back through Chapter 2 in "The Rootkit Arsenal" book that I'm currently reading. Chapter 2 was all about jumping around in memory and it seems to be a very well written book so far, but more on that some other time.

Tuesday, May 18, 2010

What does your browser tell about you

This has been talked about in a few places the past 2 days, but it is a good topic for excess info and what it tells about you. I'm pretty sure someone did something on this before, but maybe not.

Anyway, some good research to look at about how unique your browser really is and how it can be used to track back to you. This is due to plugins, cookies and other things.

A good way to block it are:
TorButton, NoScript or other Java Script blocking tools, or a bunch of corporate cloned machines! I'm sure there were other things, that is what I recall from my quick read the other day.

The main paper can be found here.

Friday, May 14, 2010

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 3:
Answer 4: 5942BA36CF732097479C51986EEE91ED
Answer 5: UPX
Answer 6: 0F37839F48F7FC77E6D50E14657FB96E
Answer 7:

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:
- Sandbox software -
- Hashtab -
- NetworkMiner -
- wireshark
- exeinfope
- PEiD
- UPX -
- 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. - appears to be the default gateway or proxy server for the network - Windows XP ssystem with .Net 2.0, 3.0, 3.5 and Java installed on it. And on a workgroup/domain called TICKLAB (need to check Satori and see why I didn't see this there?) has 4 outgoing sessions: [] - 6 sessions, downloading 7 files - 1 session [] - 1 session, downloading 1 file - 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 were: (filename as NetworkMiner saved it, may not be the name it was on the server)

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. 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 reveals a bit of interesting info. It requests the following:

broken down we have:
Logged on user id, computer name, ? hash maybe ?

So now we have answer #2.


version of IE on the infected system

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


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:

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 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. 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:

Wednesday, May 12, 2010

Twitter and clear text passwords when changing settings

There are a few links around and I actually Tweeted about this last week, but figured I'd put it here since it is a bit more permanent.

If you change any settings in Twitter it pushes that password in the clear text. Initial login is secure, but changes to settings afterward reprompt for password, and this one is sent in the clear. Something to be aware of! (Also sounds like password changes once logged on may be sent in the clear also, I didn't verify this one)

I found out about it from the NetworkMiner list and verified the issue myself. I sent something onto twitter through their help page, but haven't heard anything on it nor do I know if they've updated it, but here was the original thread and another video demo:!

Monday, May 10, 2010

Fingerprint Editor updated

There have been a few updates to this and other products on his page that I haven't mentioned. Anyway, thanks for the recent updates/fixes. If you are utilizing any of the .xml files I provide I highly recommend using this to edit them!

Also, I've updated 3 or 4 of the main .xml files multiple times in the past week after not having updated them in quite some time. So make sure you check for new updates of the .xml files. There may be some new ones that haven't made it into the latest Fingerprint Editor program.