Malware RSS Feed
A while ago Turkish security group Otku Sen created the hidden tear ransomware and published the source code online. Idea behind it was to “teach” security researchers how ransomware works. Right from the beginning the reaction of various security professionals was negative. And we were right, it didn’t take long before the first ransomware variants arrived based on the hidden tear source code (, ) and of course, things escalated a bit.
Wondering what else there was, I decided to analyze the samples in the Trojan-Ransom.MSIL.Tear class and was amazed to find 24 additional samples.
Hidden tear only encrypts files located on the user’s desktop in the “\test” directory. If such a directory doesn’t exist, then no files are encrypted and no harm is done. In one of the first samples we classified as hidden tear Trojan-Ransom.MSIL.Tear.c, they removed the “\test” directory, so in this case all the files (with a certain extension) located on the Desktop are encrypted.
Another sample, Trojan-Ransom.MSIL.Tear.f calls itself KryptoLocker. According to the message, public key cryptography was used, but when we look at the code, we see something different. The author also didn’t use a CnC this time, but asked the victims to e-mail him, so he could ask for the ransom.
The next variants, Trojan-Ransom.MSIL.Tear.g and Trojan-Ransom.MSIL.Tear.h , are the first versions that use a proper CnC (previous samples used a server with an internal IP address as the CnC server). Other samples, such as Trojan-Ransom.MSIL.Tear.i and Trojan-Ransom.MSIL.Tear.k share the same CnC, while Trojan-Ransom.MSIL.Tear.j uses another one.
Interesting is also Trojan-Ransom.MSIL.Tear.m. This variant is specifically looking for files located in the “Microsoft\Atom” directory.
Variants Trojan-Ransom.MSIL.Tear.n , Trojan-Ransom.MSIL.Tear.o, Trojan-Ransom.MSIL.Tear.p, Trojan-Ransom.MSIL.Tear.q, on the other hand just encrypt your files and doesn’t store the key anywhere.
Variants Trojan-Ransom.MSIL.Tear. r to Trojan-Ransom.MSIL.Tear.v are all more or less the same. The location of the c2 is often example.com. This of course does not work.
The last samples, Trojan-Ransom.MSIL.Tear.w, Trojan-Ransom.MSIL.Tear.x and Trojan-Ransom.MSIL.Tear.y all store the password on the hard drive and was also described earlier here.
As always, when malware gets open sourced, we see an increase in variants of that specific malware. We can therefore conclude that hidden tear completely missed its purpose. Researchers don’t need hidden tear to understand how ransomware works. Luckily enough, in this case, the copy cats didn’t fix the bugs in hidden tear. Therefore it is actually possible (with some computation) to recover your key and decrypt your files for free. More worrisome is when copy cats use well developed and sophisticated malware and start using that.
The samples discussed in this post were all samples that were not often spotted in the wild. This means the number of victims remains relatively low.
Nevertheless, bugs can be fixed and the malware can be enhanced without much effort. After this point, it is just waiting for future victims who might lose their files forever.
Recently we came across a new family of cross-platform backdoors for desktop environments. First we got the Linux variant, and with information extracted from its binary, we were able to find the variant for Windows desktops, too. Not only that, but the Windows version was additionally equipped with a valid code signing signature. Let´s have a look at both of them.
This backdoor for Linux-based operating systems comes packed via UPX and is full of features to monitor the victim’s activities, including code to capture audio and take screenshots.
One example would be this location: $HOME/.local/share/.dropbox/DropboxCache. To achieve persistence, it uses this not very stealthy method: it just creates a .desktop-file in $HOME/.config/autostart/$filename.desktop. Here’s the template for this:
This “heartbeat” request replies with a one-byte image. To upload and receive data and commands, it connects to TCP port 433 using a custom protocol and AES encryption. The binary comes with the following hardcoded public keys:
The malware then collects gathered information from the keylogger, audio captures and screenshots in /tmp/. Later it will upload collected data to the C&C.
- /tmp/ss0-DDMMyy-HHmmss-nnn.sst (Screenshots, JPEG, every 30 sec.)
- /tmp/aa0-DDMMyy-HHmmss-nnn.aat (Audiocaptures, WAV)
- /tmp/kk0-DDMMyy-HHmmss-nnn.kkt (Keylogs)
- /tmp/dd0-DDMMyy-HHmmss-nnn.ddt (Arbitrary Data)
DDMMyy = date: 280116 = 2016-01-28
HHmmss = time: 154411 = 15:44:11
nnn = milliseconds.
However, audio capturing is not activated in the event timer of this binary, just like the keylogging feature. Since the authors have statically linked libqt, xkbcommon (the library to handle keyboard descriptions) and OpenSSL (1.0.2c) to the binary, the size of the binary is over 13MB. The criminals also didn’t make any effort to obfuscate the binary in any way. In fact, the binary contains almost all symbols, which is very useful during analysis.
There are also references to the author’s source files:
Apparently, it’s written in C++ and Qt, a cross-platform application framework. According to the binary’s metadata it was compiled using “GCC 4.8.4 (Ubuntu 4.8.4-2ubuntu1~14.04)” on Ubuntu 14.04 LTS “Trusty Tahr”. According to the qt_instdate timestamp, the last time the Qt sources were configured was on 2015-09-26 (qt/qtbase.git: deprecated), which implies the compilation time of the malware to be not earlier than end of September 2015.
We detect this type of malware as Backdoor.Linux.Mokes.a.OLMyJuxM.exe aka Backdoor.Win32.Mokes.imv
Just a few days ago, we came across a rather familiar looking sample, although it was compiled for machines running Microsoft Windows. It quickly turned out to be a 32-bit Windows variant of Backdoor.Linux.Mokes.a.
After execution, the malware randomly chooses one of nine different locations in %AppData% to persistently install itself on the machine. The binary also creates a “version”-file in the same folder. As its name implies, it stores just version information, together with the full installation path of the malware itself:
Then the corresponding registry keys are created in HKCU\Software\Microsoft\Windows\CurrentVersion\Run to ensure persistence in the system.
After the malware has executed its own copy in the new location, the SetWindowsHook API is utilized to establish keylogger functionality and to monitor mouse inputs and internal messages posted to the message queue.
The next stage in its operation is to contact the hardcoded C&C server. Besides the different IP addresses and encryption key, we see almost identical behavior.
However, this particular variant uses a slightly different implementation and tries to obtain the default Windows user-agent string.
If this is not successful, the sample uses its hardcoded version:
Like the Linux variant, it connects to its C&C server in the same way: once per minute it sends a heartbeat signal via HTTP (GET /v1). To retrieve commands or to upload or download additional resources, it uses TCP Port 433.
It uses almost the same filename templates to save the obtained screenshots, audiocaptures, keylogs and other arbitrary data. Unlike the Linux variant, in this sample the keylogger is active. Below you can see the content of a keystroke logfile, located in %TEMP% and created by this sample:
And again, we spotted some unexpected code. The following screenshot shows references to code which is able to capture images from a connected camera, such as a built-in webcam.
Similar to the Linux version, the author left quite a number of suspicious strings in the binary. The following string is surprisingly honest.
From the criminal’s point of view, it’s important that the software looks legitimate and that Windows doesn’t asks the user for confirmation prior to execution of unknown software. On Windows machines this can be achieved by using Trusted Code Signing Certificates. In this particular case, the criminal managed to sign the binary with a trusted certificate from “COMODO RSA Code Signing CA”.
We detect this type of malware as Backdoor.Win32.Mokes.imv.What’s next
Since this software was intentionally designed to be platform independent, we might see also corresponding Mac OS X samples in the future.IOCs Backdoor.Linux.Mokes.a
HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Run “%PERSISTENT-FILENAME%”, “%PERSISTENT-FILEPATH%”
where %PERSISTENT-FILENAME% is one of the filenames above
and %PERSISTENT-FILEPATH% is the corresponding path
Of all the Q4 2015 events in the world of DDoS attacks and the tools used to launch them, we picked out those that, in our opinion, best illustrate the main trends behind the evolution of these threats.
- Emergence of new vectors for conducting reflection DDoS attacks;
- Increase in number of botnets composed of vulnerable IoT devices;
- Application-level attacks – the workhorse behind DDoS attack scenarios.
Web resources powered by the WordPress content management system (CMS) are popular with cybercriminals who carry out DDoS attacks. This is because WordPress supports the pingback function that notifies the author of a post published on a WordPress site when someone else links to that post on another site running the same CMS. When the post containing the link to the other web resource is published on a site with the enabled pingback function, a special XML-RPC request is sent to the site where the link leads and that resource receives and processes it. During processing, the recipient site may call the source of the request to check for the presence of the content.
This technology allows a web resource (victim) to be attacked: a bot sends a specially formed pingback request specifying the address of the victim resource as the sender to a WordPress site with the pingback function enabled. The WordPress site processes the request from the bot and sends the reply to the victim’s address. By sending pingback requests with the victim’s address to lots of WordPress resources with pingback enabled, the attackers create a substantial load on the victim resource. This is why web resources running WordPress with the pingback function enabled are of interest to cybercriminals.
In Q4 2015, resources in 69 countries were targeted by DDoS attacks #KLReportTweet
The power of one such DDoS attack registered by Kaspersky Lab experts amounted to 400 Mbit/sec and lasted 10 hours. The attackers used a compromised web application running WordPress as well as an encrypted connection to complicate traffic filtering.IoT-based botnets
In October 2015, experts registered a huge number of HTTP requests (up to 20,000 requests per second) coming from CCTV cameras. The researchers identified about 900 cameras around the world that formed a botnet used for DDoS attacks. The experts warn that in the near future new botnets utilizing vulnerable IoT devices will appear.Three new vectors for carrying out reflection DDoS attacks
Reflection DDoS attacks exploit weaknesses in a third party’s configuration to amplify an attack. In Q4, three new amplification channels were discovered. The attackers send traffic to the targeted sites via NetBIOS name servers, domain controller PRC services connected via a dynamic port, and to WD Sentinel licensing servers.Attacks on mail services
In Q4 2015, mail services were especially popular with DDoS attackers.
In particular, activity was detected by the Armada Collective cybercriminal group, which uses DDoS attacks to extort money from its victims. The group is suspected of being involved in an attack on the ProtonMail secure e-mail service in which the cybercriminals demanded $6000 to end the DDoS attack.
In Q4 2015, the largest numbers of DDoS attacks targeted victims in China, the US and South Korea. #KLReportTweet
Kaspersky Lab has extensive experience in combating cyber threats, including DDoS attacks of various types and levels of complexity. The company’s experts monitor botnet activity with the help of the DDoS Intelligence system.
The DDoS Intelligence system (part of Kaspersky DDoS Protection) is designed to intercept and analyze commands sent to bots from command and control (C&C) servers, and does not have to wait until user devices are infected or cybercriminal commands are executed in order to gather data.
This report contains the DDoS Intelligence statistics for the fourth quarter of 2015.
In the context of this report, a single (separate) DDoS attack is defined as an incident during which any break in botnet activity lasts less than 24 hours. If the same web resource was attacked by the same botnet after a break of more than 24 hours, this is regarded as a separate DDoS attack. Attacks on the same web resource from two different botnets are also regarded as separate attacks.
The geographic distribution of DDoS victims and C&C servers is determined according to their IP addresses. In this report, the number of DDoS targets is calculated based on the number of unique IP addresses reported in the quarterly statistics.
It is important to note that DDoS Intelligence statistics are limited to those botnets that were detected and analyzed by Kaspersky Lab. It should also be highlighted that botnets are just one of the tools used to carry out DDoS attacks; therefore, the data presented in this report does not cover every DDoS attack that has occurred within the specified time period.Q4 Summary
- In Q4, resources in 69 countries were targeted by DDoS attacks.
- 94.9% of the targeted resources were located in 10 countries.
- The largest numbers of DDoS attacks targeted victims in China, the US and South Korea.
- The longest DDoS attack in Q4 2015 lasted for 371 hours (or 15.5 days).
- SYN DDoS, TCP DDoS and HTTP DDoS remain the most common DDoS attack scenarios.
- The popularity of Linux-based bots continued to grow: the proportion of DDoS attacks from Linux-based botnets in the fourth quarter was 54.8%.
By the end of 2015, the geography of DDoS attacks narrowed to 69 countries. 94.9% of targeted resources were located in 10 countries.
Q4 saw a considerable increase in the proportion of DDoS attacks targeting resources located in China (from 34.5% to 50.3%) and South Korea (from 17.7% to 23.2%).
Distribution of unique DDoS attack targets by country, Q3 vs Q4 2015
The share of DDoS targets located in the US dropped by 8 percentage points, which saw it move down to third place and South Korea climb to second.
Croatia with 0.3% (-2.5 percentage points) and France, whose share fell from 1.1% to 0.7%, left the Top 10. They were replaced by Hong Kong, with the same proportion as the previous quarter, and Taiwan, whose share increased by 0.5 percentage points.
The statistics show that 94% of all attacks had targets within the Top 10 countries:
Distribution of DDoS attack by country, Q3 vs Q4 2015
In the fourth quarter, the Top 3 ranking remained the same, although the US and South Korea swapped places: South Korea’s contribution grew by 4.3 percentage points, while the US share dropped by 11.5 percentage points. The biggest increase in the proportion of DDoS attacks in Q4 was observed in China – its share grew by 18.2 percentage points.Changes in DDoS attack numbers
In Q4 2015, DDoS activity was distributed more or less evenly, with the exception of one peak that fell in late October and an increase in activity in early November.
The peak number of attacks in one day was 1,442, recorded on 2 November. The quietest day was 1 October – 163 attacks.
Number of DDoS attacks over time* in Q4 2015.
* DDoS attacks may last for several days. In this timeline, the same attack may be counted several times, i.e. one time for each day of its duration.
Monday and Tuesday were the most active days of the week in terms of DDoS attacks. In Q4, the number of attacks carried out on a Monday was 5.7 percentage points more than in the previous quarter. The figure for Tuesdays changed slightly (-0.3 percentage points).
Distribution of DDoS attack numbers by day of the week, Q4 2015Types and duration of DDoS attacks
97.5% of DDoS targets in Q4 2015 (vs. 99.3% in Q3) were attacked by bots belonging to one family. In just 2.4% of all cases cybercriminals launched attacks using bots from two different families (used by one or more botnet masters). In 0.1% of cases three or more bots were used, mainly from the Sotdas, Xor and BillGates families.
The longest DDoS attack in Q4 2015 lasted for 371 hours (or 15.5 days). #KLReportTweet
The ranking of the most popular attack methods remained unchanged, although SYN DDoS (57%) and TCP DDoS (21.8%) added 5.4 and 1.9 percentage points respectively.
The distribution of DDoS attacks by type
Once again, most attacks lasted no longer than 24 hours in Q4 2015.
The distribution of DDoS attacks by duration (hours)
The maximum duration of attacks increased again in the fourth quarter. The longest DDoS attack in the previous quarter lasted for 320 hours (13.3 days); in Q4, this record was beaten by an attack that lasted 371 hours (15.5 days).C&C servers and botnet types
In Q4 2015, South Korea maintained its leadership in terms of the number of C&C servers located on its territory, with its share growing by 2.4 percentage points. The US share decreased slightly – from 12.4% to 11.5%, while China’s contribution grew by 1.4 percentage points.
In Q4 2015, SYN DDoS, TCP DDoS and HTTP DDoS remain the most common DDoS attack scenarios. #KLReportTweet
The Top 3 ranking remained the same. The countries in fourth and fifth switched places – Russia’s share increased from 4.6% to 5.5%, while the share of the UK declined from 4.8% to 2.6%.
Distribution of botnet C&C servers by country in Q4 2015
The proportion of DDoS attacks from Linux-based botnets in Q4 2015 was 54.8% #KLReportTweet
In Q4, the correlation between active bots created from Windows and Linux saw the proportion of attacks by Linux bots grow from 45.6% to 54.8%.
Correlation between attacks launched from Windows and Linux botnetsConclusion
Events in Q4 2015 demonstrated that the cybercriminals behind DDoS attacks utilize not only what are considered to be classic botnets that include workstations and PCs but also any other vulnerable resources that are available. These include vulnerable web applications, servers and IoT devices. In combination with new channels for carrying out reflection DDoS attacks this suggests that in the near future we can expect a further increase in DDoS capacity and the emergence of botnets consisting of new types of vulnerable devices.
Late last year, a wave of cyber-attacks hit several critical sectors in Ukraine. Widely discussed in the media, the attacks took advantage of known BlackEnergy Trojans as well as several new modules.
BlackEnergy is a Trojan that was created by a hacker known as Cr4sh. In 2007, he reportedly stopped working on it and sold the source code for an estimated $700. The source code appears to have been picked by one or more threat actors and was used to conduct DDoS attacks against Georgia in 2008. These unknown actors continued launching DDoS attacks over the next few years. Around 2014, a specific user group of BlackEnergy attackers came to our attention when they began deploying SCADA-related plugins to victims in the ICS and energy sectors around the world. This indicated a unique skillset, well above the average DDoS botnet master.
For simplicity, we’re calling them the BlackEnergy APT group.
One of the prefered targets of the BlackEnergy APT has always been Ukraine. Since the middle of 2015, one of the preferred attack vectors for BlackEnergy in Ukraine has been Excel documents with macros that drop the Trojan to disk if the user chooses to run the script in the document.
A few days ago, we discovered a new document that appears to be part of the ongoing BlackEnergy APT group attacks against Ukraine. Unlike previous Office files used in previous attacks, this is not an Excel workbook, but a Microsoft Word document. The lure used a document mentioning the Ukraine “Right Sector” party and appears to have been used against a television channel.Introduction
At the end of the last year, a wave of attacks hit several critical sectors in Ukraine. Widely discussed in the media and by our colleagues from ESET, iSIGHT Partners and other companies, the attacks took advantage of both known BlackEnergy Trojans as well as several new modules. A very good analysis and overview of the BlackEnergy attacks in Ukraine throughout 2014 and 2015 was published by the Ukrainian security firm Cys Centrum (the text is only available in Russian for now, but can be read via Google Translate).
In the past, we have written about BlackEnergy, focusing on their destructive payloads, Siemens equipment exploitation and router attack plugins. You can read blogs published by my GReAT colleagues Kurt Baumgartner and Maria Garnaeva here and here. We also published about the BlackEnergy DDoS attacks.
Since mid-2015, one of the preferred attack vectors for BlackEnergy in Ukraine has been Excel documents with macros which drop the trojan to disk if the user chooses to run the script in the document.
For the historians out there, Office documents with macros were a huge problem in the early 2000s, when Word and Excel supported Autorun macros. That meant that a virus or trojan could run upon the loading of the document and automatically infect a system. Microsoft later disabled this feature and current Office versions need the user to specifically enable the Macros in the document to run them. To get past this inconvenience, modern day attackers commonly rely on social engineering, asking the user to enable the macros in order to view “enhanced content”.
Few days ago, we came by a new document that appears to be part of the ongoing attacks BlackEnergy against Ukraine. Unlike previous Office files used in the recent attacks, this is not an Excel workbook, but a Microsoft Word document:
“$RR143TB.doc” (md5: e15b36c2e394d599a8ab352159089dd2)
This document was uploaded to a multiscanner service from Ukraine on Jan 20 2016, with relatively low detection. It has a creation_datetime and last_saved field of 2015-07-27 10:21:00. This means the document may have been created and used earlier, but was only recently noticed by the victim.
Upon opening the document, the user is presented with a dialog recommending the enabling of macros to view the document.
Interestingly, the document lure mentions “Pravii Sektor” (the Right Sector), a nationalist party in Ukraine. The party was formed in November 2013 and has since played an active role in the country’s political scene.
To extract the macros from the document without using Word, or running them, we can use a publicly available tool such as oledump by Didier Stevens. Here’s a brief cut and paste:
As we can see, the macro builds a string in memory that contains a file that is created and written as “vba_macro.exe”.
The file is then promptly executed using the Shell command.
The vba_macro.exe payload (md5: ac2d7f21c826ce0c449481f79138aebd) is a typical BlackEnergy dropper. It drops the final payload as “%LOCALAPPDATA%\FONTCACHE.DAT”, which is a DLL file. It then proceeds to run it, using rundll32:
To ensure execution on every system startup, the dropper creates a LNK file into the system startup folder, which executes the same command as above on every system boot.
The final payload (FONTCACHE.DAT, md5: 3fa9130c9ec44e36e52142f3688313ff) is a minimalistic BlackEnergy (v3) trojan that proceeds to connect to its hardcoded C&C server, 188.8.131.52, on Port 80. The server was previously mentioned by our colleagues from ESET in their analysis earlier this month. The server is currently offline, or limits the connections by IP address. If the server is online, the malware issues as HTTP POST request to it, sending basic victim info and requesting commands.
The request is BASE64 encoded. Some of the fields contain:
The b_id contains a build id and an unique machine identifier and is computed from system information, which makes it unique per victim. This allows the attackers to distinguish between different infected machines in the same network. The field b_gen seems to refer to the victim ID, which in this case is 301018stb. STB could refer to the Ukrainian TV station “STB”, http://www.stb.ua/ru/. This TV station has been publicly mentioned as a victim of the BlackEnergy Wiper attacks in October 2015.Conclusions
BlackEnergy is a highly dynamic threat actor and the current attacks in Ukraine indicate that destructive actions are on their main agenda, in addition to compromising industrial control installations and espionage activities.
Our targeting analysis indicates the following sectors have been actively targeted in recent years. If your organization falls into these categories, then you should take BlackEnergy into account when designing your defences:
- ICS, Energy, government and media in Ukraine
- ICS/SCADA companies worldwide
- Energy companies worldwide
The earliest signs of destructive payloads with BlackEnergy go back as far as June 2014. However, the old versions were crude and full of bugs. In the recent attacks, the developers appear to have gotten rid of the unsigned driver which they relied upon to wipe disks at low level and replaced it with more high level wiping capabilities that focus on file extensions as opposed on disks. This is no less destructive than the disk payloads, of course, and has the advantage of not requiring administrative privileges as well as working without problems on modern 64-bit systems.
Interestingly, the use of Word documents (instead of Excel) was also mentioned by ICS-CERT, in their alert 14-281-01B.
It is particularly important to remember that all types of Office documents can contain macros, not just Excel files. This also includes Word, as shown here and alerted by ICS-CERT and PowerPoint, as previously mentioned by Cys Centrum.
In terms of the use of Word documents with macros in APT attacks, we recently observed the Turla group relying on Word documents with macros to drop malicious payloads (Kaspersky Private report available). This leads us to believe that many of these attacks are successful and their popularity will increase.
We will continue to monitor the BlackEnergy attacks in Ukraine and update our readers with more data when available.
Kaspersky Lab products detect the various trojans mentioned here as: Backdoor.Win32.Fonten.* and
To know more about countering BlackEnergy and similar offensives, read this article on Kaspersky Business Blog.Indicators of compromise Word document with macros (Trojan-Downloader.Script.Generic):
e15b36c2e394d599a8ab352159089dd2Dropper from Word document (Backdoor.Win32.Fonten.y):
ac2d7f21c826ce0c449481f79138aebdFinal payload from Word document (Backdoor.Win32.Fonten.o):
3fa9130c9ec44e36e52142f3688313ffBlackEnergy C&C Server:
We were recently analyzing a family of mobile banking Trojans called Trojan-Banker.AndroidOS.Asacub, and discovered that one of its C&C servers (used, in particular, by the earliest modification we know of, as well as by some of the more recent ones) at chugumshimusona[.]com is also used by CoreBot, a Windows spyware Trojan. This prompted us to do a more detailed analysis of the mobile banking Trojan.
The earliest versions of Asacub that we know of emerged in the first half of June 2015, with functionality that was closer to that of spyware Trojans than to banking malware. The early Asacub stole all incoming SMS messages regardless of who sent them, and uploaded them to a malicious server. The Trojan was capable of receiving and processing the following commands from the C&C:
- get_history: upload browser history to a malicious server;
- get_contacts: upload list of contacts to a malicious server;
- get_listapp: upload a list of installed applications to a malicious server;
- block_phone: turn off the phone’s screen;
- send_sms: send an SMS with a specified text to a specified number.
New versions of Asacub emerged in the second half of July 2015. The malicious files that we are aware of used the logos of European banks in their interface, unlike the early versions of the Trojan, which used the logo of a major US bank.
There was also a dramatic rise in the number of commands that Asacub could execute:
- get_sms: upload all SMSs to a malicious server;
- del_sms: delete a specified SMS;
- set_time: set a new time interval for contacting the C&C;
- get_time: upload the time interval for contacting the C&C to the C&C server;
- mute_vol: mute the phone;
- start_alarm: enable phone mode in which the device processor continues to run when the screen goes blank;
- stop_alarm: disable phone mode in which the device processor continues to run when the screen goes blank;
- block_phone: turn off the phone’s screen;
- rev_shell: remote command line that allows a cybercriminal to execute commands in the device’s command line;
- intercept_start: enable interception of all incoming SMSs;
- intercept_stop: disable interception of all incoming SMSs.
One command that was very unusual for this type of malware was rev_shell, or Reverse shell, a remote command line. After receiving this command, the Trojan connects a remote server to the console of the infected device, making it easy for cybercriminals to execute commands on the device, and see the output (results) of those commands. This functionality is typical of backdoors and very rarely found in banking malware – the latter aims to steal money from the victim’s bank account, not control the device.
The most recent versions of Asacub – detected in September 2015 or later – have functionality that is more focused on stealing banking information than earlier versions. While earlier versions only used a bank logo in an icon, in the more recent versions we found several phishing screens with bank logos.
One of the screenshots was in Russian and was called ‘ActivityVTB24’ in the Trojan’s code. The name resembles that of a large Russian bank, but the text in the screen referred to the Ukrainian bank Privat24.
Phishing screens were present in all the modifications of Asacub created since September that are known to us, but only the window with bank card entry fields was used. This could mean that the cybercriminals only plan to attack the users of banks whose logos and/or names they use, or that a version of Asacub already exists that does so.
After launching, the ‘autumnal version’ of the Trojan begins stealing all incoming SMSs. It can also execute the following commands:
- get_history: upload browser history to a malicious server;
- get_contacts: upload list of contacts to a malicious server;
- get_cc: display a phishing window used to steal bank card data;
- get_listapp: upload a list of installed applications to a malicious server;
- change_redir: enable call forwarding to a specified number;
- block_phone: turn off the phone’s screen;
- send_ussd: run a specified USSD request;
- update: download a file from a specified link and install it;
- send_sms: send an SMS with a specified text to a specified number.
Although we have not registered any Asacub attacks on users in the US, the fact that the logo of a major US bank is used should serve as a warning sign. It appears the Trojan is developing rapidly, and new dangerous features, which could be activated at any time, are being added to it.
As for the relationship between Asacub and the Corebot Trojan, we were unable to trace any link between them, except that they share the same C&C server. Asacub could be Corebot’s mobile version; however, it is more likely that the same malicious actor purchased both Trojans and has been using them simultaneously.Asacub today
Very late in 2015, we discovered a fresh Asacub modification capable of carrying out new commands:
- GPS_track_current – get the device’s coordinates and send them to the attacker;
- camera_shot – take a snapshot with the device’s camera;
- network_protocol – in those modifications we know of, receiving this command doesn’t produce any results, but there could be plans to use it in the future to change the protocol used by the malware to interact with the C&C server.
This modification does not include any phishing screens, but banks are still mentioned in the code. Specifically, the Trojan keeps attempting to close the window of a certain Ukrainian bank’s official app.
Code used to close a banking application
In addition, our analysis of the Trojan’s communication with its C&C server has shown that it frequently gets commands to work with the mobile banking service of a major Russian bank.
During the New Year holidays, the new modification was actively distributed in Russia via SMS spam. In just one week, from December 28, 2015 to January 4, 2016, we recorded attempts to infect over 6,500 unique users. As a result, the Trojan made the Top 5 most active malicious programs. After that, the activity of the new Asacub modification declined slightly. We continue to follow developments related to this malware.
When mass-produced electronic spying programs became widely known by the public, many email providers, businesses, and individuals started to use data encryption. Some of them have implemented forced encryption solutions to server connections, while others went further and implemented end-to-end encryption for data transmission as well as server storage.
Unfortunately, albeit important, said measures did not solve the core problem. Well, the original architectural design used in emails allows for metadata to be read as plain text on both sent and received messages. Said metadata includes recipient, sender, sent/receipt date, subject, message size, whether there are attachments, and the email client used to send out the message, among other data.
This information is enough for someone behind targeted campaigns attacks to reconstruct a time line for conversations, learn when people communicate with one another, what they talk about, and how often they communicate. Using this information to fill in the gaps, threat actors are able to learn enough about their targets.
In addition to the above, technologies are evolving, so something that is encrypted today may be easily decrypted a few years later, sometimes only months later, depending on how strong the encryption key is and how fast technologies are developing.
Said scenario has made people move away from email exchanges when it comes to confidential conversations. Instead, they started using secure mobile messaging applications with end-to-end encryption, no server storage and timed deletion. On the one hand, these applications manage strong data and connection encryptions. On the other hand, they manage auto deletion on cell phones and provider servers. Finally, they practically have no metadata or are impersonal, thus not allowing identifiers about targets or data correlation. This way, conversations are truly kept confidential, safe, and practical.
Naturally, this scenario has made threat actors develop implants for mobile devices since, from a hacking perspective, they address all the aforementioned technical limitations―that is, the inability to intercept conversations between users who have migrated to these secure mobile messaging applications. What is an implant? This is an interesting terminology invented by the very same threat actors behind targeted attacks. We saw it for the first time during the Careto campaign we announced a few years ago.
Now we will analyze some implants developed by HackingTeam to infect mobile devices running on iOS (Apple), Android, Blackberry, and Windows Mobile. HackingTeam isn’t the only group developing mobile implants. There are several campaigns with different roots, which have been investing in the development of mobile malware and used it in targeted attacks at the regional and international level.Implants for Androids
Android-based phones are more affordable and, consequently, more popular worldwide. That is why threat actors responsible for targeted attacks have Android phones as their #1 priority and have developed implants for this operating system in particular.
Let’s analyze what one of these implants is capable of.
It is well known that the encryption algorithm used in text messages is weak. It is safe to assume that practically all text messages sent are susceptible to interception. That is precisely why many users have been using instant messaging programs. In the coding fragment above, we can see how threat actors are able to obtain access to the messaging database used by WeChat, a mobile application for text message exchange.
Let’s assume that the messaging application being used by the victim is really secure and has applied a strong end-to-end encryption, but all messages sent and received are stored locally. In said case, threat actors would still have the ability to decode these messages. Well, when they steal a database along with the encryption key that is stored within the victim’s device, threat actors behind these attacks can decrypt all contents. This includes all database elements, not only the text information, but also geographic locations shared, pictures, files, and other data.
Besides, threat actors have the ability to manipulate the camera on the device. They can even take pictures of the victim for identity confirmation. This also correlates with other data, such as the wireless network provider that the phone is connected to.
Actually, it doesn’t matter what application the victim is using. Once the mobile end point is infected, threat actors are able to read all messages sent and received by the victim. In the following code segments, we can see the instructions used to interact with messaging applications Viber and WhatsApp.
If a mobile devices is compromised with an implant, the rule becomes very simple – if you read a secure text message on your screen, the threat actor behind that implant, reads it too.Implants for iOS
Undoubtedly, Apple mobile devices also enjoy a large market share. In some markets, they are certainly more popular than Android devices.
Apple has managed the safety architecture of its devices very well. However, it doesn’t make them completely immune to malware attacks, especially when there are high-profile threat actors involved.
There are several infection vectors for these devices. Likewise, when high-profile targets are selected, threat actors behind these targeted attacks may apply infection techniques that use exploits whose costs are higher―hundreds of thousands of dollars―but highly effective, as well. When targets are of an average profile, less sophisticated, but equally effective infection techniques are used. For example, we would point to malware installations from a previously infected computer when a mobile device is connected through a USB port.
What technical abilities do iOS implants have? Let’s see the following implant example:
This Trojan infects iOS devices as they are being charged by the victim of the attack by using a previous Jailbreak made to the device. In other words, if targets usually charge their cell phones using a USB cable, the pre-infected computer may force a complete Jailbreak on the device and, once the process is complete, the aforementioned implant is installed.
In this code, you can see that the attacker is able to infected the device and confirm the victim’s identity. This is a crucial step during targeted attacks, since threat actors behind this kind of attacks wouldn’t want to infect the wrong victim and―worse yet―lose control of their implant and spoil the entire operation, thus exposing their attack to the public.
Consequently, one of the technical abilities of these implants is to verify the phone number of their victim, along with other data to make sure they’re not targeting the wrong person.
Among other preliminary surveying actions, this implant also verifies the name of the mobile device and the exact model, battery status, Wi-Fi connection data, and the IMEI number, which is unique to each device.
Why would they check the battery status? Well, there are several reasons for that, the main one of them being that data can be transferred through the internet to the hacker’s server as this information is extracted from an infected device. When phones are connected to the internet, be it through a data plan or Wi-Fi connection, the battery drains faster than normal. If threat actors extract data at an unsuitable moment, the victim could easily notice that there’s something wrong with the phone, since the battery would be hot and start draining faster than normal. That is the reason why threat actors would rather extract information from victims―especially heavy data like photos or videos―at a moment when their battery is being charged and the cell phone is connected to the Wi-Fi.
A key part of spying techniques is to combine a victim’s real world with the digital world they live in. In other words, the objective is not only to steal information stored in the cell phone, but also to spy conventional conversations carried out off line. How do they do it? By enabling the front camera and microphone on hacked devices. The problem is that, if the cell phone isn’t in silent or vibrate mode, it will make a particular sound as a picture is taken with the camera. How to resolve it? Well, implants have a special setting that disables camera sounds.
Once the victim is confirmed, the hacker once again starts to compile the information they are interested in. The coding below shows that threat actors are interested in the Skype conversations their victims are having.
This way, threat actors have complete control over their victims’ conversations. In this example, Skype is the messaging application being used by threat actors, but it could actually be any application of their choice, including those considered very secure apps. As mentioned above, the weakest link is the mobile end point and, once it is compromised, there is no need to even crack any encryption algorithm, no matter how strong it may be.Implants for Blackberry
Some targets may use Blackberry phones, which are known to be one of the most secure operating systems in the market. Even though they are safer, threat actors behind targeted attacks don’t lag behind and they have their arsenal ready.
This implant is characterized by a strong code obfuscation technique. Analyzing it is complex task. When we look at the code, we can clearly see that even though the implant comes from the same threat actor, the developer belongs to another developer group. It’s as if a specific group were in charge of developing implants for this operating system in particular.
What actions may these implants develop in an infected Blackberry device? Well, there are several possible actions:
- Checking the Battery Status
- Tracking the victim’s geographic location
- Detecting when a SIM card is replaced
- Reading text messages stored within the device
- Compiling a list of calls made and received by the device.
Once Blackberry phones start to use the Android operating system, threat actors will have a farther-reaching operation.Implants for Windows Mobile
Windows Mobile aren’t necessarily the most popular operating system for mobile devices in the market, but it is the native OS used by Nokia devices, which are preferred by people looking for quality and a solid track history. There is a possibility that some targets may use this operating system, and that is why the development of implants for Windows Mobile devices is underway as well. Next, we will see the technical scope of implants for Windows Mobile devices.
When infecting a victim’s mobile device, this implant is hidden under a dynamic library file by the name bthclient.dll, which is supposedly a Bluetooth driver.
The technical abilities of these implants are practically limitless. Threat actors may develop several actions, such as checking:
- A list of apps installed,
- The name of the Wi-Fi access point to which the victim is connected,
- Clipboard content that usually contains information of interest to the victim and, consequently, to the attacker.
Threat actors may even be able to learn the name of the APN that victims connect to while using the data plan through their provider.
Additionally, threat actors can actively monitor specific applications, such as the native email client and communications hub being used by a Windows Mobile device to process the victim’s communication data.
Considering the explanation in the introduction, it is probable that the most sensitive conversations take place in secure end-to-end mobile applications and not necessarily emails sent with PGP. Threat actors are aware of it, and that is why they have been actively working not only on developing implants for desktop computers, but also for mobile devices. We can say for sure that threat actors enjoy multiple benefits when they infect a mobile device, instead of a traditional computer. Their victims are always carrying their cell phones with them, so these devices contain information that their work computers won’t. Besides, mobile devices are usually less protected from a technological point of view, and victims oftentimes don’t believe their cell phones could ever become infected.
Despite a strong data encryption, a compromised mobile end point is completely exposed to spying, since threat actors have the same ability to read messages as users themselves. Threat actors don’t need to struggle with encryption algorithms, nor intercept data at the network layer level. They simply read this information the same way, as their victim would.
Mobile implants don’t belong to the group of massive attacks launched by cybercriminals; they are actually targeted attacks in which victims are carefully selected before the attack. What Makes You A Target?
There are several factors involved in being a target, including whether you are a politically exposed person, have contacts of interest to threat actors, are working on a secret or sensitive project that is also of interest, among others. One thing is certain: if you’re targeted by such an attack, the probability of infection is very high.
Everything we’re seeing now is a battle for numbers. You cannot decide whether you’ll become a victim, but one thing you could do is elevate the cost of such an attack to the point that threat actors might give up and move on to a less expensive target who is more tangible in terms of time invested and risk of the exploit campaign being discovered. How Can Someone Elevate the Cost of an Attack? Here is a set of best practices and habits in general. Each case is unique, but the main idea is to make threat actors lack motivation once it becomes too laborious to carry out their operation, thus increasing their risk of failure.
Among the basic recommendations to improve the security of our mobile devices, we could highlight the following:
- Always use a VPN connection to connect to the Internet. This will help making your network traffic not easily interceptable and susceptible to malware that could be directly injected into a legitimate application being downloaded from the internet.
- Do not charge your mobile devices using a USB port connected to a computer. The best thing you can do is to plug your phone directly into the AC power adapter.
- Install an anti-malware program. It has to be the best one. It seems that the future of these solutions lies precisely in the same technologies already implemented for desktop security: Default Deny and Whitelisting.
- Protect your devices with a password, not a PIN. If the PIN is found, threat actors may gain physical access to your mobile device and install the implant without your knowledge.
- Use encryption in the data storage memories implemented by your mobile devices. This advice is especially current for devices that allow for memory disks extraction. If threat actors extract your memory by connecting it to another device, they’ll also be able to easily manipulate your operating system and your data in general.
- Do NOT Jailbreak your device, especially if you’re not very sure what it implies.
- Don’t use second-hand cell phones that may already come with pre-installed implants. This piece of advice is especially important if your cell phone comes from someone you’re not very familiar with.
- Always keep the operating system in your mobile device updated and install the latest upgrade as soon as it becomes available.
- Review all processes being executed in your device memory.
- Review all authorized apps in your system and disable the automatic data submission function for logs and other service data, even if the communication is between your cell phone and your provider.
- Finally, keep in mind that, without a doubt, conventional conversations in a natural environment are always safer than those carried out electronically.
Perhaps one of the most explosively discussed subjects of 2015 was the compromise and data dump of Hacking Team, the infamous Italian spyware company.
For those who are not familiar with the subject, Hacking Team was founded in 2003 and specialized in selling spyware and surveillance tools to governments and law enforcement agencies. On July 5, 2015, a large amount of data from the company was leaked to the Internet with a hacker known as “Phineas Fisher” claiming responsibility for the breach. Previously, “Phineas Fisher” did a similar attack against Gamma International, another company in the spyware/surveillance business.
The hacking of Hacking Team was widely discussed in the media from many different points of view, such as the legality of selling spyware to oppressive governments, the quality (or lack of…) of the tools and leaked email spools displaying the company’s business practices.
One of these stories attracted our attention.How a Russian hacker made $45,000 selling a 0-day Flash exploit to Hacking Team
So reads the title of a fascinating article written for Ars Technica by Cyrus Farivar on July 10, 2015. The article tells the story of Vitaliy Toropov, a 33-year-old exploit developer from Moscow who made a living by selling zero-day vulnerabilities to companies such as Hacking Team.
In the Ars Technica article, Cyrus writes the following paragraph, which shows the original offer from the exploit seller:
Excerpt from the Ars Technica article
For a company like Hacking Team, zero-days are their “bread and butter” — their software cannot infect their targets without effective exploits and zero-days, especially those that can bypass modern defense technologies such as ASLR and DEP. Those exploits are in very high demand.
The trade between these two continued until they finally agreed on purchasing an Adobe Flash Player zero-day, now defunct, for which Vitaliy Toropov promptly received a $20,000 advance payment.
A good salesman, Vitaliy Toropov immediately mailed back and offered a discount on the next purchases. So writes Cyrus, in his Ars Technica story:
Excerpt from the Ars Technica article
This section of the story immediately spiked our attention. A Microsoft Silverlight exploit written more than two years ago and may survive in the future? If that was true, it would be a heavyweight bug, with huge potential to successfully attack a lot of major targets. For instance, when you install Silverlight, it not only registers itself in Internet Explorer, but also in Mozilla Firefox, so the attack vector could be quite large.The hunt for the Silverlight zero-day
In the past, we successfully caught and stopped several zero-days, including CVE-2014-0515 and CVE-2014-0546 (used by the Animal Farm APT group), CVE-2014-0497 (used by the DarkHotel APT group) and CVE-2015-2360 (used by the Duqu APT group). We also found CVE-2013-0633 a FlashPlayer zero-day that was used by Hacking Team and another unknown group.
We strongly believe that discovery of these exploits and reporting them to the affected software manufacturers free of charge makes the world a bit safer for everyone.
So while reading the Ars Technica story, the idea to catch Vitaliy Toropov’s unknown Silverlight exploit materialized.
How does one catch zero-days in the wild? In our case, we rely on several well-written tools, technologies and our wits. Our internal tools include KSN (Kaspersky Security Network) and AEP (Automatic Exploit Prevention).
To catch this possibly unknown Silverlight exploit we started by investigating the other exploits written by Vitaliy Toropov. Luckily, Vitaliy Toropov has a rather comprehensive profile on OVSDB. Additionally, PacketStorm has a number of entries from him:
This one caught our attention for two reasons:
- It is a Silverlight exploit
- It comes with a proof of concept written by Vitaly himself
One can easily grab the PoC from the same place:
Which we did.
The archive contains a well-written readme file that describes the bug, as well as source codes for the PoC exploit.
The exploit in this PoC simply fires up calc.exe on the victim’s machine. The archive includes a debug version compiled by the author, which is extremely useful to us, because we can use it to identify specific programming techniques such as specific strings or shellcode used by the developer.
The most interesting file in the archive is:
Size: 17920 bytes
This is the actual DLL that implements the Silverlight exploit from 2013, as coded by Vitaliy Toropov.
With this file in hand, we decided to build several special detections for it. In particular, we wrote a YARA rule for this file which took advantage of several of the specific strings from the file. Here’s what our detection looked like in YARA:
Pretty straightforward, no?
Actually, nowadays we write YARA rules for all high-profile cases and we think it’s a very effective way to fight cyberattacks. Great props to the Victor Manuel Alvarez and the folks at VirusTotal (now Google) for creating such a powerful and versatile tool!The long wait…
After implementing the detection, we waited, hoping that an APT group would use it. Since Vitaliy Toropov was offering it to Hacking Team, we also assumed that he sold it to other buyers, and what good is a zero-day if you don’t use it?
Unfortunately, for several months, nothing happened. We had already forgotten about this until late November 2015.
On November 25th, one of our generic detections for Toropov’s 2013 Silverlight exploit triggered for one of our users. Hours later, a sample was also uploaded to a multiscanner service from Lao People’s Democratic Republic (Laos).
This file was compiled in July 21, 2015, which is about two weeks after the Hacking Team breach. This also made us think it was probably not one of the older 2013 exploits but a new one.
It took us some time to analyse and understand the bug. When we were absolutely sure it was indeed a new zero-day exploit, we disclosed the bug to Microsoft.
Microsoft confirmed the zero-day (CVE-2016-0034) and issued a patch on January 12, 2016.Technical analysis of the bug:
The vulnerability exists in the BinaryReader class. When you create an instance of this class you can pass your own realization of the encoding process:
Moreover, for the Encoding process you can use your own Decoder class:
Looking at the BinaryReader.Read() code, we see the following:
Indeed, the “index” value was checked correctly before this call:
But if you will look deeper inside InternalReadChars (this function is marked as unsafe and it is using pointers manipulations) function you will see the following code:
The problem appears because the GetChars function could be user-defined, for instance:
Therefore, as you can see we can control the “index” variable from user-defined code. Let’s do some debugging.
This is a Test.buf variable, where 05 is the array length before triggering the vulnerability:
After calling BinaryRead.Read method we are stopping in InternalReadChars method (index is 0):
After this call we stopped in user-defined code:
This is a first call of user-defined function and we return incorrect value from it. In the next iteration, the “index” variable contains the incorrect offset:
After we change the offset we can easily modify memory, for instance:
This is a Test.buf object after our modifications in decoder method:
One of the biggest questions we have is whether this is Vitaliy Toropov’s Silverlight zero-day which he tried to sell to Hacking Team. Or is it a different one?
Several things make us think it’s one of his exploits, such as the custom error strings. Of course, there is no way to be sure and there might be several Silverlight exploits out there. One thing is for sure though – the world is a bit safer with the discovery and patching of this one.
One final note: due to copyright reasons, we couldn’t check if the leaked Hacking Team archive has this exploit as well. We assume the security community which found the other zero-days in the HackingTeam leaks will also be able to check for this one.
If you’d like to learn how to write effective YARA rules and catch new APTs and zero-days, why not take our elite YARA training before SAS 2016? Hunt APTs with Yara like a GReAT Ninja (with trainers Costin Raiu, Vitaly Kamluk and Sergey Mineev). The class is almost sold out!
Kaspersky products detect new Silverlight exploit as HEUR:Exploit.MSIL.Agent.gen.
с новым годом! Microsoft rings in the New Year with a new set of ten security bulletins MS16-001 through MS16-010, patching 24 CVE detailed vulnerabilities. These bulletins effect Microsoft web browsers and plugins, Office software, Windows system software, and Exchange mail servers. Six of them maintain a critical rating. The Critical bulletins effect the following software:
- Silverlight Runtime
- Internet Explorer
- Microsoft Edge
- VBScript and JScript scripting engine
- Microsoft Office, Visio, and SharePoint
- Windows Win32k Kernel Components
Somewhat surprisingly with over twenty vulnerabilities, Microsoft claims to be unaware of public exploitation of any of them at the time of reporting, however they acknowledge at least three were publicly disclosed. Nonetheless, the urgency to patch remains, so please update your software.
Of these, the Silverlight vulnerability CVE-2016-0034 (note that Mitre records the CVE as assigned on 2015.12.04) appears to be the most interesting and most risky, as it enabled remote code execution across multiple platforms for this widespread software, including Apple. But more of the IE, Edge and add-on related vulnerabilities also provide opportunity for mass exploitation. Don’t forget to return to Securelist soon for concrete perspective and upcoming posts detailing past and ongoing exploitation of these issues.
It’s also assuring to see Microsoft security operations pushing the edges of improving TLS algorithms to encrypt web sessions and provide greater privacy. Even their Technet page for a summary of these Bulletins provides TLS 1.2, implementing 3DES_EDE_CBC with HMAC-SHA1 and a RSA key exchange. But, it looks like their research group hasn’t pushed forward their work on post-quantum resistant TLS key exchange (Full RWLE Paper [pdf]), as “R-LWE in TLS” into production. Tomorrow’s privacy will have to wait.