Thanks to @Set_Abominae for sharing details about this Exploit Kit.
Thanks to @tlansec for identifying this EK - LightsOut.
NOTE: Information is based on the sample captured on 2013-09-27
Emmanuel Tacheau a Threat Researcher at Cisco shared his findings on this Exploit Kit in his latest blog post linking it to a watering-hole type of attack aimed at Energy & Oil Industries. Below is the list of target types he identified:
- An oil and gas exploration firm with operations in Africa, Morocco, and Brazil;
- A company that owns multiple hydro electric plants throughout the Czech Republic and Bulgaria;
- A natural gas power station in the UK;
- A gas distributor located in France;
- An industrial supplier to the energy, nuclear and aerospace industries;
- Various investment and capital firms that specialize in the energy sector.
"It's the first page of the second chapter"
The below pattern is specific to this particular EK sample.
There are 2 layers of landing pages. The first landing page is a single '<iframe>' loading the second landing page.
- Internet browser type
- Internet browser version
- Operating System version
- Operating System type (32/64 bit)
The function(screenshot above) returns one of the following values - 'msie', 'opera' or 'firefox'. It's worth noting that 'opera' value is not being used in any conditions or anywhere else in the code. Code leftovers? Future plans?
Another unused code branch here. Even though Firefox browser version is being identified, the value is not used anywhere else in the code.
Yet again, the OS type is being identified, but the value is not used. It's quite possible that the content of the second landing page is being generated on the fly and depending on some conditions parts of the code are chosen. If that's the case they need to work on the generation logic. Below are other samples of some 'dead' code.
The function above is never called.
If Adobe infection vector would be used the code above controls the execution flow.
Currently empty, but if armed the three functions will be targeting Adobe Reader plugin versions '9.3.4', '9.4.0' and '10.1'.
Once Internet browser and Operating System types and versions are identified, one of the following code branches will be taken.
Exploit code for IE7 on XP or W2K or W2K3 will be called following a request for malicious JAR file. I couldn't identify the IE7 exploit used in this instance and would appreciate the community help on it. The code is posted on pastebin.com. Please contact me on Twitter or email if you have any information.
CVE-2013-1347 is targeted if IE8 on XP or W2K or W2K3 is detected. Malicious JAR will be requested after IE8 exploit attempt. The last condition is a 'safety net' - targets all other types of Internet browsers with Java plugin enabled.
Malicious JAR file is selected using the simple logic below.
There are 2 JAR files to choose from - for Java 6 or for Java 7. Just as simple as that - no patch level checks, no narrowing the attack surface to increase the success rate and reduce the detection chance. This logic is probably dictated by the choice of Java vulnerabilities targeted - 'CVE-2012-1723(Java 6)' and 'CVE-2013-2465(Java 7)'. In both cases the call for a JAR file is implemented through a GET request for an HTML page that would have an '<applet>' to pull the JAR file down.
The content of HTML pages for both Java 6 and 7 paths is quite simple - a single '<applet>' to request a JAR file.
"The chase is better than the catch!"
With the exception to some naming of some .class files, there is no obfuscation applied to Java source code or bytecode. Most of the methods and variables are meaningfully named. No parameters are passed to JVM running the JAR file.
Java 6 JAR file attempts to exploit 'CVE-2012-1723' and if successful proceeds to download the Initial Payload from hardcoded URL.
The Initial Payload will be stored in Java Temp folder with hardcoded filename - 'TMPprovider0.dll'. The payload is executed with the following code.
That's pretty much all functionality included in Java 6 JAR file. Java 7 JAR is as straight to the business as the Java 6 one only with 1 extra step though. The execution starts with a slightly modified 'CVE-2013-2465' exploit code copied from 'packetstormsecurity.com' advisory.
The Initial Payload is downloaded through the same URL and will be stored in the same location with the same filename as in Java 6 sample.
There is one extra step performed for the Initial Payload delivered by Java 7 JAR file.
'hidden' and 'system' file attributes are set on the Initial Payload file stored in Java Temp folder. It's worth mentioning the Initial Payload is not 'protected' in any way during transmission.
Lack of originality, lack of sophistication... Really simple exploit kit. Nothing to highlight here. I wonder about the success rate for it. Some details below.
|Source/Credits:||PCAP from @Set_Abominae. Live Fiddler capture|
|Infection vectors detected:||Java 6, Java 7, IE7, IE8|
CVE-2012-1723 CVE-2013-1347 CVE-2013-2465 CVE-???
|Transfer mode:||encoded / gzip|
|Java infection vector|
|Captured with:||Java 1.6.23 / Java 1.7.15|
|JAR hidden content:||None|
|Initial Payload delivery method:||URL|
|Initial Payload encryption/encoding:||No|
|Initial Payload store location:||Java Temp folder|
|Initial Payload filename:||Hardcoded - 'TMPprovider0.dll'|
|Adobe infection vector|
|Captured with:||Not implemented|
|Initial Payload delivery method:|
|Initial Payload store location:|
|Initial Payload filename:|
Java 6 JAR - virustotal.com Java 7 JAR - virustotal.com
EXE(MD5 8f8471acff7e18f61dc2def2bc353574) https://malwr.com/ https://www.virustotal.com
Initial Payload crashes in VM Possibly VM/debug aware