This week, a malicious pattern of activity was observed in websites being compromised, which in turn redirected to a Red Kit exploit kit (EK) landing page. Some infected websites that were seen:
Two different mechanisms were used to infect the websites. The first one being a standard iframe injection, which leads to the Red Kit EK landing page through URL redirections. The other mechanism leverages SEO based techniques to carry out HTTP 302 redirections that lead to the RedKit EK landing page.
The snapshot below shows some of the sample URLs/SEO redirections that were seen. Please refer to this URLQuery search in order to identify other URLs exhibiting the redirection patterns.
Upon visiting the infected webpage, it sends the user to a malicious redirection (HTTP 302). The actual exploit code as shown below is then ultimately delivered.
- neptunebenson[dot]com
- route66marathon[dot]com
- whitesteeple[dot]com
Two different mechanisms were used to infect the websites. The first one being a standard iframe injection, which leads to the Red Kit EK landing page through URL redirections. The other mechanism leverages SEO based techniques to carry out HTTP 302 redirections that lead to the RedKit EK landing page.
The snapshot below shows some of the sample URLs/SEO redirections that were seen. Please refer to this URLQuery search in order to identify other URLs exhibiting the redirection patterns.
Upon visiting the infected webpage, it sends the user to a malicious redirection (HTTP 302). The actual exploit code as shown below is then ultimately delivered.
The first landing page uses a typical RedKit Exploit, which contains the obfuscated URL that is used to fetch the payload as shown in the highlighted box below.
The Java Sandbox bypass exploit is carried out leveraging an unsigned applet with the suspicious parameter "__applet_ssv_validated" passed, which exploits the following vulnerabilities: CVE-2013-1493 / CVE-2013-2423 / CVE-2012-1723.
The jar applet gets the obfuscated URL from the parameter "name", which is passed by the jnlp as shown above. It is then decoded into the final URL through the following code:
This URL contains the encrypted binary payload. The applet creates a URL Connection Steam to download the encrypted binary stream. The binary stream is then decrypted using the AES CBC 128 bit cipher block chaining scheme. The IV (Initial Vector) and the decryption key are stored inside the applet. After decryption, it stores the binary file onto the temporary folder with a random filename by making a call to java.io.tmpdir. The snapshot below summarizes some of the important routines involved in the decryption process.
The binary file was packed using UPX and has anti-vm/anti-debugging detection routines. The binary is a Keylogger Tojan that steals credentials such as credit card numbers, passwords etc. and sends it over to a remote location. Currently, the binary is being detected only by three AV vendors as malicious.
Binary Reports:
Jar File Report:
It is always a good practice to keep vulnerable browser plugins such as Adobe/Java constantly updated. This protects the end user from malicious EKs leveraging known vulnerabilities. For more specfic information related to Java Plugins and how to disable them, please refer this great blog post from my colleague Julien Sobrier.
