Video Screencast Help
Security Response

The Layers of Trojan.Ransompage

Created: 05 Aug 2009 21:29:40 GMT • Updated: 23 Jan 2014 18:33:38 GMT
Fred Gutierrez's picture
+2 2 Votes
Login to vote

Trojan.Ransompage is interesting because it is the first ransom threat that is designed to target three different browser platforms. Not only has the malware author chosen to target the two most popular browsers in Firefox and Internet Explorer, but Opera is also a target. This shows that the malware author wanted to target more than one browser in order to maximize the chances of success in case an infected user decided to change browsers rather than pay the ransom.

To attack Internet Explorer users the Trojan will drop a file called msmedia.dll and install it as a browser helper object (BHO). To target Firefox users the Trojan will install an extension called “informer” that consists of the following files: install.rdf, chrome.manifest, informer.xul, and informer.js. With Opera, the Trojan will drop a file called feeder.js that also acts as an extension and is written in JavaScript. These three different payloads all have the same functionality. They will install the banner we saw in the previous blog posting on this topic in the bottom right of each browser, shown below.

imagebrowser image

Curiously the malware author decided to use a scripting language instead of a regular executable. Most of the time, we see payloads being delivered by an executable file. However in this case, the payload came in the form of a .wsf file. According to Microsoft:

A Windows script (*.wsf) file is a text document containing Extensible Markup Language (XML) code. It incorporates several features that offer you increased scripting flexibility. Because Windows script files are not engine-specific, they can contain script from any Windows Script compatible scripting engine. They act as a container.

In this case the malware author chose to use obfuscated JavaScript within the .wsf document. In order to fully analyze the Trojan we will need to de-obfuscate the JavaScript and analyze the resulting code. In this particular threat the author uses numerous different obfuscation, encoding, and ”encryption” techniques that I will discuss here.

Layer 1: De-obfuscating the JavaScript
Layer 2: Understanding the main payload
Layer 3: Figure out what is happening to Internet Explorer, Firefox, and Opera

Layer 1

In layer one, the first thing that needs to be done is to de-obfuscate the JavaScript. Let’s take a look at what we have to work with:

imagebrowser image
As you can see, some work has to be done in order to find out what the Trojan is trying to do. After stripping out the unnecessary elements (the xml wrapper) and simply formatting the code, the script becomes a bit more readable:

imagebrowser image
While this may seem confusing, taking a closer look at the code actually reveals that the malware author threw in several dummy loops and randomly named variables to deter further analysis. These instances are shown inside the red boxes. For example, the first condition in the top red box shows a statement of “IF ( 0 > 1 ) …” This will never be true; therefore, anything inside that grouping will never run. The same goes for the following “while” loop. In fact, the only instructions that are actually successfully run in that portion of the script are the instructions building the aiSUfXq6Rpq2e8m string, shown with the green arrows.

After removing the dummy loops and renaming the variables to something more understandable we arrive at the following code:

imagebrowser image

As can be seen from the formatted code above, there is a layer of encryption to go through. The important line from the decryption routine above is:

decrypting[i] = String[strFromCharCod]('0x'+encrypted_payload[strSubstr](i*2, 2)^key[strCharCodeAt](j));

This shows that the payload is xor’d with the key. Of course, for the threat to run it must be able to decrypt itself, so we will just wait until the payload has been decrypted and then output the decrypted code to the screen. We can do this by calling alert(decrypted_payload); on line 25 above.

Inspecting the decrypted payload shows another script. This second script reveals more of the purpose of this malware:

imagebrowser image
We can see that the script will call three functions (highlighted in the red box above): install_ie(), install_op(), and install_ff().

Layer 2

Looking at the decrypted script from layer one, we can see that the install functions create some registry keys and drop some files. With this script we can get an overview of what the malware author is doing—and how. Registry modifications are not encoded at this layer so we can see that the script is trying to install a BHO for Internet Explorer, an extension for Firefox, and some user-created JavaScript for Opera. However, to uncover the actions taken by the Firefox extension or the user-created JavaScript for Opera, we need to perform some more analysis. In this case we will look at the script dropped for Opera:

imagebrowser image

The Opera script is encoded with hex characters. A hex editor can be used to convert the code above to readable ASCII characters. Once this conversion has taken place, the code below will be revealed and can be analyzed further:

imagebrowser image
Again, the malware author has taken efforts to hide is being attempted with this code. This will be investigated in Layer 3. The components for Firefox and Internet Explorer were encoded in a similar way and can be decoded in the same manner.

Layer 3

You may recall that in the beginning, the malware used dummy loops and randomly named variables. In this case, a text editor that supports code coloring shows that the script is using comment lines to hide the payload (the comments are shown in green in the previous screenshot). Nothing a little regular expression magic can’t fix. After removing the comments, formatting the code, and renaming the random variables, the code is again more readable.

imagebrowser image
The decryption routine is much like the first decryption routine that was used back in Layer 1, so we can decrypt it using the same technique as described before. The resulting decrypted code shows the true intentions of the code:

imagebrowser image
The malware author uses a mix of CSS, the <div> tag, as well as an iframe injection to display the malicious banner on the browser. This is the origin of the Russian banner we saw in the beginning. The same tricks are used to infect Firefox. For Internet Explorer, the malware author drops a DLL file called msmedia.dll, which is installed as a BHO. This malicious BHO is then used by Internet Explorer to display the banner.

The malware author has taken several steps to hide the payload. However, with a little patience we are able to understand exactly how the threat operates. In fact, the threat uses cookies to determine whether to show the ad or not. It sets a cookie named “_imac” and changes its value to “JFYDEKR47HE” when it chooses to stop displaying the ad. The malware also expires after 30 days. This means that if users set their system clocks ahead 30 days the ad will disappear. In addition, Internet Explorer users can manually remove the browser helper object (instructions can be found in several different places). Firefox users can disable the extension called “Informer” to stop displaying the ad as well. In any browser, blocking the domain will also result in not displaying the ad. We have added detection for this strain as Trojan.Ransompage.