Malware Alerts

Subscribe to Malware Alerts feed Malware Alerts
Online headquarters of Kaspersky Lab security experts.
Updated: 11 hours 39 min 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