The investigation into the Duqu Trojan is into its sixth month, and March brought further progress as we were able to establish which language was used for its Framework code. This discovery was made with the help of the international IT community, from which we received several hundred possible explanations and hypotheses.
The Duqu Framework was written in C and compiled with MSVC 2008 with the options “/O1” and “/Ob1”. Its creators most probably used the object-oriented extension of the C language which is typically called “OO C”. The event-driven architecture was developed as part of the Framework or within the OO C extension. The C&C communication code could have been borrowed from another malware project and then adapted to meet Duqu’s needs. We believe that the code was developed by professionals who used old-school programming know-how. The approach adopted by Duqu’s creators usually occurs in serious programming projects, but almost never in malicious programs. This is yet more evidence that Duqu, along with Stuxnet, is a unique development that stands out from other malicious programs.
After investing so much money in projects like Duqu and Stuxnet, it’s not that easy to just shut everything down. In March we found a new driver in the wild which was practically identical to those used earlier in Duqu. The previous drivers had been created on 3 November 2010, and 17 October 2011, and the new driver was created on 23 February 2012. It seems the creators of Duqu went back to work after just a four-month break.
The new Duqu driver has the same functionalities as the previous known versions. The changes in the code are insignificant; however, they demonstrate that the creators have done their job of “correcting mistakes” to prevent detection. We have not detected the main Duqu module that is associated with this driver.
To learn more about Kaspersky Lab’s statistics on Duqu victims, please follow the link below. This blog post also enlists the Trojan’s modifications that we are aware of.
Closure of the second Hlux/Kelihos botnet
Kaspersky Lab in cooperation with the CrowdStrike Intelligence Team, Dell SecureWorks and the Honeynet Project has disabled the second Hlux/Kelihos botnet. The researchers call this botnet Kelihos.B to indicate that it has been created using the second, modified variant of the original bot.
On 21 March, we began to introduce a dedicated sinkhole-router into the botnet. Our aim was to make infected computers communicate only to this router. Over the course of a week more than 116,000 bots communicated to our sinkhole-router, allowing us to gain control of the bots from the botnet owners.
When an operation to seize control of a botnet is underway, botmasters typically try to strengthen their positions by releasing a new version of the bot and launching a campaign to recruit new computers into the botnet. This was the scenario that unfolded in September, when the first Hlux/Kelihos botnet was taken down. It was repeated in March.
The new, third version of the bot, dubbed Kelihos.C came to our attention several days after the start of the sinkhole operation. Apparently, the botmasters feared that their botnet could be neutralized at any moment, and pressed ahead with their plan B. We observed that RSA keys had been modified in Kelihos.C, just like in Kelihos.B. The RSA keys were used to encrypt some structures within the messages.
Since the botnet owners promptly rolled out yet another update of the bot, some researchers remain skeptical as to whether sinkholing is an effective method to neutralize botnets. We still think applying this method is effective in making botherders’ lives harder by diverting their resources into distributing a new bot and infecting new computers. As long as the new versions of the bot do not implement major changes in their architecture and communication protocol, the game of cat and mouse can continue. A complete victory over the botnet, however, can only be claimed when the people who are behind the botnet are arrested.
Attack on ZeuS and its hosts
In mid-March Microsoft joined forces with e-payments association NACHA and FS-ISAC, an NGO representing the interests of US financial services industry members, to carry our another attack on botnet administrators. The attack was dubbed “operation b71”. With the permission of the courts, a number of servers – control centers for the most active and numerous Zeus-based botnets – were captured.
Microsoft also attempted to unmask those involved in the development and distribution of ZeuS and other Trojans of this kind, such as SpyEye and Ice-IX (the latter based on the leaked source codes of ZeuS).
Microsoft submitted class action lawsuits against 39 anonymous persons involved in the creation of the malicious code and botnets based on it. Hopefully, this Microsoft initiative will be supported by US law enforcement agencies and, with international collaboration, more cybercriminals will be brought to justice.
Indeed, these are the only measures that can help neutralize banking Trojans – as estimated by Microsoft, the total damage caused by ZeuS, SpyEye and Ice-IX already amounts to about half-a-billion dollars.
Arrest of the cybercriminals behind Carberp
Russian law enforcement agencies, together with analytics group Group-IB, completed an investigation into the criminal activities of a group that stole money using the notorious banking Trojan Carberp. According to the press service of Russia’s Department K, a specialist unit fighting hi-tech crime, the group included eight people. Customers at several dozen Russian banks fell victim to the cybercriminals, who managed to steal approximately 60 million rubles (around $2 million). Fortunately, the investigation resulted in the arrest of the cybercriminals.
In Russia news of cybercriminals being arrested is quite rare, so the announcement was very welcome. However, the investigation only dealt with a single group that used ready-made Carberp code and resorted to the services of partner networks to distribute it. The public statement claims that the group included botmasters as well as money mules who withdrew the stolen money from ATMs. However, the author of the Trojan and its partner networks remain at large. The Carberp Trojan is still being sold on specialized forums, which means it is still in use and will be used by other groups. In particular, as of today, we are following the activity of several Carberp botnets. Whether they belong to a single group or several different ones is still unclear.
Attacks on individual users
A ‘fileless’ bot
In early March, Kaspersky Lab experts detected a unique malicious attack which used malware capable of operating without creating files on infected systems.
Unlike run-of-the-mill drive-by attacks, the malware was not downloaded to the hard drive but operated exclusively in RAM. Operating as a bot, the malware sent requests which included data on the browsing history taken from the user’s browser data to the server controlled by the attackers. If the data sent to the malicious server included information indicating that the user accessed remote banking systems, then the Lurk Trojan was installed on the infected computer. The Trojan is designed to steal users’ sensitive data to gain access to online banking services at several large Russian banks.
This attack targeted Russian users. However, we cannot rule out that the same exploit and the same ‘fileless’ bot will be used against people in other parts of the world: they can be distributed via similar banner or teaser networks in other countries.
This is the first time in years that we have come across this rare kind of malware – so-called ‘fileless’ malicious programs. Such programs do not exist as files on the hard drive but operate only in the infected computer’s RAM, making it much harder for antivirus solutions to detect them.
Although ‘fileless’ malware only remains operational until the operating system is restarted, the chances of a user revisiting the infected website are usually high.
Kaspersky Lab experts frequently emphasize that timely patching is the only reliable method of protection against malware that exploits vulnerabilities. In this case, we recommend installing a patch provided by Oracle which closes the CVE-2011-3544 vulnerability in Java. The patch can be downloaded from: www.oracle.com/technetwork/topics/security/javacpuoct2011-443431.html.
Another certificate theft
We keep running into more and more signed malware. Malicious programs with valid digital signatures – Mediyes Trojans – were detected again in the middle of March along with numerous dropper files that were signed on various dates between December 2011 and 7 March 2012. In all those cases a certificate was used that was issued for the Swiss company Conpavi AG. The company is known to work with Swiss government agencies such as municipalities and cantons.
The malefactors might infect the company’s computers and steal a certificate that was later used for malware signing. (There is some notorious Zeus malware which performs this function – it searches through an infected computer for certificates and, if it succeeds, sends it to the intruder.) The fact that municipal authorities may have been involved in this accident is particularly bad news – who knows which critical data of municipal offices these bad guys gained access to.
The Mediyes stores its own driver on the system drivers directory, which later injects a malicious DLL into an Internet browser. If a user makes requests in the Google, Yahoo or Bing search engines, the Trojan duplicates all requests on the server of the perpetrator. The server responds with links from the Search123 system working on a pay-per-click (PPC) basis. The links are clicked without the users knowing about it; the bad guys make money from fake clicks.
Malicious extension for Chrome
In the beginning of March Kaspersky Lab experts detected a malicious extension for Google Chrome that targeted Facebook users in Brazil . However, nothing prevents the intruders from staging a similar attack on users from other countries.
Malicious extensions were spread on Facebook via links that appeared to be for legitimate applications. Several themes were used in these attacks, including “Change the color of your profile”, “Discover who visited your profile” and “Learn how to remove the virus from your Facebook profile”. If a user agreed to install the app, he was redirected to the official Google Chrome web store, where the malicious extension for Chrome presented itself as “Adobe Flash Player”.
An average user is hardly likely to understand all the details surrounding the publication of applications at the Google Chrome web store. A user just sees the official Google website and does not expect to be threatened by malware. However, almost anyone can use this web store for his or her Chrome extension – only a Google account is needed and the Google Chrome web store provides a special section for “homemade” extensions.
After installing the malicious extension on a computer, the perpetrators gained full access to the victim’s Facebook account. In the incident described, the extension downloaded a malicious script file from the perpetrators’ command center. When the victim entered his or her Facebook page, the script was embedded into the page’s HTML code.
The script aims to attract more ‘Likes’ for Facebook pages chosen by the criminal. It also sends out a message from the victims, urging their friends to download the same malicious extension.
Google deleted the malware as soon as they were informed about it. However, criminals have already created similar extensions and placed them at the same place – the Google Chrome web store.
The MS12-020 RDP exploit
March saw a patch release from Microsoft that closed a critical vulnerability in Microsoft Terminal Services (a.k.a. Remote Desktop). This particularly problematic vulnerability falls into the category of a use-after-free vulnerability and was located in code that runs in ring 0, i.e. code that was executed with local system privileges.
The vulnerability was first discovered by Luigi Auriemma, who created a network packet that caused Remote Desktop to crash (Denial of Service). The researcher passed on detailed information to the relevant people at Microsoft. Where that information went after that remains a mystery, but we now know that it found its way on to the Internet where, instead of a general description from Microsoft, potential attackers were gifted an example of how to exploit this Remote Desktop vulnerability.
Immediately there were a number of people interested in finding working exploits for the flaw: some wanted an exploit to carry out attacks, while others wanted to verify the existence of an exploit and warn of the dangers. Meanwhile, some security researchers began preparing for an epidemic of network worms capable of exploiting the vulnerability.
And it didn’t take long for the first exploits to appear, with versions of malicious code claiming to offer unauthorized remote access to Windows PCs via Remote Desktop.
One version, however, had all the hallmarks of a practical joke:
The author of this particular exploit signed off as the hacker Sabu of Lulzsec fame – his associates recently accused him of passing on information about other group members to the FBI, resulting in their arrest.
The code is written in Python and uses a freerdp module, as can be seen from the text in the screenshot above. However, there is no known freerdp module for Python. There is a free open source implementation for Remote Desktop Protocol known as FreeRDP, but the developers themselves know nothing about support for freerdp on the Python platform.
This did in fact turn out to be a hoax, and not the only one.
The number of exploits started to mushroom, but not one version was capable of actually executing code remotely. A dedicated website even appeared with the rather telling name istherdpexploitoutyet.com.
We have yet to see an exploit that can remotely execute code via Remote Desktop. The majority either fail to produce the intended outcome or result in the dreaded BSOD.
Nevertheless, we recommend all Microsoft Windows users check their PCs to see if Remote Desktop is being used. If it is, then the Microsoft patch should be installed immediately. It is also worth considering whether the service is absolutely necessary on your system.
We will keep you updated if a working exploit appears that can execute code remotely, but in the meantime you can check if your server is vulnerable to potential RDP attacks at this site: http://rdpcheck.com.
Threats for Mac
Throughout the month we witnessed unprecedented activity in terms of malware for Mac OS.
The most prominent case was probably the distribution of spam to addresses of Tibetan organizations. This spam contained links to JAVA exploit Exploit.Java.CVE-2011-3544.ms, detected by AlienVault Labs. This exploit is designed to install malicious programs on users’ computers depending on the type of OS on the victim’s computer. In this particular case, Backdoor.OSX.Lasyr.a was installed on the computers of Mac OS users and Trojan.Win32.Inject.djgs on Windows users’ computers (the Trojan was signed by an outdated certificate issued by the Chinese company WoSign Code Signing Authority). Notably, cybercriminals used the same servers to manage both malicious programs during attacks.
This attack was not the only example of China using malware to attack Tibetan organizations. Just one week later a DOC file detected by Kaspersky Lab as Exploit.MSWord.CVE-2009-0563.a was found in a similar spam distribution. This exploit infected computers of Mac OS X users with the malicious program Backdoor.OSX.MaControl.a. Notably, this malicious program received commands for infected computers from the freetibet2012.xicp.net server located in China.
Also in March a new modification of the malicious program Backdoor.OSX.Imuler was detected, which we described in our 2011 September report. Malicious programs belonging to this family are spread under the cover of files with safe extensions. During the March attack, cybercriminals distributed spam with erotic images with .JPG extensions and malicious executable files masked as images.
There was yet another “novelty” in March: malicious programs of the Trojan-Downloader.OSX.Flashfake family now use Twitter as a command and control server. To distribute these malicious programs cybercriminals used 200,000 hacked blogs operating under WordPress.
Banking Trojan for Android
About 18 months ago, a mobile version of the infamous ZeuS Trojan was discovered. It was dubbed ZitMo (ZeuS-in-the-Mobile). The Trojan was designed to steal mobile transaction authentication numbers (mTAN), which banks send to customers’ mobile phones via SMS. Although this type of mobile threat saw some development, it was not until March 2012 that a piece of mobile malware was detected which could steal the credentials (login and password) used for online banking authentication.
In the middle of March, a malicious program was identified that targets not only SMS messages containing mTANs but online banking credentials as well. Kaspersky Lab detects the program as Trojan-SMS.AndroidOS.Stealer.a.
After launching, the malicious application displays a window with what is presented as a dialog for token generation. To make this ‘generation’ possible, the user is prompted to enter the key required for initial authorization in the online banking system. Next, the malware generates a fake token (a random number) and the data entered by the user is sent to the cybercriminals’ mobile number and remote server complete with the IMEI and IMSI numbers. In addition, the malicious program can receive a number of commands from the remote server (mostly related to stealing mTANs).
The emergence of this kind of malware did not come as a surprise, but certain details caught our attention. All known samples of the malicious program so far target customers of Spanish banks. However, one of the remote servers to which the malware attempts to connect was in the .ru zone (the domain is now offline). Furthermore, the mobile number to which the data stolen is sent is Russian and belongs to a regional operator. This indicates that Russian malware writers were probably involved in creating this malware.
Attacks on corporations/governments/organizations
In March several hacker attacks targeting space research agencies were reported.
First and foremost, a report on incidents revealed by NASA (http://science.house.gov/hearing/subcommittee-investigations-and-oversight-hearing-nasa-cybersecurity-examination-agency’s) was of great interest. It was presented by the agency’s general inspector in readings at the US Congress Committee on Science, Space and Technology.
A NASA audit revealed an incident in November 2011 when attackers (from Chinese IP addresses) gained full access to the network of the Jet Propulsion Laboratory (JPL). Moreover, during 2011, 47 targeted attacks on NASA were detected, 13 of which were successful. In 2010-2011 there were more than 5,400 estimated incidents of varying severity involving unauthorized access to the agency’s networks or malicious programs.
Besides hacker attacks, NASA suffers from repeated loss of laptops containing confidential information. Since 2009 almost 50 have been lost, including an incident in March when a laptop containing information on management algorithms for the International Space Station disappeared.
The Japanese Aerospace Exploration Agency (JAXA) also published the results of an investigation of an incident which happened in summer 2011 but remained undetected until January 2012.
In July 2011 a JAXA employee received an email containing a malicious file. The antivirus software on the computer was not updated, which enabled the malware to infect the system. The attackers received access to all information stored on the computer and were potentially able to remotely monitor the information displayed on the screen. Fortunately, as reported by the agency, no confidential information was stored on the computer. Although this computer had access to material monitoring the work of the space truck (H-II Transfer Vehicle (HTV)), the attackers were unable to access it.
Further analysis did not reveal the use of stolen authorization information to access other JAXA and NASA systems. The leakage of about 1000 agency emails can be regarded as a negligible loss.
March in figures
Throughout the month computers running Kaspersky Lab products:
- detected and neutralized over 370 million malicious programs;
- detected 200 million (55% of all threats) web-borne infection attempts;
- detected over 42 million malicious URLs.
Threats on the Internet – March 2012
These statistics represent detected verdicts of antivirus modules and were submitted by users of Kaspersky Lab products who consented to share their local data.
In our calculations, we excluded those countries in which the number of Kaspersky Lab product users is relatively small (less than 10,000).
Map of infection risk while surfing the Internet
The 10 countries where users face the greatest risk of infection via the Internet
|#||Country||% *||Change in ranking|
|*The percentage of unique users in the country with computers running Kaspersky Lab products that blocked online threats.|
The 10 countries where users face the least risk of infection via the Internet
|#||Country||% *||Change in ranking|
|4||Hong Kong (Special Administrative Region. PRC)||12.90%||2|
|5||Macao (Special Administrative Region. PRC)||13.60%||2|
|*The percentage of unique users in the country with computers running Kaspersky Lab products that blocked online threats.|
Top 10 malicious domain zones
Top 10 countries where web resources were seeded with malware
(Global distribution of infected sites and malware hosts)
Sources of web attacks by country*
* In order to determine the geographical source of an attack, the domain name is compared to the actual IP address where the domain in question is located, and the geographical location of the IP address is determined (GEOIP).
Top 10 threats on the Internet
|#||TOP 10 WAV March||% of all attacks*||Change in ranking|
|* The percentage of unique incidents detected by the web antivirus module on users’ computers.|