Now that you understand the basics of static analysis, let’s examine some real malware. We’ll look at a potential keylogger and then a packed program.
Table 1-2 shows an abridged list of functions imported by PotentialKeylogger.exe, as collected using Dependency Walker. Because we see so many imports, we can immediately conclude that this file is not packed.
Table 1-2. An Abridged List of DLLs and Functions Imported from PotentialKeylogger.exe
User32.dll | User32.dll (continued) | |
|---|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
|
| GDI32.dll |
|
|
|
|
|
|
|
|
|
|
| |
|
| Shell32.dll |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
|
| Advapi32.dll |
|
|
|
|
| |
|
| |
|
| |
|
| |
|
|
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. Throughout this book, we will cover the imports for malicious software, focusing on the most interesting functions from a malware analysis standpoint.
When you are not sure what a function does, you will need to look it up. To help guide your analysis, Appendix A lists many of the functions of greatest interest to malware analysts. If a function is not listed in Appendix A, search for it on MSDN online.
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.
Normally, we wouldn’t know that this malware is a potential keylogger, and we would need to look for functions that provide the clues. We will be focusing on only the functions that provide hints to the functionality of the program.
The imports from Kernel32.dll in Table 1-2 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.
The imports from User32.dll are even more interesting. The large number
of GUI manipulation functions (such as RegisterClassEx, SetWindowText, and ShowWindow)
indicates a high likelihood that this program has a GUI (though the GUI is not necessarily displayed
to the user).
The function SetWindowsHookEx is commonly used in spyware
and is the most popular way that keyloggers receive keyboard inputs. This function has some
legitimate uses, but if you suspect malware and you see this function, you are probably looking at
keylogging functionality.
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. No matter which application is
currently active, a hotkey will bring the user to this application.
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, which in turn tells us that we should search for strings that look like registry keys.
Registry strings look a lot like directories. In this case, we found the string Software\Microsoft\Windows\CurrentVersion\Run, which is a registry key
(commonly used by malware) that controls which programs are automatically run when Windows starts
up.
This executable also has several exports: LowLevelKeyboardProc and Low-LevelMouseProc.
Microsoft’s documentation says, “The LowLevelKeyboardProc hook procedure is an application-defined or library-defined callback
function used with the SetWindowsHookEx function.” In other
words, this function is used with SetWindowsHookEx to specify
which function will be called when a specified event occurs—in this case, the low-level
keyboard event. The documentation for SetWindowsHookEx further
explains that this function will be called when certain low-level keyboard events occur.
The Microsoft documentation uses the name LowLevelKeyboardProc, and the programmer in this case did as well. We were able to get
valuable information because the programmer didn’t obscure the name of an export.
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\Microsoft\Windows\CurrentVersion\Run that this program sets itself to load at
system startup.
Table 1-3 shows a complete list of the functions imported by a second piece of unknown malware. The brevity of this list tells us that this program is packed or obfuscated, which is further confirmed by the fact that this program has no readable strings. A Windows compiler would not create a program that imports such a small number of functions; even a Hello, World program would have more.
Table 1-3. DLLs and Functions Imported from PackedProgram.exe
Kernel32.dll | User32.dll |
|---|---|
|
|
| |
| |
| |
| |
|
The fact that this program is packed is a valuable piece of information, but its packed nature also prevents us from learning anything more about the program using basic static analysis. We’ll need to try more advanced analysis techniques such as dynamic analysis (covered in Chapter 3) or unpacking (covered in Chapter 18).