Update 2013-10-14:
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.
The JavaScript on the second landing page will try to identify the following components before proceeding with any exploit attempts.
- Internet browser type
- Internet browser version
- Operating System version
- Operating System type (32/64 bit)
browser type check - 'BkEvhdwRlG' hold the UA string
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?
browser version check
Another unused code branch here. Even though Firefox browser version is being identified, the value is not used anywhere else in the code.
OS version check
OS type check
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.
function to check Adobe Reader plugin version
The function above is never called.
execution control code based on Adobe Reader version detected
If Adobe infection vector would be used the code above controls the execution flow.
three possible Adobe exploit branches
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.
IE7 on XP or W2K or W2K3
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.
IE8 on XP or W2K or W2K3
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.
all other browser + Java
Malicious JAR file is selected using the simple logic below.
JAR selection logic
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.
requesting JAR files through a separate HTML pages
The content of HTML pages for both Java 6 and 7 paths is quite simple - a single '<applet>' to request a JAR file.
Java 6 JAR request
Java 7 JAR request
I can't think of a good enough reason to request the JAR files through an additional HTML page. The author hasn't leant how to do it using JavaScript yet? That actually can also explain why there is no JNLP file used to launch Java 7 JAR file - it's probably in the last chapters of the book the author is reading as he/she is learning Web Programming.
"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.
part of exploit code for 'CVE-2012-1723'
Java 6 JAR file attempts to exploit 'CVE-2012-1723' and if successful proceeds to download the Initial Payload from hardcoded URL.
Initial Payload URL + store location + filename
The Initial Payload will be stored in Java Temp folder with hardcoded filename - 'TMPprovider0.dll'. The payload is executed with the following code.
Initial Payload execution 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.
part of exploit code for 'CVE-2013-2465'
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.
Initial Payload URL + store location + filename
There is one extra step performed for the Initial Payload delivered by Java 7 JAR file.
applying file attributes - 'hidden' and 'system'
'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.
"Summary"
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.
| General Information | |
| Name: | Unknown |
| Date captured: | 2013-09-27 |
| Date analysed: | 2013-09-28 |
| Source/Credits: | PCAP from @Set_Abominae. Live Fiddler capture |
| Infection vectors detected: | Java 6, Java 7, IE7, IE8 |
| Vulnerabilities targeted: | CVE-2012-1723 CVE-2013-1347 CVE-2013-2465 CVE-??? |
| Landing page | |
| Transfer mode: | encoded / gzip |
| Obfuscation: | No |
| TDS: | No |
| JNLP: | No |
| JVM parameters: | None |
| Java infection vector | |
| Captured with: | Java 1.6.23 / Java 1.7.15 |
| Obfuscation: | None |
| 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: | |
| Automated analysis | |
| Exploit components: | Java 6 JAR - virustotal.com Java 7 JAR - virustotal.com |
| Delivered malware: | EXE(MD5 8f8471acff7e18f61dc2def2bc353574) https://malwr.com/ https://www.virustotal.com |
| Additional Information | |
Initial Payload crashes in VM Possibly VM/debug aware |
External links:
http://urlquery.net/report.php?id=5963492
http://blogs.cisco.com/security/watering-hole-attacks-target-energy-sector/
http://www.exploit-db.com/exploits/25294/
No comments:
Post a Comment