cdbee59f8144be30634bf4994d51e1a0 — A Beginner‘s Malware Diary 1
The series is the journey of a security beginner who wants to become an expert and hopes to make a little contribution for security community worldwide.
When we search the md5 signature in VirusTotal, we find out its name in sha256 is ff9373cc5592c9a450a869fec605c80a98f4ae14a73054194ddcd06a1116c842 Besides, many anti-virus software regard it as a Trojan or an adware.
The malware is packed so we use upx -d cdbee59f8144be30634bf4994d51e1a0 to unpack it.
After we unpack the malware, the dependencies the malware has are very interesting to the analyst. We use Dependency Walker to disclose the libraries the malware relies on.
We enumerate all the functions used by the malware in Kernel32.dll in which Windows’ core functions are stored.
There are some functions that are handle files. For instance:
FindFirstFileExW: Searches a directory for a file or subdirectory with a name and attributes that match those specified.
FindNextFileW: Continues a file search from a previous call to the FindFirstFile, FindFirstFileEx, or FindFirstFileTransacted functions
We can speculate that the malware is able to search whatever files it wants in victim’s host.
Now, let’s take a look at USER32.dll. We enumerate the functions:
BeginPaint allows windows prepare a specified window for painting and fills a PAINTSTRUCT structure with information about the painting. It makes sense for a Trojan because it definitely needs a window to monitor victim’s behavior.
CreateWindowExW looks very fancy in MSDN document. It said the function can create child or pop-up window with the extended window style. Now, we can imagine that the Trojan is capable to do multiple tasks separately in different windows. Besides, function RegisterClassExW will register a window class for the new windows before they are created.
There is another interesting ADVAPI32.dll which tells us the malware use Windows registry.
CheckTokenMembership verifies the security identifier is enable in the access token or not.
RegisterEventSourceW gets a registered handler of an specified event log. According to the MSDN document, it has two arguments: lpUNSourceName and lpSourceName. lpUNSourceName is the name of the remote server (Use null if it is local)on which the operation is performed and lpSourceName is the name of the event source which is the software logging the event. Thus, we can speculate that the malware might log events in a remote host.
There are many functions into which I haven’t dug. As time goes on, I believe I will understand more interesting stuff from them.
After checking the library dependencies, we are going to explore the PE header.
By PEview, we can browse the header information as the following picture shows:
IMAGE_DOS_HEADER and MS-DOS Stub Program are historical legacy which is not important. Now let’s take a look at IMAGE_NT_HEADERS. The signature is always “PE\0\0” so it is not interesting.
In the machine description, IMAGE_FILE_MACHINE_i386 means the malware run on x86 platform. The Time Date Stamp description shows when the executable is compiled and we can see that the compiled time is very very close to now! Maybe it is too new for other 23 antivirus software (Based on VirusTotal) to detect it successfully.
In IMAGE_OPTIONAL_HEADER, the description of Subsystem is given. IMAGE_SUBSYSTEM_WINDOWS_GUI tells us that the Trojan is a GUI program rather a console one.
IMAGE_SECTION_HEADER is a series of meta data of sections in PE file, as the following picture demonstrates:
SECTION.text has its header IMAGE_SECTION_HEADER.text; SECTION.rdata has a header IMAGE_SECTION_HEADER.rdata and so forth. In other words, IMAGE_SECTION_HEADER.xxxx is the meta data of SECTION.xxxx .
SECTION.text contains the instructions that CPU executes.
SECTION.rdata stores the read-only global data which is accessible within the program
SECTION.data, similar to SECTION.rdata, is a section storing global data but not the read-only ones.
SECTION.rsrc has the external resources such as icon, images, font and etc, that are needed in the executable.
SECTION.reloc has a base relocation table containing entries for all base relocations.
In every IMAGE_SECTION_HEADER, Size of Raw Data describes the size of the section in hard drive; Virtual Size, on the other hand, shows how much space the section takes when data is loaded into memory. Most of time, due to the alignment requirement of an image Virtual Size is slightly smaller than Size of Raw Data since the data is padded with 0 to fulfill the requirement in compilation to image.
Based on our observation, we make a table of each section’s Virtual Size and Size of Raw Data.
It’s interesting that the .data section (the part highlighted with yellow) has bigger virtual size than its size in the disk. However, it is normal if a binary is designed to reserve some space in memory for uninitialized data. The addresses that reference the uninitialized data are in the binary and will point to those data once the executable is running.
We have mentioned that a program sometime needs external resources such as icon, images and etc. Those resources are usually not in the program but we can use tools like Resource Hacker to see what they are.
Unfortunately, the resource information in the malware is tedious … Only the default executable icon of Windows is used.
In the next article, I will practice the basic dynamic analysis. It will be interesting and fun! 😎
