Agent Tesla: Reversing combat malware in Ghidra

Today you will learn how to:

• unpack NSIS installers and analyze extracted installation scripts;
• search for the main function wrapped in CRT (you’ll be surprised how much code the compiler implicitly pushes into an .exe);
• decrypt shellcode, dump it, and search for it by the memory allocation function; and 
• correctly load the retrieved shellcode to your disassembler.

Normally, I use IDA Pro for reversal, but this time, I’m going to depart from this tradition and employ open-source Ghidra. It was released several years ago; it boasts an impressive list of bug fixes and new features; and it’s free and continuously updated.

Preparations

At the preliminary reconnaissance stage, the sample is loaded to the Detect It Easy (DiE) file identification tool. As you can see, the malware is distributed as an NSIS installer.

After extracting the installer contents, you get several files. Note that the unpacked files must include an NSIS script containing valuable information. An outdated version of 7-Zip can be used for unpacking (only versions 4.42-15.06 support the script extraction function).

In this part of the script, you can see the list of files contained in the installer and startup parameters of the only .exe file (this info will be used a bit later). Other script data include the installation path InstallDir $TEMP. Now let’s examine the PE file in DiE.

As you can see, the file is written in C/C++, compiled for 32-bit systems, and not packed (based on its’ not-so-high entropy). Let’s load it to Ghidra.

Reversal

Functions listed in the import table include VirtualAlloc. This function is of special interest because malicious programs often use it to allocate memory for unpacked data. After restoring the cross-reference, you can see what function is used to call it.

Of course, one could try the ‘fast’ way: load the malware to the debugger, set a breakpoint on VirtualAlloc and… get nothing, because Agent Tesla will terminate before this breakpoint. Therefore, I always recommend to examine interesting calls, as well as pieces of code adjacent, to them in the static setting first.

The function isn’t large; almost all its component are of interest; and I provide its full listing in the Ghidra decompiler:

The first thing that immediately attracts attention is the piece of code containing simple anti-debugging protection:

This is a popular anti-debugging trick that checks the code execution speed. If the code is executed too slowly (GetTickCount is called twice, and the execution time is measured in milliseconds), the BVar3 variable is set to 0, and the program terminates.

The next interesting piece of code opens a file; if it fails to do this, the program also terminates. This is another proof that the code must be examined in the static setting first, and only then in a debugger. So, why does the executable file terminate before the breakpoint? Let’s see what kind of file the program expects:

Defining the main function

No doubt, the param_3 argument that passes the path to the file to CreateFileA is of special significance. This argument extends beyond this function, and there is a single cross-reference to it, which takes you to the code listed below. Note the 10 ‘interesting’ functions that can be used to indirectly determine where you are!

In this code, I have already defined the FUN_00401300 function as main – but how do I know that? If you looks at the code closely, you’ll see that the name of the function calling main is __cdecl __scrt_common_main_seh(void). In other words, this function is the beginning of CRT runtime. It configures the required settings (including SEH, as its name suggests) and then loads the main function whose prototype is main(int argc, const char **argv, const char **envp) (i.e. it expects three arguments). Next, since the application under investigation is 32-bit, the calling code should look something like this:

In the decompiled listing, you can see the following code (the OpenFileArg argument has already been named):

Arguments are retrieved by calling the __get_narrow_winmain_command_line() function; in addition, the ___scrt_get_show_window_mode() method is called: it indicates whether to show the application window or not. You can also see the CRT initialization and uninitialization functions: ___scrt_initialize_crt and ___scrt_uninitialize_crt. Overall, it becomes clear that this is the CRT wrapper for the main function, and, using the steps described above, you can determine the entry point to main.

Decrypting shellcode

So, it can be concluded that the param_3 parameter is nothing else but a path passed as a command line argument. Remember a line starting with ExecWait in the installer script? It indicates that the one of the installer files, namely pgkayd.aq, is passed as an argument. Let’s continue examining the main function:

This code contains plenty of interesting stuff: a VirtualAlloc call used to get there, a decryption loop that applies XOR with a key to the encrypted data, and a (*_Dst)(); call that executes the decrypted code. I added detailed comments to the listing so that its logic is clear.

So, the decryption functions and logic have been localized, now let’s examine Agent Tesla in dynamics! The x86dbg debugger can be used to extract the decrypted shellcode as a separate file.

Extracting shellcode as a separate file

To extract the decrypted shellcode, the file has to be executed in a debugger. As you remember from the NSIS script file, the pgkayd.aq file has to be passed as an argument to the executable to ensure its correct execution. This can be set up using the x86dbg interface.

Let’s set a breakpoint on VirtualAlloc and run Agent Tesla. This allows to skip anti-debugging and argument checking that could prevent the program from running normally (because the argument has been set in the previous step) and pause the execution at VirtualAlloc. Then the execution should be continued up to ret, thus, terminating the function. The following picture can be observed: the address of memory allocated by VirtualAlloc (which is displayed in the dump window) is stored in EAX. You know that the decryption operation will be perfrormed in this buffer; accordingly, you have to set an access breakpoint at the beginning of the buffer and wait for the data to appear there. The encrypted code will be copied to the buffer, and you’ll see it in the dump window.

Taking the information collected during static analysis, you know that encrypted data are copied to the buffer and then decrypted. If you set a breakpoint immediately after the decryption loop, you’ll see how the data in the buffer have changed. To make sure that this is meaningful code, you have to disassemble these data manually (the Follow in Disassembler option in x86dbg).

As can be seen in the screenshot, the shellcode is completely decrypted and ready to be executed. Now it has to be saved to a separate file for subsequent analysis. Select the Follow in Memory Map option in the dump context menu to switch to the memory map.

Next, click Dump Memory to File in the context menu to save the allocated memory. Note the rights of this memory area: ERW (same as RWX), which indicates that the memory is ready to be executed (a red flag for any antivirus!). The dump saved in the form of a file can be loaded to Ghidra for further research. Important: you have to manually set the analysis parameters in the disassembler.

Since the original file was 32-bit and built in Visual Studio, the same parameters should be set for the shellcode.

Conclusions