Malware Analysis – GTHROTROW.EXE

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.


Email attachment

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.
Testing Lab:

  • Hypervisor: Virtual Box
  • Sandbox: Windows 7 SP1 Enterprise 32 bits

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.


Static analysis
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.

strings ori

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 original name of the executable was: Gthrothrow.exe
  • Application type: 32 bits
  • Signature: Microsoft Visual C# / Basic .Net
  • A timestamp in the file header: Tue Feb 02 22:41:05 2016
  • A path to the debug symbol file: C:\users\user\appdata\local\tmp\snntdwetuv\gthrothow.pdb
  • The checksum of the file is 0x00, which is invalid
  • An imported library: mscoree.dll
  • The application is not signed

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.


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.


Offline analysis
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.

Process 1 thred creation

Thread creation

This child process scans the file system.

P1 search

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 manager

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.).

personal info

Reading personal information /Writing to file

It does the same for Internet explorer and Mozilla Firefox.

Mozilla information

Reading personal information IE/Firefox

Windows Mail

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.


Online analysis

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 logs

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:

  • The target site in a WordPress website. The fact that the “index.php” file is stored in the “/wp-includes/images/smilies subfolder” which is unusual. It indicates that the WordPress website might have been compromised ;
  • The “ISI=AGU=TEAM” seems to be some kind of team signature ;
  • The User-Agent “HardCore Software For : Public” might give us further information about the team that developed the malware ;
  • Finally, the URL seems to be used to keep track of the infection (?action=add).

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 ( 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:

  • Never open attachment files that you received from an untrusted email. Even then, always question the legitimacy of the attachment. Perform some simple checks like checking the extension of the file and if you have any doubts, try scanning the file on
  • Since the URL doesn’t seem to be randomly generated, prevent network traffic to URL containing the signature /ISI=AGU=TEAM/
  • If you can, it would be a good idea to check for suspicious User-Agents like “HardCore Software For : Public”

When we received the malware, it was not yet detected by most antiviruses (4 out of 54 on At the time we finished writing this article the malware had a score of 31 out of 54 on

Leave a Reply

Your email address will not be published. Required fields are marked *

Time limit is exhausted. Please reload the CAPTCHA.