How to figure out which imported function(s) in a virus determine its behaviour?

Question

I want to know how to find the functions which is interesting in malware tools. For example, I have a sample of unknown virus (this sample is lab01-01.exe in the book practical malware analysis lab1-01.dll). It is not packed.

I am supposed to find out what does this malware by knowing the imported DLLs and the functions it uses. Here are the imported functions in the executable file lab01-01.exe:

KERNEL32.dll :
CloseHandle
UnmapViewOfFile
IsBadReadPtr
MapViewOfFile
CreateFileMappingA
CreateFileA
FindClose
FindNextFileA
FindFirstFileA
CopyFileA

And from MSVCRT.dll:

_getmainards
_p_initenv
_p_commode
_p_fmode
_set_apps_typr
_setusermatherr
_adjust_fdiv
_controlfp
_except_handler3
_exit
_initterm
_stricmp
_XcptFilter
exit
malloc

But, I didn't find any function imported from lab01-01.dll.

I also want to know why, although the book mentioned that both the executable file and DLL are related (it should be imported).

Answer 1

Dlls can not only be imported statically but also dynamically. For the dynamic case, it uses LoadLibrary to load the dll, and GetProcAddress to resolve the address of the function it needs.

If the dlls are imported statically, then a simple dependency walking will give you information about each dll its imports and also the function within each of them it uses. This information is actually present in the PE header which a tool like dependency walker shows you.

If the dll is imported dynamically, then walking through the imports will not give you any idea about the dlls and functions it uses. In such a case, debug the application (if possible). Set a breakpoint on kernel32.LoadLibraryA / kernel32.LoadLibraryW or even the undocumented ntdll.LdrLoadDll and run the app. When the breakpoint is hit you immediately know which dll it is trying to import. Similarly setting a breakpoint on GetProcAddress will reveal the function the application wants to use.

I am talking about the simplest case here. You may encounter malware which bypasses the LoadLibrary mechanism totally, by implementing its own PE loader. See this page for such an example. Similarly GetProcAddress can be bypassed too, by manually parsing the import tables.

This chapter from the book Practical Malware Analysis gives you a list of some important Windows API functions which can be used to get some insight into the workings of a malware.

Answer 2

Extreme Coders has provided a good answer about the IAT (Import Address Table).

This question is so abroad I was originally not going to answer but I'll try quickly summarise the sort of tools and things you'll want to look for.

Firstly, let me tell you what any imported or exported function can't really say it's used primary malware. For example, DeleteFile can be used to delete important files is considered as malware but the actual API itself can be used for common non-related malware operations.

If you want to see what APIs are actually been executed you'll want to use something like: http://www.rohitab.com/apimonitor this will give you much better graphical presentation and lists all the function parameters for that known API too. So more rich data to work with. As looking at long list is too overwhelming.

After you have found the APIs which look suspicious then you can get into a debugger and start investigating the usage of the API which comes a complexed field. You'll have to know how to software is expected to work for example.

Let's say you have a text editor just a simple notepad program you have downloaded. You'll just review APIs for unusual activity such as:

1. If you see network actvity on a simple text editor - Why does it need networking? Is it malicious related or just an auto patcher for self updating?
2. If you see process modification external or internal - Why is it doing this? Review the related APIs to memory modifying WriteProcessMemory or lower level API is NtWriteVirtualMemory.

Though really you can't rely on just checking APIs as you can use syscall directly which would bypass any listed APIs.

To determine malware you'll want to use things such as: http://camas.comodo.com/

You'll want to get yourself varies tools such as:

1. Virtual Machine (VMWare, Virtual PC or something similar). As you don't want to get your host machine infected with malware, do you? Though, do note that complexed malware can break out of virtual machines!
2. Snapshot software to compare before and after execution of file system and registry. There is a good one developed by Microsoft. I'll dig it up for you when I'm at home. So, take snapshot before you run the application and after.
3. Get yourself a debugger such as IDA PRO (ideally but very expensive) otherwise OllyDbg is my next favourite debugger.

Maybe I am getting off-topic? Anyway, I hope this information was useful. If so, I'll expand my answer.

Answer 3

While others have already provided some answers, I would like to add some additional points.

You could code a pintool (DBI) which logs all the API calls. You could add some filters in your pintool to reduce the amount of API calls you log. Using a pintool has an advantage since anti debugging techniques used by malwares would not have an effect on it. Of course, we are assuming that the malware is not trying to protect itself from DBI frameworks. However, if you set breakpoints on LoadLibrary and GetProcAddress to see which libraries are loaded dynamically and which function addresses are resolved, you could be effected by anti debugging techniques used by the malware. Before you hit the breakpoint, the malware would have already discovered that it is being debugged and alter the program flow.

I would suggest you not to conclude the functionality of a malware only by looking at the API names imported from different modules. A sequence of API calls can sometimes indicate malicious activity. For instance,

CreateProcessW
VirtualAllocEx
WriteProcessMemory
WriteProcessMemory
GetThreadContext
SetThreadContext
ResumeThread

Now, you could see these API names imported from kernel32.dll when you open the binary in a software like CFF explorer, however to conclude the usage of these APIs, an API trace would help. In this case, it is a standard method used by several binaries to perform code injection into the address space of another process.