Introduction

Firstly, malware analysis and reverse engineering has always been incredibly interesting to me and I noticed that ever since my OEP finding tutorial for UPACK, I’ve also gotten a lot of google searches for “how to reverse malware” and other such things, so, I figured I’d share my meager knowledge, seeing as how other blogs have been so helpful thus far, and they always say the best way to learn something is to teach it. I decided that it would be cool to start a series about analysis from start to finish, explaining how I analyze the file. Anyhow, enough of my rambling, on with the analysis!

Part 1: Unpacking the malware

Disclaimer: I’m using real malware, in a Windows VM. If you don’t know what you’re doing, you can get infected. I’m not responsible for that part

Tools for part 1:
– Malware – For this entire series I’m going to use a piece of malware I got from the Vulnerable Minds blog, specifically from this post. It’s called “microsoft110.exe”. You can also find the malware on offensivecomputing.net under md5 “426504b6cadf2331ef980858316349ed” if you have an account (it’s free).
– PEiD – For checking the type of packer used.
- Ollydbg 1.10 – For the unpacking part, I’m going to use Olly, just because it’s easier for this section of the analysis. You’ll also need the Ollydump plugin for ollydbg.
- ImpREC – For fixing imports, this is what you need.

Alrighty, microsoft110.exe uses a fairly standard packer, UPX, which is easily unpacked, both manually and automated. There are a fair number of tutorials about unpacking it already and some scripts to automatically unpack it for you, but I’m going to do it manually. You can tell that microsoft110.exe is packed with UPX by loading it up into PEiD:

Okay, now that the packer was verified, load it up into Olly, you should see the following starting instructions:

00424230 > $ 60 PUSHAD
00424231 . BE 00804100 MOV ESI,microsof.00418000
00424236 . 8DBE 0090FEFF LEA EDI,DWORD PTR DS:[ESI+FFFE9000]
0042423C . C787 00770100 >MOV DWORD PTR DS:[EDI+17700],4707FE20
00424246 . 57 PUSH EDI
00424247 . 83CD FF OR EBP,FFFFFFFF
0042424A . EB 0E JMP SHORT microsof.0042425A
... etc etc etc ...

The instruction highlighted in red (PUSHAD) is (most of the time) the indication that you can use this kind of unpacking to get an inflated executable. This instruction is used to save all the general registers onto the stack, so that UPX can do it’s decryption/decompression (I’m unfamiliar with UPX internals, so I can’t say which it is out of certainty). After unpacking, the registers are restored with the POPAD instruction and regular execution is started. So basically that’s where we need to stop and dump the process.

Anyway, back to the analysis, press F7 once to step into the PUSHAD instruction, note on the right you’ll see the registers change color, see the figure below:

We’re going to be following the stack pointer in memory, so right-click on the ESP value (00424231) and click on “Follow in dump”, the bottom window will display a hex dump of the memory at this address:

Note the values in ESP and the first value in the Address column match. Next we’re going to want to set a hardware breakpoint on the 4 bytes (08 02 91 7c) at the 0x0013ffa4 offset, so select the 4 bytes, right click and select breakpoint -> hardware, on access -> dword.

Now that a breakpoint was set, press F9 once to continue execution until we hit the breakpoint. When a breakpoint is hit, scroll up a little and you should see something like this:

0042437E .^EB E1 JMP SHORT microsof.00424361
00424380 > FF96 B0410200 CALL DWORD PTR DS:[ESI+241B0]
00424386 > 61 POPAD
00424387 .-E9 BC1AFFFF JMP microsof.00415E48
0042438C A4434200 DD microsof.004243A4
00424390 AC434200 DD microsof.004243AC
00424394 00874100 DD microsof.00418700

The blue line above is where the breakpoint stopped us, as you can see after scrolling up, a POPAD instruction (in green) was used immediately prior to the JMP instruction. In this simple example, all that’s required is to press F7 once to step into the JMP command, and you should have reached your OEP.

Now that the OEP was reached, use the ollydump plugin to dump the process in memory to a file, you can see the new OEP in this window, make sure that you uncheck the “Rebuild Import” option before dumping:

Take note of the modified OEP, which in this case is 0x15e48 (for later). Now that you have a dumped file, the imports have to be fixed, so fire up ImpREC and attach to the process for microsoft110.exe

In the box labeled OEP, put your new OEP (00015e48) and click on IAT AutoSearch, hopefully you will see this:

Which means the import address table was found. Now you can click on “Get Imports” and then “Fix Dump”, select the executable you dumped with ollydmp and ImportREC will fix the dump. Analysis may now begin.

This post is getting overly long, so I’ll stop here and pick it up with the next post. Be on the lookout for part 2 coming soon.

Well, regardless of whether this helped someone else or not, I’m much more likely to remember the process the next time I unpack some malware since I wrote/typed it down. Currently I’d say I’ve gotten about a third of the analysis done on the actual malware itself using IDA, so it’s slow going but picking up the pace. If you have any corrections or suggestions, *please* let me know, I’m not an expert in this subject, and I appreciate any feedback I get.

For example, let’s say you discover a new binary malware that one of your honeypots caught, here’s how I envision this would work out:

1. You register an account at the collaboration website, you can additionally assign your pgp key to your name, security people like to know who they’re actually talking with.
2. You upload the file, in this case it’s a .exe file, tagging it with a basic description (“nepenthes honeypot caught this transferred over ftp, I think it’s a trojan, etc, etc”) and tags so it becomes searchable (exe, malware, binary, ftp).
3. The file/pcap is anonymized (optional, but would be extremely nice)
4. After the initial upload, the collaboration server performs super-basic, but good baseline analysis on the file, saving the results for later. For a .exe file, it could be things like md5sum, clamscan and strings. For other types of files, different tools could be used (*cough* an automated NSM-Console session *cough*), etc
5. The malware is displayed on the page, security gurus log into their account, have the ability to download the binary to play with it themselves, and are encouraged to share what they found when doing their analysis (and how). They have the ability to upload screenshots, short video clips, textfiles, whatever would help with the analysis. This of it like a traditional website ‘shoutbox’, but with comments on a particular piece of malware or network capture.
6. Users can also create correlations between different submissions, Example: “This is the link to the network capture for the worm exploiting this particular binary malware”, now we can draw pretty graphs!
7. Discussion continues until the file has been “figure out”. Give people ‘karma’ or whatever to encourage posting.
8. ????
9. Profit!

In all seriousness, you know what I think would be great about this? The community as a whole benefits from the knowledge and talent of people who are good at an individual skill. For instance, I might suck at binary malware analysis, but I can help decode what’s going on with a network trace picked up by an IDS. Community is created, knowledge is shared, security can be improved, people become familiar with the parts of security in which they lack knowledge, everyone is happy.

Make the framework distributable, small groups of people can set up their own collaboration for working with extremely confidential files, think Trac, but instead of bug reports and svn tracking, malware/pcap collaboration and research.

There are projects already like this, I’m excited for the direction that OpenPacket is going with packet captures, upload a file and it’s automatically run through tshark, giving you a baseline to start working with. I think that if the idea is expanded, we can get a lot of different people involved. I know I’d certainly like to get better at doing binary analysis.

Does this sound interesting? It certainly does to me. I’m curious if anyone else is interested, leave me a comment and let me know if you’d be interested in something like this! (Maybe if 40 hours suddenly appear out of nowhere I’m start working on it…)

P.S. I didn’t think of all of this myself, thanks to all the people in #rawpacket for their ideas Just want to give credit where it’s due…

In the article they discuss DNS servers that can potentially serve bad information from requests, what the article *sounds like* is that this is an attack on legitimate DNS servers in order to get them to serve bad data (which would be far more serious). In actuality, the attack is using malware to change a user’s DNS settings to point to an evil DNS server, which in turn serves evil entries to the machine when a user tries to access a site like chase.com for banking.

Essentially, it’s a very advanced form of phising that uses malware to set correct settings. This is NOT the DNS poisoning attack the article vaguely describes, which would be if hackers were to able to get trusted DNS servers to send false data. It’s sad that a trusted source like Ars published the article under such a misleading title. More readership I suppose? (or honest mistake, personally I don’t think Ars would do it intentionally).

On another note, would you click on a gmail webclip that looked like this??

I’m guessing that the site isn’t malicious, just in a different language and thus displayed in “???” instead of whatever the original language was. Still, I’m curious why gmail thought I would be able to read something since 99.9% of all my email is in English. I’m also curious what a lay user would think of a webclip like that.

I apologize for the lack of consistent posting lately, I’ve been hard at work on the nsm-console for inclusion in the upcoming Hex 1.0.2 release. More posts to come!