At the beginning of February, we received a strange business proposal by email. The email seemed authentic, so did the attachment, until we noticed something was wrong.
Despite the Adobe Acrobat icon, the attachment of the email is an application, and not a pdf!
This article aims to explain to process behind the analysis of the malware that we received and expose as much information as possible concerning the origin and behavior of the said malware.
Malware PE MD5: 16662E1CF0020E864754943F15419A35
Malware PE SHA1: 967135B63DD1C7DB8DE7491631FC41FABA06E9ED
This article will be divided in two parts, a static analysis and a dynamic analysis of the malware.
The first part of this analysis will be dedicated to the static analysis of the malware. This analysis aims to gather as much information as possible from the malware, without executing it.
At first glance, string doesn’t reveal much information about the application aside the fact that it might be a Microsoft C# / Basic .Net application. We assume it by looking at the strings inside the executable.
Function indicating that it might be C#
After performing the analysis of the portable executable file, we found some interesting information about the application:
The portable executable file information confirms us that we are dealing with Microsoft C# / Basic .Net.
We now begin the reversing of the application. Since it is a Microsoft C# / Basic .Net application, we need to use the appropriate decompiler.
As one would assume, the application is obfuscated. The obfuscation of the code in the application makes the reverse process more time consuming and complicated.
Obfuscated functions in Gthrothrow.exe
Let’s take a look at the main function.
Main function of Gthrothrow
After analyzing the it, we notice that the application uses multiple other obfuscating and cipher functions to hide its content. As we see in the main function for example, it gets an object from the ressources section, by calling the ooXT() function (which is a XOR cipher utilizing a 32 bit key) to get the objects name from the hexadecimal array. Then, it uses the aDMvQp() and ApSc() to initialize the IDxVKczYU variable. The aDMvQp() function is a Rijndael cipher (AES), called to decipher the object. The ApSc() function reverses the array.
We now know that the malware is packed. The real malware payload is deciphered at runtime.
At this point, we decide to start the dynamic analysis.
The dynamic analysis will be divided in two parts.
First, the offline analysis, where we will try to understand what the malware does when it is executed on the machine. Once we know what the application is up to, we connect it via a private network to another virtual machine, to simulate an internet connection. This method will help us capture any request that the malware tries to do and help us furthermore to understand its purpose. Of course, the requests never reach their target, both virtual machines are confined in a secured private network.
We start the analysis by running the application just to see how it behaves. We notice that the application creates multiples processes during execution (up to four).
Execution of Gthrothrow.exe
The execution takes about six to seven seconds, then the malware totally shuts off.
For a deeper analysis of what the malware does during execution, we monitor the execution of the malware and log every interaction the malware has with the system.
One of the first things that the malware does is create the new process.
This child process scans the file system.
PID 2540 scanning the filesystem
After the scan, the malware creates a temporary file and start looking for information on the computer. Later on, we see the malware writing in this temporary file.
Password stealing and creation of temporary file
The temporary file must be the file it uses to write all the information it steals from the computer. As shown in the image below, the malware looks for password information. Even if Google Chrome or Opera are not installed, the malware scans the directories looking for personal information (login data, keychains, etc.).
Reading personal information /Writing to file
It does the same for Internet explorer and Mozilla Firefox.
Reading personal information IE/Firefox
Scanning for oeaccounts
We also notice that the malware scans the file system looking for .oeaccount files. These files store account data such as email address, server address, connection information, password, etc. This information is used in by the Windows Mail application.
With all the information we already gathered, we get a glance of the bigger picture. The malware is some kind of password and information stealer.
The questions remaining now are: What does the malware do with this information? Where is the information sent to? And after that, does the malware stop there or does it try to download another payload to continue execution and maybe install itself to be executed at startup?
Looking back at the first process creation, we notice that the command line used to launch the new scanning process is called with an argument.
Gthrothrow.exe command line
The argument seems to be the path to a temporary file. This file must be used to store information.
Now that we know that the malware can be called with an argument, out of curiosity we decide to execute the malware with a random argument. Surprisingly, the malware executes the scan as it is supposed to do, but doesn’t closes at the end. We take advantage of this to dump the memory of the process, hopping that interesting information will be in clear text, since the malware might have decrypted its payload, as it is currently executing.
Since the malware takes so long to execute when launched normally and stays visible the whole time during execution, we also manage to dump its process memory too.
After dumping the memory, we start looking for clear text strings that could lead us to some king of Command and Control host, or any lead regarding of its methods of communication with the internet.
Cleartext hostnames in memory dumps
We might have a lead about where the information is sent to. At this point we decide that we should start the online analysis in order to see where this lead gets us.
It is of course out of the question to let the malware communicate with the internet for now. We need to simulate an internet connection.
In order to do that, we set up our sandbox in a private network. This private network contains another virtual machine running Linux, that will reply to all the requests the malware does, as if the sandbox was connected to the internet. After setting the default gateway of our sandbox to the Linux server and starting a packet analyzer on the sandbox, we are good to go.
DNS request captured
Wireshark captured frame
Success. We have captured the request. Our intuition was a good one; the malware does try to communicate with the host we found in the dump file.
The complete URL requested is:
This request contains valuable information. We can formulate some hypothesis based on what we just found:
After some quick research of the “ISI-AGU-TEAM”, we find other URL containing the exact same tag, and the website appear to be WordPress sites also.
Example of another infected URL
This points out to a massive WordPress infection campaign.
When doing some research on the User-Agent, we were able to find out that this type of attack had already been documented in the past. Although the User-Agent is the same, it appears to be another kind of campaign since the infection vector is not the same and the information stolen differs too.
We decided to also take a look at the “index.php” page. The file hosted by the server seems to have two purposes.
Information stolen POST form
The first one is to execute de POST request, if called with the correct parameters in the URL. This allows the malware to store the data it stole (see screenshot above).
Search form and authentication
The second part is an authentication form and a search form. The search form must be used to search through the data gathered by the multiple instances of the malware.
To conclude, the application we received via email turns out to be an information and a password stealing malware. The malware first executes, gathers all the information and send it to one of the compromised website (hellomedia.ng in our version). We assume that the data can then be retrieved and managed by login in the index.php page.
By the information we got from the signature of the malware and the User-Agent of the request we assume that this malware is part of a big information and password stealing campaign, since similar attacks with the same kind of signatures can be found on the internet.
The malware doesn’t seem to use extremely advanced stealth techniques. The fact that the URLs used tend to always contain the pattern /ISI=AGU=TEAM/ should be considered as a design fault. One of the points of this kind of attack is to be unpredictable. Same goes for the for the User-Agent, that is always the same. It makes the network monitoring for this kind of infections easier.
As it seems to be some kind of big malware campaign, here are some advices on what you can do to prevent this infection and the information theft:
When we received the malware, it was not yet detected by most antiviruses (4 out of 54 on virustotal.com). At the time we finished writing this article the malware had a score of 31 out of 54 on virustotal.com.