Kaspersky Securelist

Syndikovat obsah Securelist - Kaspersky Lab’s cyberthreat research and reports
Online headquarters of Kaspersky Lab security experts.
Aktualizace: 15 min 7 sek zpět

Energetic Bear/Crouching Yeti: attacks on servers

9 hodin 16 min zpět

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, kashey.ru, and resources links to which were found on this site. These may have been links to resources developed by the site’s owner: www.esodedi.ru, www.i-stroy.ru, www.saledoor.ru

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 ftpChecker.py 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 https://github.com/sqlmapproject/sqlmap.git

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

19 Duben, 2018 - 12: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 https://t.co/ctdTBQCRNc

— 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

17 Duben, 2018 - 23: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 POST 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 mopub.com

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 appsgeyser.com

According to the appsgeyser.com 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 ushareit.com

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 quantumgraph.com 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

16 Duben, 2018 - 10: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 www.securelist.com 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:

  • wooribank.pib.smart
  • kbstar.kbbank
  • ibk.neobanking
  • sc.danb.scbankapp
  • shinhan.sbanking
  • hanabank.ebk.channel.android.hananbank
  • smart
  • epost.psf.sdsi
  • kftc.kjbsmb
  • smg.spbs
  • webzen.muorigin.google
  • ncsoft.lineagem19
  • ncsoft.lineagem
  • co.neople.neopleotp
  • co.happymoney.android.happymoney
  • nexon.axe
  • nexon.nxplay
  • atsolution.android.uotp2

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 (http://my.tv.sohu.com/user/%s) in the malicious application used for malware control. The site my.tv.sohu.com 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 sohu.com webpage, the malware extracts a Chinese string from a specific part of the HTML code.

For example, the malicious application receives the page at http://my.tv.sohu.com/user/329505338.

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 http://my.tv.sohu[.]com/user/%s https://www.baidu[.]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;' # my.tv.sohu.com pattern = u'公司&lt;/span&gt;([\u4e00-\u9fa5]+?)&lt;' # baidu.com match = re.search(pattern, page.decode("utf-8")) ext = match.group(1) 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 dec_facebook_apk.py my.tv.sohu.com_329505338.html 220.136.76[.]200:8844 $ python dec_facebook_apk.py www.baidu.com_p_wokaixin158998_detail.html 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 malware 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

12 Duben, 2018 - 12: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: intelreports@kaspersky.com.

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 intelreports@kasperksy.com.

Operation Parliament, who is doing what?

12 Duben, 2018 - 09: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: intelreports@kaspersky.com

Alternatively, please visit: https://www.kaspersky.com/enterprise-security/apt-intelligence-reporting

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

Pocket cryptofarms

4 Duben, 2018 - 12: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 placartv.com server. This same domain is used in the developer’s email address specified in the Google Play store. Unbeknown to visitors, the site placartv.com runs a script that mines cryptocurrency.

Code of the placartv.com 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 Vilny.net 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 Vilny.net VPN app

Information about the Vilny.net 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

28 Březen, 2018 - 12: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.