Malware for Brazil hosted in Mexico

A few days ago, a link that was possibly distributing malware was reported to UNAM-CERT. The site was hosted in Mexico.

At first sight, the name of the file gives away some information about the type of the attack:

 Modulo_Santader0943.exe

Virus Total reports that the sample is possibly packed with PECompact2, which gave us an idea of what to expect later, during the analysis.

After copying the executable file on the Desktop, the icon looked like a tool of the Santander Bank.

Any combination of numbers allowed us to go to the next screen; therefore, it was clear that the fake application was not validating the typed data on this first step.

The second screen requested more information. So far, the application had not sent any data over the Internet, most likely because it was saving all the information to be sent later, in one submission.

Later on, it showed a third screen requesting an identification number.

We tried using different keys, but none of them allowed us to continue with the process. We wanted to confirm our assumptions that, once the user had given all the necessary information, the application would send it to a remote site. Thus, we needed to analyze the strings and debug the application to find the remote site that stored the stolen data.

When a sample is packed, the packing algorithm usually modifies the OEP (Original Entry Point), which is where the execution begins. With this modification, it is possible to inject code to the executable to encrypt or compress it. The execution of the file will now start at the beginning of the packing algorithm and the original file will be executed after it.

As a result, we had to find the original entry point after the unpacking process; to do this we used OllyDbg.

The first thing we got, after we opened the file with Olly, was a message warning us that the a section of the file was probably compressed or encrypted.

Packing algorithms usually jump to certain memory addresses using exceptions; this is done to make sure that they will read the code sections that contain the decrypting or decompressing subroutine. In many instances, when the FS register is used, the Structured Exception Handler is called.

When the packing algorithm has unpacked the original file, it allocates somewhere in memory and to find it, we need to get to the OEP. Most packers store the OEP in the EAX register, most likely because this register is used to store the return value of the subroutines. The first step is to find a CALL EAX or JMP EAX instruction.

A possible OEP was located at the 00401000, 00401006 and 0040100D addresses, where the handler exception, that forced the program to jump to a new instruction, was located.

The exception takes place right after the instruction at 00401006. We set some breakpoints in the memory dump section to try to catch the instruction right after the exception.

After a while, we finally got the jump to OEP, at memory address 0064C2B2 (JMP EAX, where EAX points to the entry point of the original malicious file). The OEP is in memory address 0055A804.