docs Win32_malware_analysis.html,NONE,1.1
Kurt Huwig <[email protected]> Thu, 17 Jun 2004 11:49:04 +0000
| Newsgroups | gmane.comp.security.virus.openantivirus.cvs |
|---|---|
| Message-ID | <[email protected]> |
Update of /cvsroot/openantivirus/docs In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv21514 Added Files: Win32_malware_analysis.html Log Message: First version --- NEW FILE: Win32_malware_analysis.html --- <!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> <html> <head> <meta content="text/html; charset=ISO-8859-1" http-equiv="content-type"> <title>Win32 malware analysis</title> </head> <body> <h1>Win32 malware analysis</h1> <br> by Andre Post<br> High-low Research<br> June 10, 2004<br> <br> <h2>1 Introduction</h2> Nowadays, the Internet is infested with malware<a href="#1"><sup>[1]</sup></a> with periodic worldwide outbreaks of mass-mailing worms. Apparently, there are more than enough people who still do not take enough care of their computers as they should, in turn providing an infection base to today's malware. Fortunately, the security aware community is doing it's share to combat malware and to prevent further spreading. This document is for those people that would want to get into analysing win32<a href="#3"><sup>[2]</sup></a> malware. Particularly with the goal to develop signatures that could be fed to malware scanning software. In chapter 2, a general overview is given of how to setup a test system which is used as a laboratory machine. This explaines the types of software tools needed, and how they work in conjunction with each other. Chapter 3 is a tutorial which applies the techniques given in chapter 2. In this tutorial, the worm Netsky.Q is analyzed up to the point where we have a (somewhat) good fingerprint to use for specific detection.<br> <h2>2 Malware analysis in general</h2> How do we start analyzing a malware threat? Do we just double-click that weird looking attachment? Hmm...no thank you, it requires a slightly more careful approach. The nature of malware is that it wants to spread to other machines, so a good isolated setup of a lab machine is no luxury, it's mandatory. We don't want to accidentally have some malware spread out from our computers onto the Internet.<br> <br> So the first thing off is to pick a piece of hardware that is dedicated to just this one purpose: Malware analysis. Next, install the worlds most favorite operating system on it. Any 32-bit Win variant will do just fine, but make sure not to make too big a partition. Otherwise, making and restoring backups will be a pain. Now that we have the basic needs met, it's time to throw some applications in that assist us in actually analyzing the malware.<br> <br> There are a lot of applications out there that can help us out one way or another, so we'll have to answer a few questions first. If we plan on just creating a fingerprint signature for malware detection purposes, it suffices to have a disassembler and a debugger. There are many around so take your pick...some offer more options than others, but any seriously developed disassembler and debugger will do. On the other hand, if we would want to know all the little details of what the malware does exactly, it may save some time to have a good process viewer (not the one that is included in the OS), a tool to keep live track of the registry, and a tool to keep live track of file system changes.<br> <br> There it is: Dedicated hardware, a clean basic operating system, and some tools to do the job. This is the basis for any analysis run, so it is highly advisable at this point to use a backup mechanism that can be used to quickly restore the system to this virgin state after each session. If the partition on the harddisk is chosen small enough, we may even get away with using a simple CD-R(W) on which the compressed image file fits. If the image is too big to fit on CD, we may consider using a swappable harddisk or make the lab machine dual boot with a *NIX-like operating system that can be used to locally store an image of the Windows partition. If the latter is chosen, please be careful that some malware affects the boot sector, or even modifies random locations on the hard drive. In any case, always do a sector by sector backup/restore as that method does not allow for any left-overs from previous sessions.<br> <br> Action. Always open the malware file in the disassembler to get a quick scan of what we're actually dealing with here. Taking a quick look at the strings in the file usually gives a quick reference what kind of file we're actually dealing with. Within a few minutes it should be clear if the malware threat is for example wrapped in a runtime-compressor, is binary compiled Visual Basic, or just plain binary compiled from C++, Delphi or whatever language was used. That information provides us what course of action to take to get to the juicy portions of the worm. From here on it's a matter of practice, and just doing it over and over again to get a feel for it. The number of possible variations is virtually endless, but a common situation is detailed in the next chapter.<br> <h2>3 A tutorial on Netsky.Q</h2> Now that we have a rough understanding of how to analyze malware, it is time for us to get hands-on with one of todays most active worms: Netsky. In this tutorial we'll take a look at the 'Q' variant in particular, for no particular reason. It just happened to be the one that was picked randomly from a list of infected emails. So get your sample at hand. We've gone through the previous chapter, we've set up a laboratory system that's disconnected from any network at all, we've made our basic system with all the analysis tools, we've got the (tested) backups at hand ready to nuke the system and reinstall a clean machine...ready to rock...<br> <br> Boot your system. Put the malware sample in it's own directory. And run a strings extraction tool. Such a tool prints out all the strings that are in the file wich are vaguely readable for human interpretation. The juicy strings in the Netsky.Q binaries are:<br> <div style="margin-left: 40px;">Compressed by Petite (c)1999 Ian Luck.<br> @.petite<br> </div> These are just about the only real good strings (aside from the imports). And we don't really need any more strings at this point. These strings tell us that this binary is runtime compressed with Petite. This means that the real program is stored in the file in compressed/encrypted form that makes it unreadable and impossible to create an efficient and effective fingerprint signature. What do we do now?<br> <br> How do we handle compressed or encrypted malware? Simple...first open it up in our favorite disassembler and get to the Entry Point<a href="#3"><sup>[3]</sup></a>. Just scan over the assembly code to get a first impression of the routine blocks and where the loops are. The main decryption loops are located at virtual addresses (VA) 0x0040A138, 0x0040A15B and 0x0040A1A8. At this point we can open the malware executable in our favorite debugger. Set breakpoints at these VAs and look at what happens in the memory locations which are modified in those loops. During the debug run where EDI is in the range 0x004020DE- 0x00402201, we can see the imports being decrypted beautifully that are used by the real worm's code. Shortly after that, the string "This file has been tampered with and MAY BE INFECTED BY A VIRUS!" wonderfully appears at VA 0x00402224. During all of the decrypting, we can see EBX counting down the number of bytes to decrypt. The Petite decompression mechanism runs through the whole loop several times where each region of memory is accounted for with EBX counting down to 0 for each region to decompress. The last decryption loop decompresses some juicy strings: "firewalllogger.txt" followed by "BIN" and "notepad temp.eml" and "SysMonXP.exe" and finally "\". During the decryption loop of these strings take careful note of the range of ESI, since this points to the memory location that contains the raw encrypted form as it is in the file. After the decryption of these strings, the decryption is all done and the decryption engine performs an operation that makes the operating system reprocess the file but then in it's decompressed form at memory location 0x00400000. Take a look there, we can see the MZ-header there as if it was a brand new file loaded up in memory.<br> <br> Now that we have some nice signature location, how do we make the optimum balance between creating a signature that:<br> <ul> <li>Catches all instances of this particular worm</li> <li>Does not raise false positives on clean files</li> <li>Is still small (and fast) enough to ensure performance</li> </ul> The answers are quite obvious:<br> <ul> <li>Take a good portion of the encrypted file data of the strings.</li> <li>Add a small piece of the Petite code right after the Entry Point.</li> </ul> The small piece of Petite right after the Entry Point could be:<br> <div style="margin-left: 40px;">B800A04000681122400064FF3500000000<br> </div> This contains some pretty common code, but the 11224000 corresponds to 0x00402211 which is pretty uncommon at this location. So it would actually be better to take a piece of the decryption loop mentioned earlier on in this chapter.<br> <br> The good portion of the encrypted file data of the strings could be: 2B6B006169264B4B57475118417B3EA8766A37C34C7A15084269037C436262 535A3D207F63<br> This covers a good part (not all) of the juicy strings that represent the file names of the dropped files by the worm. Further analysis could be done to see which part of the decrypted code actually contains the malicious code that makes Netsky.Q email itself out. And take a signature based on that action rather than based on juicy strings. Do note that creating signatures based on strings is not a bad thing at all. Do not feel guilty ìjustî sigging on strings...the sigs shown above are good and fast enough to stop Netsky.Q dead in it's tracks.<br> <br> Happy hunting...<br> <hr style="width: 100%; height: 2px;"><a name="1"></a>[1] An abbreviation for malicious software , such as viruses, worms, and Trojan Horses.<br> <a name="2"></a>[2] Windows 32-bit binary executable format, also known as Portable Executable file format.<br> <a name="3"></a>[3] The virtual address where the program starts running once it's loaded in memory.<br> <small><small><br> $Id: Win32_malware_analysis.html,v 1.1 2004/06/17 11:49:02 kurti Exp $</small></small><br> </body> </html> ------------------------------------------------------- This SF.Net email is sponsored by The 2004 JavaOne(SM) Conference Learn from the experts at JavaOne(SM), Sun's Worldwide Java Developer Conference, June 28 - July 1 at the Moscone Center in San Francisco, CA REGISTER AND SAVE! http://java.sun.com/javaone/sf Priority Code NWMGYKND