Today we heard a disturbing rumor about a new version of Gpcode. We immediately began talking to victims and trawling the Internet for samples.
After some digging, we found a sample that answers the descriptions victims have given us. The program's currently being spread via a botnet (name withheld for security purposes).
Gpcode leaves a text file named crypted.txt which includes a ransom demand of $10. The file also contains the author's contact details: an email address, an ICQ number and a URL. The web page page contains the following text in Russian:
Для вас 3 новости, не очень хорошая и две очень хороших и Начнем мы с неочень хорошей.
Неочень хорошая новость заключается в том, что все ваши файлы зашифрованы современным алгоритмом AES-256.
В программе использован метод Открытых-закрытых ключей.
Используется 99999 клюей для шифрования, на каждой зараженной машине используется один ключ, повторов нет.
Перебор ключей к алгоритму AES-256 невозможен в ближайщие 1000 лет.
Надежды на Антивирусные компании - Нет.
Алгоритм AES-256 используют американские спец службы для шифрования своих документов.
И вот первая Хорошая новость:
Файлы можно дешифровать.
Вторая очень хорошая новость:
Для дешифрации необходимо заплатить всего-то - 10 долларов.
We came across some interesting mobile phone software yesterday. It's designed for the J2ME platform for mobiles and it's a midlet with a Kaspersky Anti-Virus icon. The application mimics the behavior of our antivirus software; it deliberately simulates the detection of a virus and then shows an error message.
At first, we thought it was a new fraudware program designed to steal money from mobile users' accounts, but after checking its behavior, we came to the conclusion that it's just a demonstration – looks like somebody was having a bit of fun. The program doesn't modify the system or try to steal any money.
Although the program isn't malicious in itself, we detect it as FraudTool – even though the program's safe to run, we think that users should be notified about it. Because it's not malicious, we've added the prefix not-a-virus. If we see another modification of this application which attempts to trick the user in some way and steal money from his/ her account, we'll remove the prefix and the program will be detected as true malware.
Here's a video clip showing how the program works (in Russian only – but even if you don't speak Russian, you might still find it interesting!):
Detected for this program was added on 7th August. We decided to call it not-a-virus:FraudTool.J2ME.KaspAV.a, because it mimics the behavior of our antivirus product for mobiles.
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?
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!
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...