Thanks to the Websense® ThreatSeeker® Network, we have discovered another interesting case of malicious web injection. This one tries to install a Java-based back door on visitors' systems. Its target is the pay-per-click company PocketCents, which has recently been targeted by two additional attacks. This company's business makes it a really interesting target for this type of attack. Given the intensive tracking they advertise in their mission statement, it seems likely that the attackers could be interested in customer information and user accounts. How better to get that information than with a backdoor installed on each visitor machine?
The following screen capture shows the injection still active at the start of our analysis:
The first interesting thing here is that it is not the usual exploitation scheme: there are no Java vulnerabilities involved in this injection, just Java code. So the code is executed by the browser without any kind of exception or memory trick.
Running of this malicious applet during our investigation did, however, generate a lot of alerts, as shown below:
The URLs from which the Java applets are executed are hosted by dropbox.com:
The "ogi45r.jar" applet works as a dropper for the jRat_tiny.jar file, as shown below. It also ensures that the Java context is running, using the "redir" parameter defined in the applet section. The value of the "redir" parameter is "hxxp://rs-ps.org," which seems to be a website used to provide a platform for online, Java-based games:
The "jRat_tiny" JAR file loads the stored file with the code shown above. Here's a further look into the code of this JAR file:
In the code above, the first point of interest is the use of resources to hide information. In this case, the resources are used to store two files: "enc.dat" and "key.dat". The first, "enc.dat," is an encrypted DES3 binary file. Once decrypted, it's executed by the Java RE command-line tool. It provides remote access to the systems with a list of commands worthy of the best RAT tools around. The second file, "key.dat," is a sort of configuration file. It's used along the initialization code, in which the first line the DES3 key is stored. The "key.dat" file is mapped on the "arrayOfStrings" array. The screenshot below shows the code snippet that, when given the DES3 key (stored in the first line of the file key.dat and referenced by the Java array "arrayofStrings") and the encrypted stream , generates another Java applet.
The "key.dat" file contains the following:
Except for the first value (the byte-based DES key), the content is encoded with the HEX values of the ASCII chars. Here's the decoded "key.dat" file:
Another interesting thing is that, due the multi-platform nature of this language, this RAT is able to detect the system on which it is running, and is totally platform-independent:
Above, we can see the attempts to detect the right command line for the environment in which "tiny_jRat.jar" has been executed. The aim of this code is to locate the right Java interpreter path on the impacted systems, and to run the decrypted Java file stored in the resources. Due to strong evidence that the "enc.dat" file was encrypted with DES3, I decided to write a light Java decrypter based on the DES3 algorithm using the cryptographic APIs of the Java framework:
The result of this really light DES3 decrypter (the code is available for other researchers, though it is not so complicated to write), when given the encrypted file and the Secret Keys retrieved by the configuration file as input, is to show that "key.dat" is a new JAR file which is the real RAT. Here is the code obtained from the new JAR file:
Again, it seems that we have a configuration file and an encryption key . This time, they use the AES algorithm, following implementation of Java class "L," which, thanks to the method "d," is able to decrypt the stream stored in the "config.dat" file, using the key stored in the "key.dat" file. The content of the key file is the following:
Here is a snippet of the AES decryption code:
With this information, it's possible to write an AES decrypter to get the configuration parameters. These include the C&C IP address and the TCP port used to contact the remote server owned by the RAT administrator to run the commands on the impacted systems, as well as other information. Looking around in the code, we can determine a lot of the features implemented by this RAT:
- DDOS routine
- command-line based commands
- remote process handling (kill , create new process, etc.)
- network commands, such as netstat
- injecting audio advice
- download and upload files from the impacted systems.
and so on.
The messages sent from remote systems by the RAT administrators seem to be handled in the Java class "B." For example, here is the code to list the running processes on the victim's system:
Here, the commands "KILLPROCESS" and " GETFILE" exfiltrate files from the impacted system:
Here, the HTTP DOS engine is used for this kind of activities:
Here is a service feature used by the RAT administrator to receive the system logs file:
A lot of other features and interesting details have also been detected. Although execution of this RAT is mitigated by Java protection when web browsers try to download and execute applets like this one, we think that this kind of platform-independent tool that doesn't require an exploitation chain could be a growing concern in the future. We have no idea how many users have been impacted by this injection. At this time, the dropbox.com JAR files have been removed.
Through our ThreatSeeker Network, we have detected that a lot of URLs are injected with the same threat:
Websense customers are protected from this and other threats by Websense ACE (Advanced Classification Engine).