Our previous blog on Gpcode said we'd managed to find a way to restore files in addition to those files that can be restored using the PhotoRec utility.

It turns out that if a user has files that are encrypted by Gpcode and versions of those same files that are unencrypted, then the pairs of files (the encrypted and corresponding unencrypted file) can be used to restore other files on the victim machine. This is the method that the StopGpcode2 tool uses.

Where can these unencrypted files be found? They may be the result of using PhotoRec. Moreover, these files may be found in a backup storage or on removable media (e.g., the original files of photographs copied to the hard disk of a computer that has been attacked by Gpcode may still be on a camera’s memory card). Unencrypted files may also have been saved somewhere on a network resource (e.g., films or video clips on a public server) that the Gpcode virus has not reached.

We can't guarantee that files will be restored, as the method used relies not only on the user having unencrypted versions of the affected files but also on the characteristics of the infected machine. All the same, the results we achieved during testing (80% of encrypted files were restored) suggest that it's worth doing if you need to recover your files.

The more pairs of files that can be found the more data that can be restored.

Detailed instructions on the use of the StopGpcode2 tool can be found in the description of Virus.Win32.Gpcode.ak.

We have discovered one interesting technique to hide malicious code from researchers.

The initial infection was common iframe injection on a web page. The iframe page loaded tiny shockwave file, which was only 158 bytes long!

This file uses internal ActionScript global variable ("$version") to get the version of user's OS and plugin for handling Shockwave files.

Our StopGpcode project has attracted a lot of attention from individual researchers and organizations who are interested in solving the puzzle of the blackmailing virus. Thanks for all the feedback.

Among other things, we've been asked a lot about how the virus propagates. Having analyzed a number of infected computers we've come to the conclusion that the virus gets onto the victim machine with the help of another malicious program – a bot with Trojan-Downloader functionality. The victim machines had been infected with this malicious program well before Gpcode appeared on them; and the bot downloaded a whole range of other Trojan programs in addition to the Gpcode virus.

The RSA private key hasn't been found, but some interesting ideas have surfaced. For instance, a detailed analysis of the algorithm used by Gpcode has shown that the author of the virus made an error which makes it possible (under certain circumstances) to decrypt encrypted files without the private key.

This method restores from 0% to 98% of all encrypted files on the computer. The results depend on a number of factors, beginning with the system that was attacked. At the moment it's impossible to give an average number of files that could be recovered from a 'typical' computer.

Kaspersky Lab researchers are currently working on creating a file restoration utility that will utilize this new method.

Currently, it's not possible to decrypt files encrypted by Gpcode.ak without the private key. However, there is a way in which encrypted files can be restored to their original condition.

When encrypting files, Gpcode.ak creates a new file next to the file that it intends to encrypt. Gpcode writes the encrypted data from the original file data to this new file, and then deletes the original file.

It's known that it is possible to restore a deleted file as long as the data on disk has not been significantly modified. This is why, right from the beginning, we recommended users not to reboot their computers, but to contact us instead. We told users who contacted us to use a range of utilities to restore deleted files from disk. Unfortunately, nearly all the available utilties are shareware – we wanted to offer an effective, accessible utility that could help restore files that had been deleted by Gpcode.

What did we settle on? An excellent free utility called PhotoRec, which was created by Christophe Grenier and which is distributed under General Public License (GPL).

The utility was originally created in order to restore graphics files (presumably that's why it's called PhotoRec, short for Photo Recovery). Later, the functionality was extended, and the utility can currently be used to restore Microsoft Office documents, executable files, PDF and TXT documents, and also a range of file archives.

You can find a full list of supported formats here. The official PhotoRec utility site is here. The PhotoRec utility is part of the TestDisk package, and you can find the latest version of TestDisk, including PhotoRec here.

It should be stressed the PhotoRec excels at the task it was designed for: restoring file data on a specific disk. However, it has difficulty in restoring exact file names and paths. In order to address this issue, we've developed a small, free program, called StopGpcode.

If you've fallen victim to GpCode, don't pay the author of the virus to restore your data. Use PhotoRec instead – if you want, you can make a donation to the developer of the program.

The description of Gpcode contains detailed instructions on how to manually restore files attacked by the virus using PhotoRec and Stopgpcode.

We've detected a new variant of Gpcode – a dangerous file-encryptor. It encrypts a whole variety of user files, targeting files with extensions such as DOC, TXT, PDF, XLS, JPG, PNG, CPP, H etc. If you're a regular visitor to Viruslist, you might remember reading about Gpcode a couple of years ago.

We recently started getting reports from infected victims, analysed a sample, and added detection for Gpcode.ak to our antivirus databases yesterday, on June 4th. However, although we detect the virus itself, we can't currently decrypt files encrypted by Gpcode.ak – the RSA encryption implemented in the malware uses a very strong, 1024 bit key.

The RSA encryption algorithm uses two keys: a public key and a private key. Messages can be encrypted using the public key, but can only be decrypted using the private key. And this is how Gpcode works: it encrypts files on victim machines using the public key which is coded into its body. Once encrypted, files can only be decrypted by someone who has the private key – in this case, the author or the owner of the malicious program.

Following on from Eugene's post, I'd like to chip in with my thoughts on what's happening at Defcon this year. I spoke at Defcon last year, and I'd say that the event is something unique – an opportunity for smart people with unconventional minds to meet and share their knowledge. Defcon not only gives you access to new ideas, but you also get to encounter the spirit of modern cyberculture.

It seems to me that the emergence of contests like Race to Zero was always simply a matter of time. And now that such a contest has appeared we'll see similar ones in the future, whether we like it or not. Of course breaking the law is wrong - I think the exact form of the contest will be modified before Defcon starts in order to meet legal restrictions.

However, I think the Race to Zero contest organizers could change the rules of the game in other ways, to make it beneficial to all participants. Let me explain...

Let's take a look at what the participants are going to manipulate: they will have the code of existing applications and probably some prepared sets of nop code. Nop code ("no operation" code) is special software code that neither affects the state of the machine nor alters the system. There are many approaches to obfuscation techniques but almost all of them have the same basic principle: the affected code is restructured and mixed with nop code. Depending on the algorithm used to mix the two sets of code, either it will be more difficult to read/re-engineer the code or the code will be able to evade detection by signature-based AV software engines.

We recently came across a very interesting suspicious web page. The HTML page of course contained malicious code that linked to the Trojan. However, it was a separate HTML page inside the benign one - the authors of the code went against HTML standards, and put in an extra <html></html> container.

What's surprising is that browsers (we checked using Internet Explorer, Firefox and Opera) don't have any problem processing a page like this. On the other hand, who would expect malicious users to observe standards?

However, this isn't the main issue. We're interested in the script that the malicious users integrated into the web page. Of course, the script is designed to make analysis as difficult as possible, using techniques to obfuscate the JavaScript.

The script itself looks more or less like this:

Nothing particularly surprising here - the majority of scripts like this can be decrypted without analysing all the steps taking to manipulate the code. You just have to find the part of the code which prints to the original web page in order to run the payload. And in this case it's the document.write() function:

If we modify this, we can see the decrypted code for the payload. Change document.write(P7E87DE2) to textarea1.innerHTML=P7E87DE2, with textarea1 being the HTML textarea container on the copy of infected page that we deliberately created on a local harddrive. Now we can see what the script does in the textarea field. Which gives us the following:

And it seems that this script doesn't print anything. This is the first impression - but a closer look at the script turns up this string:

What does this mean? It's very simple - this function gets its own code, and transforms it into a 'key' text string which is made up of letters and numbers. Within the function this string is used to generate the payload i.e. what gets entered in the text area depends on the body of the function itself!

As a consequence, if the code is modified in the slightest way, the result generated will be completely different, and may be completely nonsensical - this is what happened on our first attempt. It's a sort of defense mechanism against modifying the body of the JavaScript function. I haven't seen anything like this before in JavaScript - it's pretty smart.

However, it's possible to get round all of this simply by getting the same string from outside the function, assigning the variable q2854da60, which should be contained in the key string, to the result.

If you're an analyst doing this, and you're trying to get the script from inside the encrypted code, then you might suddenly find that when you open a correctly crafted page in order to get the hidden contents of the script, the browser will freeze. I'll just stick my two cents in here, and point out that this is the moment when your computer will get infected.

The construction used by an analyst within the <textarea></textarea> tags is crafted in such a way as to not only infect users' machines, but also to infect the computer of an analyst who's trying to get to the payload code by printing it to textarea! The construction looks like this:

So if the code is placed inside the textarea container, the code will close the textarea tag and add an iframe container - the browser uses this to load an external script which contains the exploit Trojan that infects the system.

This example shows very clearly how virus writers are combating antivirus professionals who want to protect rank and file users. And if a virus analyst makes the smallest error, his or her machine will become infected. And that's one of the reasons that I love my job - because it teaches me that there's no room for error!

Over the last couple of weeks we've been closely following the behaviour of a botnet with a C&C (command and control) center based on a popular web-based engine.

We waited for it to grow (see previous posts) and it was interesting to see the increase in the number of infected machines. And now the scale of the botnet is shrinking.

Today the botnet was made up of 6000 zombies, even though a week and a half ago there were more than 14 000! What happened? We took a look and found that there's a significant difference between the total number of infections and actual number of infected machines.

Let's take a look at the zombie network stats that we got today:

Subtract "GENERAL NUMBER BOTS" from "GENERAL NUMBER OF INFECTIONS" and there's a difference of about 10 000. This means the botnet is losing its bots!

Now let's compare the very same stats with the ones that we captured while the botnet was still growing:

The difference between "GENERAL NUMBER OF INFECTIONS" and "GENERAL NUMBER BOTS" is less than 500!

These differences are explained by the fact that AV companies have been busy detecting malicious files which were used to create the botnet. The time taken before all AV vendors detected the files was several days. During this time bots were detected and removed from PCs and this is why the botnet is losing its clients. And every day, as more and more users update their AV databases the botnet continues to lose ground...

We've been observing quite a small botnet - around 8000 zombie-machines - recently. Just a few days ago it exploded and started growing very quickly. The growth only stopped early yesterday evening - around 5pm Moscow time - when the overall total number of zombies was about 14000!

It's interesting to take a look at how the network grew. We collected some stats which are shown in the graph below:

We have found that the botnet is mostly targeting machines in Russia. Maybe this explains why its growth slowed during what is night-time in the Russian Federation.

We detect the Trojan which is used to spread the infection as Trojan-Downloader.Win32.Small.ehe. Detection was added on 30th July 2007.

We'll be keeping an close eye on this network and will keep you posted about new spikes of infections, so watch this blog.

We all know that there are many botnets (or zombie networks) all round the world. Kaspersky Lab not only detects and destroys the malware that is used to build botnets or steal confidential data, but we also look for new botnets and study their lifecycles.

Today we saw a sad, but typical picture: a small botnet with an approximately 8600 zombie machines suddenly exploded and began to grow very quickly. At first it had been growing by 5-10 new computers per day. Today the botnet grew by 4400 new zombies! The average growth rate was about 1 zombie per second!

Probably the owners of this botnet did a mass mailing of links to infected pages. Obviously, it was rather successful from the point of view of cybercriminals who own the botnet.

Botnet stats at 14:30 GMT:

The same botnet one hour later:

Such a growth of number of zombie machines proves that the users must be very attentive while checking new emails: do not open messages from unknown senders, use only plain-text view of messages and never blindly click the links included in email messages.

More on our ongoing botnet research next week.