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

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.

Unknown EK: "Here's Johnny!"

NOTE: Information is based on a sample captured on 2013-06-14

The exploit kit was delivered through a poisoned advertisement feed. The following pattern has been seen:

Other examples of the pattern and a some detection tips can be found on Malwaresigs.com

"...as seen on TV..."

Request for an ad delivered a JScript that simply assembles a string using a number of other predefined strings.

The result is another JScript that takes the browser to 'www.googlecodehosting.net' hosting the landing page.

part of the assembled JScript

The landing page has yet another JScript with two 'document.writeln' calls. The first one requests a malicious JAR file armed with 'CVE-2012-1723' and 'CVE-2013-1493'. The request is implemented with an <applet> where one of the parameters in it is the Initial Payload URL encoded with 'Base64'.

The second 'document.writeln' call requests a JNLP file. The file is embedded into an <applet> - this allows to encode the content of the file with 'Base64'.

part of 'Base64' encoded JNLP file

'version' attribute of 'j2se' element in the decoded JNLP file is set to '1.7+' - meaning the file will be executed with Java 7 only. The JAR file targeting Java 7 is armed with 'CVE-2013-2423' and will be requested through a slightly different URL. The Initial Payload URL is stored in plain text.

part of decoded JNLP file

"Package full of goodness"

This particular exploit kit sample had only the malicious JAR file delivered through the first 'document.writeln' call from the landing page. The file is fairly obfuscated. The two exploits it caries are separated into two different packages/folders within the JAR. 'CVE-2012-1723' is stored in 'site' package. 'CVE-2013-1493' is stored in 'site/color' package. The exploits do not share any methods - their code is completely separated. 'CVE-2012-1723' exploit code is executed first. Due to the code separation, the Initial Payload filename is created using two different methods.

• payload delivered by 'CVE-2012-1723' is stored in Java Temp folder with hardcoded filename - '1.exe'
• payload delivered by 'CVE-2013-1493' is stored in Java Temp folder with the filename generated using a random number between '0' and '10000' + '.exe'

There is no encryption or encoding used for protecting the Initial Payload file.

Some of the class files, methods and variable names used in the kit are either existing words in Russian or a close variation of ones. The creator of this exploit kit is more likely to know Russian language.

"Ivanoff, Petroff, Smirnoff.... Dotcacheff"

 Quick summary:

• exploit kit URL pattern is relatively unique
• was delivered through Malvertising
• Java Script seems to be a preferred language for the redirect and landing pages
• targets Java only
• JNLP fie is protected with 'Base64'
• armed with 'CVE-2012-1723', 'CVE-2013-1493' and 'CVE-2013-2423'
• Initial Payload URL is stored in 'Base64' format
• no encryption or encoding employed for Initial Payload delivery
• Initial Payload filename depends on the exploit code executed
• creator is more likely to know Russian language

The exploit kit is rather simple, but not as simple as the one seen on 2013-06-07. @MalwareSigs tagged this exploit kit with a catchy name - 'Dotcachef'. Sounds like a Russian surname. Good fit for it, ah. Just need another 'f' at the end to make it look totally cool.

Recommended read:

http://www.malwaresigs.com/2013/06/14/dotcachef/
http://www.basemont.com/new_exploit_kit_june_2013

Update 2013-08-23:

Malforsec's latest analysis on DotCacheF - http://malforsec.blogspot.com/2013/08/dotcachef-short-story.html