Infinity EK: "No...unless round is funny."

NOTE: The information is based on a sample captured on 2013-11-22

Thanks to @Set_Abominae for sharing 'intel' on this sample. The analysis was done using the data gathered during Fiddler 'live' capture.

Update 2014-01-27:

This exploit kit got an official name - Infinity.

Infinity Exploit kit logo

Update 2013-11-25:

@PhysicalDrive0 giving this EK a fancy name in this blog post.

"Smokey, this is not 'Nam. This is bowling. There are rules."

Compromise attempt starts with visiting a website injected with malicious '<iframe>'.

<iframe> injected into one of the pages on compromised website

As a side note, the website in this particular sample had been compromised twice. The same page that redirects the browser to some unknown EK also has 'CookieBomb' script injected in it.

part of 'CookieBomb' script

part of deobfuscated 'CookieBomb' script

URL the 'CookieBomb' is leading to was dead at the time the 'live' capture took place. More on 'CookieBomb' threat can be found on MMD website.

Back to Unknown EK now, the following URL pattern was observed - pastebin.com.

'Unknown EK' URL pattern

Seeing 'cnt.php' redirect script, more likely, indicates that the website was compromised through CVE-2013-1862. Hendrick Adrian(MMD) covered this subject in great details in one of his blog posts.

The EK landing page is as simple as it can only be.

Unknown EK landing page - request for JNLP

JNLP file will launch JavaFX application.

Unknown EK JNLP file

Note a number of HTTP GET requests after JavaFX application JAR is downloaded. These are result of 'Class-Path' header having references to them in 'MANIFEST.MF' file.

Unknown EK MANIFEST.MF file content

Also note, there is no HTTP GET request in Fiddler log for the Initial Payload. This is due to the way it's being requested. During JavaFX application execution the control is passed to 'javaw.exe' tool along with the class file that requests and executes the Initial Payload. 'javaw.exe' tool is not 'proxy-aware' and will send the request directly to the malicious website which technically means if you're on the network behind a web proxy and no direct access to the Internet you're safe from this exploit kit.

"Back off, man. I'm a scientist!"

There is almost no obfuscation applied to the code - some of the string variable values are split and then concatenated.

string value obfuscation example

The JAR file is armed with an exploit code for CVE-2013-2460.

part of exploit code for 'CVE-2013-2460'(after deobfuscation)

Once execution privileges are elevated, a hidden .class file is decoded and loaded. During this process it'll be saved to Java Temp folder with 'NewClass.class' filename. The class file is encoded with 'base64'. It handles Initial Payload download and execution.

part of 'base64' encoded hidden .class file

The Initial Payload URL location is not stored in any of the parameters passed to JVM or variables within the code. Instead, it's generated using some tricks JavaFX has to offer.

JavaFX trick to get part of JNLP URI 

The code above will return JNLP file parent folder URI - in this case 'hxxp://vinnypedulla.com/5/201311/'. The second part of the path will be dynamically generated using current time stamp following this pattern 'HHmmss' - for example, '113458.mp3' . The routine in the screenshot below combines both parts and requests the initial payload.

part of the Initial Payload fetcher code

The initial payload filename will be created by adding the same 6 digits(time stamp) and '.exe' string together. The file will be stored in Java Temp folder. Before it's stored and executed, it's decoded using XOR with predefined key - 'binkey'.

"Summary"

This exploit kit sample is implemented as a JavaFX application. Some variables names suggest the creator of it is a Turkish speaker - names examples: 'fia', 'analiz', 'fout', 'bais'. Light complexity. Will fail if targeted machine is behind a web proxy and has no direct access to the Internet.

Summary Information
Name:	Unknown
Date captured:	2013-11-22
Date analysed:	2013-11-23
Source/Credits:	Intel source - @Set_Abominae. Data source - live traffic capture with Fiddler.
Infection vectors detected:	Java/JavaFX
Vulnerabilities targeted:	CVE-2013-2460
Landing page
Transfer mode:	plain text
Obfuscation:	No
TDS:	No
JNLP:	Yes
JVM parameters:	None
Java infection vector
Analysed with:	Java 1.7.17
Obfuscation:	Simple string values obfuscation
JAR hidden content:	Hidden .class file - 'NewClass.class'
Initial Payload delivery method:	URL
Initial Payload encryption/encoding:	XOR. key - 'binkey'
Initial Payload store location:	Java Temp folder
Initial Payload filename:	Generated using current time - HHmmss
Adobe infection vector
Analysed with:	NA
Initial Payload delivery method:	NA
Initial Payload store location:	NA
Initial Payload filename:	NA
Automated analysis
Exploit components:	JAR - https://www.virustotal.com
Delivered malware:	EXE(MD5 b7b352ecb0ea8fc52c5a6a515b85c7e0) https://malwr.com/ https://www.virustotal.com
Additional Information
	EK creator is possibly a Turkish-speaker.

Unknown Java Malware: "Forget it, Jake. It’s Chinatown."

NOTE: The information is based on a sample captured on 2013-10-03

Another 'piece of art' work by some actor learning how to 'copy/paste' code. There is nothing wrong with copy/paste as long as you understand what the code does. Judging by the amount of unused code that even includes 'System.out.println' statements, seems the author was afraid to change and accidentally break it. This in turn helped to narrow down a potential region where the Java code is coming from. This is also another example of Java malware that is not using any exploit code, but targeting users with administrator privileges on their machines. I'll tag it 'Java Malware' as it doesn't fit the definition of an exploit kit. The real danger of this type of malware is stealthiness - as long as the payload it delivers is not being detected by AV(and it's quite easily achievable).

"Toto, I've a feeling we're not in Kansas anymore."

The URL pattern for this sample is short and simple.

The landing page doesn't have any sophisticated parts either, but at least there are simple checks for Java presence and OS type performed before pulling down Java JAR file.

checking for Java Web Start or JNLP support in the browser

Even though the checks above are performed, JNLP technology is not utilized to deliver the JAR file. These checks simply identify if Java RE is present. Returned 'boolean' value steers the execution and if found to be 'false' will stop the script execution and exit. If Java is found the following condition is checked next.

OS type check and JAR request through 'document.write'

This Java Malware targets Windows machines only. Even if Java is present the script execution will stop if no Windows OS is found. The detection is based on browser's 'User-Agent' value.

"This one time, at band camp..."

As mentioned earlier, there is no exploit code in the JAR file. The execution starts with creating a simple folder structure on drive 'C'.

call for 'docmdsyn' to create two folders

'docmdsyn' function calls 'cmd.exe' to run the commands

Regardless of the outcome of running the two commands, the execution will continue with a request for the Initial Payload using hardcoded URL and a 'borrowed' Java code.

hardcoded URL & 'downloadFile' function call

'downloadFile' function

Thinking that 'this url is error' sounds like rather strange English, I did a search for 'System.out.println("this url is error");' expression and noticed that most of the search results are pointing at Chinese websites. From what I can figure out using Google Translate, the websites are forums/boards used by Java developers to exchange knowledge and share different code samples for different purposes. The code samples there are almost 100% matching the function in the screenshot above.

The Initial Payload is XORed with a single value key - '0x12'. The encoded version of the payload will be stored in 'c:\users\public\svchost.cab' and passed to a function do decode it.

part of 'xorEn' function code

There are tons of unused code and the declaration of 'XOR_CONST' variable is just a small example of it. Hoping to find something interesting, did another search using just a part of the declaration statement - 'public static final byte XOR_CONST' . Surprisingly, the search result page contained links pointing at the same Chinese websites with Java code samples that match quite closely the code in the screenshot above even including the 'xor' key value. So, if not the author's location, at least some parts of the source code seem to be specific to one particular geographical region.

Once the Initial Payload is decoded, it'll be stored in 'c:\users\public\svchost.exe' and executed using the same 'docmdsyn' function. It's not all though. There is a small bonus in the form of some registry changes and a clean up operation.

Windows Terminal Services changes

Number of commands will be executed to enable Windows Terminal Services and delete the encoded Initial Payload. One of the registry key changes enables spawning 'Windows Command Prompt' at the login screen by hitting a key on the keyboard a few types - also known as 'sticky keys' vulnerability.

"Summary"

General Information
Name:	Unknown
Date captured:	2013-10-03
Date analysed:	2013-10-07
Source/Credits:	Live Fiddler capture
Infection vectors detected:	Java
Vulnerabilities targeted:	'sticky keys' - login bypass
Landing page
Transfer mode:	plain text
Obfuscation:	No
TDS:	No
JNLP:	No
JVM parameters:	None
Java infection vector
Captured with:	Java 1.7.17
Obfuscation:	None
JAR hidden content:	None
Initial Payload delivery method:	URL
Initial Payload encryption/encoding:	XOR single value key - 0x12
Initial Payload store location:	c:\users\public\
Initial Payload filename:	Hardcoded - 'svchost.exe'
Adobe infection vector
Captured with:	Not implemented
Initial Payload delivery method:
Initial Payload store location:
Initial Payload filename:
Automated analysis
Exploit components:	None
Delivered malware:	(JAR)MD5 - 839d43c69935a8a93e0b9f6c3d715c53 virustotal.com - link (EXE)MD5 - 27af067a2dd507862290779679c68b6d virustotal.com - link
Additional Information
	Some of the code used seems to be coming from Chinese websites sharing public Java code samples

Unknown EK: "I wanna be a billionaire so freaking bad..."

NOTE: Information is based on a sample captured on 2013-10-02

I'm not sure if definition 'exploit kit' is actually applicable here. Yes, there is an exploit code copied from PSA(Packet Storm Advisory) for 'CVE-2013-2465', but I'd expect more code around it before calling it a 'kit' and I can't imagine there is a server side code exist. There is no any sort of environment validation: plugins and their version identification, initial payload encryption, data encoding, code obfuscation. Base64 encoding is used just once to 'hide' a single string. So, another 'interesting' work.

"Landing page"

URL pattern is short and simple.

The landing page is also short and simple.

The parameter name is the first hint to the possible origins of this Java exploit. 'kurban' translated from Turkish means 'victim'. The value held by this parameter is the Initial Payload location.

"JAR file"

JAR file is 'packed' with goodies. The execution begins with an attempt to exploit 'CVE-2013-2465' vulnerability.

part of PSA exploit code for CVE-2013-2465

Just before diving into screwing 'storeImageArray()' function, a single call for 'base64coder' is made to decode a single and the only encoded string.

The author was rushing because mum just called him/her for dinner and didn't bother cleaning up someone's  'base64coder' code that might have been copied from 'source-code.biz'. All encoding methods were left in even though are not used.

A few more hints pointing at the origins or one of the languages the author is speaking.

Google translated from Turkish: 'dosyayazdirici' - printing a file, 'baglantiaç' - open link, 'bayt' - byte. The screenshot above is a part of the code that fetches the initial payload via URL passed from the landing page. Once it's downloaded, it'll be stored in the default temporary-file directory with hardcoded filename - 'thefire.exe'.

The link to the initial payload was dead by the time the capture was performed. Judging by the filename - 'install_flash_player.exe', it could have been 'ZeroAccess'.

One rather odd thing is the name for the method performing the exploit - 'uganda'. Maybe the author's favourite country or maybe the target, who knows.

"Summary"

General Information
Name:	Unknown
Date captured:	2013-10-02
Date analysed:	2013-10-04
Source/Credits:	Live Fiddler capture
Infection vectors detected:	Java
Vulnerabilities targeted:	CVE-2013-2465
Landing page
Transfer mode:	plain text
Obfuscation:	No
TDS:	No
JNLP:	No
JVM parameters:	1
Java infection vector
Captured with:	Direct download - Firefox/14.0.1
Obfuscation:	None
JAR hidden content:	None
Initial Payload delivery method:	URL
Initial Payload encryption/encoding:	No
Initial Payload store location:	Default temporary-file directory
Initial Payload filename:	Hardcoded - 'thefire.exe'
Adobe infection vector
Captured with:	Not implemented
Initial Payload delivery method:
Initial Payload store location:
Initial Payload filename:
Automated analysis
Exploit components:	Java JAR - virustotal.com
Delivered malware:	No sample available
Additional Information
	Possibly originated from Turkey or the author speaks Turkish

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/