Sunday 29 September 2013

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 '', 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 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 '' 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.


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:

Landing page
Transfer mode: encoded / gzip
Obfuscation: 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 -
Java 7 JAR -
Delivered malware:
EXE(MD5 8f8471acff7e18f61dc2def2bc353574)

Additional Information

Initial Payload crashes in VM
Possibly VM/debug aware

External links:

No comments:

Post a Comment