0xF444's blog

Lab 20

14 min read

Lab20-01.exe

The purpose of this first lab is to demonstrate the usage of the this pointer. Analyze the malware in Lab20-01.exe.

Question 1.1

Does the function at 0x401040 take any parameters?
Loading the binary in IDA and going to the specified address, we can see a function call to sub_401040 at 401025.
Since we’re dealing with a 32-bit executable, we can expect parameters to be pushed onto the stack but we see none except for moving var_4 into ecx which indicates that it could be a this pointer being passed implicitly.

When calling object functions, may it be constructors, destructors or functions that are defined within a object; the compiler must pass a pointer to the object into ecx.

This means that this function doesn’t explicitly take any parameters but takes in an object reference implicitly (this), indicating that we’re dealing with an object function.

Question 1.2

Which URL is used in the call to URLDownloadToFile?
Since we’ve established that an object pointer is passed to sub_401040, to further ease our analysis process, we can begin to infer what the object structure looks like.

The malware begins to create 4 bytes of data on the heap using the new operator, then moves the address of the allocated memory into var_8 and in turn move it into var_4 (renamed to this)
Then we see the malware moving an offset pointer to a string to the first 4 bytes of the object structure.
And since no other initializations seem to have happened, we can infer that the object structure would like something as simple as this:

class URL{
public:
char* URLptr;
}

Note: Pointers have the same size as the bitness of the executable.

Now digging inside sub_401040, we can see that it takes in the object pointer, dereferences the first object member and passes it as szURL parameter to URLDownloadToFileA.

So the URL that the malware attempts to beacon to is http://www.practicalmalwareanalysis.com/cpp.html.

Question 1.3

What does this program do?
The program simply beacons out to www.practicalmalwareanalysis.com and attempts to download cpp.html onto the victim’s system.

Lab20-02.exe

The purpose of this second lab is to demonstrate virtual functions. Analyze the malware in Lab20-02.exe.

Question 2.1

What can you learn from the interesting strings in this program?
We can see some file extension artifacts, an FTP URL and some string place holders.
This seems to be an FTP client that beacons out to a hardcoded server, or it appears as so. We’ll have to dive in this executable to see what it actually does.

Question 2.2

What do the imports tell you about this program?
Checking the imports, we see imports of FTP related functions.
We also see imports of WS2_32.dll.

These imports indicate FTP functionality and that the malware could beacon out through FTP.

Question 2.3

What is the purpose of the object created at 0x4011D9? Does it have any virtual functions?
Since the call to the new operator is assumed to be object creation, we have 8 bytes of free heap memory.
Then we see the first 4 bytes of the object getting assigned off_4060E0 and then overwritten with off_4060DC, so that’s the first 4 bytes.
Checking the offsets, we can see that one of them contains an offset to a function (function pointer).
Based on this, we can infer that the object created does indeed use a vtable, as normal functions would have a direct call instruction.

Question 2.4

Which functions could possibly be called by the call [edx] instruction at 0x401349?

To answer this question, we’ll need to trace back and find out which object whose vtable is referenced.
Based on the screenshot above, we can see that target_objptr’s first member at offset 4 is having the variable Destination which is a character pointer.
That being said, we trace back and see how target_objptr is modified.
We can see three different paths that lead to the indirect call, so we need to see how each path sets our object pointer.

Path 1

Checking block number 1, we can see that it’s very reminiscent of the block that we’ve landed on in Question 2.3, in which we saw off_4060DC as a vtable get set.
Thus, sub_401440 is a possible candidate.

Path 2

Checking block number 2, we see two blocks that lead to it.
The red block is rejected because it’ll set the this pointer to NULL, however the green block seems to have a pattern similar to Path 1 in which off_4060D8 is being set as a vtable for the object pointer.
Thus, sub_401380 is a possible candidate.

Path 3

Checking block number 3, we see two blocks that lead to it.

We reject the red block, and see that off_4060E0 is being as a vtable for the object pointer.
Thus, unknown_libname_1 (renamed to BaseObjectFunc) is a possible candidate.

If you take a closer look...

off_4060E0 was overwritten twice in Path 1 and Path 2 by their respective vtables found (check the green blocks) while it wasn’t overwritten in Path 3 which leads us to believe that whichever class that has off_4060E0 seem to be a parent class to both subclasses that are set in both paths 1 and 2, we also conclude that each path seems to be a different constructor for each object based on some conditions within this function.

Question 2.5

How could you easily set up the server that this malware expects in order
to fully analyze the malware without connecting it to the Internet?
In Question 2.2, we’ve established that the malware imports FTP related functions so we’ll pivot from this point forward and see how the malware uses this function.

If we take a closer look, FtpPutFileA is called by both functions in the vtables we’ve covered in the previous question.

So, this malware indeed is an FTP client so in order to setup a fake server, we’ll need to see which server it beacons out by means of checking all calls to InternetConnectA.
The malware beacons out to a hardcoded domain which will eventually be resolved by DNS by the OS, so our plan is as following:

  1. Redirect all DNS requests to point to our localhost as DNS Reply. → ApateDNS will do the trick.
  2. Setup an FTP server locally on the machine. → FileZilla is good.
    Upon initial configuration, we can see that the malware attempts to authenticate to the server using the anonymous username, so we’ll need to configure this as a new user with a shared folder as a base directory.
    If we run the malware now, we’ll see that the server starts to log some outbound connections.

Upon executing, we can see that the malware drops pdf files and doc files into their respective directories with filename that is set to the victim’s hostname alongside a hyphen and a counter.

Question 2.6

What is the purpose of this program?
The program basically enumerates all files with in the C:\ partition and sends .pdf and .doc files over the network through FTP to the attacker’s hardcoded FTP URL.

Question 2.7

What is the purpose of implementing a virtual function call in this program?
To answer this question, we’ll need to go back to the constructors and see the conditions that causes their block to be taken.
But first, we have to know how the malware works: it begins by taking C:\* as a parameter to the function that does all the heavy lifting.
The malware then enumerates overall files in the C:\ partition using FindFirstFileA and checks if the file extension is .doc.
And .pdf if otherwise.

Now if we analyze Object1 and Object2’s vtables, we can see that each function attempts to communicate back to the server using FtpPutFileA and passes in the Destination data member as a parameter.


From these screenshots we can confirm that the malware has a base object we’ll call File that has the Destination as a data member (as shown in Question 2.4) and a function we’ll call SendFile() that does absolutely nothing as shown in the third screenshot.
Then if the file is found to a .pdf or a .doc file, the SendFile() function gets overridden with their respective implementations that allows the malware to send these files using FTP as shown in the first 2 screenshots, from this we can make a blueprint of the classes used by the malware.

class File
{
public:
    char *Destination;
    void virtual SendFile(){};
};
class PdfFile : File
{
public:
    char *Destination;
    void SendFile()
    {
        // Pdf File Sending Implementation
    }
};
class DocFile : File
{
public:
    char *Destination;
    void SendFile()
    {
        // Doc File Sending Implementation
    }
};

This fits the description of the constructors when it creates the object onto the heap, as it creates 8 bytes: 4 for the data member and the remaining for the vtable pointer.

Lab20-03.exe

This third lab is a longer and more realistic piece of malware. This lab comes
with a configuration file named config.dat that must be in the same directory
as the lab in order to execute properly. Analyze the malware in Lab20-03.exe.

Question 3.1

What can you learn from the interesting strings in this program?
We see references of html resources:
We also see string formats that indicate a status report of the victim connected:
And error messages that indicate the functionality of the malware:
Lastly, we see a hardcoded user agent that the malware may attempt to use:
Overall, these strings give an impression that we might be dealing with a backdoor or a botnet.

Question 3.2

What do the imports tell you about this program?
We can see some interesting imports from kernel32 and advapi32.dll:

Lastly, we have imports from WS2_32.dll which are relevant to internet connectivity and beaconing.
This further hardens our guesses in the strings that it may be a backdoor attempting beacon out basic info of the victim’s PC while also doing some basic file manipulation.

Question 3.3

At 0x4036F0, there is a function call that takes the string Config error, followed a few instructions later by a call to CxxThrowException. Does the function take any parameters other than the string? Does the function return anything? What can you tell about this function from the context in which it’s used?
Judging by the renaming, signature detected by IDA and the pushes prior to the call, we can see that it takes in an object reference in ecx

We can also confirm the signature by checking all the xrefs to this function in particular, and in each one of them we can see the same exact parameters being pushed.
Digging into the function in graph mode, we can see that the exception object constructor moves a vftable into ebp whose pointer is eventually returned by the constructor.
This gives us a slight hint at what this function actually does; the function attempts to initialize an exception object used by the runtime (by possibly setting up vtables necessary to handle the exception) which is then used to throw an exception of type Read Config error, as shown by the pThrowInfo parameter to the call to CxxThrowException.

We can easily confirm this by checking what makes the program take such path:
And if we double check with all xrefs, we can see that it does this if the config.dat file itself is not in a format it’s familiar with, which leads to parsing errors.

So in conclusion, sub_4036F0 is used to initialize an internal exception object used by the C++ runtime with vtables that might be used to handle the exception that is triggered if there were issues with reading the configuration file (reading/parsing).

Question 3.4

What do the six entries in the switch table at 0x4025C8 do?

  1. The first entry (case 97) leads to a block that deconstructs a memory region in the heap and then returns.

  2. The second entry (case 98) leads to a block that calls sub_4025E0:Which takes in a string from the object passed, converts it an integer and then calls the sleep function, so this block is responsible for the backdoor to sleep for a period of time.

  3. The third entry (case 99) leads to a block that calls sub_402F80:
    Which in turn calls sub_402EF0:
    Inside this function, we can see that it attempts to create a new process from a command line argument that is in a data member within the object passed to this function.
    So this function basically creates a new process remotely from the attacker.

  4. The fourth entry (case 100) leads to a block that calls sub_402BA0:
    Which calls sub_402A20 if no exceptions are triggered.
    The function pushes in 0x1f4 into the sleep function before beginning it’s functionality and then it attempts to allocate memory onto the heap using the new operator.
    Then it starts to push in a hostshort and a Source parameters and then calls sub_403D50.
    If we check the called functions from sub_403D50, we can see socket related functions:
    We can also affirm this by looking at the exception type that is generated if the function fails:
    So, we can rename this function as SocketConnect.

    In case you haven’t noticed: the malware throws an exception type of the intended functionality of any given function given in plaintext, we can use this confirm our findings.

    Then the malware calls sub_404CF0, which when analyzed seems to prepare an HTTP header and then calls sub_404480
    If we check the function calls from sub_404480:
    This seems to be function responsible for sending data, so we’ll rename it SendData, and since sub_404CF0 has initialized an HTTP get header, we can rename this function to SendHTTPGet, both findings are confirmed by their exception types respectively.
    Then after SendHTTPGet is called, we can see that sub_404B10 is called:
    Within this function, we can see that sub_4048E0 is called and afterwards a string comparison is done on "HTTP/":
    This gives us a clue on what sub_4048E0 does, if we dig into it, we can see that there are calls of recv():
    Which is confirmed by the exception type:
    We can rename sub_4048E0 as ReadResponse(), and with that we have a slight hint at sub_404B10 does: it attempts to receive chunks of data and parse it individually to check if it’s a valid HTTP response.

    And judging from the exception type, this seems to validate our guesses, so we can rename sub_404B10 as ReceivefromServer.
    Then we call sub_4015C0 seems to be an encoding function:
    Which is confirmed by the exception type:
    We can rename sub_4015C0 as EncodingFunc.
    Lastly, we can see calls to CreateFileA with access GENERIC_WRITE and then passes the file handle into WriteFile.
    This tells us that sub_402BA0 is actually downloading a file from the server, which is confirmed by the exception type.
    From this we conclude that the 6th entry is downloading a file from the server and writing it on the victim’s PC.

  5. The fifth entry (case 101) leads to a block that calls sub_402C70:
    And using the same analysis technique as the last entry, we can that it attempts to obtain a file handle with GENERIC_READ access:
    Then attempts to read the contents of the file:
    Then opens a socket for beaconing:
    Then it attaches the data read from the file, attaches it to the HTTP header and sends via a POST request:
    The malware has to receive a response from the server and acknowledge the operation and then decodes the received response:

    This is confirmed by the exception type:

    So in conclusion, this entry attempts to read a file from the victim’s PC and uploads it back to the attacker’s server.

  6. The sixth entry (case 102) leads to a block that calls sub_402D30:
    In this function, the sleep function is called for half a second and then we see a call to GetUserNameA:

    Then we see calls to GetVersionExA and GetSystemDefaultLCID:
    Then it begins preparing a format in which it prints out all of this obtained information into a buffer:
    Lastly, it begins to setup a beacon to upload all of this information to the server:
    All of this is confirmed by the exception type that this function uses:

    So in conclusion, this entry sends basic information about the victim’s PC to the attacker’s server.

Question 3.5

What is the purpose of this program?
This program serves as a full-fledged backdoor that is able to upload/download files to/from the attacker’s server, it can also execute command line executables remotely using CreateProcessA and can send basic information about the victims who got infected all while encoding the data communicated to avoid network based detection.

Next Lab: Lab 21
Previous Lab: Lab 19

Graph View