A peak of new infections of Trojan.Mebroot has been found in the wild and after some investigation the data shows that there is a new wave of Mebroot Trojans being distributed through a popular exploit pack. The binary executables are using a newer packer to avoid detection from antivirus products. Mebroot has been around for some time; apart from updating their packer, the most interesting thing about this infection is how Mebroot gets itself onto your machine in the first place. I had a glance at the network capture and the intrusion seems to be coming from Java: ... Images 1 and 2: The network activity shows a series of http GET requests that end up downloading an executable onto the machine. This data stream shows some requests being made to the malicious server. In particular the request in image 1 is downloading a .jar archive (which is basically a .zip archive with .class files inside). This archive is being run and it ends up in the request in image 2, where you can recognize the header of an executable file. This is quite unusual. Although Java exploits aren’t new we usually don’t see many of them in the wild. So let’s start from the beginning and see what happened! The starting point of the exploit is an HTML page containing obfuscated javascript code that takes care of checking the version and language of your browser, and thus redirects you to the appropriate sub-page. This sub-page again contains encoded javascript code that has a selection of different known exploits targeting popular Web media technologies (Flash, Pdf, Adodb Stream, DirectShow, etc). In particular, the following exploit rings a bell: Image 3: The exploit is using a Java applet. This code is embedding a Java applet into the Web page, executing it, and then passing it a URL as a parameter (escaped in hexadecimal encoding). Our attention now moves onto the Java applet itself. It is a .jar file containing two modules (player.class and and mediapl.class), the former being referenced by the code in the exploit page. Once decompiled, this java applet is very small and contains some interesting code: Image 4: The first Java module. This code is related to a privilege excalation vulneratibility (CVE-2008-5353) that was reported initially in May 2009 for Mac OS X, but is known to also affect other platforms including Windows. The way the exploit works is simply through the use of deserialization of an object (the object is in the serialized form “ac-ed-00-75...” in image 4) to load it dynamically. This causes the following code to run, bypassing the Java sandbox and running commands with the current user’s privileges. We can see that soon after the deserialization code there is a call to the mediapl class: Image 5: A third embedded Java class is being deserialized and run. This class again has another embedded Java class (again serialized in the hexadecimal encoding “ca-fe-ba-be…”) that is loaded dynamically, and after doing some version checking it will end up downloading an executable and running it through the regsvr32 command, as shown in image 6: Image 6: The final code running outside of the Java sandbox. As stated above, Java is not the only exploit being served and as usual with these exploit packs they have a set of exploits that are being tried against the machine. This Java exploit does not work on latest updated Java software, so as usual, the advice is to keep your software updated to mitigate the risk of exposure.