Reversing a Crypt0l0cker dropper

Ransomware – public enemy number one in today’s digital landscape. Malicious software designed to block access to a computer system until a sum of money is paid has become the most common form of cybercrime.

This week a client of ours was attacked by Crypt0l0cker, a known ransomware strain, which is making a comeback in European countries [1]. Luckily we were able to quickly localize all affected users and prevent the malice from spreading. Of course, after the fact I was curious to find out how the attack was carried out.

It all started with your typical email sent out to the financial department claiming to be a pending bill. The email contained a link to download a ZIP archive, which contained a JavaScript file. Once extracted and opened it would download and execute the malware.

As in any self-respecting cybercrime situation, the JavaScript file was obfuscated, preventing anybody from directly understanding what it was doing by just looking at the code. So the journey began by downloading the ZIP, extracting it and checking the code. The complete source code is available here and is over 500 lines long.

At first glance, it looks complex and cumbersome. But in reality, after tracing it with a debugger, it becomes rather simple and straight forward. The only relevant parts that need to be reversed are the following:

At this point it is already evident that this JavaScript code is designed for a Microsoft environment, as nobody else implements ActiveXObject. Additionally, we can already see that the run method will be called on this object. All that is left to do is to decode the actual command that will be executed.

By checking the values returned by each of the functions we get the following output:

The ActiveXObject created earlier appears to execute a powershell command, and to understand it we need to take this reversing exercise one stop further. The easiest way, again, is to pop a powershell CLI and check the resulting value inside the Invoke-Expression call, which leads us to the answer:

To conclude, the 500+ lines of obfuscated code amount to these 4 simple expressions that download the cryptolocker [2] from a hacked Vietnamese gift shop [3], and execute it, unleashing the encryption beast on the unsuspecting hard drive. As far as today goes, there are no known decryptors for this locker. The ransom is $500, which goes up to $1000 if it’s not payed by the first deadline. This means complete data loss and a system reinstall from scratch. Having a backup with all your important data is definitely the easiest, cheapest and most secure thing you can do to remediate the damage suffered from a Crypt0l0cker infection.


An overview of modern exploit kits

nformation security technology is an endless loop of change and evolution in both offensive and defensive ways. Blackhats create demand for new offensive technologies; whitehats respond with new defensive barriers. An exploit kit (EK) is a software kit designed to run on web servers, with the purpose of identifying software vulnerabilities in client machines communicating with it. Exploit kits discover and exploit vulnerabilities to upload and execute malicious code in the client browser. In today’s blog post we are going to briefly review currently used EKs, along with their delivery techniques, exploits and malicious payloads.

Reportedly, the infamous players Angler and Neutrino have now stepped down, and are no longer seen in the wild [1], all the while Rig is running strong since 2014. According to research by Talos Intelligence [2], Sundown has also become an important player since 2016.


Even though there have been reports of exploit kits pushing cleartext code [3] to their victims, most modern exploit kits use advanced techniques for hiding their code. Among one of the more notable and interesting techniques recently seen is steganography [4], which is the practice of concealing messages or information within other nonsecret text or data. By embedding malicious code within images it becomes impossible to detect by an untrained eye, and difficult to reverse, especially if the injected bytes are further obfuscated.

Second commonly used technique to pressure the victim into installing malicious software is social engineering [5], which is the practice of psychological manipulation of people into performing actions or divulging confidential information. Victims are served malicious content that is designed to toy with their emotions, such as fear, happiness, the will to help others, etc. to make the victim visit a malicious page.

Last but not least, there are browser lockers. Browser lockers normally rely on JavaScript to render a user’s browser unusable by continuously showing alert messages, pop-ups, or going in fullscreen mode. This loop continues until the user performs a specific action, which is usually installing software or calling a fake tech support number.


Exploits commonly used by EKs are targeted against all the common suspects: Microsoft IE/Edge, Adobe Flash, Java, and Silverlight. Some EKs also have Mozilla Firefox, Google Chrome and Opera exploits. To give you an idea, there is an outdated list of Common Vulnerability Enumerations (CVEs) [6] previously seen in various packs. Some of those CVEs are still used in modern packs, since a vast majority of users do not apply security updates regularly, or even worse – use End of Life (EOL) systems, such as Windows XP.

After leaks from the Hacking Team and the like, a wave of Flash exploits dominated the market. At one point Flash CVEs were literally submitted by the dozens on a daily basis. So many were submitted in a short period of time that now all major web browser vendors block outdated Flash plugins, with plans to completely phase out Flash in favour of HTML5 [7].

The “winner” of course remains Internet Explorer. This browser has seen so many reliably-exploitable vulnerabilities that now no self-respecting user will even touch it with a stick. IE’s younger brother, Microsoft Edge, seems to be following in the same steps, potentially becoming the next big thing on the EK market.

Several exploits currently implemented in Sundown and Rig EKs [8] have been released to the public domain. By analyzing these, you may get a better understanding of the state of affairs.


There are various common malicious programs circulating in the wild and pushed to exploited clients. Consistent with the global trend [9], all EKs are mostly infecting users with ransomware[10]. Ransomware is a type of malicious software designed to block access to a computer system until a sum of money is paid. This is achieved by encrypting the entire hard drive of the infected computer, rendering all information inaccessible. The victim is then asked to pay a ransom for the decryption key to be able to recover his or her files. If the ransom is not payed on time, the price is usually increased, and if the payment deadline is missed again, the decryption key is deleted. Albeit having payed the ransom, there is no guarantee that the victim will receive the decryption key, nor that the ransomware will be deleted. It is common practice to continuously infect the same clients that keep paying the ransom.

All modern EKs are seen to distribute Cerber [11], CryptoMix [12], Chip [13], and Locky [14], all of which are ransomware programs.

Apart from ransomware, an occasional banker trojan has also been observed in the wild. A banker trojan is a malicious program used to obtain confidential information about customers and clients using online banking and payment systems. A Zeus-based Terdot loader was identified as one of the malware samples distributed by Sundown [15].


Every few years some exploit kits step down and other emerge, but the certainty remains – there will always be a market for exploits. Whether a cybercrime ring or a government agency, everybody has their interest in obtaining unauthorized access to remote systems. With steganography now becoming standard, there will certainly be more interesting and innovating techniques to bypass sandboxes and security solutions alike.


Breaking open the Android Switcher

In late December 2016, the Android Switcher trojan was making the news. A trojan is “a type of malware that is often disguised as legitimate software. Trojans can be employed by cyber-thieves and hackers trying to gain access to users’ systems. Users are typically tricked by some form of social engineering into loading and executing Trojans on their systems. Once activated, Trojans can enable cyber-criminals to spy on you, steal your sensitive data, and gain backdoor access to your system” (source).

We decided to investigate this trojan for a short writeup of its functionalities and capabilities, so I downloaded a sample from Virustotal and cracked it open in the lab.

The first notable observation is that there is a lot of code written in Chinese (figure 1). Additionally, there are a lot of com classes, which makes it look as if it were a merged version of many different applications. This could simply be a way of adding extra trash-code to obfuscate the real functionality.

There are several hardcoded URLs for data exfiltration (figures 2 and 3), which receive internal network and device information.

Checking WHOIS records shows that the domain name is registered in Beijing (figure 4), and at the moment of writing this blog post is no longer accessible.

The trojan attacks a victim’s router by trying a series of predefined username:password combinations. These combinations are hardcoded inside one of the Java classes, and do not include very extensive tests.

According to previous research by Kaspersky Lab, the attacks are exclusively destined for TP-Link routers. This is determined based on the hardcoded JavaScript scripts that are used to navigate through the router admin panel (figure 5).

The malware also includes some interesting functionalities worth noting, such as: * Target Chinese users * Check if the device is rooted * DNS hijacking * User input emulation * Screen capturing


Android Switcher relies on a very limited set of default/weak credentials to gain access to the router and change its DNS settings. Nevertheless, according to Kaspersky’s research, this trojan was able to gain access to nearly 1,300 networks. If the next version contains a more extended set of username:password pairs and implements the capability of accessing other router models, this trojan will be able to pull in thousands of hijacked devices.

It is recommended to check that your router is configured to use a known public DNS entity, such as Google ( Additionally, it is highly recommended to change your default router password.

Deobfuscating a JavaScript exploit

Recently, one of our partners sent us an interesting piece of obfuscated JavaScript code that was used to run ads on their network. As it turned out, the code was malicious in nature, and in the present article I would like to analyze it and show how obfuscated JavaScript code can reverse engineered.

The following screenshot shows the code that we received:

In the above screenshot, there are two URLs that are readily identifiable (masked for this public release to preserve confidentiality of the affected party). The one used in the land variable is a tracker used to monitors a brand’s performance. The other one is embedded in the final part of code. This final part gave an impression to be garbage, for the exception of some artifacts (like the URL and JavaScript code).

As can be observed, the encoded text on line 58 is stored as a string and is passed as a parameter to what appears to be the decoding function defined on line 3. The decoded output is executed with the eval() call on line 2.

The eval() call will evaluate whatever is returned by the function that is defined inside the call. The function returns the decoded string on line 57. This is where we can intercept the execution flow and have a look at what is to be evaluated after the decoding function. We simply replace the return call with console.log(), save and run the script. Now we will see the decoded code printed out to console. Checking the console, I got the following output:

More obfuscated code! Analyzing we can see that _$_f4ea is an array of string values that appear to be JavaScript. The rest of the code selectively picks values from _$_f4ea and merges them into a coherent set of instructions. This time it’s not possible to get the decoded code by simply running the decoder function and printing out the result. Reversing this part will require manual substitution of values from the array. By using a JavaScript interpreter, it’s possible to semi-automate the process to get values from the _$_f4ea array, and then merge them together manually.

The final result looks, like this:

Now we can see a clear picture of what is really going on. Lets quickly review it line by line.

The first two lines define the iframe variable and the inCode that will later be injected into the URL that was previously identified. Lines 4-10 set iframe parameters and append it to the HTML document. Here we can see that inCode is injected into the css parameter in the URL passed to f.src. Upon further investigation it became evident that this website is suffering from an HTML injection vulnerability that allows malicious actors to inject arbitrary code, and more importantly have HTTP requests appear as if coming from the website itself. This is the core of the exploit. The vulnerable website is hosted in Spain. The attackers were routing all their ad traffic though this vulnerable website, thereby converting all their traffic to Spanish traffic, and finally sending it to the ad tracker that we previously identified.

It appears that the purpose of this exploit was to illegitimately augment Spanish traffic volume and get higher payouts by country. This of course led to the campaign being banned on our partner’s network.