Join our blog
You can contribute to our blog if you have +100 points. Comment on articles and blogposts, and other users will rate your comments. You receive points for positive ratings.
In response to numerous requests for comments and clarifications after our presentation at the Kaspersky Security Analyst Summit 2014, we have created this FAQ with some answers to the most commonly asked questions.
Kaspersky Lab decided to undertake full research on this topic after discovering several privately owned laptops of Kaspersky Lab security researchers had the Computrace agent running without prior authorization. Such unauthorized activations quickly became alarming when our reverse engineering revealed serious vulnerabilities in the Computrace agent protocol design.
The third security conference called ZeroNights conference has quickly grown into the largest security events in Russia. The conference first started in St Petersburg in 2011 with presentations from respectable speakers that included Dave Aitel and The Grugq. This year, ZeroNights had 800+ visitors, including quite a few English speakers and not surprisingly the presentations of Russian speakers were simultaneously translated in English for all.
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.
We all know that cybercriminals will target anything and everything they can reach. And at Kaspersky, we also know that a lot of IT admins don’t look after their Internet resources. Sad but true – ask an admin if their servers are protected, and you’ll often get the answer, “Oh, come on, who needs my SQL server?”
A few months ago we set up a new honeypot (http://www.mwcollect.org) in our Japanese research centre in Tokyo. The honeypot is mainly used to collect malicious Windows executables, which it does pretty well by emulating shellcode when it finds network exploits. A side effect of using the honeypot to listen on all ports is that we get statistics (as well as unexpected data) coming in on various network ports of the host, which has a global IP address.
This graph shows the number of attacks and unwanted connections on specified ports of our server. It shows the ten ports most commonly used, but even the least commonly targeted port (in this case, port 1130) gets about 16 connections a day.
Here’s a table of the common services using each port:
Hopefully, this proves what seems to us to be obvious – there’s someone on the Internet who wants your SQL server! (And a few other things besides…) And the data above shows that there are a lot of bad guys looking for backdoored orphaned hosts on the internet. Some of them are trying to find Backdoor.Win32.Noknok, while others are trying to break in through legitimate services like Radmin and Windows Remote Desktop.
Maybe you’re wondering just who it is who is looking for badly protected resources? Here’s another graph with those details, showing how many connections different countries make to our honeypot every day:
Take a minute to compare it to the previous graph! You can see that the number of MSSQL attack attempts is mirrored by attacks coming from China. And recently, South Korean hosts have joined this massive attempt to exploit the service.
Running a honeypot helps us get valuable data; we’re kept busy analyzing it and crunching the numbers, and finally, it’s a cheap form of entertainment. Our honeypot is running on 500MHz Pentium III CPU with 384 Mb RAM, which nowadays probably costs less than $100. So if you’re thinking of throwing out some really old, slow hardware, consider setting up a honeypot! ;-)
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:
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: