LightsOut EK: "By the way... How much is the fish!?"

Thanks to @Set_Abominae for sharing details about this Exploit Kit.

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.

Originally thinking that this Exploit Kit must be a state of art code with all possible obfuscation in the world applied (taking the target types into account), I was a little bit disappointed to see another 'somehow-somewhat' job - unused code, copy-paste from 'packetstormsecurity.com', almost no Java code obfuscation, no use of encryption or encoding, etc.

"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)

variables that hold gathered values

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/

Unknown EK: "... It ain't no trick, To get rich quick, If ya dig dig dig ..."

Yet, another 'wannabe' exploit kit in the making. Thanks to @Set_Abominae for sharing this sample. The sample was discovered through @urlquery service.

NOTE: The information is based on a sample captured on 2013-09-05

"Heigh-ho, Heigh-ho"

URL pattern is rather 'messy', but at the same time unique.

HTTP requests observed

The Landing Page is as simple as it can only be. No fancy JavaScripts, no obfuscation, no data encoding. It targets Java and Adobe products by bombarding a potential victim machine with all it's got - doesn't do any version checks. Here is the list of vulnerabilities it tries to exploit:

• CVE-2010-0188 (Adobe Reader and Acrobat before 8.2.1 and before 9.3.1)
• CVE-2010-1297 (Adobe Flash Player before 9.0.277.0 and before 10.1.53.64; Adobe AIR before 2.0.2.12610; and Adobe Reader and Acrobat before 9.3.3, and before 8.2.3)
• CVE-2010-2884 (Adobe Flash Player 10.1.82.76 and earlier and Adobe Reader and Acrobat before 9.4 and before 8.2.5)
• CVE-2008-2992 (Adobe Acrobat and Reader 8.1.2 and earlier)
• CVE-2013-2465 (Java 7 through to update 21, Java 6 update 45 and earlier) 

Adobe infection vector starts with assembly of an array that holds the list of URLs pointing at the malicious PDF files.

filling up array with URLs

Once the array is ready, the malicious PDFs are requested one by one using this function:

requesting malicious PDFs

It's possible that multiple copies of the Initial Payload will be requested if Adobe product installed on a victim's PC is vulnerable to more than one exploit attempted. It's hard to tell though what exactly is going to happen in this scenario since the Initial Payload delivered through each Adobe exploit is stored with hardcoded name - 'update.exe' and in a predefined location - 'user Temp folder'.

part of shellcode extracted from malicious PDF file

Java infection vector starts with a request for malicious JAR file. No additional parameters (encoded URL, decoding key, etc,.) are passed to JVM.

requesting JAR file using <object>

The author is possibly a big fan of 'Toby The Tram Engine'(sorry, couldn't resist). Anyway, the JAR file is armed with an exploit for CVE-2013-2465.

part of CVE-2013-2465 exploit code

Initial Payload is requested using hardcoded URL and stored in Java Temp folder with yet again hardcoded filename - 'g.exe'.

The Initial Payload execution method is rather interesting - 'cmd.exe' is used.

Once executed, it launches Internet browser and checks for Internet connectivity by 'calling home'

The browser will be redirected to 'Google', but additional payload will be requested on the background.

additional payload request

this one turned out to be a BitCoin miner

Neither Initial or additional payloads were transferred with any encoding/encryption applied. At the time of writing, all the 3 files had good coverage on VT(see summary for more details).

Summary

Another 'piece of ... art' work by someone who just learnt how to write 'Hello, World!'. I guess I should take a stab at naming it. 'Toby EK' sounds too simple and non-tech. 'Teletubbies EK' on the other hand reflects both the technical complexity of the exploit kit and the professional level of the author/authors. Well, anyway here is the summary for this particular sample.

General Information
Name:	Unknown
Date captured:	2013-09-05
Date analysed:	2013-09-07
Source/Credits:	PCAP from @urlquery shared by @Set_Abominae
Infection vectors detected:	Java, Adobe
Vulnerabilities targeted:	CVE-2010-0188 CVE-2010-1297 CVE-2010-2884 CVE-2008-2992 CVE-2013-2465
Landing page
Transfer mode:	encoded / gzip
Obfuscation:	No
TDS:	No
JNLP:	No
JVM parameters:	None
Java infection vector
Captured with:	Java 1.6.26
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 - 'g.exe'
Adobe infection vector
Captured with:	Adobe Reader 8
Initial Payload delivery method:	URL
Initial Payload store location:	User Temp folder
Initial Payload filename:	Hardcoded - 'update.exe'
Automated analysis
Exploit components:	PDF1 - http://jsunpack.jeek.org/ PDF2 - http://jsunpack.jeek.org/ PDF3 - http://jsunpack.jeek.org/ PDF4 - http://jsunpack.jeek.org/ PDF5 - http://jsunpack.jeek.org/
Delivered malware:	EXE1(MD5 0e9337ee028e3e4b0bffebd7d1e502d2) https://malwr.com/ https://www.virustotal.com EXE2(MD5 de660551fb0670c16ec5b344d63406dd) https://malwr.com/ https://www.virustotal.com EXE3(MD5 3256da849bc3c62a6a015cf077794df2) https://malwr.com/ https://www.virustotal.com
Additional Information
	BitCoin miner is configured to use 'eu-stratum.btcguild.com' mining pool.