Sunday, 8 June 2014

CottonCastle EK: "I hate to break this to you, but this isn't gonna be an open casket."

NOTE: The information is based on a sample captured on 2014-06-06

Thanks to @Set_Abominae for sharing this sample.

Update 2014-06-10@kafeine shared his experience with this exploit kit. Covers the history of the name, how it was first detected and what other exploits it has in its arsenal.

Whenever there is any doubt, there is no doubt

It's a rather interesting name for an exploit kit. Trying to find any references to 'Cotton Castle' you end up with links pointing at an amazing looking location in Turkey - Pamukkale. I can't be sure if the exploit kit name tips you off on the country of the origin, but let's find out what it's made of to be sure we better understand this threat.

In this particular sample a compromise attempt started with visiting a webpage with a link to a JavaScript that starts the redirect chain. The following HTTP traffic was observed.

'CottonCastle EK' HTTP traffic

The JavaScript starting the redirect chain is ''. According to almighty Google Search, the name belongs to a legit JavaScript application developed by 'Designcise' and meant to assist web developers with organizing a webpage content. Nevertheless, in this particular case that's not what this script is doing at all. The script appears to be checking the following before initiating a redirect:
  • presence of the word 'government' in the current session 'cookies'
  • types of 'frames', 'XMLHttpRequest', 'mozSetImageElement'
  • monitoring users interaction with the webpage - mouseovers, clicks and movements
Part of JavaScript checking browser 'cookies' and some element types

Part of JavaScript hooking mouse activity

Part of JavaScript showing 'EventListener' and 'attachEvent'

Once the required for redirect conditions are met, the browser is redirected to an HTML page containing another JavaScript.

Part of JavaScript showing the function initiating the redirect

This type of behaviour could be found with some of the news/ads reach websites where additional content is pulled based on user's webpage interaction and in this case might be exactly that, but we'll carry on assuming this activity is a malicious.

The webpage the browser is taken to is rather simple in terms of the content - 1 line of text that looks like a news headline.

Part of the page showing the line of text and an <iframe>

Let's take a look at some WHOIS data for the domain hosting this page.

Extract from WHOIS results for ''

Doesn't appear to be well 'hidden' if it was registered with a malicious intention, once again, making me think that this could be just a case of a compromised news/ad feed. Anyway, let's focus on the '<iframe>' link that leads to another webpage.

Part of the second HTML page in the redirect chain

Note yet another JavaScript URI that looks like a request for an ad banner - 'static.js?ads-banner=1620850'.

Part of JavaScript redirecting to EK landing page

'Surprisingly', there is no ad banner in the response. Instead it contains a lightly obfuscated JavaScript that compiles the next URL in the redirect chain. It takes a predefined URL, adds the referrer to it and requests the resulting URL.

This was the last redirect in the chain, so the browser finally arrives on the 'CottonCastle EK' landing page. Before we proceed with the analysis of the EK parts, let's quickly sum up what we've found so far and speculate a little bit about it. It's hard to tell for sure where the actual badness starts. Technically, it would be fair to say it starts from the very first page we landed on - '', but we should also consider a scenario where the first redirect to '' through '' JavaScript could be a normal operational mode for '' to pull news/advertisement content for its web pages. So, in this case the news/ad feed is compromised and more likely begins at ''. On the other hand, all domain names involved in the delivery of news/ad feeds could be a part of a well organised malvertising network and the redirect initiating link has been maliciously injected into '' website pages. Alright, that would be enough for speculations.

The statement below is true. 
The statement above is false.

The server replies with 203 HTTP status code when the landing page is requested. More likely, a rather unusual status code is being used by the server side of 'CottonCaste EK' for some internal processing or it could be specific to this particular sample only. String variables on the landing page are lightly obfuscated.

'CottonCastle EK' string obfuscation example

On top of that, the code is padded/fragmented by comment blocks.

'CottonCastle EK' comment blocks fragmentation example

As a first step, the code will launch an '<applet>' containing a Java application.

'<applet>' launching Java application

Next, the code will attempt to create a 'ShockwaveFlash' ActiveXObject and if successful will identify its version.

Part of JavaScript code that creates a 'ShockwaveFlash' ActiveXObject

Version value returned will be broken down into individual number values and stored as an array. The array will be converted into a string  by XORing each array element by a static key '343' and adding them together. The resulting string will be passed to a function that generates a GET request using a pre-defined URI and the passed ShockwaveFlash version value, plus, a bunch of other pre-defined parameters stored as HEX strings.

Part of JavaScript generating GET request for a ShockwaveFlash component

Just for a little bit of extra fun, we can find what version of Shockwave Flash Player was installed on the machine this particular sample of 'CottonCastle EK' was captured from. Here is the part of GET request corresponding to this sample - '/forum/tracker/3/ON/0dc93648889f84dcc7f0f70c25fbe9c6/349.341.456.342/'. If we take each individual numeric value from '/349.341.456.342/' and XOR it by '343' we get the version of Shockwave Flash Player - ''.

This particular GET request received HTTP 409 response. I assume that the server side of 'CottonCastle EK' responds with HTTP 409 Status code when it decides not to serve the exploit component or something went wrong sending it.

Lastly, another JavaScript on the landing page will try to identify 'ScriptEngineMajorVersion', 'ScriptEngineMinorVersion' and 'ScriptEngineBuildVersion' values. Like in the case with 'ShockwaveFlash' version values, each of the found values will be XORed by '343' and the resulting string passed to a function that generates a GET request using a pre-defined URI and the value passed. The request initiation is set on a 2.5 seconds timer.

Part of JavaScript generating GET request using detected values

So, the Java application will be requested and executed first. The request is implemented using JNLP file.

'CottonCastle EK' Java application JNLP file

Surprisingly, JNLP file has no 'Security Warning Window' bypass attributes and interestingly enough other attributes are properly named. According to the naming, this Java application is called 'jBitTorrent Client' that provides 'Java implementation of the bittorrent protocol' and will run on '<j2se version="1.6+" />'. The execution starts with 'com.s' class file. Let's take a look at the JAR file content.

'CottonCastle EK' JAR file structure

The two class files 's.class' and 't.class' contain a 'wrapper' code. In a nutshell, the code decrypts and loads some of the JAR file components. The '.dat' files included in the JAR file serve different purpose:
  • 'd.dat' - Windows PE executable
  • 'j.dat' - operating system reconnaissance, payload download and execution
  • 'p.dat' - JVM parameters collector, execution path selector
  • 'u.dat' - exploit code for CVE-2013-0422 (JmxMBeanServer)
Every '.dat' file is RC4 encrypted. The decryption key is stored in 'adv' parameter passed to JVM. In this particular sample it was - 'OrbitWhite'.

The Java code is fairly obfuscated. String values are also encrypted with RC4(using the same decryption key) and stored in HEX representation. 'java.lang.reflect.Method' features are used a lot.

Example of obfuscated string values

The execution flow is the following:
  1. 'wrapper' initialization
  2. 'wrapper' decrypts 'u.dat' file and passes it to 'javax.script.ScriptEngineManager'
  3. decrypted from 'u.dat' JavaScript exploits 'CVE-2013-0422'
  4. 'wrapper' decrypts 'p.dat' and loads it as a class file
  5. 'p.dat' class file gathers passed to JVM parameters, decrypts 'j.dat' file and passes it to 'javax.script.ScriptEngineManager'
  6. 'j.dat' JavaScript collects values of some OS parameters, decrypts and drops the payload stored in 'd.dat' file
  7. 'j.dat' JavaScript downloads a VB script and executes it
  8. VB script checks for presence of AV, downloads an executable file, decrypts, stores and executes it
  9. 'j.dat' JavaScript deletes all the cache and temp files created during the execution
Let's take it from step 6, 'j.dat' JavaScript decrypts 'd.dat' file and attempts to save it into the folder specified under 'allusersprofile' environment variable. The new filename for 'd.dat' file will be - 'java.dll'. If the script fails to save the file under 'allusersprofile' it saves it into the folder specified under 'temp' environment variable.

Part of 'j.dat' JavaScript that handles 'd.dat' file

After that, the script decrypts the value stored in 'session' variable that was pre-loaded by 'p.dat' file. The decrypted value is the URL for an HTML page containing encoded VB script. The page is downloaded and processed by 'mshta' tool.

Part of encoded VB script 

VB script is decoded and executed by the following JavaScript:

JavaScript that decodes and executed embedded VB script

List of operations performed by VB script:
  • query list of all running processes
  • check results of the query against a pre-defined list of processes
  • callback to a pre-defined URL in the event of blacklisted processes detected
  • build filename and filepath for malware payload
  • download, decode and execute the malware payload
  • callback to a pre-defined URL reporting a success deployment
List of running processes is pulled from 'WMI service'

Part of VB script creating the list of running processes

The generated list is checked against the list of process names belonging to some security products - 38 in total. Each entry on the list is formatted - 'code_letter:process_name,'. NOTE: the list below contains only the product or service names. Filenames corresponding to these services/products were purposely left out.
  • AVG Scanning Core Module - Server Part
  • AVG Watchdog Service
  • Ad-Aware Antivirus Service
  • ArcaVir
  • Avast! Service
  • Avira Scheduler
  • BitDefender Agent
  • BullGuard Behavioural Detection
  • CA eTrust Antivirus
  • Comodo Agent Service
  • Dr. Web
  • ESET Service
  • F-Secure Host Process
  • G DATA Personal Firewall
  • Ikarus Security Software
  • Jetico Personal Firewall
  • K7TotalSecurity Service Manager
  • Kaspersky Lab
  • McAfee Service Host
  • Microsoft Security Client User Interface
  • Norman Privacy Tools
  • Norton 360
  • Norton AV
  • Norton Internet Security
  • Omniquad firewall or Dynamic Security Agent or AGuardDogSuite
  • Outpost Firewall
  • PC Tools Security Service
  • PC Tools ThreatFire Service
  • Panda Software Controler
  • Rising Antivirus
  • Solo Antivirus
  • Solo Scheduler
  • Sophos Administrator Service
  • Sophos Anti-Virus
  • Trend Micro Anti-Malware Solution Platform
  • TrustPort Antivirus Management Agent
  • ZoneAlarm ForceField 
Interestingly enough, only two of the products are actually blacklisted - 'Norton 360' and 'Norton Internet Security'. If a blacklisted process is found the script will call to '' + '1000/' + 'code_letter' corresponding to a detected process. Otherwise, it'll proceed with creating the filename for the malware payload.

Part of VB script creating the filename for the malware paylaod

Another rather strange 'twist' in here. If you take a look at the screenshot above you'll notice that the name is created based on a condition. 'ap' variable is evaluated and depending on the result the prefix of the filename is selected. The value 'a' corresponds to 'avast! Service'. I'm not quite sure why this product receives a 'special treatment', but the possible filenames for the malware payload are - 'Windows-Patch-KB874923-x86.exe' or 'Windows-KB874923-x86.exe'. The file will be saved to the folder specified under '%TMP%' environment variable. Prior being saved to the disk, the file is run through a XOR routine that decrypts it. The decryption key is stored in plain text in the VB script. In this particular sample it is - 'e2400a24ac76b37cb0adff1dfd022e08'. Once decrypted and saved, it's executed using 'cmd.exe'. Spawned 'black screen' will try to calm a worried user down with 'echo Install Windows Updates'

Part of VB script that performs decryption and execution

The last thing the script does is generating the callback URL. The format is the same as per case with blacklisted process except to the middle part - instead of '1000/' it uses '111/'.

At this stage the control is passed back to 'j.dat' JavaScript and the very last operation it performs - 'clean up'.

Part of JavaScript showing the 'clean up' function

The script takes a good care cleaning up the 'leftovers'. In another rather interesting 'twist', 'Kaspersky Labs' are getting 'special treatment' during this process. On top of deleting temporary files created during the overall execution, the script deletes the content of 'Kaspersky Lab' folder located in '%programdata%'(Win Vista+) or '%allusersprofile%'(Win XP). 'Kaspersky Labs' products keep application tracing '.LOG' files in this location, so more likely the script is cleaning it out to remove its traces there too.

This would conclude the Java analysis part, so let's sum things up a little bit. I have to admit it was a rather interesting 'descent' for me. Do not want to sound as if I'm admiring someone with malicious intentions, but as a techie I have to say it's a nicely written piece of code. Use of Minification and 3 different programming languages is actually quite cool. JavaScript in 'j.dat' was a particularly interesting piece. At some point I even started thinking could this EK be a 'state sponsored' work, but that would be just silly, right. One thing I was not able to figure out is the purpose of the Windows PE file. It's only 2.5KB in size with 3 really short functions inside. Anyway, the Java part of this EK is fairly complex - detection evasion through encryption, system reconnaissance, support for blacklisting certain processes, clean up procedure. Overall observation is the Java part of 'CottonCastle EK' focuses more on being undetected rather being successful.

If you build it, he will come.

Since this sample doesn't have the 'Shockwave Flash Player' exploit part(@kafeine has covered this in one of his blog posts), the last component of 'CottonCastle EK' we have in this sample is the 'IE' exploit part. As mentioned in the beginning of the post, after collecting some of the values related to the browser environment a GET request is sent to the server. If the server is satisfied with the request it returns an HTML page with a JavaScript that decodes a blob of data stored in one of the variables.

Example of the data blob

JavaScript that decodes the data blob

The result of the decoding is another JavaScript.

Part of the decoded JavaScript showing indicators of 'CVE-2013-2551' exploit code

Thanks to @regenpijp for help identifying the vulnerability this exploit code is targeting - CVE-2013-2551.

Additional information on this EK can be found here -

This concludes 'CottonCastle EK' analysis. For the information on the delivered payload please see the summary table below.

Summary Information
Name: CottonCastle Exploit Kit
Date captured: 2014-06-06
Date analysed: 2013-06-07
Source/Credits: Data source - @Set_Abominae.
Intel source - @kafeine
Infection vectors detected: Java / Shockwave Flash Player / Internet Explorer
Vulnerabilities targeted: CVE-2013-0422
Landing page
Obfuscation: Yes
TDS: Multi redirect chain
JVM parameters: Yes
Java infection vector
Captured with: Java 1.7.05
Obfuscation: RC4 encrypted string values, Java Reflections, Minification
JAR extra content: Number of RC4 encrypted files with '.dat' file extension
Initial Payload delivery method: URL
Initial Payload encryption/encoding: XOR. key - 'e2400a24ac76b37cb0adff1dfd022e08'
Initial Payload store location: System Temp folder
Initial Payload filename: Static. 'Windows-Patch-KB874923-x86.exe' or 'Windows-KB874923-x86.exe'
Browser infection vector
Analysed with: Internet Explorer 7
Initial Payload delivery method: URL
Initial Payload store location: NA
Initial Payload filename: NA
Automated analysis
Exploit components:
JAR - (no detection)
Delivered malware:
EXE(MD5 b619fce7efde0453c06f68565a8bdbb6)
Additional Information

Java malicious component is implemented with the use of different evasion techniques. Execution is controlled and depends on the values of different system/OS parameters.