Tuesday, November 19, 2013

Screensaver Malware Like It's 2006

This content has moved to http://oalabs.openanalysis.net/2013/11/19/screensaver-malware-using-scr-executables/

Remember way back in 2006 when custom screen savers were the new hotness and everyone was googling "free screensavers" and getting infected with trojaned slideshows of majestic wildlife? Well it seems screensaver malware has been re-invented in a clever new way and is being used to infect victims as part of a large e-mail trojan distribution campaign.

If you are reading this there is a good chance that you are trying to figure out why you are staring at an efax attachment that contains a screensaver (.scr) file. In order to understand this we will need to dive into the internals of windows file associations.

Background - Windows File Associations

Windows uses the file extension (the part of the file after the last . ) to determine which program should be used to open the file. This is mapped in the HKEY_CLASSES_ROOT registry hive. In the hive there are a bunch of file extension keys.

The value of these keys maps to a second key in the same hive which describes which how the file should be opened (/shell/open/command).

In the case of a few special files instead of being opened by another program there is a %1 in the key value that indicates the file should be executed itself. As you can see screen savers (.scr) are one such file. This means that any time you double click an .scr file you are really just executing it or to put it in even simpler terms .scr is just another extension for an executable (.exe).

The Malware Threat

It seems an ongoing  e-mail trojan distribution campaign that had been using zipped .exe attachments has re-tooled and are now using zipped .scr attachments. The campaign seems to favour spoofing eFax emails with a spoofed address and a fairly decent replication of a real eFax e-mail.

Attached is a .zip file that contains the .scr file. As you can see on a default Windows7 system the file extensions are not visible and thanks to a pdf icon in the .scr file it does a good job of mimicking a real eFax PDF.

If we take a close look at the efax .scr file we can see that it is really nothing more than an executable with a pdf icon.

As we can see VirusTotal definitely identifies the .scr as a malicious file and malwr has a decent profile of its malicious behaviour


So, why go to all the trouble of renaming the .exe malware to .scr? At first I suspected that this was part of the social engineering aspect of the e-mail; an attempt to make the file less suspicious to the victim. This may indeed be part of the reason for the renaming but, as noted above, file extensions are not visible on a default Windows7 install so most users will never see the extension. Instead I suspect the more plausible explanation for the rename is to avoid e-mail filter detection (and possibly some network antivirus detection). Some older/lower end/poorly configure IPS/IDS and e-mail filtering technology does not examine the full file contents and only uses the file extension to determine if an attachment is suspicious or not. This is especially true of zipped files given the overhead/bandwidth required to unzip and then inspect files.

Whatever the reason, if you have IPS/IDS or e-mail filters that are just using file extensions in zip files to evaluate threats you will want to add .scr to the list of suspicious files. In fact I used a little powershell magic to search the HKEY_CLASSES_ROOT registry hive for all file extensions that are treated like executable files.
HKEY_CLASSES_ROOT\.bat = batfile
HKEY_CLASSES_ROOT\batfile\shell\open\command = "%1" %*
HKEY_CLASSES_ROOT\.cmd = cmdfile
HKEY_CLASSES_ROOT\cmdfile\shell\open\command = "%1" %*
HKEY_CLASSES_ROOT\.com = comfile
HKEY_CLASSES_ROOT\comfile\shell\open\command = "%1" %*
HKEY_CLASSES_ROOT\.exe = exefile
HKEY_CLASSES_ROOT\exefile\shell\open\command = "%1" %*
HKEY_CLASSES_ROOT\.pif = piffile
HKEY_CLASSES_ROOT\piffile\shell\open\command = "%1" %*
HKEY_CLASSES_ROOT\.scr = scrfile
HKEY_CLASSES_ROOT\scrfile\shell\open\command = "%1" /S
Based on these results you should be detecting .bat .cmd .com .exe .pif and .scr files in .zip e-mail attachments as potentially malicious. In fact, if we look though the most recent efax submission to malwr.com it looks like another file extension .pif is already been used by the malware campaign.


Wednesday, October 2, 2013

Sweet Orange - Update

This content has moved to http://oalabs.openanalysis.net/2013/10/01/sweet-orange-exploit-kit-2013/

After 48h of monitoring the Sweet Orange EK noted in our previous post some of the indicators have changed. Now that we know what changes and what doesn't we can refactor our previous indicators and make them more robust.

We now know the refresh rate for the domain generation and url parameter changes. The EK changes url parameters every minute while the domain is changed ever 6 minutes.

What Has Changed

The strings used to obfuscate the applet parameters have been changed and the applet has been recompiled to adapt the decryption/de-obfuscation algorithm.


The port that the malware host is using has changed so the URL regex indicators need to change.


The IP address is now fluctuating within the same (AS12695) the IPs seen include

What Has Stayed The Same

The exploits and the general frame of the exploit landing page have stayed the same.

No-ip dynamic DNS is still being used with the domain "sytes.net".

The binary exploit remains the same, it has been repacked but I wrote a terrible python script that is able to identify it based on a unique pattern of strings in the binary.

You can download the bin checker script here.

Once I get some free time I'll post about the second Java exploit and reverse the payload.

Tuesday, October 1, 2013

Sweet Orange In Action

This content has moved to http://oalabs.openanalysis.net/2013/10/01/sweet-orange-exploit-kit-2013/

In this write up we will examine an operational Sweet Orange Exploit Kit. The focus will be on the exploits delivered and the behaviour of the exploit kit.

The Drive-By

The Sweet Orange kit that we will be examining was using an iframe injected into a compromised website to load the exploit landing page. We can see that the iframe has clearly been injected as it sits above the <!DOCTYPE> tag.

The Exploit Kit Landing Page

The iframe loads the exploit kit landing page which contains some fairly simple obfuscated javascript and a Java applet. The landing page doesn't use any browser/plugin profiling to tailor it's exploits, but the server does use the user agent string to filter out un-exploitable os/browser combinations. If the server deems you un-exploitable you get a nice 404 error (this may also be used to avoid detection).

Once we de-obfuscate the javascript we can see that it's written a Java JNLP applet tag to the document. The JNLP applet tag includes a BASE64 encoded JNLP file in the "value" parameter (see ref. here). There is also another applet on the page that does not use JNLP. This writeup will focus on the JNLP applet as it targets victims who are running Java 1.7 while the second applet targets Java 1.6.

Once we decode the BASE64 JNLP file we can see just what this exploit kit is up to. We can see the parameter "__applet_ssv_validated" has been set to "true" which is a Java security warning (Click2Play) bypass released on April 24, 2013 (see ref. here).

Inside the Exploit

With the Java security warning safely circumvented the exploit kit is free to run the applet. Let's take a closer look at the applet JAR file "CNOeJXH.jar". We can see there are a few classes in the JAR and a file called "wgSqXvtqE.mp4". Spoiler alert: we find out later that the mp4 file is just a cleverly obfuscated class file.

Let's start by decompiling the main class "piXDw.class" and go from there. Once we decompile the class files we can see that they are obfuscated. At first these look pretty difficult to decipher but upon closer inspection we can see there is just some junk code added (all of the Math.ulp assignments are junk) and there is some string manipulation. To illustrate I've included a snip of some obfuscated code before de-obfuscation.

After we de-obfuscate we can see the init() for the applet simply checks to see if the victim is running Java 1.7+ then calls a method "wnYoY(piXDw pixdw, Class aclass[])" from "GVep.class". Lets investigate further.

Taking a look at "GVep.class" we can see that it reads in the mp4 file, de-obfuscates it, then transformed it into a binary file and loads it. We will get to just what is inside the mp4 file in a minute but for now we have spotted the exploit that is being used: CVE-2013-2460.

Well this is interesting, let's take a look at the "wgSqXvtqE.mp4" file and see if we can't extract the class. At first we see we will need to de-obfuscate the ascii by removing "------------|||||||||||||||||||||||||||||||||||||".

And now we are left with what appears to be an ascii representation of the hex bytes of a class file.

We can use some python to quickly convert this into binary and decompile into it's original java.

Judging by the similarity of the exploit structure to other examples of "Sweet Orange" we can assume that this is some variation of the Sweet Orange exploit kit. An excellent writeup on the the kit can be found here

Now that we have confirm that this is indeed CVE-2013-2460 what happens after the security manager is disabled? We can see that there is one line of code after the security manger has been disabled, let's start there. 

If we work backwards we can see that "String as[]" contains the applet params.

Let's decrypt these parameters and see what we have (you can download a copy of my terrible python script here).

ParamDecrypted Value

If we follow this example all the way through we can see that the malware constructs a url request like so in order to download the binary payload (the count.exe parameter number is randomly generated) . 

After some manual testing it was confirmed that the "count.exe" parameter is not required to obtain the payload. 


Before we move on to behavioural analysis we will recap what we have learned so far:

Behaviour and Indicators

The exploit kit uses dynamic DNS provided by http://www.noip.com under the domain "sytes.net". The kit uses a subdomain generation algorithm to generate a new subdomain every few minutes. Old subdomains are unregistered making research a bit more difficult. After tracking the subdomain generation for 24h it is confirmed that all subdomains that have been used resolve to this IP: (AS12695), not a big surprise. 

A list of identified domains can be found below.

The url pattern for landing page:

The url pattern for the payload binary is:

The payload is also re-generated every few minutes. It is UPX packed and has a low VT hit rate (about 5/46 for each new generation). Once I have some more time I will take a closer look.

File MD5Virus Total
50e073712917e5cc1c53005dc377bdb0 virustotal

Zip of some payloads can be found here.


Updated indicators and analysis can be found here.