In the past three years we wrote many times about Crimeware toolkits. These toolkits have become the cyber criminals’ tool of choice when conducting crime online. Starting from the moment we spotted the first crimeware toolkit – the WebAttacker – we have since seen hundreds of them all over the web, also today. 
Blockbuster Crimeware toolkits include AdPack, Fiesta,and G-Pack;. Less popular ones include UniquePack 2.0, Sploit25 2.2, Nuc_Pack, and Nuke sploits P4ck – to just name a few. 
In this blog post, we would like to share with you one of the toolkits that we have been tracking for the last six months – LuckySploit. LuckySploit brings code obfuscation to a whole new level of sophistication, far more advanced than all others we have seen so far. 
 
LuckySploit tries to exploit the same vulnerabilities other toolkits are trying to – Adobe Flash and PDF exploits, IE7 data binding vulnerability, the recent MS09-002, signed applets etc. its uniqueness consists of the way it hides/obfuscates these exploits to avoid detection by signature and heuristic based security products. 
Code Obfuscation by LuckySploit 
Here’s how it works. First, as we have seen with many other crimeware toolkits, a user is visiting a compromised website and is being redirected (using IFRAME or other techniques) to a server armed with LuckySploit. All is invisible to the user’s eyes and happens “behind the browser scene”. 
The first LuckySploit’s malicious page that is sent to the user’s browser contains a moderately obfuscated JavaScript code. The code is created at runtime with random variables and functions names. This part is used to construct the “brains” of the toolkit – an asymmetric key encryption and decryption. 
From this point on forwards, there’s a ‘dialog’ between the victim’s browser and the remote server, in which the browser sends metadata regarding its supported features (running platform, supported applications, installed plug-ins etc.). It receives in return an exploit suitable for those features. The browser’s supported features are being sent encrypted to the remote server using the server’s public key along with a random key generated at the client side. In return, the exploiting code is being sent encrypted by server, using the client’s key. 
This dynamic technique makes it almost impossible to do an offline (or post-infection) analysis of the toolkit and the served malicious code, since the key used by the client is not available. On every round a new key is generated. Following is a diagram demonstrating the entire process: 
 
We simplified this s diagram to make the process easier to understand. The dialog between the client and the server could be longer or shorter depending on the toolkit’s settings, the version of the client browser and the installed plug-ins. 
While the key generated by the browser is a simple, symmetric key, the server key is truly asymmetric, and uses RSA-like algorithm. Here’s a screenshot of a malicious server private key: 
 
Here are some code snippets of LuckySploit we want to show you. 
First, the obfuscation JS (partial) sent at the beginning of the attack: 
 
Here’s how it looks like when de-obfuscated (partial): 
 
Highlighted are two interesting lines of code: 1) the setting of the server’s public key, and 2) the dynamic creation of the result, which leads to the second part of the dialog between the client and the server. 
A new script tag is added to the page, the SRC value of the script tag contains the “next key” generated by the client as GET data. Below is shown how the server response at this stage looks like (partial): 
 
Please note that it is assumed that the browser already knows “rc4Decrypt” and the key. 
Below you see how it looks like when decrypted (partial): 
 
Please notice the generation of the “nextkey”, which contains the browser’s supported features (plug-in versions in this case) and the new SCRIPT tag. 
Administration 
LuckySploit is accompanied with a very handy administration panel. Below is a screenshot of this panel. 
 
The options “extra silent”, “silent”, etc. differs from one another by the amount of round-trips between the client and the server. As more round-trips are involved, it’ll be more difficult to detect the exploitation, and to decrypt the messages. The cost would be a higher load (CPU time and traffic) on the malicious server. 
LuckySploit’s administration panel supports multi-campaigns/users. This is achieved by special parameters allowing each campaign control over the evasive level, the download executable, the exploits used, stats collected etc. 
 
Finally, let’s have a look at the LuckySploit’s administration dashboard: 
 
Just look at the 20% infection rate – alarming! 
This toolkit is a great example for the sophistication, time and efforts that toolkit makers are investing in to make their “Swiss knife” undetectable for security products. The reason they are investing so much in this is clear – they make money out of it, and money is what drives the cybercriminals. 
Posted by Moshe Basanchig & Daniel Chechik