As Eugene Kaspersky had written earlier, we were expecting new DDoS attacks on resources covering the Russian presidential election. So, as the country went to the polls on 4 March, we were on the lookout for new DDoS attacks.

We were surprised to hear a news report from one mass media source that claimed a series of attacks from foreign countries had targeted the servers responsible for broadcasting from polling stations. The announcement came at about 21:00, but there was no trace of any attack on our monitoring system. The media report did not clarify exactly what sort of attacks had been staged. Instead of a DDoS attack, the journalists might have been referring to a different method of seizing unauthorized access, such as an SQL injection.

Over the past few weeks, we have been busy researching the Command and Control infrastructure used by Duqu.

It is now a well-known fact that the original Duqu samples were using a C&C server in India, located at an ISP called Webwerks. Since then, another Duqu C&C server has been discovered which was hosted on a server at Combell Group Nv, in Belgium.

At Kaspersky Lab we have currently cataloged and identified over 12 different Duqu variants. These connect to the C&C server in India, to the one in Belgium, but also to other C&C servers, notably two servers in Vietnam and one in the Netherlands. Besides these, many other servers were used as part of the infrastructure, some of them used as main C&C proxies while others were used by the attackers to jump around the world and make tracing more difficult. Overall, we estimate there have been more than a dozen Duqu command and control servers active during the past three years.

Before going any further, let us say that we still do not know who is behind Duqu and Stuxnet. Although we have analyzed some of the servers, the attackers have covered their tracks quite effectively. On 20 October 2011 a major cleanup operation of the Duqu network was initiated. The attackers wiped every single server they had used as far back as 2009 – in India, Vietnam, Germany, the UK and so on. Nevertheless, despite the massive cleanup, we can shed some light on how the C&C network worked.

We have received several reports from people around the world asking for help with infections very similar to the GpCode trojan that we detected in 2008.

GpCode was initially detected in 2004 and it reappeared almost every year until 2008. Since then, the author has been silent. A few copycats created some imitations of GpCode that were mostly hot air and not real threats because they weren’t using strong cryptographic algorithms.

As we explained before, this type of malware is very dangerous because the chances of getting your data back are very low. It is almost the same as permanent removal of the data from your hard drive. Back in 2006 and 2008, we managed to offer a few ways of recovering and even decrypting your data with our decryption tools.

Now, GpCode is back and it is stronger than before. Unlike the previous variants, it doesn't delete files after encryption. Instead it overwrites data in the files, which makes it impossible to use data-recovery software such as PhotoRec, which we suggested during the last attack.

Preliminary analysis showed that RSA-1024 and AES-256 are used as crypto-algorithms. The malware encrypts only part of the file, starting from the first byte.

The malware detection was added today as Trojan-Ransom.Win32.GpCode.ax. Kaspersky Lab experts are working on an in-depth analysis of the recent Trojan and will update you on every discovery that may assist with data recovery.

If you think you are infected, we recommend that you do not change anything on your system as it may prevent potential data recovery if we find a solution. It is safe to shutdown the computer or restart it despite claims by the malware writer that files are deleted after N days - we haven't seen any evidence of time-based file deleting mechanism. But nevertheless, it is better to stay away from any changes that could be made to the file system which, for example, may be caused by computer restart.

People who are not should be aware of the problem and should recognize GpCode from the first second when the warnings appears on your screen. Pushing Reset/Power button on your desktop may save a significant amount of your valuable data! Please remember this and tell your friends that if you see a sudden popup of notepad with text like this:

Don't hesitate and turn off your PC, pull out the power cable if this is fastest!

Another sign of infection is immediate change of the Desktop background to something like this:

We will keep posting more information and screenshots as we continue our investigation.

Gumblar malware first appeared in spring 2009. Since then it has attracted a lot of attention of local ISPs in many countries, because it steals FTP credentials and injects malicious links in legitimate content as well as uploading backdoors on compromised servers.

We have already described the general architecture of the Gumblar system here. The only thing which has changed since that time is the number of compromised servers and the additional layer of servers in the infection process chain. The infection process now starts from a legitimate webpage which has an injected <script> tag (such page called an html-redirector) which refers to a server that has php (called a php-redirector) that produces javascript that further redirects the browser. There may be between one and four redirections like this and finally the browser gets the content from the server that’s the actual infector. The last server in the chain has a bundle of exploits which is used to attack Internet users. Recent numbers show how many URLs of different types are in that process:

The numbers above show only a slice of the real picture that we were able to get, which means that the real numbers may be much bigger. At this moment no one has information on how many compromised client machines are in the Gumblar botnet, but we believe it’s more than just the number of compromised servers, because the number of servers represents only the count of infected users that have their own websites and use FTP clients on the infected system.

We counted the total number of Gumblar server backdoors and it currently stands at about 4,460.

The danger from the Gumblar system lies not only in the potentially huge client botnet, but also in the aggregated power of the compromised servers. This is clearly understood by security researchers and ISPs. Many attempts have been made to analyze how big the system is and who stands behind it.

Japan was one of the countries which dedicated a lot of resources to the problem of Gumblar because:

• Japanese servers are in the top 5 in terms of number of infections worldwide;
• 2.there is not as much local malware in Japan as in other countries, so Gumblar - which blindly crosses international borders – quickly gained a lot of attention.

We have been tracking Gumblar from the beginning from our Japanese research lab. In fact, downloading new samples, decoding and unpacking shellcodes and extracting new URLs has become a daily routine for many researchers in Japan, not only us.

Gumblar developers have noticed non-stop activity coming from many Japanese IPs targeting their system. The hard work analysing the threat and the active online data being harvested from Japan resulted in a response from the bad guys. Not so long ago we came across a new variant of the infector script created by the Gumblar developers which verifies where the remote client is coming from. The script uses a free IP-to-country database to locate the country of the client. And if the country turns out to be Japan, the script halts and doesn't attack. Below is the part of the code which implements it:

In the highlighted piece of code, the function ‘gC’ gets the country code of the current client and if this equals ‘111’ (which stands for JP in the IP-to-country database) the code sets the value of the variable ‘$zz’ to 0 which halts the application.

Similar activity has been seen at FTP servers that we are monitoring. Japanese servers are no longer reinfected, while other countries are still under attack (the interval between server reinfections varies from 11 to 33 hours).

Unluckily for the bad guys we are an international team of researchers, so even if they try to ban Japanese IPs - which may limit the number of data harvesters coming from Japan - we still have resources to continue our research from other countries.

We've been looking at the infrastructure of the Gumblar malware and found some curious facts on how Gumblar operates which we would like to share to make hosting owners aware of the Gumblar threat.

Analysis of some infected websites showed that the only way to inject the infection of Gumblar was by using FTP access, because those websites have no server-side scripting. Later this was proved by an analysis of FTP log files.

The malicious code injection in HTML pages (which is a simple insertion of <script> tag in every file having HTML) was done by downloading all files from the server that could have HTML, changing them and uploading back. We call the websites modified in this way “redirectors”, because they simply redirect browsers to the website spreading malware.

The injected script refers to another website hosting exploits and registering all attacked clients. These websites have to support php, because the backend is implemented in php. We call these websites infectors, because they host the exploits and malicious executable file for Windows. The malicious Windows executable is pushed when the attack is successful. The executable waits for the user to enter FTP credentials.

We've been able to find where the server code for redirectors and infectors websites was coming from. And we've found an additional tier of infrastructure - a set of compromised websites which we call “injectors”. These websites host a generic php backdoor which lets the owner execute any php code on the webserver.

Malware writers today always try to conceal their identities, right? Wrong – even some of today’s profit driven cyber criminals reveal their identities. We are a bit surprised, but here is the story of how a blackhat has revealed his identity and is trying to ‘get compensation’ from Kaspersky for conducting research.

Recently we have been looking into a new service for malware writers: [avtracker dot info]. This is an online service designed to track AV vendors. The home page of [avtracker dot info] describes the service which includes protection for malicious programs against analysis by malware researchers and also calls for a DDoS attacks against security companies:

Moreover, some of our fellow researchers shared a network request with us that was used to report back to [avtracker dot info]. This request was used in a special spy program which was distributed to various antivirus labs by the owner of [avtracker dot info]. If executed, this spyware would contact the owner and describe the environment of the infected machine. We played around with this request, and substituted various random strings instead of the user name and system parameters.

The WHOIS listing was of no use – [avtracker dot info] was registered anonymously. This was no surprise – cyber criminals usually do register domains anonymously to hinder identification.

So far, nothing out of the ordinary – a normal day in the life of an antivirus company. And then…surprise – the owner of the malware writers’ service contacted us and revealed his identity. Moreover, he even demanded a ransom of 2000 euro to compensate his purported losses when we attempt to ‘break’ his new toy.

At the time of writing, we have received the spy program, which had the following message in its code pointing to the same person who contacted us:

Naturally, we have gathered all relevant data and forwarded it to our lawyer who will now take the next steps. If all cyber criminals were as cooperative as this one, life would be much easier for AV companies.

We have seen quite a few different and controversial comments regarding the recent attack on usa.kaspersky.com/support. People have questions and want answers: what really happened and what risk did the penetration create?

As a member of group dealing with the incident analysis I would like to share our results.

We confirm that the vulnerability existed in the new version of usa.kaspersky.com/support. We analyzed the log files and found requests with SQL injection. There were several attackers with IP addresses from Romanian ISPs. The requests were initially made with an automated tool - the screenshots showed that the hackers used a variant of an Acunetix tool.

Once the initial probes told the attackers that this section was vulnerable they attempted to manually exploit the vulnerability to get data about the structure of the database. They used an Information_Schema database to query existing table names and table columns. After collecting field names the attackers made a few attempts to extract the data from tables. Those queries failed because the attackers specified the wrong database. The attackers stopped after they got only the column and table names from the database and decided to go for glory. No data modification queries UPDATE,INSERT,DELETE... were logged.

After conducting the attack, the attackers decided to show off their ‘great code of ethics’ by sending Kaspersky an email - on a Saturday to several public email boxes. They gave us exactly 1 hour to respond. And posted on their blog without having received a response.

To sum up:

1. We are lucky the hackers proved to be more interested in fame than in causing damage
2. Secure development MUST be a key priority for web development - anywhere, anytime and all the time, and
3. It is a lesson to us all - check, check and re-check your processes and your code.

The latest Gpcode variant, which we wrote about here, is much less of a threat than its predecessors. The claims made by the author about the use of AES-256 and the enormous number of unique keys were a bluff. The author even didn’t use a public key in encryption, so all the information needed to decrypt files is right there in the body of the malicious program.

Our analysis shows that the Trojan uses the 3DES algorithm but the author dug up an off-the-peg Delphi component rather than going to the trouble of creating his own encryption routine. The Trojan's code is pretty messy throughout – and very different in style to previous versions of Gpcode – which indicates that the author isn't much of a programmer.

We've called this new variant Trojan-Ransom.Win32.Gpcode.am. Our antivirus updates include procedures for restoring encrypted files – so if you've fallen victim to Gpcode.am, just update your av databases and run a full scan of your machine. And because Gpcode was spread by another malicious program, P2P-Worm.Win32.Socks.fe, don't be surprised if your antivirus brings some other nasties to light.

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:

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.