Reverse Engineering Malware (Part 5)

If you would like to read the other parts in this article series please go to:

In part four of the article series on reverse engineering we covered how to recognize and then unpack a UPX packed file. In this last part we will actually look at the malware sample in its uncompressed format.

Reverse engineering and you, Part V

Over the course of this last part on reverse engineering we will take a look at the now unpacked piece of malware. It is at this juncture that a point or two need be mentioned about reverse engineering. There are various goals for performing reverse engineering and also various methodologies. Put simply, in our case we are doing rev eng for the purposes of analyzing malware. What we want to extract from this analysis is a better understanding of what the malware itself does, and perhaps to some extent, how it does it. One should still use both static and dynamic rev eng principles as described earlier in the series.

Performing rev eng for exploit development for example, is a far different beast. For one you are doing the analysis on an existing program such as say Windows XP or some other FTP server program for instance. What you are looking for is also quite different. You will be looking for any instances of possible buffer overflows, format string issues and other such related poor coding vulnerabilities. With this type of endeavor you are actually going through subroutines operand by operand. This kind of work is hard, tedious, and time consuming. Also, it requires a rather sound understanding of programming. Much like malware rev eng you also apply the static and dynamic approaches to rev eng for exploit development.

So as we can see, there are various reasons as to why you might want to perform reverse engineering, and there are also differing goals. Your choice of tools is pretty much the standard toolkit consisting of a debugger, disassembler, and hex editor amongst others. With that said let us move on to the actual analysis of the unpacked malware. As you will soon see, it is a rather quick affair as the information we wish to extract is done relatively easily.

Onwards and upwards

You may recall earlier in the series that I suggested you install the MAP (Malcode Analyst Pack) from IDefense. What we shall now do as a first step in our analysis of the malware is run the strings command from the MAP tool against the unpacked malware. All you need to do is right click on the malware and you should see the “Strings” option show up in the dialog box. From there, all you need to do is click it. Once the program is done another window will pop up with the results. Please see below for the output that should shown.

Figure 1

Well we can see in the screenshot above that the first few entries pertain to the MZ header itself and some of the various sections within it ie: .text, .data, and idata to name a few. Also listed is another MD5 hash of the file and its size. Now I scrolled down in my string output and started to see actual text strings of interest that were pulled out of the binary itself.

Figure 2

One of the entries there that grabs my attention is the “shlwapi.dll” one. This dll file does not ring any bells with me offhand so I go off to Microsoft Technet to do a search on it there. From the hits I see come up I am not overwhelmed with confidence that this piece of malware has our best intentions at heart. There is a long list of vulnerabilities associated with this dll and that strengthens the case for this malware being just that, malware.

Figure 3

After having looked at this I continue to scroll down the list of ascii strings pulled out of the malware binary. The majority of them consist the normal writing, opening, and other fiddling with registry keys. Also, there is the long list of other ascii strings that seem to allude to the fact that this piece of malware, once executed, will present the user with some type of window. I come to this assumption by the “CreateWindowExA” string as seen in the screenshot below.

Figure 4

Well the spelling of that ascii string seems fairly straightforward, but let’s take a look via Google to see if we can come up with a better explanation of just what it does. That is just what I do, as seen in the screenshot below. My suspicions are seemingly confirmed in that a window will likely be presented to the user once the malware is executed.

Figure 5

The rest of the strings output contains a large array of other interesting ascii words that would need to be quickly run to ground in order to get a better understanding of what the malware will do once invoked. This type of activity that we have done falls squarely in the static phase of reverse engineering. As you can see, there is a fair amount of information that can be gleaned from the malware binary.

From static to dynamic

Anyhow, I don’t know about you but I would like to make things a bit more exciting and get to the meat of the matter. So on that note let’s get rolling on to the dynamic portion of our analysis. You will need to have installed and running both regmon and filemon. Once installed and running make sure that you have excluded all running stuff found in both applications. This way you will be able to capture all activity that happens once we invoke the malware. On that note let’s fire up our little malware specimen. This I do by simply renaming the malware with a .exe extension, and I invoke it via a DOS prompt. Once I have done that, wouldn’t you know it, a pop-up window is presented to me. You really do have to love strings and what it can pull out of a binary.

Figure 6

So as we thought when we saw the CreateWindowExA ascii string, and then Googled it we came up with its purpose. This was part of the code used to create the popup window we see above us. Now how about what happened in regmon and filemon after I invoked the malware binary? Well let’s take a look at the two screenshots below.

Figure 7

Figure 8

Well much as we imagined the malware definitely made a whole bunch of changes to registry keys, wrote to some files and did the usual stuff we associate with malware. To properly analyze the output noted by both regmon and filemon would take time. This would be followed by actually checking to see if anything was inserted onto the hard drive itself. This type of activity is rather commonplace when dealing with malware as often they try to further trojan your computer to maintain access to it. That, or have you download spyware, or other type malware from a website or ftp server. Nothing new there really, as it has been well chronicled on many computer security sites.

Wrap Up

Well as promised the action in the last part was fast and furious. You can see now that doing reverse engineering for malware purposes is not necessarily an overly complex endeavor. It can be however if custom packers are involved, or other type of malware obfuscation is involved. All you really need to do is put your nose to the grindstone and access the many, many, sites on the Internet that deal with malware, and how to analyze it. On that note I sincerely hope this article series was of use to you, and as always welcome your feedback. Till next time!

If you would like to read the other parts in this article series please go to:

About The Author

Leave a Comment

Your email address will not be published. Required fields are marked *

This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.

Scroll to Top