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:



At the time of the analysis, the sample already had a considerable amount of time propagating itself; however, only 26 out of 43 antivirus engines detected it as malicious, according to the Virus Total report


The sample’s signatures can be seen on the image below:


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.


At the beginning of our analysis, PEiD showed the same information as VT, indicating that the algorithm used to pack the sample was PECompact2.x


Because the executable was packed, we were unable to check the strings with BinText , the software that we normally use in Windows to get the strings in a file. When attempting to open the file with it, BinText returned a warning message saying there had been a problem with the reading of the file due to a non-standard format or compression.


Using the “strings” command in linux, we got this information:

The dynamic analysis of the file did not show modifications on the registry keys, no files were created nor deleted and there was no network traffic. It just started a process and opened a fake application of the Santander Bank in Brazil.

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.


At this point, we dump the memory and saved it in a file to get the malicious software without packing protection. We analyzed the executable again using PEiD and, as expected, it no longer detected a packer.


On the Internet, there are some scripts for OllyDbg available and they can be used to find the OEP in packed samples. We found one specifically for PECompact 2.xx, written by hacnho in 2004.


The script is loaded with OllyScript and the OEP is found right away, much faster than when we did it manually.


With the sample unpacked, we looked for clues about the address used to send the stolen data. An analysis of the strings gave us the website.


As we mentioned at the beginning, the file had been known for a while and by the time we analyze it, the website was already down.