Malware Alerts

Subscribe to Malware Alerts feed Malware Alerts
Online headquarters of Kaspersky Lab security experts.
Updated: 30 min 54 sec ago

DDoS attacks in Q4 2017

Tue, 02/06/2018 - 04:01

News overview

In terms of DDoS attacks, the last quarter of 2017 was livelier than the previous one. Some major botnets were discovered and destroyed. For instance, early December saw the FBI, Microsoft, and Europol team up to knock out the Andromeda botnet, in operation since 2011. In late October, the Indian Computer Emergency Response Team (CERT) issued a warning about a massive botnet being assembled by a hacker group using the Reaper and IoTroop malware; earlier that same month, the spread of Sockbot through infected Google Play apps was detected and terminated.

Besides the various battles with Trojan-infested botnets, the last three months of 2017 were dominated by three main DDoS trends: politically motivated attacks, attempts to cash in on the soaring price of Bitcoin, and tougher law enforcement.

Politically motivated DDoS attacks remain eye-catching, but fairly ineffective. In late October again, during parliamentary elections in the Czech Republic, the country’s statistical office was hit by a DDoS attack in the middle of the vote count. The attack was a nuisance, but nothing more, and the results of the elections were duly announced on time.

Another DDoS-based political protest was aimed at the Spanish government in connection with the Catalan question. Hacktivists from the Anonymous group managed to take down the website of Spain’s Constitutional Court, and defaced the Ministry of Public Works and Transport’s website with the message “Free Catalonia.”

But politics is politics, and business is, well, just that. As we noted in the previous quarter, Bitcoin and everything associated with it has hit peak commercial popularity — not surprising, considering the explosive growth in its value. No sooner had Bitcoin spawned a new kind of cryptocurrency in the shape of Bitcoin Gold (BTG) than BTG sites immediately came under DDoS fire. After the price of the cryptocurrency took off in November, DDoS attacks rained down on the Bitfinex exchange — apparently with the aim of profiting from Bitcoin price fluctuations caused by denial of service. Still punch-drunk from the November attack, Bitfinex was paralyzed by two more onslaughts in early December.

On the topic of total failure, it would be amiss not to mention the shutdown of four shadow markets in the deep web used for all kinds of illegal trade: Trade Route, Tochka, Wall Street Market, and Dream Market. They have been operating erratically ever since October. It wasn’t clear at first what was behind these massive, well-coordinated attacks: the law enforcement agencies (as in the recent destruction of AlphaBay and Hansa) or competitors attempting to encroach on their territory. The subsequent attacks on all other trading platforms in early December dispelled most analysts’ doubts that it was a full-scale cyberwar between drug cartels.

However, the law — in particular, the judicial system — is not sitting idly by. Q4 saw a whole host of charges and sentences handed down in DDoS-related cases. The US judicial system was the most active: in mid-December, three defendants, Paras Jha, Josiah White, and Dalton Norman, confessed to being the brains behind the Mirai botnet.

And in late December, the founders of the notorious hacker groups Lizard Squad and PoodleCorp — Zachary Buchta of the U.S. and Bradley Jan Willem van Rooy of the Netherlands — were convicted.

In Britain, the high-profile case of young hacker Alex Bessell from Liverpool went to trial. Bessell was recently jailed for having launched a series of major cyber attacks in the period 2011-2013 against such giants as Skype, Google, and Pokemon. An even younger British hacker who targeted NatWest Bank, the National Crime Agency, Vodafone, the BBC, and Amazon was handed 16 months’ detention, suspended for two years.

A curious incident concerned 46-year-old John Gammell of Minnesota, who was charged with hiring three hacking services to create problems for his former employers, the websites of the judicial system of the district where he lived, and several other companies where he was once a contractor. The sponsors of DDoS attacks are often hard to track down, but Gammel couldn’t resist the temptation to tease his targets with emails — which led to his capture. As the investigators reported, the hacking services dealt with Gammel very professionally and cordially, thanking him for procuring their services and even upgrading his membership.

Quarter trends

Q4 demonstrated that DDoS attacks can be categorized as persistent online “crosstalk.” Junk traffic has become so widespread that server failure from too many requests might not be attack-related, but the accidental result of botnet side activities. For instance, in December we logged a huge number of requests to non-existent 2nd and 3rd level domains, which created an abnormal load on DNS servers in the RU zone. A modification of the Lethic Trojan turned out to be the culprit. This long-known malware comes in many different flavors, its main task being to allow spam traffic to pass through infected devices, basically like a proxy server.

The version we discovered was unlike most modifications in that it operates in multiple threads to create a huge number of requests to non-existent domains. The study found that this behavior was an attempt to mask the command-and-control (C&C) server addresses behind numerous junk requests, and the excessive load on the DNS servers was simply the result of the malware’s poor design. Nevertheless, DDoS attacks on DNS servers using junk requests are quite common and easy to implement. Our experts have assisted clients in many such instances. What’s interesting here is the method employed, as well as the perhaps unintended effect.

Statistics for botnet-assisted DDoS attacks Methodology

Kaspersky Lab has extensive experience of combating cyber threats, including DDoS attacks of various complexity types and ranges. Company experts track the actions of botnets by using the DDoS Intelligence system.
Being part of the Kaspersky DDoS Prevention solution, the DDoS Intelligence system intercepts and analyzes commands sent to bots from C&C servers and requires neither the infection of any user devices, nor the actual execution of cybercriminals’ commands.

This report contains DDoS Intelligence statistics for Q4 2017.

In the context of this report, it is assumed that an incident is a separate (single) DDoS-attack if the interval between botnet activity periods does not exceed 24 hours. For example, if the same web resource was attacked by the same botnet with an interval of 24 hours or more, then this incident is considered as two attacks. Also, bot requests originating from different botnets but directed at one resource count as separate attacks.

The geographical locations of DDoS-attack victims and C&C servers used to send commands are determined by their respective IP addresses. The number of unique targets of DDoS attacks in this report is counted by the number of unique IP addresses in the quarterly statistics.

DDoS Intelligence statistics are limited only to those botnets detected and analyzed by Kaspersky Lab. It should also be noted that botnets are just one of the tools for performing DDoS attacks; thus, the data presented in this report do not cover every single DDoS attack that occurred during the specified period.

Quarter results
  • In Q4 2017, DDoS attacks were registered against targets in 84 countries (98 in Q3). However, as in the previous quarter, the overwhelming majority of attacks occurred in the top ten countries in the list (94.48% vs. 93.56%).
  • More than half of all attacks in Q4 (51.84%) were aimed at targets in China — almost unchanged since Q3 (51.56%).
  • In terms of both number of attacks and number of targets, South Korea, China, and the US remain out in front. But in terms of number of botnet C&C servers, Russia pulled alongside this trio: its relative share matched China’s.
  • The longest DDoS attack of Q4 2017 lasted 146 hours (just over six days). This is significantly shorter than the previous quarter’s record of 215 hours (almost nine days). 2017’s longest attack (277 hours) was registered in Q2.
  • The days before and after Black Friday and Cyber Monday saw increased activity on dummy Linux servers (honeypot traps), which lasted right up until the beginning of December.
  • SYN DDoS remains the most common attack method, while the least popular is ICMP DDoS. According to Kaspersky DDoS Protection data, the frequency of multi-method attacks rose.
  • In Q4 2017, the share of Linux botnets climbed slightly to 71.19% of all attacks.
Geography of attacks

In Q4 2017, DDoS attacks affected 84 countries, which represents a slight improvement over the previous quarter, when 98 countries were hit. Traditionally, China is most in the firing line, although the country’s share of attacks decreased slightly (from 63.30% to 59.18%), approaching the Q2 level. The figures for the US and South Korea, which retained second and third place, went up slightly to 16.00% and 10.21%, respectively.

Fourth place went to Britain (2.70%), which climbed 1.4% to overtake Russia. Although Russia’s share of attacks dropped insignificantly (by 0.3%), that was enough to push it into sixth place behind Vietnam (1.26%), which made a return to the leaderboard, squeezing Hong Kong out of the top ten.

Distribution of DDoS attacks by country, Q3 and Q4 2017

The percentage of attacks directed against targets in the top ten countries grew in the last quarter (but not by much) to almost 92.90% vs. 91.27% in Q3 2017. The landscape is much the same as before.

About half of all targets are still in China (51.84%), followed by the US (19.32%), where the number of targets is again nearing 20% after a slight dip in Q3; South Korea is third with 10.37%. Vietnam again ousted Hong Kong from the top ten, taking ninth place with a 1.13% share, while Russia (1.21%) came seventh with a loss of 1%, making way for Britain (3.93%), France (1.60%), Canada (1.24%), and the Netherlands (1.22%), whose figures did not change much against the previous quarter.

Distribution of unique DDoS-attack targets by country, Q3 and Q4 2017

Dynamics of the number of DDoS attacks

Statistical analysis of specially prepared Linux servers —  so-called honeypot traps — shows that peak botnet activity this quarter occurred during the pre- and post-holiday sales. Feverish cybercriminal activity was clearly observed around Black Friday and Cyber Monday, dying down by the second third of December.

The most significant peaks occurred on November 24 and 29, when the number of individual IPs storming our resources doubled. Some increase in activity was also observed in late October — most likely Halloween-related.

Such fluctuations point to attempts by cybercriminals to boost their botnets in the run-up to major sales. Pre-holiday periods are incubators of cybercriminal growth for two reasons: first, users are less discerning and more likely to “surrender” their devices to intruders; second, the prospect of a fast buck makes it possible to blackmail Internet companies with lost profits or to offer one’s services in the cut-throat struggle online.

Dynamics of the number of Linux-based attacks in Q4 in 2017*
*Shows changes in the number of unique IPs per 24 hours


Types and duration of DDoS attacks

In Q4, the share of SYN DDoS attacks decreased (from 60.43% to 55.63%) due to less activity by the Linux-based Xor DDoS botnet. These attacks still rank first, however. The percentage of ICMP attacks (3.37%), still the least common, also fell. The relative frequency of other types of attacks increased, but whereas in the previous quarter TCP attacks ranked second after SYN, UDP overshadowed both these types, rising from second-to-last to second-from-top (in Q4 UDP DDoS accounted for 15.24% of all attacks).

Distribution of DDoS attacks by type, Q4 2017

Kaspersky DDoS Protection annual statistics show a decline in the popularity of DDoS attacks involving only pure HTTP and HTTPS flooding. The frequency of multi-method attacks rose accordingly. Nevertheless, one in three mixed attacks contained an HTTP or HTTPS flood. This may be due to the fact that HTTP(S) attacks are quite expensive and complex, while in a mixed attack they can be used by cybercriminals to increase the overall effectiveness without additional costs.

Correlation between attack types according to Kaspersky DDoS Protection, 2016 and 2017

The longest attack in Q4 was significantly shorter than its Q3 counterpart: 146 hours (about 6 days) vs. 215 (about 9). That’s barely half the Q2 and 2017 record of 277 hours. Overall, the share of longish attacks continues to decline, albeit insignificantly. This also applies to attacks lasting 100-139 hours and 50-99 hours (the shares of these categories are so small that even a change of 0.01% is news). The most common are still micro-attacks, lasting no more than four hours: their share rose slightly to 76.76% (vs. 76.09% in Q3). Also up was the proportion of attacks lasting 10-49 hours, but again not by much — about 1.5%.

Distribution of DDoS attacks by duration (hours), Q3 and Q4 2017


C&C servers and botnet types

The top three countries by number of C&C servers remained as before: South Korea (46.63%), the US (17.26%), China (5.95%). Yet although the figures for the latter two climbed slightly against Q3, China had to share third place with Russia (7.14%), which gained 2%, the reason being that despite the fact that the leaders’ share changed insignificantly percentage-wise, in absolute terms the number of C&C servers detected in all three countries almost halved. This is at least partially due to the termination of many Nitol botnet admin servers and the less active Xor botnet. On a separate note, this category’s top ten welcomed Canada, Turkey, and Lithuania (1.19% each), while Italy, Hong Kong, and Britain departed the list.

Distribution of botnet C&C servers by country, Q4 2017

The steady increase in the number of Linux-based botnets continued this quarter: their share now stands at 71.19% against Q3’s 69.62%. Accordingly, the share of Windows-based botnets fell from 30.38% to 28.81%.

Correlation between Windows- and Linux-based botnet attacks, Q4 2017



Q4 2017 represented something of a lull: both the number and duration of DDoS attacks were down against the previous quarter. The final three months of 2017 were even calmer than the first three. Alongside the rising number of multicomponent attacks involving various combinations of SYN, TCP Connect, HTTP flooding, and UDP flooding techniques, the emerging pattern suggests a backsliding for DDoS botnets in general. Perhaps the economic climate or tougher law enforcement has made it harder to maintain large botnets, causing their operators to switch tactics and start combining components from a range of botnets.

At the same time, the increase in the number of attacks on honeypot traps in the runup to holiday sales indicates that cybercriminals are keen to expand their botnets at the most opportune moment, looking to grab a slice of the pie by pressuring owners of online resources and preventing them from making a profit. In any event, the DDoS spikes around Black Friday and Cyber Monday were a salient feature of this quarter.

Another aspect of the late fall/early winter period was the continued attacks on cryptocurrency exchanges in line with the trends of the past months. Such fervor on the part of cybercriminals is not surprising given the explosive growth in the price of Bitcoin and Monero. Barring a collapse in the exchange rate (short-term fluctuations that only encourage speculators do not count), these exchanges are set to remain a prime target throughout 2018.

What’s more, the last quarter showed that not only are DDoS attacks a means to make financial or political gain, but can produce accidental side effects, as we saw last December with the junk traffic generated by the Lethic spam bot. Clearly, the Internet is now so saturated with digital noise that an arbitrary resource can be hit by botnet activity without being the target of the attack or representing any value whatsoever to the attackers.

Every little bitcoin helps

Thu, 02/01/2018 - 04:03

It often happens that inventions and technologies that start out good end up turning into dangerous tools in the hands of criminals. Blockchain is no exception to this rule, especially in its most common cryptocurrency incarnation. Cryptocurrencies crop up in all kinds of spam: from traditional advertising (courses about investment and trade) to more fraudulent and malicious varieties. Quite often, cryptocurrencies are used by attackers as originally intended — as a means of payment (albeit from victims). We found and delved into several spam mailings in which cybercrooks exploited user paranoia about information threats and took bitcoins as payment for peace of mind. The attacks targeted employees of small companies, but such emails could be sent to any user’s personal mail.

In the first email, the attacker claimed to have installed malware on a porn site visited by the victim, and to be in possession of several videos recorded from both the device screen and cameras; not only that, a keylogger had supposedly provided access to the user’s IM, email, and social media contacts. To get the attacker off their back, the victim was asked to transfer the equivalent of $320 to the bitcoin wallet specified in the email. It was also mentioned that a built-in tracking pixel would inform the attacker that the email had been seen. And if the recipient wanted proof of that, they should reply to the message, whereupon the compromising info would be sent out to five of their contacts. As a postscript, the scammer warned against going to the police: he allegedly lived in Belarus, so the investigation would drag on for years.

The next email was wordy but imaginative, written by a hacker by the name of Andrey. The attacker informed the recipient that he had studied the latter’s company, together with its employees and their relatives, found weaknesses, and was planning to ruin it. The author listed no fewer than seven ways to achieve this goal, from simply writing negative reviews on various websites to creating fake company reports in his garage(!) and sending them to government departments. However, the hacker’s preferred outcome was for the company to see sense and transfer 3 bitcoins to his wallet. Like the previous email, it specifically mentioned not going to the cops, since “Andrey” lived in Ukraine.

Another email was the work of not one hacker, but an entire chain gang. The attackers allegedly had hacked the company’s server and got hold of information about its clients, bank accounts, tax payments, etc. Now they were threatening to damage the company’s reputation by publishing this information online. It was also stated that at some unspecified moment they would launch an attack on the company’s servers and computers, encrypting all data. To call off the attack, the blackmailers demanded 0.5 bitcoin. If the cryptopayment was not made before the start of the attack, the amount would rise to 2 bitcoins.

Sadly and (perhaps) surprisingly, some people still fall for such concoctions. The targets of these mailings are usually small companies that lack the resources for decent anti-spam protection and basic information security training for staff. So let us reiterate: be vigilant, stay calm, and take anonymous threats of this kind with a pinch of salt.

Cybercriminals target early IRS 2018 refunds now

Wed, 01/31/2018 - 12:54

On Monday, Jan 29th, IRS officially opened its 2018 season. Some taxpayers already filed their taxes and cybercriminals know it too. So, right after two days of the official 2018 season opening, we got phishing messages with a fake refund status Websites:

The link in the email leads to a hacked Brazilian restaurant, redirecting to Website with Australian domain zone.

So, the whole scheme is to steal credit card information of the taxpayers expecting a tax refund from IRS. Both URLs are blocked by Kaspersky Anti-Phishing now.

The mentioned Website was hacked and includes an old Webshell uploaded back to 2016.

Should we expect more campaigns like this? Definitely yes. Stay watchful and don’t lose your refunds!

Denis and Co.

Thu, 01/25/2018 - 06:00

In April 2017, we published a detailed review of a malicious program that used DNS tunneling to communicate to its C&C. That study prompted us to develop a technology to detect similar threats, which allowed us to collect a multitude of malware samples using DNS tunneling.

In this article, we will examine some of the most notable malicious programs that use DNS tunneling. Kaspersky Lab’s security products detect them with generic (‘Trojan.Denes.UDP.C&C’ or ‘Backdoor.Win32.Denis.*’) or individual verdicts.


The first piece of malware we’ll look at has a multi-layer C&C communication protocol structure that is similar to the OSI model and sets it apart from all the other Trojans reviewed here. The creators of Trojan.Win32.Ismdoor.gen have obviously put a lot of effort into its design and development.

Of course, for its transport layer this Trojan uses a DNS tunnel. The length of outgoing ‘datagrams’ are limited to 60 characters, though DNS server configurations and the actual protocol permit this value to be larger. The C&C server’s commands are resolved into IPv6 addresses.

A typical query sent to the C&C server looks like this:

n.n.c.<Session ID >.<Server domain>.com

Structure of transport layer request and response

There is a session layer protocol in place above the DNS tunnel transport layer, which implies the ability to exchange ‘short’ and ‘long’ packets. It differs from the transport layer in that it has a mechanism to check for lost messages. While a transport layer session closes with the exchange of data on the number of packets sent and received, a session layer closes by checking that every sent packet has been received correctly. It is up to the server which option to use; for instance, the ‘long’ packet protocol is used for uploading files from an infected computer.

Example of short message exchange protocol

Short messages

At this level, the bot’s operation can be broken down into five steps:

  • Declare session ID to server;
  • Send a message in packets;
  • Send the number of packets sent;
  • Receive the number of incoming packets;
  • Receive incoming packets.

A session example:

  1. Declare session ID to server

Each time a communication session is opened the bot generates a GUID and sends it to the server. This GUID is then used to identify all communications within that session, and is always written in the third-level domain position. In this case, the URL has the following structure:

n.n.c.<Session ID>.<Server domain>.com

The message A67DDB8A2A17334765443253702AA3 is a positive response. Otherwise, the GUID is sent to the server again.

  1. Send a message in packets

As we said earlier, the selected communication mechanism imposes certain restrictions on packet sizes. An outgoing message is broken into packets 60 bytes long, and sent in the form of URLs:

<Outgoing packet>.<Packet number>.dr.<Session ID >. <Server domain>.com

The response must be A67DDB885A3432576548A2A3707334.

  1. Send the number of packets sent

When all packets have been sent successfully, their number is sent as a query in the following format:

n.<Number of packets>.f.<Session ID >.<Server domain>.com

It should be noted that the packet numbering starts with 0. The response is 20202020202020202020202020202020.

  1. Receive the number of incoming packets

This step is implemented with the following type of URL format:

n.n.fc.<Sessions ID >.<Server domain>.com

The response must be in the following format:

A67D: DB8: 85A3: 4325: 7654: 8A2A :: <Number of incoming packets>

  1. Receive incoming packets

The request to receive the next packet looks like this:

www. <Packet number>.s. <Session ID > .<Server domain>.com

The incoming messages come in the form of 16-byte IPv6 packets.

Long messages

In this case, communication with the server can be broken down into the following steps:

  • Send the number of packets which the file was divided into;
  • Send the file;
  • Send periodic queries to server to check for lost packets;
  • Resend lost packets.

The session ID comes from the query in which the file was requested.

  1. Send the number of packets

Query: n.<Number of packets>.<Session ID >.<Server domain >.com

Response: A67DDB8A2A17334765443253702AA3.

  1. Send the file in packets

Query: <Outgoing packet>.<Packet number >.d.<Session ID >.<Server domain >.com

Response: the server does not reply to this message, or sends a ‘Server failure’ response.

  1. Send periodic queries to server to check for lost packets

Over regular intervals, the bot sends the following query to the server:

uff<Number of packets>.< Number of packets >.<Server domain >.com

Response: 20202020202020202020202020202020

After that, the steps ‘Receive the number of incoming packets’ and ‘Receive incoming packets’ from the previous section are implemented.

In response, the numbers of packets – separated by commas – that the server has missed are sent.

  1. Resend lost packets

Query: <Outgoing packet>.<Packet number>.dl.<Session ID>.<Server domain>.com

The presentation layer in OSI is responsible for coding and decoding messages. The server response contained in an IPv4 address field is a regular ASCII string that is divisible by sixteen. The query to the server contained in a DNS query is coded in Base64 with a redefined index table.

Example of the first message and its representation in the ‘datagram’ body

The application layer is simply a set of GET-like queries to the C&C server:

  • Check connection. This query is the string ‘M:CC?’;
  • Register connection. This determines the available commands, and the IDs of the infected computer and the bot (M:AV?appId=<…>&uniqueId=<…>);
  • Registration confirmation command;
  • ‘Generic’ response (M:ME?appId=<…>&message=<…>);
  • Receive command (M:GAC?appId=8);
  • Confirm command (M:CR?cd=<Command GUID>);
  • Send file (M:SF?commandId=CmdResult=<Command GUID>|||<Result of command execution >);
  • Receive file (M:GF?).

As stated above, this Trojan is well designed and written, has a well-thought-out system of communication as well as a payload rich in capabilities. Below is a list of its main commands:

  • SI — send information about the infected system;
  • RunNewVersion — update;
  • Restart — restart;
  • remove — remove itself;
  • CreateMimi1Bat — execute Mimikatz;
  • ExecuteKL — activate keylogger;
  • RemoveKL — remove files created by ExecuteKL;
  • GetVersion — report the Trojan’s version;
  • PauseUpload —suspend uploading files to the server;
  • ResumeUpload — resume uploading files to the server;
  • PauseDownload —suspend downloading files from the server;
  • ResumeDownload — resume downloading files from the server;
  • PWS — take a screenshot;
  • DownloadFile — download a file from the server;
  • UploadFile — upload a file to the server.

The other commands available to the Trojan are responsible for the logic of its operation (such as changing the C&C address, etc.).


This next sample uses a different workflow based on ANY DNS packets. This mechanism allows the malicious program to receive DNS packets of a random structure from the server. With this Trojan, there is no logical breakdown into sub-protocols – there are just outgoing and incoming requests. We were able to detect several modifications of this Trojan. Below, we describe features and characteristics present in all of them.

One interesting peculiarity of Backdoor.Win32.ClIEcker is how it finds out the victim computer’s IP address – to do so it uses Internet Explorer’s COM interface. The Trojan contains a list of website addresses where the visitor can see their own IP address (such as The Trojan randomly selects one of these, visits that address, finds the string in the body of the page that is followed by the IP address, and extracts it. To disguise this query as much as possible, the Trojan will also select a random referral address and use it in the appropriate request to Internet Explorer.

The only thing that remains unclear is why such a complicated method is used; typically, Trojans find out a computer’s IP address by requesting data from sites that return a string containing the IP address as an HTML page. Perhaps it was done in an attempt to avoid resolving to an IP address that may be in the IoC list for this Trojan, or it might just have been a thoughtless cut-and-paste job from a code repository or forum.

To complicate things even further, the Trojan supports a command to open a website in Internet Explorer upon request from the server – for this, a trivial call in the form “IEXPLORE.EXE” is used, rather than the complex COM interaction. Because of this, the Trojan could be detected as a Trojan-Clicker, though, as we explained in an earlier article, Trojan Clickers typically use a virtual desktop to do this.

Examples of URL addresses used for resolving IP/referral address and receiving page contents via COM

In the initiating request, several parameters describing the victim system are sent along with a unique RC4 key that’s created using the following info about the victim computer:

  • Major version of the operating system;
  • Logical flag indicating if a modem connection is used or not;
  • Trojan ID;
  • User’s encrypted IP address;
  • Antivirus service code.

Some explanation should be given for the last point. The Trojan contains a list of security software; each security product is coded by a bit in this code sent to the server. For example, all processes related to McAfee products will be denoted by the flag 0x400 in the antivirus service code.

Next, we will give a description for some of the commands:

Code Arguments Description 0 File name Execute the downloaded file. 1 URL Open the specified webpage in IE. 2,3 NULL These commands must receive the code for the executable file as an argument, save the file and run it. In the first case, the current version of the Trojan ceases running. For some reason, these commands are disabled. The Trojan ignores the rest of this list of commands and proceeds to request a new one. 5 Server query period in minutes There are two possible values for the server query period. One is used if the previous list of commands was executed in full. Otherwise, the other is used. This command sets the wait period for the first option. 6 NULL Stop running. 7 Wait period in minutes Pause for the specified period. 18 Modifier If the modifier is >= 0, then the next command on the list is executed. Otherwise, processing of the list terminates. 19 Server query period in minutes Sets the server query period in the event that processing of the list was interrupted. 21 NULL Sets flag for prompt reconnection. This allows the Trojan to query the server for a new list of commands immediately after it completes the previous list. 22 NULL Delete the downloaded file. 23 File name Set a new name for the downloaded file.

The command with code 8 deserves special attention, as it contains the Trojan’s main functions. Its job is to download and launch the payload. This command has the following arguments:

Name of argument Description File_Size Size of the downloaded file. SessionID Session ID. ServerKey Key for RC4 received from the server. GetFile_URL URL for file download. DNS_URL URL of the DNS server which will be used to create a DNS tunnel. GetPacketInterval Server query period for the next packet. KeyMod Flag for modifying the key. ReportURL URL of the server where successful file download will be reported. ExecMode File execution modifier. If it is larger than 2, the file will be neither saved nor executed. If it equals 2, the file will be saved and executed. Otherwise, the Trojan will attempt to inject the downloaded file into the IE process. Packet_Number Packet number.

The file is transferred in TXT DNS packets.

All communication with the server is, by default, encrypted with an RC4 key that is generated based on information about the victim computer. However, the server may request that the key be changed, and send a new key in a file download request. In any case, the key required for generating the S-box is encrypted with itself, and the resulting string is subsequently used. The S-box is modified according to the packet number, so it is unique for every new packet.

When decryption is completed, the integrity of the resulting file is checked with CRC32.


Backdoor.Win32.Denis has the simplest structure and the simplest DNS server communication functionality. This piece of malware has the same name as the Trojan described in this article, however, all similarities finish there.

This malicious program uses A DNS-format packets to communicate with the DNS server; in this format, the response size is limited to 4 bytes. All indicators point to this being a regular Trojan Downloader, and it is quite slow in downloading files. The typical format of a message sent to the server looks like this:

IC<Container type>.<UID>.<Container>.<Server address>

By ‘container’, we mean the results of the Trojan’s operation in a packed form. The structure of the container may vary significantly depending on the command and the response. UID is the user’s ID that is 0x20 bytes long. It is a Base32 string which, after decoding, has the following structure:

Offset Description 0x0 – 0xF Contains the user host name. 0x10 – 0x14 Contains the user IP address.

The container is also a Base32 string:

Offset Description 0x0 – 0x3 The time taken to create the message in seconds. 0x4 – 0xB ‘IACIMAOQ’ signature. 0xC – 0x22 Message.

A total of four types of containers exist. The Trojan determines which one is required, depending on the command it has received, and the results of executing it:

Type Purpose Message Description 1 Send information about the victim system. Information about the logical drives in the user’s system. The first byte indicates the amount of data sent. Pairs of bytes then follow: the letter of the logical drive and its type. The rest is filled with arbitrary characters. 2 Send information about the status of file receiving. Real file size, the current file size, counter of lost responses. If the transferred file does not exist yet, it is created and the container type is changed to 1. Otherwise, a message is sent in which the first 4 bytes contain the complete file size that was received in the message coded 0xC0. The next 4 bytes store the current file size. The next 4 bytes contain the counter of lost messages coming from the server. The rest is filled with arbitrary characters. 3 Send information about successful receipt of the file. No Prior to each network communication, the current file size is compared to real file size. If they match, then container type is changed to 4. 4 Send information about the successful execution of the command with code 0xCB. No NULL


Code Arguments Description 0x7F Stored in the 4th byte. Number of minutes. Pause for the specified number of minutes. Send container type 1. 0xC0 Stored in the last three bytes. The size of the transferred file. Receive the size of the transferred file. Send container type 2. 0xCB NULL Rename the current executable file to < APPDATA>\ IACIMAOQ. Send container type 4. 0xA The 2nd byte stores the number of the packet. The 3rd and 4th bytes are a pair of bytes of the transferred file. Receive part of file and write it. Send container type 1.

As can be seen from the description of commands, this Trojan’s purpose is to download and launch files.


15b36b1e3a41ad80bbd363aea8f2d704 — Trojan.Win32.Ismdoor.gen
1FD599FB9FA62EB91511002771D78104 — Backdoor.Win32.ClIEcker
1f3a2c48a7f5c2c31e71f552d74c3543 — Backdoor.Win32.Denis

A silver bullet for the attacker

Mon, 01/22/2018 - 10:51

In the past years, the problem of vulnerabilities in industrial automation systems has been becoming increasingly important. The fact that industrial control systems have been developing in parallel with IT systems, relatively independently and often without regard for modern secure coding practices is probably the main source of ICS security problems. As a result of this, numerous custom solutions have appeared, including proprietary network protocols and algorithms for authentication and encryption. It is these solutions that were the main source of threats discovered by ICS IT security researchers. At the same time, we can see that industrial automation systems derive some of their problems from common technologies (examples include CodeSys Runtime, Microsoft Windows vulnerabilities, etc.).

Companies attach different priority levels to such problems and the risks associated with them. It is obvious for everybody that vulnerability information should never be disclosed until a patch is released. However, many companies believe that this information should not be published even when a patch is available. For software developers, this is always a blow to their reputation. And companies that use vulnerable systems are not always physically able to install a patch or this installation may involve significant costs (interrupted operation of the systems to be updated, the cost of work related to installing updates, etc.).

We assess risks based on our experience of a security system developer and supplier. We are convinced that it is absolutely essential to inform users of vulnerable software about the new threat and the need to update their software as soon as possible. This certainly does not guarantee that all users of vulnerable systems will promptly update them and the threat will go away. However, in our experience, if this is not done very few users update their systems in a timely manner, even if patches are available. We confront hundreds of thousands of new threats every day and we can see that threat actors are on a constant lookout for new attack opportunities. And we realize that by keeping silent about problems we give those threat actors a chance.

This is why we decided to share information on one of our discoveries: according to our research, connecting a software license management token to a computer may open a hidden remote access channel for an attacker.

Why we decided to analyze SafeNet Sentinel

While performing various penetration tests, Kaspersky Lab ICS CERT experts repeatedly encountered the same service on the computers of customers who used software and hardware solutions by different industrial vendors. The experts didn’t attach much importance to it until it was found to be vulnerable. The service was hasplms.exe, which is part of the SafeNet Sentinel hardware-based solution by Gemalto. The solution provides license control for software used by customers and is widely used in ICS and IT systems.

The solution’s software part consists of a driver, a web application and a set of other software components. The hardware part is a USB token. The token needs to be connected to a PC or server on which a software license is required. Some of the USB token models are listed in the table below.

License control solutions of this type are based on the following operating principles: a software product requires a license to operate properly; when a USB token is plugged into the computer, the software “sees” the license and becomes fully functional. The token must be plugged in every time the software is started and remain connected while it is in use. The software part of the Gemalto solution is installed once and remains functional regardless of the life cycle of the software requiring a token.

This Gemalto solution is used in products by other software vendors, including such companies as ABB, General Electric, HP, Cadac Group, Zemax and many other organizations, the number of which, according to some estimates, reaches 40 thousand.

According to the results of independent research conducted by Frost and Sullivan in 2011, SafeNet Sentinel, which is currently owned by Gemalto, has a 40% market share for license control solutions in North America and over 60% in Europe.

The number of end users who use Gemalto solutions is not known. However, if each company has 100 clients, the number of users is in the millions. Unfortunately, few people realize that connecting a token to a computer to control licenses may not be a safe thing to do.

Vulnerabilities and attack vectors

From researchers’ viewpoint, hasplms.exe exhibited a rather curious behavior in the system: it could be remotely accessed and communicated with on open port 1947. The protocol type was defined by the network packet header – either HTTP or a proprietary binary protocol was used. The service also had an API of its own, which was based on the HTTP protocol.

Analyzing the service was made more difficult by the fact that the binary file used a VMProtect-type protector and generated its bytecode from the original Gemalto code. Due to this, it was decided to use fuzzing as the main tool for analyzing the vulnerable service’s behavior.

First of all, we looked at the localization function – the user could download language packs consisting of two files, one of which was localize.xml. The second file, in HTML format, had parameters, one of which turned out to be vulnerable to buffer overflow. It would have been a simple vulnerability, if it wasn’t for one curious detail: although, as mentioned above, a protector was used, for some reason the developers did not use any of the classical mechanisms providing protection from such binary vulnerabilities (such as Stack Canary, Stack Cookie, ASLR, etc.). As a result, a simple buffer overflow could allow an attacker to execute arbitrary code on the remote system.

Note that such software development flaws are very rare in modern solutions. As a rule, secure coding practices are implemented when developing serious commercial products (such as SDL – security development lifecycle), which means that security is designed into applications at the development stage, rather than being implemented as an additional option.

This attack vector can be used without LPE (local privilege escalation) – the vulnerable process runs with SYSTEM privileges, enabling malicious code to run with the highest privileges.

Sample script loading a language pack file

Result of Buffer Overflow exploitation, leading to RCE

The vulnerability was assigned the number CVE-2017-11496.

This was just one of the vulnerabilities we found. And the overall result of our research was disquieting.

In late 2016 – early 2017, 11 vulnerabilities were identified: two allowed remote code execution if exploited and nine were denial-of-service vulnerabilities.

By June 2017, Kaspersky Lab ICS CERT had identified three more vulnerabilities: an XML bomb and two denial-of-service flaws, one of which could potentially lead to remote execution of arbitrary code.

In total, 14 vulnerabilities have been identified, all quite dangerous (for example, exploitation of each of the Remote Execution of Arbitrary Code type vulnerabilities is automatically performed with SYSTEM privileges, i.e., the highest privilege level in Windows).

All attack vectors affecting the vulnerable service were multi-stage.

We promptly sent all information on the vulnerabilities identified to Gemalto. The vulnerabilities were assigned the following respective CVE numbers:

In addition to vulnerability descriptions, we sent a description of peculiar functionality to Gemalto.

Peculiar functionality

Kaspersky Lab ICS CERT experts have found that hasplms.exe has some rather unusual functionality:

  • When a Gemalto USB token is first connected to a computer (even if the active session is blocked), a driver and service that accepts network connections on port 1947 are installed if the Internet access is available.
  • If a driver is manually downloaded from the Gemalto website and installed, a driver and service that accept network connections on port 1947 are installed and port 1947 is added to Windows firewall exceptions.
  • If Gemalto software is installed as part of a third-party installation file, port 1947 is also added to Windows firewall exceptions.
  • There is an API function which enables or disables the administrative panel in the web interface, making it possible to modify the settings of the program part of the SafeNet Sentinel hardware-based solution. The panel is available by default on the localhost IP address –
  • The API can be used to change the internal proxy settings for updating language packs.
  • After changing the proxy server, the service’s internal logic can be used to obtain the NTLM hash of the user account under which the hasplms.exe process is running (i.e., SYSTEM).

This appears to be an undocumented feature and can be used for stealthy remote access. This means that remote attackers can use these capabilities to gain access to the administrative panel of the Gemalto software, carry out attacks with system user privileges and conceal their presence after completing these attacks.

As mentioned above, Gemalto representatives were informed of this attack vector.

Non-transparent security

Solutions, technologies or individual software modules used by many third-party vendors often do not undergo proper security testing. This potentially opens up new attack vectors. At the same time, closing vulnerabilities in such products, which are often used, among other applications, in banking and industrial control systems, is not always a smooth process: for some reason, vendors of such systems are in no hurry to notify their users of problems identified in their products.

In early 2017, we sent information about 11 vulnerabilities we had identified to Gemalto. It was only in late June that, in response to our repeated requests, the vendor informed us that a patch had been released and information about the vulnerabilities that had been closed, as well as a new version of the driver, could be found on the company’s internal user portal.

On June 26, we informed Gemalto of the suspicious functionality and of three more vulnerabilities. This time, things went quicker: on July 21 the vendor released a private notice on a new driver version – without any mention of the vulnerabilities closed.

According to Gemalto, the company has notified all of its customers of the need to update the driver via their account dashboards. However, this was apparently not sufficient: after we published information about the vulnerabilities identified, we were contacted by several developers of software which uses hasplms. It became clear from our communication with them that they were not aware of the problem and continued to use versions of the product with multiple vulnerabilities.

Update software to the current version (7.6) ASAP

We urge those users and companies that use Gemalto’s SafeNet Sentinel to install the latest (secure) version of the driver as soon as possible or contact Gemalto for instructions on updating the driver. We also recommend closing port 1947, at least on the external firewall (on the network perimeter) – but only as long as this does not interfere with business processes.

In the case of installing the driver via Microsoft Windows Update servers, we recommend checking hasplms.exe to make sure it is the latest version. If an obsolete version is used, it is crucial to install the latest (secure) version of the driver from the vendor’s website or contact Gemalto for instructions on updating the driver.

We also recommend closing port 1947, at least on the external firewall (on the network perimeter) – but only as long as this does not interfere with business processes. This will help to reduce the risk of the vulnerabilities being exploited.

Some software vendors who use third-party solutions as part of their products may be very thorough about the security of their own code, while leaving the security of third-party solutions to other companies (the vendors of these solutions). We very much hope that most companies act responsibly both with respect to their own solutions and with respect to third-party solutions used in their products.

Skygofree: Following in the footsteps of HackingTeam

Tue, 01/16/2018 - 05:00

At the beginning of October 2017, we discovered new Android spyware with several features previously unseen in the wild. In the course of further research, we found a number of related samples that point to a long-term development process. We believe the initial versions of this malware were created at least three years ago – at the end of 2014. Since then, the implant’s functionality has been improving and remarkable new features implemented, such as the ability to record audio surroundings via the microphone when an infected device is in a specified location; the stealing of WhatsApp messages via Accessibility Services; and the ability to connect an infected device to Wi-Fi networks controlled by cybercriminals.

We observed many web landing pages that mimic the sites of mobile operators and which are used to spread the Android implants. These domains have been registered by the attackers since 2015. According to our telemetry, that was the year the distribution campaign was at its most active. The activities continue: the most recently observed domain was registered on October 31, 2017. Based on our KSN statistics, there are several infected individuals, exclusively in Italy.

Moreover, as we dived deeper into the investigation, we discovered several spyware tools for Windows that form an implant for exfiltrating sensitive data on a targeted machine. The version we found was built at the beginning of 2017, and at the moment we are not sure whether this implant has been used in the wild.

Malware Features


According to the observed samples and their signatures, early versions of this Android malware were developed by the end of 2014 and the campaign has remained active ever since.

Signature of one of the earliest versions

The code and functionality have changed numerous times; from simple unobfuscated malware at the beginning to sophisticated multi-stage spyware that gives attackers full remote control of the infected device. We have examined all the detected versions, including the latest one that is signed by a certificate valid from September 14, 2017.

The implant provides the ability to grab a lot of exfiltrated data, like call records, text messages, geolocation, surrounding audio, calendar events, and other memory information stored on the device.

After manual launch, it shows a fake welcome notification to the user:

Dear Customer, we’re updating your configuration and it will be ready as soon as possible.

At the same time, it hides an icon and starts background services to hide further actions from the user.

Service Name Purpose AndroidAlarmManager Uploading last recorded .amr audio AndroidSystemService Audio recording AndroidSystemQueues Location tracking with movement detection ClearSystems GSM tracking (CID, LAC, PSC) ClipService Clipboard stealing AndroidFileManager Uploading all exfiltrated data AndroidPush XMPP С&C protocol ( RegistrationService Registration on C&C via HTTP (

Interestingly, a self-protection feature was implemented in almost every service. Since in Android 8.0 (SDK API 26) the system is able to kill idle services, this code raises a fake update notification to prevent it:

Cybercriminals have the ability to control the implant via HTTP, XMPP, binary SMS and FirebaseCloudMessaging (or GoogleCloudMessaging in older versions) protocols. Such a diversity of protocols gives the attackers more flexible control. In the latest implant versions there are 48 different commands. You can find a full list with short descriptions in the Appendix. Here are some of the most notable:

  • ‘geofence’ – this command adds a specified location to the implant’s internal database and when it matches a device’s current location the malware triggers and begins to record surrounding audio.
  • ”social” – this command that starts the ‘AndroidMDMSupport’ service – this allows the files of any other installed application to be grabbed. The service name makes it clear that by applications the attackers mean MDM solutions that are business-specific tools. The operator can specify a path with the database of any targeted application and server-side PHP script name for uploading.

    Several hardcoded applications targeted by the MDM-grabbing command

  • ‘wifi’ – this command creates a new Wi-Fi connection with specified configurations from the command and enable Wi-Fi if it is disabled. So, when a device connects to the established network, this process will be in silent and automatic mode. This command is used to connect the victim to a Wi-Fi network controlled by the cybercriminals to perform traffic sniffing and man-in-the-middle (MitM) attacks.

    addWifiConfig method code fragments

  • ‘camera’ – this command records a video/capture a photo using the front-facing camera when someone next unlocks the device.

Some versions of the Skygofree feature the self-protection ability exclusively for Huawei devices. There is a ‘protected apps’ list in this brand’s smartphones, related to a battery-saving concept. Apps not selected as protected apps stop working once the screen is off and await re-activation, so the implant is able to determine that it is running on a Huawei device and add itself to this list. Due to this feature, it is clear that the developers paid special attention to the work of the implant on Huawei devices.

Also, we found a debug version of the implant (70a937b2504b3ad6c623581424c7e53d) that contains interesting constants, including the version of the spyware.

Debug BuildConfig with the version

After a deep analysis of all discovered versions of Skygofree, we made an approximate timeline of the implant’s evolution.

Mobile implant evolution timeline

However, some facts indicate that the APK samples from stage two can also be used separately as the first step of the infection. Below is a list of the payloads used by the Skygofree implant in the second and third stages.

Reverse shell payload

The reverse shell module is an external ELF file compiled by the attackers to run on Android. The choice of a particular payload is determined by the implant’s version, and it can be downloaded from the command and control (C&C) server soon after the implant starts, or after a specific command. In the most recent case, the choice of the payload zip file depends on the device process architecture. For now, we observe only one payload version for following the ARM CPUs: arm64-v8a, armeabi, armeabi-v7a.

Note that in almost all cases, this payload file, contained in zip archives, is named ‘setting’ or ‘setting.o’.

The main purpose of this module is providing reverse shell features on the device by connecting with the C&C server’s socket.

Reverse shell payload

The payload is started by the main module with a specified host and port as a parameter that is hardcoded to ‘’ and ‘30010’ in some versions:

Alternatively, they could be hardcoded directly into the payload code:

We also observed variants that were equipped with similar reverse shell payloads directly in the main APK /lib/ path.

Equipped reverse shell payload with specific string

After an in-depth look, we found that some versions of the reverse shell payload code share similarities with PRISM – a stealth reverse shell backdoor that is available on Github.

Reverse shell payload from

Exploit payload

At the same time, we found an important payload binary that is trying to exploit several known vulnerabilities and escalate privileges. According to several timestamps, this payload is used by implant versions created since 2016. It can also be downloaded by a specific command. The exploit payload contains following file components:

Component name Description run_root_shell/arrs_put_user.o/arrs_put_user/poc Exploit ELF db Sqlite3 tool ELF device.db Sqlite3 database with supported devices and their constants needed for privilege escalation

‘device.db’ is a database used by the exploit. It contains two tables – ‘supported_devices’ and ‘device_address’. The first table contains 205 devices with some Linux properties; the second contains the specific memory addresses associated with them that are needed for successful exploitation. You can find a full list of targeted models in the Appendix.

Fragment of the database with targeted devices and specific memory addresses

If the infected device is not listed in this database, the exploit tries to discover these addresses programmatically.

After downloading and unpacking, the main module executes the exploit binary file. Once executed, the module attempts to get root privileges on the device by exploiting the following vulnerabilities:

CVE-2014-3153 (futex aka TowelRoot)

Exploitation process

After an in-depth look, we found that the exploit payload code shares several similarities with the public project android-rooting-tools.

Decompiled exploit function code fragment

run_with_mmap function from the android-rooting-tools project

As can be seen from the comparison, there are similar strings and also a unique comment in Italian, so it looks like the attackers created this exploit payload based on android-rooting-tools project source code.

Busybox payload

Busybox is public software that provides several Linux tools in a single ELF file. In earlier versions, it operated with shell commands like this:

Stealing WhatsApp encryption key with Busybox

Social payload

Actually, this is not a standalone payload file – in all the observed versions its code was compiled with exploit payload in one file (‘poc_perm’, ‘arrs_put_user’, ‘arrs_put_user.o’). This is due to the fact that the implant needs to escalate privileges before performing social payload actions. This payload is also used by the earlier versions of the implant. It has similar functionality to the ‘AndroidMDMSupport’ command from the current versions – stealing data belonging to other installed applications. The payload will execute shell code to steal data from various applications. The example below steals Facebook data:

All the other hardcoded applications targeted by the payload:

Package name Name LINE: Free Calls & Messages com.facebook.orca Facebook messenger com.facebook.katana Facebook com.whatsapp WhatsApp com.viber.voip Viber Parser payload

Upon receiving a specific command, the implant can download a special payload to grab sensitive information from external applications. The case where we observed this involved WhatsApp.

In the examined version, it was downloaded from:


The payload can be a .dex or .apk file which is a Java-compiled Android executable. After downloading, it will be loaded by the main module via DexClassLoader api:

As mentioned, we observed a payload that exclusively targets the WhatsApp messenger and it does so in an original way. The payload uses the Android Accessibility Service to get information directly from the displayed elements on the screen, so it waits for the targeted application to be launched and then parses all nodes to find text messages:

Note that the implant needs special permission to use the Accessibility Service API, but there is a command that performs a request with a phishing text displayed to the user to obtain such permission.


We have found multiple components that form an entire spyware system for the Windows platform.

Name MD5 Purpose msconf.exe 55fb01048b6287eadcbd9a0f86d21adf Main module, reverse shell network.exe f673bb1d519138ced7659484c0b66c5b Sending exfiltrated data system.exe d3baa45ed342fbc5a56d974d36d5f73f Surrounding sound recording by mic update.exe 395f9f87df728134b5e3c1ca4d48e9fa Keylogging wow.exe 16311b16fd48c1c87c6476a455093e7a Screenshot capturing skype_sync2.exe 6bcc3559d7405f25ea403317353d905f Skype call recording to MP3

All modules, except skype_sync2.exe, are written in Python and packed to binary files via the Py2exe tool. This sort of conversion allows Python code to be run in a Windows environment without pre-installed Python binaries.

msconf.exe is the main module that provides control of the implant and reverse shell feature. It opens a socket on the victim’s machine and connects with a server-side component of the implant located at Before connecting with the socket, it creates a malware environment in ‘APPDATA/myupd’ and creates a sqlite3 database there – ‘myupd_tmp\\mng.db’:

INSERT INTO MANAGE (ID,Send,Keylogg,Screenshot,Audio) VALUES (1, 1, 1, 1, 0 )

Finally, the malware modifies the ‘Software\Microsoft\Windows\CurrentVersion\Run’ registry key to enable autostart of the main module.

The code contains multiple comments in Italian, here is the most noteworthy example:

“Receive commands from the remote server, here you can set the key commands to command the virus”

Here are the available commands:

Name Description cd Change current directory to specified quit Close the socket nggexe Execute received command via Python’s subprocess.Popen() without outputs ngguploads Upload specified file to the specified URL nggdownloads Download content from the specified URLs and save to specified file nggfilesystem Dump file structure of the C: path, save it to the file in json format and zip it nggstart_screen
nggstop_screen Enable/disable screenshot module. When enabled, it makes a screenshot every 25 seconds nggstart_key
nggstop_key Enable/disable keylogging module nggstart_rec
nggstop_rec Enable/disable surrounding sounds recording module ngg_status Send components status to the C&C socket *any other* Execute received command via Python’s subprocess.Popen(), output result will be sent to the C&C socket.

All modules set hidden attributes to their files:

Module Paths Exfiltrated data format msconf.exe %APPDATA%/myupd/gen/ (file structure dump) system.exe %APPDATA%/myupd/aud/ %d%m%Y%H%M%S.wav (surrounding sounds) update.exe %APPDATA%/myupd_tmp/txt/
%APPDATA%/myupd/txt/ %Y%m%d-%H%M%S.txt (keylogging) wow.exe %APPDATA%/myupd/scr/ %Y%m%d-%H%M%S.jpg (screenshots) skype_sync2.exe %APPDATA%/myupd_tmp/skype/
%APPDATA%/myupd/skype/ yyyyMMddHHmmss_in.mp3
(skype calls records)

Moreover, we found one module written in .Net – skype_sync2.exe. The main purpose of this module is to exfiltrate Skype call recordings. Just like the previous modules, it contains multiple strings in Italian.

After launch, it downloads a codec for MP3 encoding directly from the C&C server:

The skype_sync2.exe module has a compilation timestamp – Feb 06 2017 and the following PDB string:


network.exe is a module for submitting all exfiltrated data to the server. In the observed version of the implant it doesn’t have an interface to work with the skype_sync2.exe module.

network.exe submitting to the server code snippet

Code similarities

We found some code similarities between the implant for Windows and other public accessible projects.


It appears the developers have copied the functional part of the keylogger module from this project.

update.exe module and Keylogger by ‘El3ct71k’ code comparison

update.exe module and Xenotix Python Keylogger code comparison

‘addStartup’ method from msconf.exe module

‘addStartup’ method from Xenotix Python Keylogger


We found several landing pages that spread the Android implants.

Malicious URL Referrer Dates 2015-02-04 to
present time – 2015-07-01 2015-01-20 to
present time currently active 2015-03-04 2015-01-14 2015-03-31 2015-02-04
2015-07-20 2015-07-08

Many of these domains are outdated, but almost all (except one – appPro_AC.apk) samples located on the server are still accessible. All the observed landing pages mimic the mobile operators’ web pages through their domain name and web page content as well.

Landing web pages that mimic the Vodafone and Three mobile operator sites

** AGG. 2.3.2015 ***
Dear Customer, in order to avoid malfunctions to your internet connection, we encourage you to upgrade your configuration. Download the update now and keep on navigating at maximum speed!
Do you doubt how to configure your smartphone?
Follow the simple steps below and enter the Vodafone Fast Network.
Installation Guide
Click on the DOWNLOAD button you will find on this page and download the application on your smartphone.
Set your Smartphone
Go to Settings-> Security for your device and put a check mark on Unknown Sources (some models are called Sources Unknown).
Go to notifications on your device (or directly in the Downloads folder) and click Vodafone Configuration Update to install.
Try high speed
Restart your device and wait for confirmation sms. Your smartphone is now configured.

Further research of the attacker’s infrastructure revealed more related mimicking domains.

Unfortunately, for now we can’t say in what environment these landing pages were used in the wild, but according to all the information at our dsiposal, we can assume that they are perfect for exploitation using malicious redirects or man-in-the-middle attacks. For example, this could be when the victim’s device connects to a Wi-Fi access point that is infected or controlled by the attackers.


During the research, we found plenty of traces of the developers and those doing the maintaining.

  • As already stated in the ‘malware features’ part, there are multiple giveaways in the code. Here are just some of them:
ngglobal FirebaseCloudMessaging topic name Issuer: CN = neggfrom several certificates negg.ddns[.]net, negg1.ddns[.]net, negg2.ddns[.]net – C&C servers NG SuperShell – string from the reverse shell payload ngg – prefix in commands names of the implant for Windows

Signature with specific issuer

  • Whois records and IP relationships provide many interesting insights as well. There are a lot of other ‘Negg’ mentions in Whois records and references to it. For example:

The Skygofree Android implant is one of the most powerful spyware tools that we have ever seen for this platform. As a result of the long-term development process, there are multiple, exceptional capabilities: usage of multiple exploits for gaining root privileges, a complex payload structure, never-before-seen surveillance features such as recording surrounding audio in specified locations.

Given the many artifacts we discovered in the malware code, as well as infrastructure analysis, we are pretty confident that the developer of the Skygofree implants is an Italian IT company that works on surveillance solutions, just like HackingTeam.


Skygofree is so named because the word was used in one of the domains. The malware has no connection to Sky, Sky Go or any other subsidiary of Sky, and does not affect the Sky Go service or app.

 Skygofree Appendix — Indicators of Compromise (PDF)

Happy IR in the New Year!

Thu, 12/28/2017 - 06:56

At the end of last year Mr. Jake Williams from aka @MalwareJake asked a very important question about Lack of visibility during detecting APT intrusions in twitter. Results show us that endpoint analysis is the most important part of any research connected with APTs. Also, for sure endpoint forensics is critical during any Incident Response (IR) because in many cases the initial intrusion happened too far away in time so there are no relevant logs and no backups to identify the first victim and the way how attackers were moving from one computer to another. At least once a year we have such issues during IR activities with our customers. In these cases we use a very simple script that is uploaded to every Windows computer in the corporate network to collect logs, NTFS data, entries from the Windows registry and strings from the binary files to find out how exactly the attackers were moving through the network. It’s holiday season and it is our pleasure to share this script with you. We hope it will help to save a lot of time during IR and any malware/APT investigations providing the so much needed visibility into potentially infected endpoint PCs.

Let’s start with collecting the collect file system information from the computer using the wonderful forensics tool FLS (administrative privileges required) from the open source package Sleuthkit. The only thing that the official Windows build lacks is Windows XP/2003 support. If you are planning to run the tool on Windows XP/2003 machines then you may need to recompile FLS from sources using MinGW or download our our pre-compiled version (see the end of this blog post). We also do not want to write the results to the computers’ hard drive to avoid wiping its unallocated space. So the tool is going to utilize a big (approx. 300 MB free space for one corporate computer ) share folder that should be prepared in advance and should be accessible from all computer in the network that will execute the script:

set data_share=”\\corp_share\data_share”
net use y: %data_share%
mkdir y:\%COMPUTERNAME%_report
set dp=y:\%COMPUTERNAME%_report
echo %date% %time% %COMPUTERNAME% > %dp%\report.log
fls.exe -lpr \\.\c: >> %dp%\fls.log

It will take several (dozens of) minutes to create the full list of filesystem entries for the computer’s system drive. After that we are ready to extract the inode numbers of Windows registry files that are interesting to us. We will use the ICAT tool from the same Sleuthkit package and the RegLookup utility to grab modification timestamps of every windows registry key. At the end we want to collect all the strings (using the tools either by Mr. Mark Russinovich or from tool (our choice)) from the registry files to search for any data from the unallocated space and deleted keys:

::Get Windows reg files
findstr /i “windows\/system32\/config\/system ” %dp%\fls.log | findstr /vi “profile” | findstr /vi log | cut -f2 -d” ” | cut -f1 -d”:” > %dp%\system.reg.inode
for /f “tokens=1” %%a in (%dp%\system.reg.inode) do icat \\.\c: %%a > %dp%\system.reg
findstr /i “windows\/system32\/config\/software ” %dp%\fls.log | findstr /vi “profile” | findstr /vi log | cut -f2 -d” ” | cut -f1 -d”:” > %dp%\software.reg.inode
for /f “tokens=1” %%a in (%dp%\software.reg.inode) do icat \\.\c: %%a > %dp%\software.reg
::Convert reg files
reglookup.exe %dp%\system.reg > %dp%\system.reg.log
reglookup.exe %dp%\software.reg > %dp%\\software.reg.log
::Get strings from reg files
strings -afel %dp%\system.reg > %dp%\system.str.log
strings -afeb %dp%\system.reg >> %dp%\system.str.log
strings -afel %dp%\software.reg > %dp%\software.str.log
strings -afeb %dp%\software.reg >> %dp%\software.str.log

Once finished, we are ready to do the same with the Windows system and security eventlog files. To parse log the files will we use the open source tools evtxexport and evtexport by Mr. Joachim Metz

::Get Logs
findstr -i “windows\/system32\/winevt/logs/system.evtx” %dp%\fls.log | cut -f2 -d” ” | cut -f1 -d”:” > %dp%\system.evtx.inode
for /f “tokens=1” %%a in (%dp%\system.evtx.inode) do icat \\.\c: %%a > %dp%\system.evtx
findstr /i “windows\/system32\/winevt/logs/security.evtx” %dp%\fls.log | cut -f2 -d” ” | cut -f1 -d”:” > %dp%\security.evtx.inode
for /f “tokens=1” %%a in (%dp%\security.evtx.inode) do icat \\.\c: %%a > %dp%\security.evtx
strings -afeb %dp%\system.evtx > %dp%\system.evtx.str.log
strings -afel %dp%\system.evtx >> %dp%\system.evtx.str.log
strings -afeb %dp%\security.evtx > %dp%\security.evtx.str.log
strings -afel %dp%\security.evtx >> %dp%\security.evtx.str.log
::Conv evtx
evtxexport.exe %dp%\system.evtx > %dp%\system.evtx.res.log
::get evt logs
findstr /i “windows\/system32\/config/SysEvent.Evt” %dp%\fls.log | cut -f2 -d” ” | cut -f1 -d”:” > %dp%\SysEvent.Evt.inode
for /f “tokens=1” %%a in (%dp%\SysEvent.Evt.inode) do icat \\.\c: %%a > %dp%\SysEvent.Evt
findstr /i “windows\/system32\/config/SecEvent.Evt” %dp%\fls.log | cut -f2 -d” ” | cut -f1 -d”:” > %dp%\SecEvent.Evt.inode
for /f “tokens=1” %%a in (%dp%\SecEvent.Evt.inode) do icat \\.\c: %%a > %dp%\SecEvent.Evt
::get strings from evt
strings -afeb %dp%\SysEvent.Evt > %dp%\SysEvent.Evt.str.log
strings -afel %dp%\SysEvent.Evt >> %dp%\SysEvent.Evt.str.log
strings -afeb %dp%\SecEvent.Evt > %dp%\SecEvent.Evt.str.log
strings -afel %dp%\SecEvent.Evt >> %dp%\SecEvent.Evt.str.log
::Conv evt
evtexport.exe %dp%\SysEvent.Evt > %dp%\SysEvent.Evt.res.log

Actually this is it. All logs will be collected in our share’s folder so we may search for something interesting. In the latest cases with Carbanak we were looking for mentions of the malicious Powershell scripts so let’s add the following string in our version of this script:

findstr /i “powershell” %dp%\*.log >> %dp%\report.log

This will provide us with a complete picture of how the attackers were moving from one computer to another with exact timestamps and artifacts on NTFS, registry and logs that is critical for fast and effective IR with no lack of endpoint visibility. GLHF and HAPPY IR in NEW YEAR!


SHA256 ( = c166d1e150db24ea27014e1d4a9eeb79f9e317ded9918a623fee8e66a010f9fa

Nhash: petty pranks with big finances

Thu, 12/21/2017 - 05:00

According to our data, cryptocurrency miners are rapidly gaining in popularity. In an earlier publication we noted that cybercriminals were making use of social engineering to install this sort of software on users’ computers. This time, we’d like to dwell more on how exactly the computers of gullible users start working for cybercriminals.

Beware freebies

We detected a number of similar websites with offers to download various types of free software. Some of them really were free applications (such as OpenOffice), while others attempted to entice users with “free” software packages of Adobe Premiere Pro, CorelDraw, PowerPoint, etc. From the victim’s point of view, the software was indeed free – it didn’t ask for activation keys and could be used immediately. Moreover, the cybercriminals used domain names resembling those of recognized legitimate products, such as,, etc. There was one thing all these apps had in common – they were installed on the victim computer along with a custom-configured version of cryptocurrency mining software from the NiceHash project.

All sites followed the same design template, differing only in their product descriptions and download links

Mining coins at any price

Kaspersky Lab’s products detect the NiceHash miner with the verdict not-a-virus:RiskTool.Win64.BitCoinMiner.cgi; it is not malicious according to Kaspersky Lab’s classification. According to KSN data, around 200 files are detected with this verdict. We chose the file FineReader- for analysis. It was obtained from the website which is no longer available; at this website, it was presented as a “free full version” of ABBYY FineReader. It should be noted that this hacked version, minus the miner component, has long been available on the internet via Torrent file distribution systems:

The executable file contains the installation package Inno Setup; unpacking it will produce a number of folders containing the actual software and its resources, as well as an installation guide script. The installer’s root folder looks like this:

The {app} folder is of interest to us; it contains the software that is installed. This folder contains a ‘portable’ version of FineReader:

The lib folder contains some suspicious-looking files:

Among these files is the NiceHash miner that we mentioned above. There are also text files in this folder that contain the information required to initialize the miner – namely the wallet details and the mining pool’s address. This folder will be installed stealthily to the victim computer while FineReader is installing.

A shortcut will also be created in the autorun folder:

The shortcut reveals the path to the miner’s work directory on the C drive:

That leaves the tskmgr.exe and system.exe files of interest for analysis. Both files are BAT scripts compiled into PE files. Let’s look at the contents of system.exe after extracting the BAT script:

It ensures the wallet’s address is up to date and initializes the miner’s operation. It contacts the following addresses:


After the third query, the following response is received:

This is a PowerShell script that assigns a unique ID to the infected computer and launches mining with the correct wallet details (in this specific case, the zcash cryptocurrency is mined). IDs are generated following a specific algorithm based on the mining start time. For example, the ID 4v09v2017v03v24v26 is made up of the date (14.09.2017) and time (03:24:26).

We have also identified other types of covert miners with a slightly different logic. Below is the same Inno Setup installation package, but if we take a look at its contents, we can see lots of shortcuts:

Let’s take a look inside:

This is a classic case – the shortcuts are scattered across the system; when opened by the user, they launch the miner. The package includes the TrayIt! utility that hides the miner’s window from the user by minimizing it to the system tray. This miner doesn’t receive any data from the server, but instead operates using the wallet and pool details that were hardwired into it.


Among the mining pools used by cybercriminals, we detected some that provided statistics about the wallets and the number of miners. At the time of our analysis, total revenue from all wallets was nearly US$3400.

The t1WSaZQxqBLLtGMKsGT6t9WGHom8LcE8Ng5 wallet

The t1JA25kJrAaUw9xe6TzGiC8BU5pZRhgL4Ho wallet

The t1N7sapDRuYdqzKgPwet8L31Z9Aa96i7hy4 wallet

The 3MR6WuGkuPDqPZgibV6gi4DaC7qMabEFks wallet


This small piece of research once again demonstrates that no one should ignore protection measures and get lulled into a false sense of security, believing cybercriminals are only interested in financial organizations; practice shows that regular users are also targeted. The mining software that we analyzed, albeit incapable of inflicting any damage, can seriously impair your workstation’s performance by hijacking its resources and making it work for somebody else.

Indicators of Compromise C&C





Travle aka PYLOT backdoor hits Russian-speaking targets

Tue, 12/19/2017 - 05:00

.travle-big-table td{border:1px solid #eee!important}.travle-big-table td[colspan="3"]{padding: 10px;}

At the end of September, Palo Alto released a report on Unit42 activity where they – among other things – talked about PYLOT malware. We have been detecting attacks that have employed the use of this backdoor since at least 2015 and refer to it as Travle. Coincidentally, KL was recently involved in an investigation of a successful attack where Travle was detected, during which we conducted a deep analysis of this malware. So, with this intelligence ready we are sharing our findings in this blog to supplement Palo Alto’s research with additional details.

Technical Details MD5 SIZE LINKER COMPILED ON 7643335D06BAEC5A14C95A393592EA3F 164352 11.0 2016-10-14 06:21:07

The Travle sample found during our investigation was a DLL with a single exported function (MSOProtect). The malware name Travle was chosen given a string found in early samples of this family: “Travle Path Failed!”. This typo was replaced with correct word “Travel” in newer releases. We believe that Travle could be a successor to the NetTraveler family.

First of all, we detected numerous malicious documents being used in spear-phishing attacks with file names suggesting Russian-speaking targets with executables maintained in encrypted form:

This encryption method has been well known for a long time – it was first used in exploit documents to conceal Enfal, then we discovered this backdoor – Travle. Later documents with such encryption started maintaining another one APT family – Microcin. Travle C2 domains often overlap with those of Enfal. In regard to NetTraveler, at some point Enfal samples started using the same encryption method for maintaining the C2 URL as was used in NetTraveler:

Enfal sample with NetTraveler-like C2 string encryption

So, clearly these backdoors – Enfal, NetTraveler, Travle and Microcin – are all related to each other and are believed to have Chinese-speaking origins. And after finding the string “Travel path failed!” we believe that the Travle backdoor could be intended as a successor to the NetTraveler malware.

The malware starts by initializing the following variables:

%TEMP%\KB287640\ – local malware drop-zone
%TEMP%\KB887209\ – plugins storage
<malware install path>\~KB178495.DAT – configuration file path

Surprisingly, these paths remain the same in all samples of this family. If no configuration file is found, Travle reads the default settings from its resource “RAW_DATA. Settings are maintained in an encrypted form. Here is the code for decryption:

for (i = size – 1; i > 1; –i)
buf[i] ^=  buf[i – 2]

The storage format for the configuration block is as follows:

  Offset Size Value 0 0x81 C2 domain 0x102 0x81 C2 URL path 0x204 2 C2 port (not used) 0x206 0xB not used 0x21C 0xB Sample ID 0x232 0x401 Bot’s first RC4 key 0xA34 0x401 Bot’s second RC4 key 0x1238 2 not used

The described sample maintains the following configuration data:

Field Value C2 domain C2 URL path /zzw/ Sample ID MjdfS0584 1st RC4 key mffAFe4bgaadbAzpoYRf 2nd RC4 key mffAFe4bgaadbAzpoYRf

The Travle backdoor starts its communication with the C2 by sending gathered information about the target operating system in an HTTP POST request to a URL built using the C2 domain and the path specified in the settings. The information sent includes the following data:

  • UserID – based on the computer name and IP-address
  • Computer name
  • Keyboard layout
  • OS version
  • IP-addresses
  • MAC-address

Once the C2 receives the first packet, it responds with a block of data containing the following information:

  • URL path for receiving commands
  • URL path for reporting on command execution results
  • URL path for downloading files from C2
  • URL path for uploading files to C2
  • C2 second RC4 key
  • C2 first RC4 key
  • C2 ID

After this packet has been received, Travle waits for additional commands from the server.

Communication encryption

The ciphering algorithm depends on the type of transmitted object. There are three possible variants:

  1. Data
    • Data is ciphered with Base64
    • The resulting string is appended to the header with a size of 0x58 bytes
    • The resulting buffer is ciphered by RC4 with the C2 first RC4 key
    • The resulting buffer is ciphered with Base64
  2. List of strings
    • Each line is ciphered by RC4 with the C2 second RC4 key
    • The resulting buffer is ciphered with Base64
    • All the previously Base64-ciphered strings are merged in one delimited with \r\n”
    • The resulting string is appended to the header with a size of 0x54 bytes
    • The resulting buffer is ciphered by RC4 with the C2 first RC4 key
    • The resulting buffer is ciphered with Base64
  3. File
    • Compressed with LZO
    • The resulting archive is ciphered with the C2 second RC4 key
Messages format

The header for the transmitted data is as follows:

Offset (bytes) Size (bytes) Description 0 0x14 Random set of bytes 0x14 4 Data type / Command ordinal 0x18 4 NULL / Command ID 0x1C 4 Size of data 0x20 0x14 Sample ID 0x34 0x24 User ID 0x58 Size of data Data

The file is transferred to the C2 in a POST request as a multipart content type with boundary “kdncia987231875123nnm“. All samples of Travle we have discovered use this value.

Message types from bot to C2

The command ID is specified at offset 0x18 in the header.

Technical messages are as follows:

ID Description Data content 1 Information about OS Information about OS 2 Request for the first command NULL 3 Request for the list of commands NULL 4 Command is successfully executed Information about command execution or the name of transmitted file 5 Command execution failed Information about an error

Operational messages are as follows:

ID Description Data content 1 Bot sends the list of files in the requested directory The list of files 11 Bot sends the content of the requested file The content of the file Message types – from C2 to bot

In case of bot sending POST request C2 responses with data of following format:

ID Description Data content 0 Information about C2 The list of C2 parameters 1 Commands The list of commands

Bot also may send GET request for retrieving a specific file from the server. In this case, C2 responses with the requested file.

General communication between bot and C2

Interaction with C2 includes two stages:

1st (automatic – carried out with no operator actions). It consists of:

  • Sending information about the OS
  • Receiving information about C2
  • Sending a request for the first command
  • Receiving the command with ordinal 1 and first argument “*”
  • Sending the request for the next command

2nd (carried out by operators). It consists of:

  • Sending commands to the bot
  • Sending files to the bot
  • Sending results of the executed commands to the C2
Commands – general bot functionality Ordinal Arguments Action Scan File System 1 Path In case of “Path” is not “*”, the bot collects the list of files and folders in the specified directory with creation date between specified values and files with an “Encrypted” attribute.
If the “Path” is “*”, the search for files and folders is done in complete file system.
In any case, the search is recursive. Minimum date Maximum date Run Process 2 Path to the batch or executable file The bot executes specified batch file or application with passed arguments. Command line arguments File Presence Test 4 File name The bot examines if specified file exists. Delete File 3 File name File deletion. Rename File 5 Old file name File renaming. New file name Move File 6 Old path File moving. New path Create New Config 7 Content of the new configuration The bot creates the file with new configuration. Process File With Batch 48 Batch script The bot sends GET request to the C2 for downloading a file specified in one command argument. Batch script received in another command argument is saved in the file and executed with a parameter – file name of the downloaded file. File path Run Batch 49 Batch script The bot receives a BAT-file and executes it. Download File 16 File path The bot sends a GET request for downloading a file. The file is saved with the specified name and location. Upload File 17 File path The bot sends the content of a requested file in a POST message. Download And Run Plugin 32 Plugin name The bot sends a GET request for downloading Plugin (DLL). Plugin is saved in the file system and launched with the use of the LoadLibrary API function. Plugin argument Unload Plugin 33 Plugin name The bot unloads a plugin library from memory. Delete Plugin 34 Plugin name The bot unloads a plugin from memory and deletes the plugin file. Load And Run Plugin 35 Plugin name The bot loads a plugin in memory with a specified parameter. Plugin argument Plugins

Unfortunately, we have been unable to receive plugins from any C2 found in examined Travle samples, but after analyzing the code of Travle we can briefly describe how they are handled.

Plugins are handled with the use of commands 32-35. From all the analyzed Travle samples, we found out that not every Travle sample is able to work with plugins.

Each plugin DLL is saved in a file and loaded with the use of the LoadLibrary API function. The DLL should export three functions: GetPluginInfo, Starting and FreeMemory. These functions are invoked one-by-one at the plugin DLL loading stage. When Travle has to unload the plugin DLL it calls the FreeLibrary API function.

In all analyzed Travle samples, plugins are saved in the same location: %TEMP%\KB887209\.


The actor or actors responsible for the Travle attack has been active during the last few years, apparently not worried about being tracked by AV companies. Usually, modifications and new additions to their arsenal are discovered and detected quite quickly. Still, the fact that they didn´t really need to change their TTPs during all these years seems to suggest that they don´t need to increase their sophistication level in order to fulfill their goals. What’s worse, according to subjects of decoy documents these backdoors are used primarily in the CIS region against government organizations, military entities and companies engaged in high-tech research, which indicates that even high-profile targets still have a long way to go to implement IT-sec best practices which efficiently resist targeted attacks.

We detect Travle samples with the following verdicts:


More information about the Travle APT is available to customers of the Kaspersky Intelligence Reporting Service. Contact:

Jack of all trades

Mon, 12/18/2017 - 05:00

Nowadays, it’s all too easy to end up with malicious apps on your smartphone, even if you’re using the official Google Play app store. The situation gets even worse when you go somewhere other than the official store – fake applications, limited security checks, and so on. However, the spread of malware targeting Android OS is not limited to unofficial stores – advertising, SMS-spam campaigns and other techniques are also used. Among this array of threats we found a rather interesting sample – Trojan.AndroidOS.Loapi. This Trojan boasts a complicated modular architecture that means it can conduct a variety of malicious activities: mine cryptocurrencies, annoy users with constant ads, launch DDoS attacks from the affected device and much more. We’ve never seen such a ‘jack of all trades’ before.

Distribution and infection

Samples of the Loapi family are distributed via advertising campaigns. Malicious files are downloaded after the user is redirected to the attackers’ malicious web resource. We found more than 20 such resources, whose domains refer to popular antivirus solutions and even a famous porn site. As we can see from the image below, Loapi mainly hides behind the mask of antivirus solutions or adult content apps:

After the installation process is finished, the application tries to obtain device administrator permissions, asking for them in a loop until the user agrees. Trojan.AndroidOS.Loapi also checks if the device is rooted, but never subsequently uses root privileges – no doubt they will be used in some new module in the future.

After acquiring admin privileges, the malicious app either hides its icon in the menu or simulates various antivirus activity, depending on the type of application it masquerades as:


Loapi aggressively fights any attempts to revoke device manager permissions. If the user tries to take away these permissions, the malicious app locks the screen and closes the window with device manager settings, executing the following code:

As well as this fairly standard technique to prevent removal, we also found an interesting feature in the self-protection mechanism. The Trojan is capable of receiving from its C&C server a list of apps that pose a danger. This list is used to monitor the installation and launch of those dangerous apps. If one of the apps is installed or launched, then the Trojan shows a fake message claiming it has detected some malware and, of course, prompts the user to delete it:

This message is shown in a loop, so even if the user rejects the offer, the message will be shown again and again until the user finally agrees and deletes the application.

Layered architecture

Let’s take a look at the Trojan’s architecture in more detail:

  1. At the initial stage, the malicious app loads a file from the “assets” folder, decodes it using Base64 and afterwards decrypts it using XOR operations and the app signature hash as a key. A DEX file with payload, which was retrieved after these operations, is loaded with ClassLoader.
  2. At the second stage, the malicious app sends JSON with information about the device to the central C&C server hxxps://

    A command in the following format is received as a response from the server:

    Where “installs” is a list of module IDs that have to be downloaded and launched; “removes” is a list of module IDs that have to be deleted; “domains” is a list of domains to be used as C&C servers; “reservedDomains” is an additional reserved list of domains; “hic” is a flag that shows that the app icon should be hidden from the user; and “dangerousPackages” is a list of apps that must be prevented from launching and installing for self-protection purposes.

  3. At the third stage, the modules are downloaded and initialized. All the malicious functionality is concealed inside them. Let’s take a closer look at the modules we received from the cybercriminals’ server.
Advertisement module

Purpose and functionality: this module is used for the aggressive display of advertisements on the user’s device. It can also be used for secretly boosting ratings. Functionality:

  • Display video ads and banners
  • Open specified URL
  • Create shortcuts on the device
  • Show notifications
  • Open pages in popular social networks, including Facebook, Instagram, VK
  • Download and install other applications

Example of task to show ads received from the server:

While handling this task, the application sends a hidden request with a specific User-Agent and Referrer to the web page hxxps://, which in turn redirects to a page with the ads.

SMS module

Purpose and functionality: this module is used for different manipulations with text messages. Periodically sends requests to the C&C server to obtain relevant settings and commands. Functionality:

  • Send inbox SMS messages to attackers’ server
  • Reply to incoming messages according to specified masks (masks are received from C&C server)
  • Send SMS messages with specified text to specified number (all information is received from C&C server)
  • Delete SMS messages from inbox and sent folder according to specified masks (masks are received from C&C server)
  • Execute requests to URL and run specified Javascript code in the page received as a response (legacy functionality that was later moved to a separate module)
Web crawling module

Purpose and functionality: this module is used for hidden Javascript code execution on web pages with WAP billing in order to subscribe the user to various services. Sometimes mobile operators send a text message asking for confirmation of a subscription. In such cases the Trojan uses SMS module functionality to send a reply with the required text. Also, this module can be used for web page crawling. An example of a web page crawling task received from the server is shown below:

This module together with the advertisement module tried to open about 28,000 unique URLs on one device during our 24-hour experiment.

Proxy module

Purpose and functionality: this module is an implementation of an HTTP proxy server that allows the attackers to send HTTP requests from the victim’s device. This can be used to organize DDoS attacks against specified resources. This module can also change the internet connection type on a device (from mobile traffic to Wi-Fi and vice versa).

Mining Monero

Purpose and functionality: this module uses the Android version of minerd to perform Monero (XMR) cryptocurrency mining. Mining is initiated using the code below:

The code uses the following arguments:

  • url – mining pool address, “stratum+tcp://”
  • this.user – username, value randomly selected from the following list: “”, “”, “”, “”, “”, “”, “”, “”, “”,
  • password – constant value, “qwe”
Old ties

During our investigation we found a potential connection between Loapi and Trojan.AndroidOS.Podec. We gathered some evidence to support this theory:

  • Matching C&C server IP addresses. The current address of the active Loapi C&C server is resolved with DNS to and But if we take a look at the history, we can see other IP addresses to which this URL resolved before:

    At first, this URL was resolved to the IP address If we analyze the history of DNS records that resolved to this address, we see the following:

    As we can see from the records, in 2015 (when Podec was active), this IP address was resolved from various generated domains, and many of them were used in Podec (for example,, in the 0AF37F5F07BBF85AFC9D3502C45B81F2 sample).

  • Matching unique fields at the initial information collection stage. Both Trojans collect information with similar structure and content and send it in JSON format to the attackers’ server during the initial stage. Both JSON objects have the fields “Param1”, “Param2” and “PseudoId”. We performed a search in our internal ElasticSearch clusters – where we store information about clean and malicious applications – and found these fields were only used in Podec and Loapi.
  • Similar obfuscation.
  • Similar ways of detecting SU on a device.
  • Similar functionality (both can subscribe users to paid services).

None of these arguments can be considered conclusive proof of our theory, but taken together they suggest there’s a high probability that the malicious applications Podec and Loapi were created by the same group of cybercriminals.


Loapi is an interesting representative from the world of malicious Android apps. It’s creators have implemented almost the entire spectrum of techniques for attacking devices: the Trojan can subscribe users to paid services, send SMS messages to any number, generate traffic and make money from showing advertisements, use the computing power of a device to mine cryptocurrencies, as well as perform a variety of actions on the internet on behalf of the user/device. The only thing missing is user espionage, but the modular architecture of this Trojan means it’s possible to add this sort of functionality at any time.


As part of our dynamic malware analysis we installed the malicious application on a test device. The images below show what happened to it after two days:

Because of the constant load caused by the mining module and generated traffic, the battery bulged and deformed the phone cover.

C&C (advertisement module) (SMS module and mining module) (web crawler) (proxy module)


List of web resources from which the malicious application was downloaded:

Domain IP,,,,,,,,,,,,,

Kaspersky Security Bulletin. Overall statistics for 2017

Thu, 12/14/2017 - 05:00

All the statistics used in this report were obtained using Kaspersky Security Network (KSN), a distributed antivirus network that works with various anti-malware protection components. The data was collected from KSN users who agreed to provide it. Millions of Kaspersky Lab product users from 213 countries and territories worldwide participate in this global exchange of information about malicious activity.

The year in figures
  • 4%of user computers were subjected to at least one Malware-class web attack over the year.
  • Kaspersky Lab solutions repelled 1 188 728 338 attacks launched from online resources located all over the world.
  • 199 455 606 unique URLs were recognized as malicious by web antivirus components.
  • Kaspersky Lab’s web antivirus detected 15 714 700 unique malicious objects.
  • 939 722 computers of unique users were targeted by encryptors.
  • Kaspersky Lab solutions blocked attempts to launch malware capable of stealing money via online banking on 1 126 701 devices

Fill the form below to download the Kaspersky Security Bulletin 2017. Overall Statistics for 2017 full report (English, PDF):
MktoForms2.loadForm("//", "802-IJN-240", 15914);

Still Stealing

Tue, 12/12/2017 - 05:00

Two years ago in October 2015 we published a blogpost about a popular malware that was being distributed from the Google Play Store. Over the next two years we detected several similar apps on Google Play, but in October and November 2017 we found 85 new malicious apps on Google Play that are stealing credentials for All of them have been detected by Kaspersky Lab products as Trojan-PSW.AndroidOS.MyVk.o. We reported 72 of them to Google and they deleted these malicious apps from Google Play Store, 13 other apps were already deleted. Furthermore, we reported these apps with technical details to One of these apps was masquerading as a game and was installed more than a million times according to Google Play Store.

One of the apps detected as Trojan-PSW.AndroidOS.MyVk.o was distributed as a game.

There were some other popular apps among them too – seven apps had 10,000-100,000 installations from Google Play and nine apps had 1,000-10,000 installation. All other apps had fewer than 1,000 installations.

App detected as Trojan-PSW.AndroidOS.MyVk.o on Google Play Store

Most of these apps were uploaded to Google Play in October 2017, but several of them were uploaded in July 2017, so they were being distributed for as long as 3 months. Moreover, the most popular app was initially uploaded to the Google Play Store on March 2017, but without any malicious code—it was just a game. Cybercriminals updated this app with a malicious version only in October 2017, having waited more than 7 months to do so!

Most of these apps looked like apps for – for listening to music or for monitoring user page visits.

App detected as Trojan-PSW.AndroidOS.MyVk.o on Google Play Store

Sure, such apps need a user to login into an account – that’s why they didn’t look suspicious. The only apps whose functionality was not VK-related were game apps. Because VK is popular mostly in CIS countries, cybercriminals checked the device language and asked for VK credentials only from users with certain languages – Russian, Ukrainian, Kazakh, Armenian, Azerbaijani, Belarusian, Kyrgyz, Romanian, Tajik, and Uzbek.

Code where a Trojan checks the device language.

These cybercriminals were publishing their malicious apps on Google Play Store for more than two years, so they had to modify their code to bypass detection. In these apps they used a modified VK SDK with tricky code–users logged on to the standard page, but the cybercriminals used malicious JS code to get the credentials from the login page and pass them back to the app.

Malicious code where a Trojan executes JS code to get VK credentials.

Then the credentials are encrypted and uploaded to the malicious website.

Code where a Trojan decrypts a malicious URL, encrypts stolen credentials and uploads them.

The interesting thing is that although most of these malicious apps had a described functionality, a few of them were slightly different—they also used malicious JS code from the OnPageFinished method, but not only for extracting credentials but for uploading them too.

Malicious code where a Trojan executes JS code to get and upload VK credentials

We think that cybercriminals use stolen credentials mostly for promoting groups in They silently add users to promote various groups and increase their popularity by doing so. We have reason to think so because there were complaints from some infected users that their accounts had been silently added to such groups.

Another reason to think so is that we were able to find several other apps on Google Play that were published by the same cybercriminals responsible for Trojan-PSW.AndroidOS.MyVk.o. They were published as unofficial clients for Telegram, a popular messaging app. All of them were detected by Kaspersky Lab products as not-a-virus:HEUR:RiskTool.AndroidOS.Hcatam.a. We notified Google about these apps too and they deleted them from Google Play Store.

App infected with not-a-virus:HEUR:RiskTool.AndroidOS.Hcatam.a on Google Play Store

These apps were not only masquerading as Telegram apps, they were actually built using an open source Telegram SDK and work almost like every other such app. Except one thing – they added users to promoted groups/chats. These apps receive a list with groups/chats from their server. What’s more, they can add users to groups anytime – to do so they steal a GCM token which allows cybercriminals to send commands 24/7.

We also discovered an interesting thing about the malicious website According to KSN statistics, in some cases it was used for mining cryptocurrencies by using an API from

  • space
APPS Package name MD5 com.parmrp.rump F5F8DF1F35A942F9092BDE9F277B7120 com.weeclient.clientold 6B55AF8C4FB6968082CA2C88745043A1 com.anocat.stelth C70DCF9F0441E3230F2F338467CD9CB7 com.xclient.old 6D6B0B97FACAA2E6D4E985FA5E3332A1 com.junglebeat.musicplayer.offmus 238B6B7069815D0187C7F39E1114C38 com.yourmusicoff.yourmusickoff 1A623B3784256105333962DDCA50785F 1A7B22616C3B8223116B542D5AFD5C05 com.musicould.close 053E2CF49A5D818663D9010344AA3329 com.prostie.dvijenija 2B39B22EF2384F0AA529705AF68B1192 com.appoffline.musicplayer 6974770565C5F0FFDD52FC74F1BCA732 com.planeplane.paperplane 6CBC63CBE753B2E4CB6B9A8505775389

Cybercriminals vs financial institutions in 2018: what to expect

Wed, 12/06/2017 - 04:00

ul li {margin-bottom:2.4rem;} Introduction – key events in 2017

2017 was a year of great changes in the world of cyberthreats facing financial organizations.

Firstly, in 2017 we witnessed a continuation of cyberattacks targeting systems running SWIFT — a fundamental part of the world’s financial ecosystem. Attackers were able to use malware in financial institutions to manipulate applications responsible for cross-border transactions, making it possible to withdraw money from any financial organization in the world, because SWIFT software is unified and used by almost all the major players in the financial market. Victims of these attacks included several banks in more than 10 countries around the world.

Secondly, in 2017 we saw the range of financial organizations that cybercriminals have been trying to penetrate, expand significantly. Different cybercriminal groups penetrated bank infrastructure, e-money systems, cryptocurrency exchanges, capital management funds, and even casinos. Their main goal was to withdraw very large sums of money.

To complete their cybercriminal activities, attackers rely on proven schemes of monetizing network access. In addition to their attacks on SWIFT systems, cybercriminals have been actively using ATM infections, including those on financial institution’s own networks, as well as wielding RB (remote banking) systems, PoS terminal networks, and making changes in banks’ databases to ‘play’ with card balances.

Attacks on ATMs are worth mentioning separately. This kind of robbery became so popular that 2017 saw the first ATM malware-as-a-service: with cybercriminals providing on underground forums all necessary malicious programs and video instructions to gain access to ATMs. Those who bought a subscription only needed to choose an ATM, open it following the instructions, and pay the service organizers for activating the malicious program on the ATM, after which the money withdrawal process started. Schemes like this significantly increased the number of cybercriminals, even making cybercrime accessible to non-professionals.

We saw the interception of bank customers’ electronic operations through the hijacking of bank domains. Thus, customers did not have access to their bank’s real infrastructure, but to a fake one created by intruders. For several hours, criminals were therefore able to perform phishing attacks, install malicious code and wield the operations of customers who were using online banking services at the time.

It’s worth noting that, in some countries, banks have forgotten about the most “unimportant” thing – physical security. This has made attacks on banks’ financial assets possible. In some cases, this was due to easy access to cable lines, to which small Raspberry Pi devices were then connected. For several months these devices passively collected information about bank networks and sent intercepted data over LTE connections to the servers of intruders.

Predictions for 2018
  • Attacks via the underlying blockchain technologies of financial systems

Almost all of the world’s large financial organizations are actively investing in systems based on blockchain technology. Any new technology has its advantages, but also a number of new risks. Financial systems based on blockchain do not exist autonomously, therefore vulnerabilities and errors in blockchain implementation can enable attackers to earn money and disrupt the work of a financial institution. For instance, in 2016-2017, a number of vulnerabilities and errors were discovered in smart contracts, on which a number of financial institution’s services have been built.

  • More supply chain attacks in the financial sphere

Large financial organizations invest considerable resources in cybersecurity, thus the penetration of their infrastructure is not an easy task. However, a threat vector that is likely to be actively used by cybercriminals in the coming year is attacks on software vendors supplying financial organizations. Such vendors, for the most part, have a weak level of protection compared to the financial organizations themselves. Last year, we witnessed a number of attacks like this: including against  NetSarang, CCleaner, and MeDoc. As we can see, attackers replaced or modified updates for very different types of software. In the next year, we can expect cybercriminals to perform attacks via software designed specifically for financial organizations, including software for ATMs and PoS terminals. A few months ago we registered the first attempts of this kind, when attackers embedded a malicious module into a firmware installation file, and placed it on the official website of one of the American ATM software vendors.

  • Mass media (in general, including Twitter accounts, Facebook pages, Telegram, etc.) hacks and manipulation for getting financial profit through stock/crypto exchange trade

2017 will be remembered as the year of ‘fake news’. Besides the manipulation of public opinion, this phrase can also mean a dishonest way of earning money. While stock exchange trading is mostly carried out by robots manipulating source data, which is used to make certain transactions, it can also lead to enormous changes in the price of goods, financial instruments and cryptocurrencies. In fact, just one tweet from an influencer, or a wave of messages on a social network created with the help of fake accounts, can drive the markets. And this method will certainly be used by intruders. With this approach, it’s almost impossible to find out which of the beneficiaries is the customer of the attack.

  • ATM malware automation

The first malware for ATMs appeared in 2009, and since then these devices have received constant attention from cyber-fraudsters. There has been a continuous evolution of this type of attack. The past year saw the emergence of ATM malware-as-a-service, and the next step will be the full automation of such attacks – a mini-computer will be connected automatically to an ATM, leading to malware installation and jackpotting or card data collection. This will significantly shorten the time needed for intruders to commit their crime.

  • More attacks on crypto exchange platforms

For the past year, cryptocurrencies have attracted a huge number of investors, which in turn has led to a boom in new services for trading various coins and tokens. Traditional players in the financial market, with highly developed cybersecurity protection, haven’t rushed to enter this field.

This situation provides attackers with an ideal opportunity to target cryptocurrency exchanges. On the one hand, new companies haven’t managed to test their security systems properly. On the other hand, the entire cryptocurrency exchange business, technically speaking, is built on well-known principles and technologies. Thus, attackers know, as well as have, the necessary toolkit to penetrate the infrastructure of new sites and services working with cryptocurrencies.

  • Traditional card fraud will spike due to the huge data breaches of the previous year

Big personal data leaks – including the recent Equifax case, which resulted in more than 140 million U.S. residents’ data being leaked to cybercriminals, and the Uber case, when the data of another 57 million customers was leaked – has created a situation where traditional banking security can seriously fail, because it’s based on the analysis of data about current or potential customers.

For example, detailed knowledge of a victim’s personal data can allow attackers to pose as a banking customer, and extract their victim’s money or security information, while to the bank concerned, their request looks legitimate. Therefore, the coming year may be marked by a spike in quite traditional fraud schemes, with the big data that has been collected (but not properly protected) by organizations about their customers for years, set to help attackers in the successful realization of their fraud schemes.

  • More nation-state sponsored attacks against financial organizations

The infamous Lazarus group, which is likely to be North-Korean state-sponsored, has attacked a number of banks in different parts of the world in the last few years. These have included banks in countries in Latin America, Europe, Asia and Oceania. Their main purpose has been to withdraw large sums of money, amounting to hundreds of millions of dollars. In addition, the data released by the Shadow Brokers indicates that experienced state-sponsored APT-groups are targeting financial institutions in order to learn more about cash flows. It is very likely that, next year other APT groups from countries that have just joined the cyber-spy game will follow this approach – both to earn money and to obtain information about customers, the flow of funds and the internal procedures of financial organizations.

  • Fintechs’ inclusion and mobile only-users: a fall in the number of traditional PC-oriented internet-banking Trojans. Novice mobile banking users will be a new prime target for criminals

Digital banks will continue revolutionizing the financial sector on a global scale, especially in emerging markets. For example, in Brazil and Mexico, these banks are gaining more and more momentum and this, of course, has attracted cybercriminal attention. We are sure that the world of cybercrime will see increasing attacks against this type of banks and their customers. Their main feature is the complete absence of branches and traditional customer service. All communication between the bank and its customers actually occur through a mobile application. This can have several consequences.

The first is a decrease in the number of Windows Trojans, aimed at stealing money through traditional internet banking. The second is that the growing number of digital financial institutions will lead to organic growth in the number of users that are easy targets for cybercriminals: people without any mobile banking experience, but with banking applications installed on their mobile devices. These people will be the main targets for both malware attacks, such as Svpeng, and schemes completely built on social engineering. Persuading a customer to transfer money through a mobile application is much easier than forcing them to go to a physical bank and make a transaction.


During the past few years, the number and quality of attacks aimed at financial sector organizations has grown continuously. These are attacks on the infrastructure of an organization and its employees, not its customers.

The financial institutions that have not already thought about cybersecurity will soon face the consequences of hacker attacks. And these consequences will be incompatible with the continuation of these businesses: they will lead to a complete halt in operations as well as extreme losses.

To prevent situations like this from happening, it is necessary to constantly adapt security systems to new emerging threats. This is impossible without analyzing data and information about the most important and relevant cyberattacks aimed at financial organizations.

An effective approach to combating attacks will be for banks to choose the right security solutions, but also to use specialized intelligence reports on attacks as these contain information that must be implemented immediately into overall protection systems. For example, using YARA-rules and IOCs (indicators of compromise), will become vital for financial organizations in the coming months.

Kaspersky Security Bulletin: Review of the Year 2017

Tue, 12/05/2017 - 05:00

ul li {margin-bottom:2.4rem;} Introduction

The end of the year is a good time to take stock of the main cyberthreat incidents that took place over the preceding 12 months or so. To reflect on the impact these events had on organizations and individuals, and consider what they could mean for the overall evolution of the threat landscape.

Looking back over 2017, what stands out most is the growing number of blurred boundaries: between different types of threat and different types of threat actor.  Examples of this trend include the headline-making ExPetr attack in June. At first sight, this seemed to be yet another ransomware program, but it turned out to be a targeted, destructive data wiper. Another example is the dumping of code by the Shadow Brokers group, which placed advanced exploits allegedly developed by the NSA at the disposal of criminal groups that would otherwise not have had access to such sophisticated code. Yet another is the emergence of advanced targeted threat (APT) campaigns focused not on cyberespionage, but on theft,  stealing money to finance other activities the APT group is involved in. It will be interesting to see how this trend evolves over 2018.

Highlights of 2017
  • The defining cyber-moments of 2017 were, without doubt, the WannaCry, ExPetr and BadRabbit ransomware attacks. The infamous Lazarus threat actor is believed to have been behind WannaCry, which spread at staggering speed and is now believed to have claimed around 700,000 victims worldwide. ExPetr was more targeted, hitting businesses including many well-known global brands through infected business software.  Maersk, the world’s largest container ship and supply vessel company has declared anticipated losses of between $200 and $300 as a result of ‘significant business interruption’ caused by the attack; while FedEx/TNT has announced around $300 in lost earnings.
  • Elsewhere, the world’s big cyberespionage threat actors continued to do what they do, but with new, harder-to-detect tools and approaches. We reported on a wide range of campaigns, including the historically significant Moonlight Maze, believed to be related to Turla, as well as another Turla-related APT we call WhiteBear. We also uncovered the most recent toolkit of the Lamberts, an advanced threat actor that can be compared with Duqu, Equation, Regin or ProjectSauron in terms of complexity, and more technical details about the Spring Dragon group. In October, our advanced exploit prevention systems identified a new Adobe Flash zero-day exploit used in the wild against our customers, delivered through a Microsoft Office document.  We can confidently link this attack to an actor we track as BlackOasis.  For a more detailed summary of APT activity during 2017, you can view our annual APT review webinar here.
  • In 2017 we also observed a resurgence of targeted attacks designed to destroy data, either instead of, or as well as data theft, for example Shamoon 2.0 and StoneDrill. We also uncovered threat actors achieving success, sometimes for years, with simple and poorly executed campaigns. The EyePyramid attack in Italy was a good example of this. Microcin provided another instance of how cybercriminals can achieve their goals by using cheap tools and selecting their targets with care.
  • 2017 also revealed the extent to which advanced threat actors were diversifying into common theft to fund their expensive operations. We reported on BlueNoroff a subset of the infamous Lazarus group and responsible for the generation of illegal profits. BlueNoroff targeted financial institutions, casinos, companies developing financial trade software and those in the crypto-currency business, among others. One of the most notable BlueNoroff campaigns was its attacks on financial institutions in Poland.
  • Attacks on ATMs continued to rise in 2017, with attackers targeting bank infrastructure and payment systems using sophisticated fileless malware, as well as by the more rudimentary methods of taping over CCTVs and drilling holes. More recently, we discovered a new targeted attack on financial institutions – mainly banks in Russia, but also some in Malaysia and Armenia. The attackers behind this Silence Trojan used a similar approach to Carbanak.
  • Supply chain attacks appear to be the new ‘watering holes’ when it comes to targeting business victims. An emerging threat in 2017, seen in ExPetr and ShadowPad, which looks set to increase further in 2018.
  • A year on from the Mirai botnet in 2016, the Hajime botnet was able to compromise 300,000 connected devices – and it was just one of many campaigns focused on connected devices and systems.
  • 2017 also saw a number of massive data breaches, with millions of records exposed overall –  these include Avanti Markets, Election Systems & Software, Dow Jones, America’s Job Link Alliance and Equifax. The Uber data breach which took place in October 2016 and exposed the data of 57 million customers and drivers was only made public in November 2017.
  • The mobile malware landscape also evolved in 2017, and Trojanized mobile apps were downloaded in their tens of thousands or more, resulting in victims being swamped with aggressive advertising, hit with ransomware or facing theft through SMS and WAP billing. Mobile malware added new tricks to avoid detection, bypass security and exploit new services. As in 2016, many such apps were readily available through reputable sources such as the Google Play Store. Trojans particularly prevalent in 2017 included the Ztorg Trojan, Svpeng, Dvmap, Asacub and Faketoken.

2017 was a year when many things turned out to be very different from what they initially seemed to be. Ransomware was a wiper; legitimate business software was a weapon; advanced threat actors made use of simple tools while attackers farther down the food chain got their hands on highly sophisticated ones. These shifting sands of the cyberthreat landscape represent a growing challenge for security defenders.

For more information on these trends and advice on staying safe, please see the full Review of the Year 2017.

 Download the Kaspersky Security Bulletin: Review of the Year 2017

Kaspersky Security Bulletin – Story of the year 2017

Tue, 11/28/2017 - 05:00

 Download the Kaspersky Security Bulletin: Story of the year 2017

Introduction: what we learned in 2017

In 2017, the ransomware threat suddenly and spectacularly evolved. Three unprecedented outbreaks transformed the landscape for ransomware, probably forever. The attacks targeted businesses and used worms and recently leaked exploits to self-propagate, encrypting data and demanding a ransom they didn’t really want. The perpetrators of these attacks are unlikely to be the common thieves usually lurking behind ransomware. At least one of the attacks carried flaws that suggest it may have been released too soon, another spread via compromised business software, two are related and the two biggest appear to have been designed for data destruction. The cost to victims of these three attacks is already running into hundreds of millions of dollars.

Welcome to ransomware in 2017 – the year global enterprises and industrial systems were added to the ever-growing list of victims, and targeted attackers started taking a serious interest in the threat. It was also a year of consistently high attack numbers, but limited innovation.

This short paper highlights some of the key moments.

The massive outbreaks that were not all they seemed WannaCry

It all started on May 12, when the security community observed something it hadn’t seen for almost a decade: a cyberattack with a worm that spread uncontrollably. On this occasion the worm was designed to install the WannaCry crypto-ransomware on infected machines.

The WannaCry epidemic affected hundreds of thousands of computers around the globe. To propagate, the worm used an exploit dubbed EternalBlue and a backdoor DoublePulsar, both of which had been made public by the Shadow Brokers group a month prior to the outbreak. The worm automatically targeted all computers sharing the same local subnet as the infected machine, as well as random IP ranges outside the local network – spreading it rapidly across the world.

To infect a machine, WannaCry exploited a vulnerability in the Windows implementation of the SMB protocol. Microsoft had released an update to fix this vulnerability back in March 2017, but the number of unpatched machines remained so high that this hardly hindered the propagation of WannaCry.

After infecting a machine and executing a routine to spread further, WannaCry encrypted some valuable files belonging to the victim and displayed a ransom note. Full decryption of the affected files was impossible without paying the ransom – although our analysts discovered several flaws in WannaCry’s code that could allow some victims to restore some of their data without paying the ransom.

Impact of WannaCry

The attack was industry-agnostic, and victims were mainly organizations with networked systems. The ransomware also hit embedded systems. These often run on legacy OS and are therefore particularly vulnerable. Victims received a ransom demand to be paid in bitcoins. Reports suggests the ultimate number of victims could be as high as three-quarters of a million.

Car maker Renault had to close its largest factory in France and hospitals in the UK had to turn away patients. German transport giant Deutsche Bahn, Spain’s Telefónica, the West Bengal power distribution company, FedEx, Hitachi and the Russian Interior Ministry were all hit, too. A month after the initial outbreak had been contained, WannaCry was still claiming victims, including Honda, which was forced to shut down one of its production facilities, and 55 speed cameras in Victoria, Australia.

The unanswered questions about WannaCry

As a devastating high profile attack targeting businesses, WannaCry was extremely successful. As a ransomware plot to make lots of money, it was a failure. Spreading via a worm is not advisable for a threat that is most lucrative when silently stalking the shadows. Estimates suggest it only made around $55,000 in bitcoin, hampered by its high visibility. The code was poor in places, and there are suggestions that it escaped into the wild before it was fully ready. There are also a number of indicators, including early code similarities that suggest the group behind WannaCry is the infamous Korean-speaking threat actor Lazarus.

The true purpose of the WannaCry attack may never be known – was it ransomware gone wrong or a deliberate destructive attack disguised as ransomware?


The second big attack came just six weeks later, on June 27. This was spread predominantly through a supply chain infection and targeted machines mainly in Ukraine, Russia and western Europe. The company’s telemetry indicates that there were more than 5,000 attacked users. Victims received a ‘ransom demand’ of around $300, to be paid in bitcoins – although it turned out that even then they couldn’t get their files back.

ExPetr was a complex attack, involving several vectors of compromise. These included modified EternalBlue (also used by WannaCry) and EternalRomance exploits and the DoublePulsar backdoor for propagation within the corporate network; compromised MeDoc accounting software, which distributed the malware through software updates; and a compromised news website for Ukraine’s Bakhmut region that was used as a watering hole by the attackers.

What’s more, ExPetr was capable of spreading even to properly patched machines in the same local network as the initially infected computer. To do that, it harvested credentials from the infected system by means of a Mimikatz-like tool and proceeded with its lateral movement by means of the PsExec or WMIC instruments.

The encrypting component of ExPetr operated on two levels: encrypting the victim’s files with the AES-128 algorithm and then installing a modified bootloader taken from another malicious program – GoldenEye (the successor of the original Petya). This malicious bootloader encrypted the MFT, a critical data structure of the NTFS file system, and prevented further boot processes, asking for a ransom.

Impact of ExPetr

Victims of ExPetr included major organizations such as shipping ports, supermarkets, ad agencies and law firms: for example, Maersk, FedEx (TNT) and WPP. A month after the attack, TNT’s deliveries were still affected, with SMB customers suffering most. Another victim, consumer goods giant Reckitt Benckiser, lost access to 15,000 laptops, 2,000 servers and 500 computer systems in the space of just 45 minutes when the attack hit – and expects the cost to the business to be over $130 million. Maersk announced a revenue loss of around $300 million due to the attack.

The unanswered questions about ExPetr

Kaspersky Lab experts have found similarities between ExPetr and early variants of BlackEnergy’s KillDisk code – but the true motivation and purpose behind ExPetr also remain unknown.


Then, in late October, another crypto-worm, BadRabbit, appeared. The initial infection started as a drive-by download served from a number of compromised websites and mimicking an update for Adobe Flash Player. When launched on a victim’s computer, BadRabbit’s worm component attempted to self-propagate using the EternalRomance exploit and to employ a lateral movement technique similar to the one utilized by ExPetr. Most of BadRabbit’s targets were located in Russia, Ukraine, Turkey and Germany.

The ransomware component of BadRabbit encrypted the victim’s files, followed by the whole disk partitions using modules of legitimate utility DiskCryptor. The analysis of the code of BadRabbit samples and techniques suggests there is a notable similarity between this malware and ExPetr. However, unlike ExPetr, BadRabbit does not appear to be a wiper, as its cryptographic scheme technically allows the threat actors to decrypt the victim’s computer.

Leaked exploits powered many new waves of attacks

The criminals behind the aforementioned ransomware outbreaks were not the only ones to use the code of exploits leaked by the Shadow Brokers to wreak havoc.

We have discovered some other not-so-notorious ransomware families that at some point used the same exploits. Among them are AES-NI (Trojan-Ransom.Win32.AecHu) and Uiwix (a variant of Trojan-Ransom.Win32.Cryptoff). These malware families are ‘pure’ ransomware in the sense that they do not contain any worm capabilities, i.e. cannot self-replicate, which is why they did not spread nearly as widely as WannaCry, for instance. However, the threat actors behind these malware families exploited the same vulnerabilities on victims’ computers during the initial infections.

Master keys released for several ransomware families

Apart from the large-scale epidemics that shook the world, in Q2 2017 an interesting trend emerged: several criminal groups behind different ransomware cryptors concluded their activities and published the secret keys needed to decrypt victims’ files.

Below is the list of families for which keys became public in Q2:

  • Crysis (Trojan-Ransom.Win32.Crusis);
  • AES-NI (Trojan-Ransom.Win32.AecHu);
  • xdata (Trojan-Ransom.Win32.AecHu);
  • Petya/Mischa/GoldenEye (Trojan-Ransom.Win32.Petr).

The Petya/Mischa/GoldenEye master key was released shortly after the outbreak of ExPetr and might have been an attempt by the original Petya authors to show that they were not the ones behind ExPetr.

The reappearance of Crysis

Despite the fact that the Crysis ransomware appeared to die in May 2017 following the release of all the master keys, it didn’t stay dead for long. In August, we started discovering numerous new samples of this ransomware and they turned out to be almost identical copies of the previously distributed samples, with only a few differences: they had new master public keys, new email addresses that victims were supposed to use to contact the criminals, and new extensions for the encrypted files. Everything else remained unchanged – even the timestamps in the PE headers. After thorough analysis of the old and new samples, our analysts concluded that most likely the new samples were created by binary patching the old ones using a hex editor. One reason for this might be that the criminals behind the new samples didn’t possess the source code and simply reverse-engineered the ransomware to raise it from the dead and use it for their own ends.

RDP infections continue to grow

In 2016, we noticed a new emerging trend among the most widespread ransomware. Instead of trying to trick the victim into launching a malicious executable or using exploit kits, the criminals turned to another infection vector. They were brute-forcing the RDP logins and passwords on machines that had RDP turned on and that were available for access from the Internet.

In 2017, this approach became one of the main propagation methods for several widespread families, such as Crysis, Purgen/GlobeImposter and Cryakl. This means that when securing a network, InfoSec specialists should keep this vector in mind and block RDP access from outside the corporate network.

Ransomware: a year in numbers

It is important not to read too much into the absolute numbers as they reflect changes in detection methodology as much as they do evolution of the landscape. Having said that, a few top line trends are worth noting:

  • The level of innovation appears to be declining – in 2017, 38 new strains of encryption ransomware were deemed interesting and different enough to be designated as new ‘families’, compared to 62 in 2016. This could be due to the fact that the crypto-ransomware model is fairly limited and it is becoming progressively more difficult for malware developers to invent something new.
  • There were many more modifications of new and existing ransomware detected in 2017: over 96,000 compared to 54,000 in 2016. The rise in modifications may reflect attempts by attackers to obfuscate their ransomware as security solutions get better at detecting them.
  • The number of attacks as defined by hits against Kaspersky Lab customers remained fairly constant. In fact, the big spikes of 2016 have been replaced with a more consistent monthly spread. Overall, just under 950,000 unique users were attacked in 2017, compared to around 1.5 million in 2016. However, this data includes both encryptors and their downloaders; if you look at the numbers for encryptors only, the attack data for 2017 is similar to 2016. This makes sense if you consider that many attackers are starting to distribute their ransomware through other means, such as brute-forcing passwords and manual launching. These numbers do not include the many computers around the world unprotected by our solutions that fell victim to WannaCry – this number has been estimated at around 727,000 unique IP addresses.
  • WannaCry, ExPetr and BadRabbit notwithstanding, the number of attacks targeting corporates increased only slightly: 26.2% in 2017 compared to 22.6% in 2016. Just over 4% of those targeted in 2017 were SMBs.

Further details on these trends, including the most affected countries and top ransomware families, can be found in the Kaspersky Security Bulletin 2017 Statistics Report.

According to Kaspersky Lab’s annual IT security survey

  • 65% of businesses that were hit by ransomware in 2017 said they lost access to a significant amount or even all their data; while 29% said that although they were able to decrypt their data, a significant number of files were lost forever. These figures are largely consistent with those for 2016.
  • 34% of those affected took a week if not more to restore full access, up from 29% in 2016.
  • 36% paid the ransom – but 17% of them never recovered their data (32 and 19% in 2016).
Conclusion: what next for ransomware?

In 2017, we saw ransomware apparently being used by advanced threat actors to mount attacks for data destruction rather than for pure financial gain. The number of attacks on consumers, SMBs and enterprises remained high, but they mainly involved existing or modified code from known or generic families.

Is the ransomware business model starting to crack? Is there a more lucrative alternative for cybercriminals motivated by financial gain? One possibility could be cryptocurrency mining. Kaspersky Lab’s threat predictions for cryptocurrencies in 2018 suggest a rise in targeted attacks for the purpose of installing miners. While ransomware provides a potentially large but one-off income, miners can result in lower but longer earnings, and this could be a tempting prospect for many attackers in ransomware’s current turbulent landscape. But one thing’s for sure, ransomware won’t just disappear – neither as a direct threat, nor as a disguise for deeper attacks.

The fight against ransomware continues
  • Through collaboration: On July 25, 2016, the No More Ransom initiative was launched by Kaspersky Lab, the Dutch National Police, Europol, and McAfee. It is a unique example of the power of joint public-private collaboration to both fight cybercriminals and help their victims with expertise, tips and decryption tools. One year on, the project has 109 partners and is available in 26 languages. The online portal carries 54 decryption tools, which between them cover 104 families of ransomware. To date, more than 28,000 devices have been decrypted, depriving cybercriminals of an estimated US$9.5 million in ransom.
  • Through intelligence: Kaspersky Lab has monitored the ransomware threat from the start, and was one of the first to provide regular threat intelligence updates on extortion malware in order to boost industry awareness. The company publishes regular overviews of the evolving ransomware landscape, for instance, here and here.
  • Through technology: Kaspersky Lab offers multi-layered protection against this widespread and increasing threat, including a free anti-ransomware tool that anyone can download and use, regardless of the security solution they use. The company’s products include a further layer of technology: System Watcher that can block and roll back malicious changes made on a device, such as the encryption of files or blocked access to the monitor.

IoT lottery: finding a perfectly secure connected device

Mon, 11/27/2017 - 05:00

Black Friday and Cyber Monday are great for shopping. Vendors flood the market with all kinds of goods, including lots of exciting connected devices that promise to make our life easier, happier and more comfortable. Being enthusiastic shoppers just like many other people around the world, at Kaspersky Lab we are, however paranoid enough to look at any Internet of Things (IoT)-device with some concern, even when the price is favorable. All because there is little fun in buying a coffeemaker that would give up your home or corporate Wi-Fi password to an anonymous hacker, or a baby-monitor that could livestream your family moments to someone you most definitely don’t want it livestreamed to.

It is no secret that the current state of security of the IoT is far from perfect, and in buying one of those devices you are potentially buying a digital backdoor to your house. So, while preparing for IoT-shopping this year, we asked ourselves: what are our chances of buying a perfectly secure connected device? To find the answer, we conducted a small experiment: we randomly took several different connected devices and reviewed their security set up. It would be an exaggeration to say that we conducted a deep investigation. This exercise was more about what you’d be able to see at first glance if you had a clue about how these things should and shouldn’t work. As a result we found some rather worrying security issues and a few, less serious, but unnecessary ones.

We looked at the following devices: a smart battery charger, an app-controlled toy car, an app-controlled smart set of scales, a smart vacuum cleaner, a smart iron, an IP camera, a smart watch, and a smart home hub.

Smart Charger

The first device we checked was the smart charger that attracted us with its built-in Wi-Fi connectivity. You may ask yourself: who would need a remotely controlled battery charger, especially when you need to manually set the battery to charge? Nevertheless, it exists and it allows you not only to charge the battery, but to manage the way you charge it. Like a boss.

The device we tested charges and restores most types of batteries with a nominal voltage from 3 to 12 volts. It has a Wi-Fi module, which allows the device owner to connect remotely to control the charging process, to change the charging settings and to check how much electricity the battery is storing at any time.

Once turned on, the device switches by default to ‘access point’ mode. The user should then connect to the device and open the management interface web page. The connection between the charger and the device you use to access the management panel uses the outdated and vulnerable WEP algorithm instead of WPA2. However it is password protected. Having said that, the predefined password is ‘11111’ and it is actually written in the official documentation that comes with the device and is searchable online. However, you can change the password to a more secure one. Having said that, the length of the password is limited, for some reason, to five symbols. Based on the information available here, it would take four minutes to crack such a password. In addition to that the web interface of the device itself has no password protection at all. It is available as is, once it is connected to your home Wi-Fi network.

Who would attack a smart charger anyway, you may well ask, and you would probably be right as there are likely few black hat hackers in the world who would want to do that. Especially when it requires the attacker to be within range of the Wi-Fi signal or have access to your Wi-Fi router (which, by the way, is a much bigger problem). On the other hand, the ability to interfere with how the battery is charging, or randomly switching the parameters could be considered as worth a try by a wicked person. The probability of real damage, like setting fire to the battery or just ruining it is heavily dependent on the type of battery, however the attack can be performed just for lulz. Just because they can.

To sum up: most likely when using this device, you won’t be in constant danger of a devastating remote cyberattack. However, if your battery eventually catches fire while charging, it could be a sign that you have a hacker in your neighborhood, and you have to change the password for the device. Or it could be the work of a remote hacker, which probably means that your Wi-Fi router needs a firmware update or a password change.

Smart App-Controlled Wireless Spy Vehicle

While some people are looking for useful IoT features, other seek entertainment and fun. After all, who didn’t dream of their own spying toolset when they were young? Well, a Smart App-Controlled Wireless Spy Vehicle would have seemed a dream come true.

This smart device is actually a spy camera on wheels, connected via Wi-Fi and managed via an application. The spy vehicle, sold in toy stores, has Wi-Fi as the only connection interface. For management there are two official applications, for iOS and Android. We assumed that there could be a weakness in the Wi-Fi connections – and we turned out to be right.

The device is able to execute the following commands:

  • Move across the area (with multiple riding modes, it is possible to control speed and direction)
  • View an image from the navigation camera during movement, for ease of navigation
  • View an image from the main camera, which can also be rotated in different directions (there is even a night vision mode)
  • Record photos and videos that are stored in the phone’s memory
  • Play audio remotely via a built-in speaker

Once connected to a phone, it becomes a Wi-Fi access point without password requirements. In other words, any person connected to it can send remote commands to the vehicle – you’d just need to know which commands to send. And if you – being a bit concerned about the lack of password protection in a child’s toy that has spying capabilities – decided to set one up, you’d find there was no opportunity to do so. And if you have basic network sniffing software on your laptop, and decided you’d like to see what the vehicle was currently filming, you’d be able to intercept the traffic between the vehicle and the controlling device.

That said, a remote attack is not possible with this device, and an offensive third-party would have to be within the range of the toy’s Wi-Fi signal which should be enabled. But on the other hand, nothing prevents an attacker from listening to your traffic in a passive mode and catching the moment when the device is used. So if you have seen someone with a Wi-Fi antenna near your house recently, chances are they’re curious about your private life, and have the means to look into it.

Smart Robo Vacuum Cleaner. With camera

Speaking of other devices with cameras that are around you, we spent some time trying to figure out why a smart vacuum cleaner would need to have a web-cam – is it for the macro filming of dust? Or to explore the exciting under-bed world? Joking aside, this function was made specifically for the cleaning enthusiast: if you find it exciting to control the vacuum cleaner manually while checking exactly what it’s doing, this is the gadget for you. Just keep in mind that it is not quite secure.

The device is managed via a specific application – you can control the cleaner’s movement, get video live-streaming while it’s cleaning, take pictures, etc. The video will disappear after streaming, while photos are stored in the application.

There are two ways to connect to the device via Wi-Fi:

  • With the cleaner as access point. If you don’t have a Wi-Fi network in your home, the device will provide the connection itself. You simply connect to the cleaner via the mobile application – and off you go!
  • The cleaner can also work as a Wi-Fi adapter, connected to an existing access point. After connecting to the cleaner-as-access-point you can then connect the device to your home Wi-Fi network for better connection and operation radius.

As the device is managed via a mobile phone application, the user should first go through some kind of authorization. Interestingly enough, for this they only need to enter a weak default password – and that’s it. Thus, an attacker just needs to connect to cleaner’s access point, type in the default password to authorize themselves in the application for pairing the mobile phone and the cleaner. After the pairing is completed, they can control the device. Also, after connection to a local network, the robot vacuum cleaner will be visible in the local network and available via a telnet protocol to anyone who is also connected to this network. Yes, the connection is password protected, which can be changed by the owner of the device (but really, who does that?!), and no, there is no brute force protection in place.

Also the traffic between the app and the device is encrypted, but the key is hard-coded into the app. We are still examining the device, and the following statement should be taken with a big grain of salt, but potentially a third-party could download the app from Google Play, find the key and use it in a Man-in-the-Middle attack against the protocol.

And, of course, like any other Android-app controlled connected device, the robot vacuum cleaner is a subject to attack via rooting malware: upon gaining super user rights, it can access the information coming from the cleaner’s camera and its controls. During the research, we also noticed that the device itself runs on a very old version of Linux OS, which potentially makes it subject to a range of other attacks through unpatched vulnerabilities. This, however, is the subject of ongoing research.

Smart Camera

IP cameras are the devices targeted most often by IoT-hackers. History shows that, besides the obvious unauthorized surveillance, this kind of device can be used for devastating DDoS-attacks. Not surprisingly, today almost any vendor producing such cameras is in the cross-hairs of hackers.

In 2015, our attempt to evaluate the state of security of consumer IoT took a look at baby monitor; this year we’ve focused on a rather different kind of camera: the ones used for outside surveillance – for example the ones you’ve put up in your yard to make sure neighbors don’t steal apples from your trees.

Originally, the device and its relatives from the same vendor were insecure due to a lack of vendor attention to the problem. But the issue of camera protection changed dramatically around 2016 after reports of unauthorized access to cameras became publicly known through a number of publications like here or here.

Previously, all the cameras sold by this vendor were supplied with a factory default account and default password ‘12345’. Of course, users tended not to change the password. In 2016, the picture changed radically when the vendor became an industry pioneer in security issues, and started to supply cameras in ‘not activated’ mode. Thus, there was no access to the camera before activation. Activation required the creation of a password and some network settings. Moreover, the password was validated in terms of basic complexity requirements (length, variety of characters, numbers and special characters). Activation of the camera could be performed from any PC with access to the camera over the local network.

Since this reform, updating the firmware on a camera with a default password leads to the camera demanding a password change and warning the user about security issues every time they connect. The password requirements are quite solid:

Additionally, protection from password brute forcing has been implemented:

Moreover, the vendor added a new security feature to the firmware in 2016. This involves protection against brute forcing, by automatically blocking access for an IP address after five to seven attempts to enter the wrong password. The lock is automatically removed after 30 minutes. The feature, which is enabled by default, significantly increases the level of security.

Nevertheless, not everything is perfect in the camera. For instance, the exchange of data with the cloud is performed via HTTP, with the camera’s serial number as its ID. This obviously makes Man-in-the-Middle attacks more realistic.

In addition to a standard WEB interface for such devices, there is a specialized tool for camera configuration, which can search for cameras on the network, display data on the cameras, and perform basic settings including activation, password changes, and the implementation of password resets for network settings. When triggering the device search the PC sends a single Ethernet frame.

The camera’s response is not encrypted, and contains model information such as the firmware, date reset and network settings. Since this data is transmitted in a non-encrypted way and the request does not have authorization, this one Ethernet package can detect all cameras on the network and obtain detailed information about them. The algorithm has one more weakness: when forming a response, time delays are not considered. As a consequence, it is easy to organize a DDoS attack in the network, sending such requests to all cameras within the presented Ethernet network .

Apart from the described specific protocol, cameras support a standard SSDP protocol for sending notifications, and this allows any software or hardware to automatically detect the cameras. This SSDP data also contains information about the model and serial number of the camera.

One more attack vector lies in the remote password reset, which is supported by a technical support service. Anyone with access to the camera’s network can select a camera through the specialized tool for camera configuration and request the reset procedure. As a result, a small file containing the serial number of the camera is created. The file is sent to the technical support service, which then either refuses the request or sends a special code to enter a new password. Interestingly enough, the service doesn’t even try to check whether the user is the owner of the camera – outdoor surveillance assumes that the camera is located out of reach, and it is almost impossible to identify remotely the author of the request. In this scenario, an insider cybercriminal attack is the most probable vector.

To sum up: luckily this is not the worst camera we’ve ever seen when it comes to cybersecurity; however, some unnecessary issues are still there to be exploited by an offensive user.

Smart Bathroom Scales

Remember that picture from the internet, where hacked smart scales threaten to post their owner’s weight online if they don’t pay a ransom? Well, joking aside we’ve proved this may be possible!

This is a smart device, interacting with a smartphone app via Bluetooth, but it is also equipped with a Wi-Fi module. This connectivity provides the owner with a number of additional features, from weight monitoring on a private website secured by a password to body analysis and integration with various healthcare apps. Interestingly enough, the only Wi-Fi-enabled feature is the receiving of weather updates.

We decided to test the possibility of arbitrary updates\software installation on the specified device in LAN using ARP spoofing and the implementation of Man-in-the-Middle attacks. Here’s what we found.

The mobile phone interacts with the main server via HTTPS, in a series of queries. The scales themselves are connected to the mobile phone via Bluetooth. The process of pairing is simple: you request connection via the application, and then turn the scales’ Bluetooth connection on. Given the very limited time for this stage, it is very unlikely that someone will be able to pair the devices without the user’s knowledge.

Among other things, the device transmits via Bluetooth various user data – mail, indication of weight, etc. The device receives updates via the application. The latter sends the current version of updates and a number of other parameters to the server – the server, in turn, passes to the application a link to the downloaded file and its checksum.

However the updates are provided as is, on the HTTP channel, without encryption, and the updates themselves are also not encrypted. Thus, if you are able to listen to the network to which the device is connected you would be able to spoof the server response or the update itself.

This enabled us to, firstly, ‘roll back’ the version of the updates, and then install a modified version that does not match the one retrieved from the server. In this scenario, the further development of attacks is possible, like installing arbitrary software on the device.

The good news is that this device has no camera, so even if any other severe vulnerabilities are found, you are safe. Besides that, who would want to spend time on hacking smart scales? Well, the concern is a valid one. First of all, see the picture at the beginning of this text, and secondly: as we already mentioned above, sometimes hackers do things just because they can, because certain things are just fun to crack.

Smart Iron

Fun to crack – that is something you can definitely say about a smart iron. The very existence of such a device made us very curious. The list of things you could potentially do should a severe vulnerability be found and exploited looked promising. However, the reality turned out to be rather less amusing. Spoiler: based on our research it is impossible to set fire to the house by hacking the iron. However, there are some other rather interesting issues with this device.

The iron has a Bluetooth connection that enables a number of remote management options through a mobile app. We assumed that communication with the server would be insecure, allowing someone to take control of the device and its sensitive data, as manufacturers would not be paying enough attention to the protection of this channel, believing that a smart iron would be of little value to an attacker.

Once it is connected to the user’s mobile phone, the iron is managed via the application, which exists in versions for both iOS and Android. The app allows you to:

  • View the orientation of the iron (whether it is lying flat, standing, or hanging by its cable)
  • Disable (but – sadly – not enable) the iron
  • Activate ‘safe mode’ (in which iron does not react to a mechanical switch on. To turn the iron on when it is in that mode you need to turn off safe mode in the app).

In terms of on/off safety the iron automatically switches off if it is stationary for five seconds in a ‘lying’ position, or for eight minutes in a ‘standing’ position.

The iron can also be controlled via the internet. For this, it is necessary to have a gateway near the device, like a separate smartphone or tablet with internet access and a special app.

Given all that, we decided to take a closer look at the applications for the device. There are three of them – one for iOS and two for Android. The first Android app is for when you manage the device via Bluetooth and are standing nearby, and the other one is for the gateway, which serves as an online door to your iron when you are not at home. The iOS app is for Bluetooth management. Speaking about the security of all applications, it is worth mentioning that the vendor’s code is not obfuscated at all.

When viewing online traffic, we found out that the Android Bluetooth application uses HTTPS, which is a sensible solution. The corresponding app for iOS does not and neither does the gateway app for Android. We decided to test the traffic for the iOS application.

Example of phishing attack via the application

Once it is enabled, the application offers the user the chance to register, and then sends the data without encryption via HTTP. This gives us a very simple attack vector based on the interception of traffic between the mobile application and the vendor’s server within the local network.

As already mentioned, the phone also communicates with the iron using BLE. The BLE traffic is also not encrypted. After deeper investigation of the applications, we were able to control the iron by creating specific commands just from looking into what is transmitted between the devices.

So, if you were a hacker, what could you do with all this knowledge? First of all if you would be able to capture the user’s credentials, to pass the authorization stage in an official application and to switch off the iron or set it to ‘safe mode’. It is important to note here that these applications are used for all of the vendor’s smart devices, and there are quite a few. This significantly enlarges the attack surface.

No need to worry if you miss the chance to intercept the authentication data. Given that the data exchange between the app and the device is not encrypted, you would be able to intercept a token transmitted from the server to the application and then create your own commands to the iron.

As a result, within the local network an attacker can perform:

  • Identity theft (steal personal email address, username, password)
  • Extortion (take advantage of the ignorance of the user to enable ‘safe mode’ so that the user could not mechanically turn on the iron, and to demand money for disabling ‘safe mode’)

Of course both these vectors are highly unlikely to be extensively performed in the wild, but they are still possible. Just imagine how embarrassing it would be if your private information was compromised, not as a result of an attack by a sophisticated hackers, but because of the poor security of your smart iron.

Smart home hub

The biggest problem with the vast majority of connected devices currently available is that most of them work with your smartphone as a separate, independent device, and are not integrated into a larger smart ecosystem. The problem is partly solved by so called smart hubs – nodes that unite in one place the data exchange between multiple separate smart devices. Although prior art in finding a secure smart hub, conducted by multiple other researchers, leaves little room for hope, we tried anyway and took a fancy smart hub with a touch screen and the ability to work with different IoT-protocols. It is universally compatible, works with ZigBee и ZWave home automation standards, and very easy to handle: according to the manufacturer, it can be set up within three minutes, using the touchscreen.

In addition the hub serves as a wireless Wi-Fi router.

Given all the features this multi-purpose device has, being a router, range extender, access point or wireless bridge, we decided to check one of the most common and most dangerous risks related to unauthorized external access to the router. Because, if successful, it would possibly lead to full control of a user’s smart home, including all connected devices.

And, no surprise, our research has shown there is such a possibility.

To check our assumption we created a local network, by connecting a PC, the device and one more router to each other. All network devices received their IP addresses, and we successfully scanned available ports. Our initial research has shown that, by default, there are two opened ports over WAN. The first one, port 80, is one of the most commonly used and assigned to protocol HTTP. It is the port from which a computer sends and receives web client-based communication and messages from a web server, and which is used to send and receive HTML pages or data. If opened, it means that any user can connect to port 80 and thus have access to the user’s device via the HTTP protocol.

The second one, port 22 for contacting SSH (Secure Shell) servers is used for remote control of the device. Attackers can gain access to a device if they obtain or successfully brute force a root password. Usually it’s not an easy task to do. However, in our research we explored another interesting risky thing with the smart hub that makes this much easier.

While analyzing the router, we discovered it might have problems with a very common threat risk – weak password generation. In the router system we found ELF (Executable and Linkable Format) file ‘rname’ with a list of names. By looking at this list and the password displayed on the screen, it became clear that device’s password is generated based on the names from this file and, thus, it doesn’t take long for brute force cracking.

After a hard reset, the source line for passwords remained, with slightly changed symbols. However, the main password base remained the same, and that still leaves a chance to generate a password.

In addition, we found that for device access a root account is constantly used. Thus, offensive users will know the login and a base part of the password, which will significantly facilitate a hacker attack.

In case the device has a public IP address and the ports described above are opened, the router can be available for external access from the internet. Or, in other case, if a provider or an ISP (Internet Service Provider) improperly configures the visibility of neighboring hosts of the local network, these devices will be available to the entire local network within the same ISP.

In all, we weren’t surprised; just like most any other smart hubs on the market, this one provides a really vast attack surface for an intruder. And this surface covers not only the device itself, but the network it works on. And here are the conclusions which the results of our experiment have brought us to.


Based on what we’ve seen while doing this exercise, the vendors of many IoT-devices developing their products assume that:

  1. They won’t be attacked due to limited device functionality and a lack of serious consequences in the case of a successful attack.
  2. The appropriate level of security for an IoT-device is when there is no easy way to communicate with the wider internet and the attacker needs to have access to the local network the device is connected to.

We have to say that these assumptions are reasonable, but only until the moment when a vulnerable router or multifunctional smart hub, like the one described above, appears in the network to which all other devices are connected. From that moment, all the other devices, no matter how severe or trivial their security issues, are exposed to interference. It is easy to imagine a house, apartment or office populated with all these devices simultaneously, and also easy to imagine what a nightmare it would be if someone tried each of described threat vectors.

So in answer to the question we asked ourselves at the beginning of this experiment, we can say that, based on our results at least, it is still hard to find a perfectly secure IoT-device.

On the other hand, no matter which device you purchase, most likely it won’t carry really severe security issues, but again, only until you connect them to a vulnerable router or smart hub.

Keeping that and the ongoing high sales holiday season in mind we’d like to share the following advice on how to choose IoT devices:

  1. When choosing what part of your life you’re going to make a little bit smarter, consider the security risks. Think twice if you really need a camera-equipped robo vacuum cleaner or a smart iron, which can potentially spill some of your personal data to an unknown third-party.
  2. Before buying an IoT device, search the internet for news of any vulnerability. The Internet of Things is a very hot topic now, and a lot of researchers are doing a great job of finding security issues in products of this kind: from baby monitors to app controlled rifles. It is likely that the device you are going to purchase has already been examined by security researchers and it is possible to find out whether the issues found in the device have been patched.
  3. It is not always a great idea to buy the most recent products released on the market. Along with the standard bugs you get in new products, recently-launched devices might contain security issues that haven’t yet been discovered by security researchers. The best choice is to buy products that have already experienced several software updates.
  4. To overcome challenges of smart devices’ cybersecurity, Kaspersky Lab has released a beta version of its solution for the ‘smart’ home and the Internet of Things – the Kaspersky IoT Scanner. This free application for the Android platform scans the home Wi-Fi network, informing the user about devices connected to it and their level of security.

When it comes to the vendors of IoT-devices, the advice is simple: collaborate with the security vendors and community when developing new devices and improving old ones.

P.S. 1 out of 8

There was one random device in our research, which showed strong enough security for us at least not to be worried about private data leakage or any other devastating consequences. It was a smart watch. Like most other similar devices, these watches require an app to pair them with the smartphone and use. From that moment, most of data exchange between the device and the smartphone, the app and the vendors’ cloud service are reliably encrypted and, without a really deep dive into encryption protocol features or the vendor’s cloud services it is really hard to do anything malicious with the device.

For the pairing the owner should use the pin code displayed on the clock for successful authorization. The pin is randomly generated and is not transmitted from the clock. After entering the pin code in the app, the phone and clock create the key for encryption, and all subsequent communication is encrypted. Thus, in the case of BLE traffic interception an attacker will have to decrypt it as well. For this, an attacker will need to intercept traffic at the stage of generating the encryption key.

It is apparently impossible to get user data (steps, heart rate etc.) directly from the device. Data synchronization from the clock on the phone is encrypted and, in the same form is sent to the server. Thus, data on the phone is not decrypted, so the encryption algorithm and the key are unknown.

From our perspective this is an example of a really responsible approach to the product, because, by default the vendor of this device could also easily limit their security efforts to assuming that no one will try to hack their watches, as, even if successful, nothing serious happens. This is probably true: it is hard to imagine a hacker who would pursue an opportunity to steal information about how many steps you made or how fast your heart beats at any given moment of the day. Nevertheless, the vendor did their best to eliminate even that small possibility. And this is good, because cybersecurity is not all those boring and costly procedures which you have to implement because some hackers found some errors in your products, we think cybersecurity is an important and valuable feature of an IoT-product, just like its usability, design and list of useful functions. We are sure that as soon as IoT-vendors understand this fact clearly, the whole connected ecosystem will become much more secure than it is now.