Red October – Java Exploit Delivery Vector Analysis

Since the publication of our report, our colleagues from Seculert have discovered and posted a blog about the usage of another delivery vector in the Red October attacks (http://blog.seculert.com/2013/01/operation-red-october-java-angle.html).

In addition to Office documents (CVE-2009-3129, CVE-2010-3333, CVE-2012-0158), it appears that the attackers also infiltrated victim network(s) via Java exploitation (MD5: 35f1572eb7759cb7a66ca459c093e8a1 – ‘NewsFinder.jar’), known as the ‘Rhino’ exploit (CVE-2011-3544).

We know the early February 2012 timeframe that they would have used this technique, and this exploit use is consistent with their approach in that it’s not 0-day. Most likely, a link to the site was emailed to potential victims, and the victim systems were running an outdated version of Java.

However, it seems that this vector was not heavily used by the group. When we downloaded the php responsible for serving the ‘.jar’ malcode archive, the line of code delivering the java exploit was commented out. Also, the related links, java, and the executable payload are proving difficult to track down to this point.

The domain involved in the attack is presented only once in a public sandbox at malwr.com (http://malwr.com/analysis/c3b0d1403ba35c3aba8f4529f43fb300/), and only on February 14th, the very same day that they registered the domain hotinfonews.com:

 

Following that quick public disclosure, related MD5s and links do not show up in public or private repositories, unlike the many other Red October components.

We could speculate that the group successfully delivered their malware payload to the appropriate target(s) for a few days, then didn’t need the effort any longer. Which may also tell us that this group, which meticulously adapted and developed their infiltration and collection toolset to their victims’ environment, had a need to shift to Java from their usual spearphishing techniques in early February 2012. And then they went back to their spear phishing.

Also of note, there was a log recording three separate victim systems behind an IP address in the US, each connecting with a governmental economic research institute in the Middle East.
So, this Java Rhino exploit appears to be of limited use. And, the functionality embedded on the server side PHP script that delivers this file is very different from the common and related functionality that we see in the backdoors used throughout the five year campaign.

The crypto routines maintained and delivered within the exploit itself are configured such that the key used to decrypt the URL strings within the exploit is delivered within the Java applet itself. Here is our PHP encryption routine to encrypt the Url for the downloader content:

And this is the function to embed the applet in the HTML, passing the encrypted URL string through parameter ‘p’:

Here is the code within the applet that consumes the encrypted strings and uses it. The resulting functionality downloads the file from the URL and writes it to ‘javaln.exe’. Notice that the strb and stra variables maintain the same strings as the $files and $charset variables in the php script:

 

This “transfer” decryption routine returns a URL that is concatenated with the other variables, resulting in “hXXp://www.hotinfonews.com/news/dailynews2.php?id=&t=win”. It is this content that is written to disk and executed on the victim’s machine. A description of that downloader follows. It is most interesting that this exploit/php combination’s encryption routine is different from the obfuscation commonly used throughout Red October modules. It further suggests that potentially this limited use package was developed separately from the rest for a specific target.

2nd stage of the attack: EXE, downloader

The second stage of the attack is downloaded from “http://www.hotinfonews.com/news/dailynews2.php” and executed by the payload of the Java exploit. It acts as a downloader for the next stage of the attack.

Known file location: %TEMP%javaln.exe
MD5: c3b0d1403ba35c3aba8f4529f43fb300

The file is a PE EXE file, compiled with Microsoft Visual Studio 2008 on 2012.02.06. The file is protected by an obfuscation layer, the same as used in many Red October modules.

Obfuscation layer disassembled

The module creates a mutex named “MtxJavaUpdateSln” and exits if it already exists.
After that, it sleeps for 79 seconds and then creates one of the following registry values to be loaded automatically on startup:
[HKEY_LOCAL_MACHINESOFTWAREMicrosoftWindowsCurrentVersionRun] JavaUpdateSln=%full path to own executable%

[HKEY_CURRENT_USERSOFTWAREMicrosoftWindowsCurrentVersionRun] JavaUpdateSln=%full path to own executable%

Then, after a 49 second delay, it enters an infinite loop waiting for a working Internet connection. Every 67 seconds it sends a HTTP POST request to the following sites:

• www.microsoft.com
• update.microsoft.com
• www.google.com

Once a valid connection is established, it continues to its main loop.

C&C server connection loop

Every 180 seconds the module sends a HTTP POST request to its C&C server.
The request is sent to a hardcoded URL: www.dailyinfonews.net/reportdatas.php

The contents of the post request follow the following format:

id=%unique user ID, retrieved from the overlay of the file%&
A=%integer, indicates whether the autorun registry key was written%&
B=%0 or 1, indicates if user has administrative rights%&
C=%integer, level of privilege assigned to the current user%

HTTP POST request sent to the C&C server

The module decrypts the C&C response with AMPRNG algorithm using a hardcoded key. Then, it checks if there is a valid EXE signature (“MZ”) at offset 37 in the decrypted buffer. If the signature is present, it writes the EXE file to “%TEMP%nvsvc%p%p.exe” (%p depends on system time) and executes it.

3rd stage of the attack: EXE, unknown

Currently, the C&C server is unavailable and we do not have the executables that were served to the “javaln.exe” downloader. Most likely, they were the actual droppers, similar to the ones used with Word and Excel exploits.

Conclusions

As more information about the Red October becomes available and third parties are publishing their own research into the attacks, it becomes clear that the scope of the operation is bigger than originally thought.

In addition to the Java exploit presented here, it’s possible that other delivery mechanisms were used during the 5 years since this gang was active. For instance, we haven’t seen any PDF exploits yet, which are very popular with other groups – an unusual thing.

We will continue to monitor the situation and publish updates as the story uncovers.