Lab 1-1 | Practical Malware Analysis

1. Upload the files to http://www.VirusTotal.com/ and view the reports. Does either file match any existing antivirus signatures?

Here we can see that it is indeed detected and by quite a few of them. However the author explains that the executable and dll were malware pieces written specifically for this book, so we can assume that those pieces just got famous and now everyone knows them.

2. When were these files compiled?

Here we can see that those two files were compiled the 19th of December of 2010 and 19 seconds apart of each other, which tells us that they were compiled at the same time.
Apparently these hackers don’t believe in a peaceful christmas.

3. Are there any indications that either of these files is packed or obfuscated? If so, what are these indicators?

Luckily for us, the section names weren’t obfuscated. Being able to know which section is which, I took a peek to the IMAGE_SECTION_HEADER .text ( the section which contains the instructions that the CPU will execute ) and checked the Virtual Size and the Size of Raw Data.

The Virtual Size will tell us how much space takes a section during the loading process, the size of the raw data tells us the size of the section on the disk. From the book, we can make a first statement saying it is not packed, since the size of both is not extremely different.

As we can see in the image above, virtual size is 970 and Raw Data size is 1000. The difference
small and it could be due to the alignment in the memory and disk.

Next, we’ll try to make sure that this sample isn’t packed by looking at the imports.

As we can see, there are quite a few imports here, which is a good indicative that the files are not

packed.

We could have used PEiD for this from the start by the way, I just thought that getting used to check the other variables is a good practice.

4. Do any imports hint at what this malware does? If so, which imports are they?

I’m going to try and explain what I suspect happens here while explaining a bit each import.

First of all, in the executable file, we can see that we have imports from KERNEL32.dll and MSVCRT.dll.

From the wikipedia page:

KERNEL32.DLL exposes to applications most of the Win32 base APIs, such as memory management, input/output (I/O) operations, process and thread creation, and synchronization functions.

MSVCRT.DLL is the C standard library for the Visual C++ (MSVC) compiler from version 4.2 to 6.0. It provides programs compiled by these versions of MSVC with most of the standard C library functions. These include string manipulation, memory allocation, C-style input/output calls, and others. MSVCP*.DLL is the corresponding C++ library.

Hmm, so could that mean that the sample was compiled with Visual Studio? Well, yes! We just saw with PEiD. Now we know that it’s written in C++ too.

Now, inside KERNEL32.dll we find a series of functions

First of all, we see CloseHandle. MSDN tells us that this will close an open object handle, but, what is a handle anyways? What does Microsoft mean when talking about an object handle?

Microsoft explains stuff about objects and handles that could be of our interest: https://msdn.microsoft.com/en-us/library/windows/desktop/ms724457(v=vs.85).aspx

So from StackOverflow:

Properly, in Windows, (and generally in computing) a handle is an abstraction which hides a real memory address from the API user, allowing the system to reorganize physical memory transparently to the program. Resolving a handle into a pointer locks the memory, and releasing the handle invalidates the pointer.

Hm, interesting. So the executable created a handle and then released it. What more did it do?

We can also see that it calls UnmapViewOfFile, but what does it mean to map the view of a file?

Mapping a file makes the specified portion of a file visible in the address space of the calling process.

Interesting.

IsBadReadPtr:

Verifies that the calling process has read access to the specified range of memory.

And what about FindFirstFileA, FindNextFileA or FindClose?

Searches a directory for a file or subdirectory with a name that matches a specific name (or partial name if wildcards are used).

Continues a file search from a previous call to the FindFirstFile, [...] functions.

Closes a file search handle opened by the FindFirstFile, [...].

And CopyFileA:

Copies an existing file to a new file.

So what this executable will do is find files, check if it actually has read access to those files and copy them to a new file? What a bunch of bastards!

Now let’s take a look at the dll.
Oh look, a sleep function! Some time ago SANS institute released a document called Sleeping your Way out of the Sandbox. In this paper it talked about how malware knows that sandboxes have finite resources, and so, if the malware delayed the execution of its code just long enough for the sandbox to time out, it would be able to execute this same code out of the sandbox. Clever, right?
It’s also a good indicator that we found malware.
Right after the sleep function we see it starts a process and… a mutex? What’s that? Well, turns out that mutex do have quite a bit of importance in the malware world.

First of all, what a mutex does is lock a program object in order to avoid other programs from running when this one is.
What would happen if the malware creators didn’t lock their programs? Well, it could happen that different instances of the malware infected the same machine. Quite impractical if you try to keep a functional low profile, right?
https://www.alienvault.com/blogs/labs-research/malware-exploring-mutex-objects

But as we saw before, it creates a process and then sleeps. Huh, strange.
Let’s keep looking.

WS2_32.dll imports functions by ordinal and not name and we won’t be able to ever see what happens there, oh sad :(
I’m just kidding. Let’s open IDA Pro.

Load the dll and press shift + 12, the strings window will pop open. We could just look at the strings in the string window, but I’m not that type of person.

Oh wow, so it has an IP address? So it’s very probable that it’s sending the files it copied right into that IP address.

Since the book tells us that malware can use CreateProcess in combination with Sleep to wait to send data to a C&C server, we will deduce that that IP is the C&C one. Maybe this was a trick from the writer? Maybe the real IP was hidden somewhere else? Who knows, we’ll discover in future chapters, but let’s just keep it simple for the moment :)

Also, if we look at the strings of the executable, we’ll find something equally as interesting.

So it makes a new file called kerne132.dll that is supposed to replace the Kernel32.dll.

5. Are there any other files or host-based indicators that you could look for on infected systems?

The kerne132.dll would be a great indicator, just like the string SADFHUHF.

6. What network-based indicators could be used to find this malware on infected machines?

The IP address works fine for this.

7. What would you guess is the purpose of these files?

So this malware will install itself with the executable, which will use too to scan all the directories for files, copy them and create the new kerne132.dll file.
The dll, in its turn, will start the sleeping process waiting for a signal from the C&C server ( the one from the IP address ) from where it will receive the orders.
The next chapters will most probably enter into detail about how we can see what happens during the communication process.