CHAPTER 2 BASIC ANALYSIS.pdf
- 1. Chapter 2 Basic Analysis Prepared by, Dr. A. Manju, M.E., Ph.D, Assistant Professor, SRM Institute of Science & Technology, Ramapuram Campus Michael Sikorski, Practical Malware Analysis – The Hands-On Guide to Dissecting Malicious Software, Kindle Edition, No Starch Press; 1 edition (1 February 2012), ISBN: 1593272901
- 2. Outline Antivirus Scanning Hashing: Fingerprint for Malware Finding Strings Packing Files Detecting Packers with PEiD Portable Executable File Format Static, Runtime and Dynamic Linking Imported and Exported Functions
- 3. Antivirus Scanning When first analyzing prospective malware, a good first step is to run it through multiple antivirus programs, which may already have identified it. But antivirus tools are certainly not perfect. They rely mainly on a database of identifiable pieces of known suspicious code ( file signatures), as well as behavioral and pattern-matching analysis (heuristics) to identify suspect files. One problem is that malware writers can easily modify their code, thereby changing their program’s signature and evading virus scanners. Also, rare malware often goes undetected by antivirus software because it’s simply not in the database. Finally, heuristics, while often successful in identifying unknown malicious code, can be bypassed by new and unique malware. Because the various antivirus programs use different signatures and heuristics, it’s useful to run several different antivirus programs against the same piece of suspected malware.
- 4. Hashing: Fingerprint for Malware • Hashing is a common method used to uniquely identify malware. • The malicious software is run through a hashing program that produces a unique hash that identifies that malware (a sort of fingerprint). • The Message-Digest Algorithm 5 (MD5) hash function is the one most commonly used for malware analysis, though the Secure Hash Algorithm 1 (SHA-1) is also popular. • For example, using the freely available md5deep program to calculate the hash of the Solitaire program that comes with Windows would generate the following output: C:>md5deep c:WINDOWSsystem32sol.exe 373e7a863a1a345c60edb9e20ec3231 c:WINDOWSsystem32sol.exe The hash is 373e7a863a1a345c60edb9e20ec3231.
- 5. Hashing: Fingerprint for Malware • The GUI-based WinMD5 calculator, shown in below figure, can calculate and display hashes for several files at a time. Once you have a unique hash for a piece of malware, you can use it as follows: Use the hash as a label. Share that hash with other analysts to help them to identify malware. Search for that hash online to see if the file has already been identified.
- 6. Finding Strings A string in a program is a sequence of characters such as “the.” A program contains strings if it prints a message, connects to a URL, or copies a file to a specific location. Searching through the strings can be a simple way to get hints about the functionality of a program. For example, if the program accesses a URL, then you will see the URL accessed stored as a string in the program. You can use the Strings program (http://bit.ly/ic4plL), to search an executable for strings, which are typically stored in either ASCII or Unicode format.
- 7. Finding Strings Both ASCII and Unicode formats store characters in sequences that end with a NULL terminator to indicate that the string is complete. ASCII strings use 1 byte per character, and Unicode uses 2 bytes per character. Figure shows the string BAD stored as ASCII. The ASCII string is stored as the bytes 0x42, 0x41, 0x44, and 0x00, where 0x42 is the ASCII representation of a capital letter B, 0x41 represents the letter A, and so on. The 0x00 at the end is the NULL terminator.
- 8. Finding Strings The Unicode string is stored as the bytes 0x42, 0x00, 0x41, and so on. A capital B is represented by the bytes 0x42 and 0x00, and the NULL terminator is two 0x00 bytes in a row. When Strings searches an executable for ASCII and Unicode strings, it ignores context and formatting, so that it can analyze any file type and detect strings across an entire file. Strings searches for a three-letter or greater sequence of ASCII and Unicode characters, followed by a string termination character.
- 9. Packing Files When the packed program is run, a small wrapper program also runs to decompress the packed file and then run the unpacked file, as shown in below figure. When a packed program is analyzed statically, only the small wrapper program can be dissected. Fig: The file on the left is the original executable, with all strings, imports, and other information visible. On the right is a packed executable. All of the packed file’s strings, imports, and other information are compressed and invisible to most static analysis tools.
- 10. Detecting Packers with PEiD ➢ One way to detect packed files is with the PEiD program. You can use PEiD to detect the type of packer or compiler employed to build an application, which makes analyzing the packed file much easier. Below figure shows information about the orig_af2.ex_ file as reported by PEiD. ➢ As you can see, PEiD has identified the file as being packed with UPX version 0.89.6-1.02 or 1.05-2.90. ➢ When a program is packed, you must unpack it in order to be able to perform any analysis. For example, to unpack malware packed with UPX, you would simply download UPX (http:// upx.sourceforge.net/) and run it like so, using the packed program as input: upx -d PackedProgram.exe
- 12. Portable Executable File Format The format of a file can reveal a lot about the program’s functionality. The Portable Executable (PE) file format is used by Windows executables, object code, and DLLs. The PE file format is a data structure that contains the information necessary for the Windows OS loader to manage the wrapped executable code. Nearly every file with executable code that is loaded by Windows is in the PE file format, though some legacy file formats do appear on rare occasion in malware. PE files begin with a header that includes information about the code, the type of application, required library functions, and space requirements. The information in the PE header is of great value to the malware analyst.
- 13. Static, Runtime and Dynamic Linking • Static linking is the least commonly used method of linking libraries, although it is common in UNIX and Linux programs. • When a library is statically linked to an executable, all code from that library is copied into the executable, which makes the executable grow in size. • When analyzing code, it’s difficult to differentiate between statically linked code and the executable’s own code, because nothing in the PE file header indicates that the file contains linked code.
- 14. Static, Runtime and Dynamic Linking • Runtime linking is commonly used in malware, especially when it’s packed or obfuscated. • Executables that use runtime linking connect to libraries only when that function is needed, not at program start, as with dynamically linked programs. • Several Microsoft Windows functions allow programmers to import linked functions not listed in a program’s file header. LoadLibrary GetProcAddress LdrGetProcAddress LdrLoadDll
- 15. Static, Runtime and Dynamic Linking • Dynamic linking is the most common and the most interesting for malware analysts. • When libraries are dynamically linked, the host OS searches for the necessary libraries when the program is loaded. • When the program calls the linked library function, that function executes within the library.
- 16. Exploring Dynamically Linked Functions with Dependency Walker
- 17. Exploring Dynamically Linked Functions with Dependency Walker • The Dependency Walker program, distributed with some versions of Microsoft Visual Studio and other Microsoft development packages, lists only dynamically linked functions in an executable. • (1) Dependency Walker’s analysis of SERVICES.EX_ • (2) The far left pane, shows the program as well as the DLLs being imported, namely KERNEL32.DLL and WS2_32.DLL. • (3) Clicking KERNEL32.DLL shows its imported functions in the upper-right pane. We see several functions, but the most interesting is CreateProcessA, which tells us that the program will probably create another process, and suggests that when running the program, we should watch for the launch of additional programs.
- 18. Exploring Dynamically Linked Functions with Dependency Walker • (4) The middle right pane, lists all functions in KERNEL32.DLL that can be imported— information that is not particularly useful to us. • Notice the column in panes (3) and (4) labeled Ordinal. Executables can import functions by ordinal instead of name. When importing a function by ordinal, the name of the function never appears in the original executable, and it can be harder for an analyst to figure out which function is being used. When malware imports a function by ordinal, you can find out which function is being imported by looking up the ordinal value in the pane at (4). • The bottom two panes ((5) and (6)) list additional information about the versions of DLLs that would be loaded if you ran the program and any reported errors, respectively. • A program’s DLLs can tell you a lot about its functionality. For example, below table lists common DLLs and what they tell you about an application.
- 19. Exploring Dynamically Linked Functions with Dependency Walker
- 20. Imported Functions and Exported Functions • Imported Functions • The PE file header also includes information about specific functions used by an executable. The names of these Windows functions can give you a good idea about what the executable does. Microsoft does an excellent job of documenting the Windows API through the Microsoft Developer Network (MSDN) library.
- 21. Imported Functions and Exported Functions • Exported Functions Like imports, DLLs and EXEs export functions to interact with other programs and code. Typically, a DLL implements one or more functions and exports them for use by an executable that can then import and use them. The PE file contains information about which functions a file exports. Because DLLs are specifically implemented to provide functionality used by EXEs, exported functions are most common in DLLs. EXEs are not designed to provide functionality for other EXEs, and exported functions are rare. If you discover exports in an executable, they often will provide useful information.
- 23. PotentialKeylogger.exe: An unpacked Executable • Like most average-sized programs, this executable contains a large number of imported functions. Unfortunately, only a small minority of those functions are particularly interesting for malware analysis. • As a new analyst, you will spend time looking up many functions that aren’t very interesting, but you’ll quickly start to learn which functions could be important and which ones are not. For the purposes of this example, we will show you a large number of imports that are uninteresting, so you can become familiar with looking at a lot of data and focusing on some key nuggets of information. • The imports from Kernel32.dll in above table tell us that this software can open and manipulate processes (such as OpenProcess, GetCurrentProcess, and GetProcessHeap) and files (such as ReadFile, CreateFile, and WriteFile). • The functions FindFirstFile and FindNextFile are particularly interesting ones that we can use to search through directories.
- 24. PotentialKeylogger.exe: An unpacked Executable • User32.dll - RegisterClassEx, SetWindowText, and ShowWindow • The function SetWindowsHookEx is commonly used in spyware and is the most popular way that keyloggers receive keyboard inputs. • The function RegisterHotKey is also interesting. It registers a hotkey (such as CTRL- SHIFT-P) so that whenever the user presses that hotkey combination, the application is notified. • The imports from GDI32.dll are graphics-related and simply confirm that the program probably has a GUI. The imports from Shell32.dll tell us that this program can launch other programs—a feature common to both malware and legitimate programs. • The imports from Advapi32.dll tell us that this program uses the registry, that controls which programs are automatically run when Windows starts up.
- 25. PotentialKeylogger.exe: An unpacked Executable • This executable also has several exports: • LowLevelKeyboardProc and LowLevelMouseProc. - “The LowLevelKeyboardProc hook procedure is an application-defined or library-defined callback function used with the SetWindowsHookEx function.”
- 26. PotentialKeylogger.exe: An unpacked Executable • Using the information gleaned from a static analysis of these imports and exports, we can draw some significant conclusions or formulate some hypotheses about this malware. • For one, it seems likely that this is a local keylogger that uses SetWindowsHookEx to record keystrokes. • We can also surmise that it has a GUI that is displayed only to a specific user, and that the hotkey registered with RegisterHotKey specifies the hotkey that the malicious user enters to see the keylogger GUI and access recorded keystrokes. • We can further speculate from the registry function and the existence of Software MicrosoftWindowsCurrentVersionRun that this program sets itself to load at system startup.
- 27. Examining PE files with PEview
- 28. Examining PE files with PEview • The PE file format stores interesting information within its header. We can use the PEview tool to browse through the information. • (1) the left pane, displays the main parts of a PE header. The IMAGE_FILE_HEADER entry is highlighted because it is currently selected. • The first two parts of the PE header—the IMAGE_DOS_HEADER and MS-DOS Stub Program—are historical and offer no information of particular interest to us. • The next section of the PE header, IMAGE_NT_HEADERS, shows the NT headers. The signature is always the same and can be ignored. • (2) The IMAGE_FILE_HEADER entry, highlighted and displayed in the right panel, contains basic information about the file. • The Time Date Stamp description at (3) tells us when this executable was compiled, which can be very useful in malware analysis and incident response. is an older attack, and antivirus programs might contain signatures for the malware.
- 29. Examining PE files with PEview The IMAGE_OPTIONAL_HEADER section includes several important pieces of information. The Subsystem description indicates whether this is a console or GUI program. Console programs have the value IMAGE_SUBSYSTEM_WINDOWS_CUI and run inside a command window. GUI programs have the value IMAGE_ SUBSYSTEM_WINDOWS_GUI and run within the Windows system. The most interesting information comes from the section headers, which are in IMAGE_SECTION_HEADER. These headers are used to describe each section of a PE file.
- 30. Examining PE files with PEview
- 31. Examining PE files with PEview Virtual Size at (1) tells us how much space is allocated for a section during the loading process. The Size of Raw Data at (2) shows how big the section is on disk. These two values should usually be equal, because data should take up just as much space on the disk as it does in memory. Small differences are normal, and are due to differences between alignment in memory and on disk. The section sizes can be useful in detecting packed executables. For example, if the Virtual Size is much larger than the Size of Raw Data, you know that the section takes up more space in memory than it does on disk. This is often indicative of packed code, particularly if the .text section is larger in memory than on disk.
- 32. Examining PE files with PEview
- 33. Viewing the Resource Section with Resource Hacker
- 34. Viewing the Resource Section with Resource Hacker • The Icon section lists images shown when the executable is in a file listing. • The Menu section stores all menus that appear in various windows, such as the File, Edit, and View menus. This section contains the names of all the menus, as well as the text shown for each. The names should give you a good idea of their functionality. • The Dialog section contains the program’s dialog menus. The dialog at (2) shows what the user will see when running calc.exe. If we knew nothing else about calc.exe, we could identify it as a calculator program simply by looking at this dialog menu. • The String Table section stores strings. • The Version Info section contains a version number and often the company name and a copyright statement.
- 35. PE Header Summary The PE header contains useful information for the malware analyst, and we will continue to examine it in subsequent chapters. Below table reviews the key information that can be obtained from a PE header.