PMA - Lab 09-02

Questions

Analyze the malware found in the file Lab09-02.exe using OllyDbg to answer the following questions.

Questions:
1. What strings do you see statically in the binary?
2. What happens when you run this binary?
3. How can you get this sample to run its malicious payload?
4. What is happening at 0x00401133?
5. What arguments are being passed to subroutine 0x00401089?
6. What domain name does this malware use?
7. What encoding routine is being used to obfuscate the domain name?
8. What is the significance of the CreateProcessA call at 0x0040106E?

Answers

1. What strings do you see statically in the binary?

By first running strings on the binary, we can see the imports and the string “cmd”:

2. What happens when you run this binary?

We can see that this binary starts and exits in less than a second:


And it finishes without doing much…

3. How can you get this sample to run its malicious payload?

To understand this, let’s open the sample in x32dbg:
First, we need to find main. Again we do this by searching after the call to GetCommandLineA for a function that takes 3 arguments, and we found “sub_401128”:

Let’s step inside and put a breakpoint, then press run again (I added a comment calling this main):

So we can see that it is building 2 strings - we can see ascii characters ending with a NULL terminator, those strings are:

1. “1qaz2wsx3edc”
2. “ocl.exe”

Both are stack variables of main saved at “ebp-1B0” and “ebp-1A0”.

After that we can see a call to GetModuleFileNameA:

Right after it, we can see a call to 0x401550, and it passes 0x5C and the PATH of our file.
After running it, we can see that it returns a pointer to the last part of our path. If we take a look at the hex values, we can see its at the last 0x5C “\” found in the string:

Based on that we can guess pretty confidentaly that this is a short function named “strrchr” - we can also open it in IDA and see what it recognized it as:

The next call after at 0x4014C0 takes two arguments:

• “ocl.exe”
• “Lab09-02.exe”

So one of them is the string we found at the start, and the other is the name of our executable (it removed the path including the “\” by adding 1 to the string address)
We can see that it returned eax = 1, meaning it doesn’t take the “je” at 0x401240 so it just jumps to the end of the program.

We can guess that this function compares the two strings with each other, so this is a short function named “strcmp” - we can also open it in IDA and see what it recognized it as:

That means the name of our file should be “ocl.exe” to pass this check.
So let’s rename this file to “ocl.exe” and try again:

We can see that this time the function returned 0 - meaning are analysis was right.

4. What is happening at 0x00401133?

Let’s take a look at it:

We already saw that part in question 3, this is where the malware builds two strings by moving the hex values into local variable offsets.

5. What arguments are being passed to subroutine 0x00401089?

We can then see a call to WSAStartup and WSASocketA so we can expect to see something related to network functionality later on.
Right after those two calls, we can see the call to the subroutine 0x00401089, and we can see that it is passing to it:

• an address to the string: “1qaz2wsx3edc” (The other string it builded)
• an address 0x12FD90

We can step into this subroutine to see what happens with this address.
We can see that there a call to sub_401440 and it sends the string “1qaz2wsx3edc” and it returns eax=0x0C (12) this looks like its strlen.
A quick way to check it is we can run it again, and before executing this subroutine modify the string by changing the last letter (“c”) to 0x00. Because we removed one letter, we expect to get eax=0x0B (11):

Now let’s see what value eax returns:
So yeah, its 0x0B, this is “strlen”. And if we take a look at it in IDA:

Now we can see a for loop, we can take a look at it in IDA and rename some stuff to make it clear:

Note: I wrote some comments to explain the flow of this function.
This function takes a key and an encrypted buffer with the length of 32 chars, decrypts the buffer by XORing it with the key (And because it is XOR, it can be done both ways, to encrypt/decrypt).
The modulo found there is because the key needs to wrap around if the data it wants to encrypt/decrypt is longer than 12 bytes.

We can get the decrypted value by viewing in dump the address the decrypted buffer is built at:

We can run untill the end of the for loop, before we return by selecting that line and running until selection (or just put a breakpoint there):

And we can see the decrypted value there:

Decrypted: “www[.]practicalmalwareanalysis[.]com”

6. What domain name does this malware use?

We can see the call to GetHostByName with the URL - “www[.]practicalmalwareanalysis[.]com” that was decrypted just before:

And we can see that if it is successful, it will connect to the IP it will get from there:

7. What encoding routine is being used to obfuscate the domain name?

A XOR encoding routine, that we already analyzed in question 5.
Let’s try to use cyberchef to make sure we understood correctly the way it encryptes/decryptes!
Because know that it sends the encrypted buffer and the key to the decryption function, we can copy the encrypted buffer (32 bytes from that address - 2 lines):

And decode them in CyberChef:

And we can see that we get the correct URL!

8. What is the significance of the CreateProcessA call at 0x0040106E?

After the routine that gets the IP, we can see that it tries to connect to the IP it got on port 9999:

If it failes it sleeps for 30 seconds, and loop back to the start. If it succeedes, we can see a call to sub_401000, right before we close the socket, and the only parameter we send this subroutine is the socket:

In this situation, we can run fakenet for example to pass this section by making the malware think it succeeded with getting the connection… but we can continue for now in IDA.
If we enter that sub we can see the call to CreateProcessA call 0x0040106E (The one the question asked about):

Now we can take a look at a few things, to understand more what is happening here we need to take a look at CreateProcessA’s lpStartupInfo - STARTUPINFO.
Let’s start with the flags, which tells us what fields will be used in the structure:

dwFlags:
A bitfield that determines whether certain STARTUPINFO members are used when the process creates a window. This member can be one or more of the following values.

We can see that only those will be used:

So let’s understand what we set each one to:

• ShowWindow - We can see that it set it to zero, if we take a look what it stands for:
  
  So this window will be hidden from the user.
• StdHandles - we can see that it sets each one to the same value as the others, and all of them to the argument it sent this subroutine.
  This means that all input, output and error will go to the socket. So all of the data that will be send over the socket will be passed to process, and all of the data that the process will create will be sent back through the socket.
  After that we can see that the command line of CreateProcessA is set to “cmd”.

So basically what will happen is this will launch a hidden cmd that will send all data through the socket, and receive everything from the socket.
In other words, this malware is a reverse shell that connects to an encrypted url on port 9999, and in order to be able to run, it must be named “ocl.exe”.