Trojan-Downloader.Win32.Cabby.cemx - Part Two - Functional

In the previous part, the first defense layer of the malware was dismantled and removed. We dumped the process after decrypting the main code, saving it in a separate executable file.
It is time to understand the logic and meaning of the Downloader itself.

Network activity

Express analysis of network activity showed that the malware scans a few resources on the list and downloads some efax.jpg from the first available. Here is an example request:

Download .jpg and see the insides of this file - a random collection of bytes. Neither the JPG "FF D8" signatures, nor any lines. Again encrypted data? We will understand later.

')

API Recovery

Almost at the very beginning of the listing we stick into the procedure 0x0040214C . It recovers the addresses of the API functions necessary for executing the Downloader code.
There is no point in citing the entire listing of the procedure - too bulky and of the same type. At the very beginning, the lines with the DLL names are decrypted, after which these DLLs are connected using LoadLibrary, and pointers to them are saved to the stack:

Next, using the received pointers and the decrypted names of the required APIs, using GetProcAddress, the addresses of the required APIs are found and stored in variables.

This is all the meaning of this procedure.
The only thing that can be considered in more detail is the procedure for decoding string variables.
An example of its use:

The insides of the procedure itself:

Decryption byte, key 16 bytes. If the string is more than 16 bytes, the key is repeated cyclically.

Cheat for user

Immediately after the restoration of the required API, the allocation of three 512 byte buffers. We will follow them.

Next, one of the buffers is used to save the path to the% Temp% directory obtained with GetTempPath. Take note ...
Slightly below, the resource name string is decrypted using the 0x00402F4F procedure parsed above, its offset is located and stored in the% Temp% directory, as an .cab archive. The archive name is randomly generated by the procedure 0x00401EE8 .
An example of creating a file:

Writing data from resources to a new file:

From the archive created in% Temp% .cab, the .rtf file is extracted with the file name, as in the case of the executable module, after which it is launched for display to the user:

Antiheuristics?

After unpacking and launching .rtf, we note a relatively pleasant discovery - this procedure:

The call is at offset 0x00401D04 .
At the very beginning, GetTickCount returns the number of milliseconds since the system was started, after which there is a cycle with Sleep and the second GetTickCount request. Further, the first is subtracted from the last result, and the resulting delta is compared with the constant 0x668A0 . We translate the constant to decimal, we get 420000, or 7 minutes. Why is the discovery pleasant? Yes, because after opening .rtf, you can simply complete the process within 7 minutes and forget about the CTB-Locker (although, probably, someone who suspects the process of suspicious actions and complete it will not even launch an unknown attachment). Perhaps this is a time-attack on the heuristics of some antiviruses.
For reversing, this is not a particularly pleasant moment, since I don’t really want to wait for 7 minutes every time I have to restart the process. Therefore, we change the constant for 1 second and forget about this timer, like this:

JPG download

Came to the fragment that loads from the network the .jpg mentioned at the very beginning. There is a loop that randomly selects a pointer to an encrypted string variable (URL), decrypts the procedure parsed above, passes the URL to the download procedure (we will not parse it, nothing interesting - the standard formation of a request to the web server), again encrypts the URL with the same procedure. After the described actions, the response from the web server is transmitted to the procedure 0x00402019 , at the very beginning of which, by the amount of received data, it is determined whether the file or an empty response was received from the server, after which it is decided to continue the search cycle of the URL or decrypt the received file.

The first request always goes to “sintjoep.nl/images/efax.jpg”, and the response from the server is not checked at all, and the cycle for searching the remaining URLs immediately begins. It is not clear why ...
How to calculate all the resources from which fake .jpg can load? After all, after each request, the URL is encrypted again, and if the download is successful, the loop from the resource search cycle occurs ... Minor manipulations with the code and BP at key points:

Here we are overwritten by the NOPs (No OPeration) of the URL reverse encryption procedure. Do not forget about the exit from the loop iteration. There, too, we will block the conditional transition after checking the response from the server, which will lead to an infinite loop:

As a result, this is what was achieved:

So, as the URL is randomly selected in the cycle, then the chance that the first time all the lines are decrypted is in order somehow not enough ... As you can see in the screenshot, one URL was not deciphered during rather long attempts at searching. "Korean random!" Nah, so not interesting ... There is the procedure 0x00401FF3 , which generates this random, but why listen to it? After all, you can immediately transfer to the required string and its size in the “hands” decoding procedure! (why it didn’t immediately come to mind ...)
Pointers to encrypted strings and their sizes were saved immediately after the process started, beyond EntryPoint (it was not clear then). Now, above, in the screenshot of the stack are visible pointers to the URL, and under each of them is the size of the string. So we look - the pointer to the remaining encrypted URL is at offset 0x00401708 , and the size of the string is 0x24 (36 bytes). We take into account that the size is specified for ASCII, and we have UNICODE, therefore we multiply by 2 and get 0x48 (72 bytes). We change the values ​​of the EDI registers (pointer to string) and ESI (string size in bytes) for the calculated values ​​and transfer control to the decryption procedure. We get a profit - all the resources from which this sample Downloader can load CTB-Locker:

All these are absolutely normal sites, pre-hacked to use them as a springboard for the spread of malware. These resources are valid only for this sample Downloader'a. Another copy of Trojan-Downloader.Win32.Cabby came into my hands. cfeu (according to KAV classification), there are other URLs in it. His activity was noticed a couple of days after catching and the appearance of signatures at first.
Someone will say that it is easier and faster to remove the track with a packet analyzer and analyze DNS queries - and it will be right. But the purpose of the article is not in simplicity, but in knowledge.

JPG decryption

So, got malicious .jpg:

Then we get into the decryption procedure. At the very beginning of the file, four bytes at offset 0x4 is the size of the encrypted data, which starts at offset 0x8 and will be decoded:

The decryption procedure itself is similar to the one that worked with strings — the same key, the same logic — so there is no sense in disassembling it. By the way, the 16 byte key itself: "CA 95 02 43 17 46 67 E4 FF 6E 8E D1 4E 7A BE 86".
After decryption we get the expected result:

Surprise

As it turned out, the received and decrypted .jpg is not just an executable file, but a container with executable files. As mentioned above, four bytes at offset 0x4 is the size of all data in the container. Next come the payloads, in front of each of which are four bytes - the size of the payload. In our case, the container was not only a CTB-Locker ...
After decryption, the offset of the first payload and its size is offset by the second, which is transferred to a fairly large procedure 0x00402AC9 . I will not describe it, because this can stretch out for another article. In essence, this is a self-written PE Loader, which projects the DLL from its decrypted container into its process and transfers control to the Grab_Psw function. As you can already guess from the name of the exported function, this DLL is nothing more than a Password Stealer, stealing credentials from various applications. The range of applications is quite wide.
Passwords go through HTTP POST in the same encrypted JPG. Here is an example:

At the time of analysis on all target resources, the host 3858850926.php has already been deleted. And then bad luck - the malware died in an endless cycle of searching for resources to send stolen credentials.
Hmm ... but this is not the end, the files were encrypted to users.
After each attempt, the response from the server is checked for the presence of the string “Confirmed” using the SHLWAPI.StrStrA API:

The conditional transition is performed on the result returned by SHLWAPI.StrStrA:

Well, let's make JNZ out of it:

Thereby they deceived the application, letting it know that the passwords were successfully sent - you can continue.

CTB-Locker

Immediately after the malware “sent” stolen credentials to the server, a transition occurs to the procedure 0x004028CC , which creates a new .exe file with a random name in the% Temp% directory. After that, it writes the first payload from the decrypted container (JPG, which was taken earlier), maintains timeout before launching, launches the created .exe, again maintains timeout and deletes the file.

The downloader process then terminates.
We get the file from% Temp% before launch for execution and send it to Virustotal. Expected Verdict:

Link to report .

Conclusion

General Downloader script:

1. Extracts from the .rtf resource section and opens it to deceive the user;
2. After 7 minutes, download the encrypted container under the guise of .jpg;
3. Decrypts the container and projects the DLL from it into its own memory using the self-written PE Loader;
4. Calls the “Grab_Psw” function from the DLL, which steals credentials from various applications;
5. Sends stolen credentials in an encrypted container disguised as a .jpg file to the Internet;
6. Extracts the CTB-Locker container received in section 2 to the% Temp% directory and launches it.

The analysis revealed that the CTB-Locker is not the only threat that this sample brings with it Trojan-Downloader.Win32.Cabby.cemx. Together with the cryptographer, the network leaks the credentials of a wide range of applications that the attackers do not warn anyone about, asking them to pay for the decryption of user data.