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.
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.