On May 23 2018, our colleagues from Cisco Talos published their excellent analysis of VPNFilter, an IoT / router malware which exhibits some worrying characteristics.

Some of the things which stand out about VPNFilter are:

  • It has a redundant, multi-stage command and control mechanism which uses three different channels to receive information
  • It has a multi-stage architecture, in which some of the more complex functionality runs only in the memory of the infected devices
  • It contains a destructive payload which is capable of rendering the infected devices unbootable
  • It uses a broken (or incorrect) RC4 implementation which has been observed before with the BlackEnergy malware
  • Stage 2 command and control can be executed over TOR, meaning it will be hard to notice for someone checking the network traffic

We’ve decided to look a bit into the C&C mechanism for the persistent malware payload. As described in the Talos blog, this mechanism has several stages:

  • First, the malware tries to visit a number of gallery pages hosted on photobucket[.]com and fetches the first image from the page.
  • If this fails, the malware tries fetching an image file from a hardcoded domain, toknowall[.]com. This C2 domain is currently sinkholed by the FBI.
  • If that fails as well, the malware goes into a passive backdoor mode, in which it processes network traffic on the infected device waiting for the attacker’s commands.

For the first two scenarios in which the malware successfully receives an image file, a C2 extraction subroutine is called which converts the image EXIF coordinates into an IPv4 address. This is used as an easy way to avoid using DNS lookups to reach the C&C. Of course, in case this fails, the malware will indeed lookup the hardcoded domain (toknownall[.]com). It may be worth pointing that in the past, the BlackEnergy APT devs have shown a preference for using IP addresses for C&C instead of hardcoded domain names, which can be easily sinkholed.

To analyse the EXIF processing mechanism, we looked into the sample 5f358afee76f2a74b1a3443c6012b27b, mentioned in the Talos blog. The sample is an i386 ELF binary and is about 280KB in size.

Unfortunately for researchers, it appears that the photobucket.com galleries used by the malware have been deleted, so the malware cannot use the first C2 mechanism anymore. For instance:

With these galleries unavailable, the malware tries to reach the hardcoded domain toknowall[.]com.
While looking at the pDNS history for this domain, we noticed that it resolved to an IP addresses in France, at OVH, between Jan and Feb 2018:

Interestingly, when visiting this website’s C2 URL, we are presented with a JPG image, suggesting it is still an active C2:

Here’s how it looks when viewed as an image:

When we look into the EXIF data for the picture, for instance using IrfanView, it looks as following:

Filename – update.jpg

  • GPS information: –
  • GPSLatitude – 97 30 -175 (97.451389)
  • GPSLongitude – -118 140 -22 (-115.672778)

How to get the IP out of these? The subroutine which calculates the C2 IP from the Latitude and Longitude can be found at offset 0x08049160 in the sample.

As it turns out, VPNFilter implements an actual EXIF parser to get the required information.

First, it searches for a binary value 0xE1. This makes sense because the EXIF attribute information begins with a tag “0xFF 0xE1”. Then, it verifies that the tag is followed by a string “Exif”. This is the exact data that should appear in a correct header of the Exif tag:

Exif tag
FF E1 Exif tag
xx Length of field
45 78 69 66 00 ‘Exif’
00 Padding

The tag is followed by an additional header:

“Attribute information” header
49 49 (or 4D 4D) Byte order, ‘II’ for little endian (‘MM’ for big endian)
2A 00 Fixed value
xx xx Offset of the first IFD

The data following this header is supposed to be the actual “attribute information” that is organized in so-called IFDs (Image File Directory) that are data records of a specific format. Each IFD consists of the following data:

IFD record
xx xx IFD tag
xx xx Data type
xx xx xx xx Number of data records of the same data type
xx xx xx xx Offset of the actual data, from the beginning of the EXIF

The malware’s parser carefully traverses each record until it finds the one with a tag ’25 88′ (0x8825 little endian). This is the tag value for “GPS Info”. That IFD record is, in turn, a list of tagged IFD records that hold separate values for latitude, longitude, timestamp, speed, etc. In our case, the code is looking for the tags ‘2’ (latitude) and ‘4’ (longitude). The data for latitude and longitude are stored as three values in the “rational” format : two 32-bit values, the first is the enumerator and the second one is the denominator. Each of these three values corresponds to degrees, minutes and seconds, respectively.

Then, for each record of interest, the code extracts the enumerator part and produces a string of three integers (i.e. “97 30 4294967121” and “4294967178 140 4294967274″ that will be displayed by a typical EXIF parser as 1193143 deg 55′ 21.00″, 4296160226 deg 47′ 54.00”). Then, curiously enough, it uses sscanf() to convert these strings back to integers. This may indicate that the GPS Info parser was taken from a third-party source file and used as-is. The extracted integers are then used to produce an actual IP address. The pseudocode in C is as follows:

const char lat[] = "97 30 4294967121"; // from Exif data
const char lon[] = "4294967178 140 4294967274"; // from Exif data
int o1p1, o1p2, o2p1, o3p1, o3p2, o4p1;
uint8_t octets[4];

sscanf(lat, "%d %d %d", &o1p2, &o1p1, &o2p1);
sscanf(lon, "%d %d %d", &o3p2, &o3p1, &o4p1);
octets[0] = o1p1 + ( o1p2 + 0x5A );
octets[1] = o2p1 + ( o1p2 + 0x5A );
octets[2] = o3p1 + ( o3p2 + 0xB4 );
octets[3] = o4p1 + ( o3p2 + 0xB4 );

printf("%u.%u.%u.%u\n", octets[0], octets[1], octets[2], octets[3]);

The implementation of the EXIF parser appears to be pretty generic. The fact that it correctly handles the byte order (swapping the data, if required) and traverses all EXIF records skipping them correctly, and that the GPS data is converted to a string and then back to integers most likely indicates that the code was reused from an EXIF-parsing library or toolkit.

For the values provided here, the code will produce the IP address “” that is a known C&C of VPNFilter.

It should be noted that this IP is included in Cisco Talos’ IOCs list as a known C&C. Currently, it appears to be down.

What’s next?

Perhaps the most interesting question is who is behind VPNFilter. In their Affidavit for sinkholing the malware C2, FBI suggests it is related to Sofacy:

Interestingly, the same Affidavit contains the following phrase: “Sofacy Group, also known as apt28, sandworm, x-agent, pawn storm, fancy bear and sednit”. This would suggest that Sandworm, also known as BlackEnergy APT, is regarded as subgroup of Sofacy by the FBI. Most threat intel companies have held these groups separate before, although their activity is known to have overlapped in several cases.

Perhaps the most interesting technical detail, which Cisco Talos points in their blog linking VPNFilter to BlackEnergy, is the usage of a flawed RC4 algorithm.The RC4 key scheduling algorithm implementation from these is missing the typical “swap” at the end of the loop. While rare, this mistake or perhaps optimization from BlackEnergy, has been spotted by researchers and described publicly going as far back as 2010. For instance, Joe Stewart’s excellent analysis of Blackenergy2 explains this peculiarity.

So, is VPNFilter related to BlackEnergy? If we are to consider only the RC4 key scheduling implementation alone, we can say there is only a low confidence link. However, it should be noted that BlackEnergy is known to have deployed router malware going back as far as 2014, which we described in our blogpost: “BE2 custom plugins, router abuse, and target profiles“. We continue to look for other similarities which could support this theory.

Read Full Article
Visit website
  • Show original
  • .
  • Share
  • .
  • Favorite
  • .
  • Email
  • .
  • Add Tags 

“If you want to change the world, start with yourself.” In the case of security research this can be rephrased to: “If you want to make the world safer, start with the smart things in your home.” Or, to be more specific, start with your router – the core of any home network as well as an interesting research object. And that router you got from your ISP as part of your internet contract is even more interesting when it comes to research.

The impact of vulnerabilities

Note: the following information about vulnerabilities has been submitted to the respective stakeholders (D-Link, ISP provider, Mitre) and we are publishing this information in accordance with vulnerability disclosure policy.

The following advisory describes four vulnerabilities and hardcoded accounts in D-Link DIR-620 firmware. The firmware runs on various D-Link routers that one of the biggest ISPs in Russia delivers to its customers (this conclusion is based on the fact that the router is provided as part of the standard customer contract and the hardcoded credentials contain the name of the ISP in the login string). This is probably why this particular model of router is so popular in Russia and CIS countries (most home routers are located behind their ISP’s NAT, which is why these routers don’t appear in the statistics).

Geography of vulnerable routers

The object of research

The latest versions of the firmware have hardcoded default credentials that can be exploited by an unauthenticated attacker to gain privileged access to the firmware and to extract sensitive data, e.g., configuration files with plain-text passwords. The vulnerable web interface allows an unauthenticated attacker to run arbitrary JavaScript code in the user environment and run arbitrary commands in the router’s operating system (OS).

Example of firmware interface (probably customized for ISP purposes)

These issues were originally identified in firmware version 1.0.37. Some of the discovered vulnerabilities were also identified in other versions of the firmware:

  • 1.3.1
  • 1.3.3
  • 1.4.0
  • 2.0.22
Technical details Weakness in user data validation (reflected cross-site scripting) (CVE-2018-6212)

The one input field that allows user input – Quick search – inspired me to look deeper into the firmware: the field facilitates an XSS attack vector. A reflected cross-site scripting (XSS) attack is possible as a result of missed filtration for special characters in this field and incorrect processing of the XMLHttpRequest object (this vulnerability was discovered in v.1.3.3, but also present in other versions).

Demonstration of a reflected XSS

Vulnerability metrics:

CVSS v3 Base Score: 6.1

Vector: (CVSS:3.0/AV:N/AC:L/PR:N/UI:R/S:C/C:L/I:L/A:N)

Hardcoded default credentials for web dashboard (CVE-2018-6213)

I downloaded the firmware and extracted the filesystem. Most Unix-based firmware includes BusyBox – software that provides several stripped-down Unix tools for embedded systems. It can easily identify the proprietary binary files, i.e., all binaries that are not in the original BusyBox toolset and which were probably modified for ISP purposes.

I extracted strings from the web server binary (httpd), and my attention was immediately drawn to the “anonymous” string. I looked at the function where this string was being used.

The code responsible for checking the user’s credentials contains ‘harcoded credentials’

These privileged credentials cannot be changed by the administrator. Privileged access to the dashboard allows an attacker to extract sensitive data.

Vulnerability metrics:

CVSS v3 Base Score: 6.5

Vector: (AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H)

OS command injection (CVE-2018-6211)

An OS command injection vulnerability is possible as a result of incorrect processing of the user’s input data in the following parameter (the vulnerability was discovered in v.1.0.3):


Example of request with OS command injection

Vulnerability metrics:

CVSS v3 Base Score: 9.1

Vector: (/CVSS:3.0/AV:N/AC:L/PR:H/UI:N/S:C/C:H/I:H/A:H)

Hardcoded default credentials for Telnet (CVE-2018-6210)

Using the vulnerability above, an attacker can extract Telnet credentials. The credentials were discovered in firmware v1.0.3. For example, by using the default credentials for Telnet an attacker can get administrative access to a router (the fragment of “etc/passwd”).

Demonstration of OS command injection vulnerability

Vulnerability metrics:

CVSS v3 Base Score: 10.0

Vector: (/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H)

How to fix it

We received an official response from the vendor stating that this router model was no longer supported. In this case, we provide the following recommendations:

  • Restrict any access to the web dashboard using a whitelist of trusted IPs
  • Restrict any access to Telnet
  • Regularly change your router admin username and password
Advisory Status

01/15/2018 – reported to vendor
01/15/2018 – reported to ISP
01/24/2018 – received a response from ISP
02/06/2018 – received a response from vendor. Official statement: the model of router was no longer supported by vendor, so vendor will only patch vulnerabilities if the ISP sends a request to do so.

If you’re interested in similar materials related to vulnerability research and you’d like to receive them first, subscribe to the newsletter

Read Full Article
Visit website
  • Show original
  • .
  • Share
  • .
  • Favorite
  • .
  • Email
  • .
  • Add Tags 

Quarterly highlights Data leaks

Early 2018 will be remembered for a series of data leak scandals. The most high-profile saw Facebook CEO Mark Zuckerberg grilled by US Congress, with many public figures supporting the Delete Facebook campaign. As a result, Zuckerberg promised to get tough and make it more difficult to harvest data from third-party apps.

But the buck doesn’t stop entirely with the tech giants—personal data often ends up in cybercriminal hands due to user carelessness. Some techniques may be timeworn, but one in particular still reels in the victims: Facebook users are one of the juiciest targets for cyberfraudsters looking to launch mass phishing attacks. Last year Facebook was one of the Top 3 most exploited company names. The schemes are numerous, but fairly standard: the user is asked to “verify” an account or lured into signing into a phishing site on the promise of interesting content.

Examples of phishing pages mimicking Facebook login

Fake pages such as these exist in all languages ​​supported by the social media. Sometimes the correct localization is selected automatically based on the victim’s IP address.

Example of code used by cybercriminals to determine the victim’s location and adapt the phishing page

Data often falls into the hands of cybercriminals through third-party apps that users themselves give access to their accounts and sometimes even allow to post messages on their own behalf.

In early March, for instance, several hundred VKontakte users were hit when third parties gained access to their private correspondence. This happened as a result of apps using the social network’s open API to request access to personal data without guaranteeing its safe storage and use.

In the headline-grabbing case of Cambridge Analytica’s This Is Your Digital Life app, users also handed over personal information voluntarily. Carelessness is the culprit: many people are unaware of just how much data they give away in personality quizzes.

Social media quizzes often ask for a lot of user data,

Remember that cybercriminals often use social media to spread malicious content. For example, we wrote about fake airline giveaways, adult video spam, and even an Alberto Suárez phishing petition.

Another major personal data story was the appearance in Russia of the GetContact app for smartphones, which not only tells users who’s calling, but shows the names under which their contacts are saved in other app users’ phone books. For this, the program needs to be fed not just the user’s own data, but the entire address book (photos, email addresses, even conversation history). That earned GetContact a ban in several countries (even before it appeared in Russia).

Telegram, ICOs, cryptocurrencies

In Q1 a battle royale broke out over the Telegram messenger. It all began late last year with talk of an upcoming ICO. That provided the backdrop for cybercriminals to create, which by the end of Q1 had allegedly raked in as much as the company’s rumored private ICO.

Fake site offering the chance to participate in the Telegram ICO

That was followed by a wave of phishing mailshots to owners of major Russian channels in Telegram. An account under the name Telegram (or something similar) sent a message informing potential victims that suspicious activity had been detected on their account and that confirmation was required to avoid having it blocked. A link was provided to a phishing site masquerading as the login page for the web version of Telegram.

Phishing site mimicking the web version of the Telegram app

If the victim agreed to fill out the form, the cybercriminals gained access to their account, plus the ability to link it to another phone number.

Another spike in scamming activity was recorded when the Internet was buzzing about the imminent takedown of the messenger in Russia. And when the messenger suffered a power outage in a server cluster, it was widely perceived as the start of the ban. Replying to Pavel Durov’s tweet about the malfunction, enterprising cybercriminals offered compensation on his behalf in cryptocurrency. To claim it, users had to follow a link to a site where they were asked to transfer a sum of money to a specified wallet number to receive their “compensation.”

But Telegram does not have a monopoly over the cryptocurrency topic this quarter. We repeatedly encountered phishing sites and email messages exploiting the launch of new ICOs. Cryptocurrency scams often bring in millions of dollars, which explains why cybercriminals are so fond of them.

For instance, on January 31–February 2 the Bee Token startup held an ICO for which participants had to register in advance on the project website, specifying their email address. Cybercriminals managed to get hold of a list of email addresses of potential investors and send out a timely invitation containing e-wallet details for making Ethereum-based investments.

Phishing email supposedly sent from the ICO organizers

123,3275 ether were transferred to this wallet (around $84,162.37). Fraudsters also set up several phishing sites under the guise of the platform’s official site.

A similar scam occurred with the Buzzcoin ICO. The project website invited users to subscribe to a newsletter by leaving an email address. The day before the official ICO start, subscribers received a fraudulent message about the start of pre-sales with a list of cryptowallets to which money should be transferred.

Phishing email supposedly sent from the ICO organizers

Cybercriminals scooped about $15,000 before the organizers took action.


One measure that addresses user safety is the General Data Protection Regulation (GDPR), a general policy on the protection and privacy of individuals. This EU regulation has a direct bearing on all companies that process data belonging to EU residents, and therefore has an international scope. The GDPR becomes enforceable on May 25 this year and stipulates large fines (up to EUR 20 million or 4% of annual revenue) for companies whose information activity does not comply with the regulation.

Such a landmark event in the IT world could hardly fail to attract cybercriminals, and in recent months (since the end of last year) we have registered a large number of spam emails related one way or another to the GDPR. It is generally B2B spam—mostly invitations to paid seminars, webinars, and workshops promising to explain the ins and outs of the new regulation and its ramifications for business.

We also came across spam offers to install on the target company’s main website or landing page special fee-based software providing web resources with everything necessary to comply with the new rules. Moreover, the site owner would supposedly be insured against problems relating to user data security.

Spam traffic also contained offers to acquire ready-made specialized databases of individuals and legal entities broken down by business division or other criteria. The sellers had no scruples about stressing that all addresses and contacts for sale were already GDPR-compliant. In fact, harvesting user data and reselling it to third parties without the consent of the owners and data carriers violates not only this regulation, but also the law in general.

Example of a spam message exploiting the GDRP topic

Note that legitimate mailers also became more active. They are already sending notices to users describing the new rules and asking for consent to use and process their data under the new policy. When the new regulation enters into force, the number of such notices will skyrocket, so we predict a surge in scam mailings aimed at obtaining personal info and authentication data for access to various accounts. We urge users to pay close attention to the new regulation and carefully study any notifications related to it. Links should be checked before clicking: they should not contain redirects to third-party sites or domains unrelated to the service on whose behalf the message was sent.

Political spam

In the runup to the Russian presidential elections, we observed a range of political spam, including messages promoting or slurring various candidates. The election topic was used for fraud: cybercriminals sent email messages offering a financial reward for taking part in public opinion polls, as a result of which money ended up being transferred in the opposite direction.

Example of a message inviting recipients to take part in a poll

Phishing for taxpayers

Every country has its own tax year, but as a rule the most active period for dealing with tax services comes at the start of the year. In Q1 we registered many phishing pages mimicking the IRS, HMRC, and other countries’ tax services.

Fake tax service websites

Spam-based malware

Back in Q1 2017 we wrote about a mailout disguised as a resume concealing a malicious file from the Fareit Trojan spyware family. The same quarter 2018, cybercriminals attempted to infect users’ computers with the Smoke Loader  backdoor, also known as Dofoil. Its toolbox includes downloading and installing malware such as cryptocurrency miners, banking Trojans, and ransomware. Smoke Loader could also disable some antivirus software and hide from detection by integrating itself into system processes.

The text of the malicious mailshot varied, with some messages imitating the business correspondence of real company employees. To open the password-protected DOC attachment, the user had to enter the password specified in the message, which triggered a request to enable macros (disabled by default); confirmation proved fatal for message recipients. We observed a trend for password-protected malicious attachments in Q1 2018: such protection hinders detection and increases the chances that the message will reach the recipient.

Examples of emails with malicious attachments

Another long-established social engineering method exploits user fears of infection, data leakage, access denial, and other bugbears. In Q1, this old trick was used to dupe users into parting with cryptocurrency. Most messages tried to scare recipients by reporting that malware was installed on their computer and that personal info (lists of contacts, monitor screenshots, webcam videos, etc.) was compromised. If the scammers didn’t receive a hush payment, it was said, the harvested information would be sent to all the victim’s contacts.

Example of a message with a ransom demand in exchange for not publicizing the victim’s personal data

Some messages from cybercriminals tried not only to extract money, but to install malware on recipients’ computers. The malware was located in a protected archive attachment that the attackers claimed was proof that they had the victim’s data.

Malware under the guise of proving cybercriminal intent

Statistics: spam Proportion of spam in email traffic

Proportion of spam in global email traffic, Q4 2017 and Q1 2018

In Q1 2018, the largest share of spam was recorded in January (54.50%). The average share of spam in global email traffic was 51.82%, down 4.63 p.p. against the figure for Q4 2017

Sources of spam by country

Sources of spam by country, Q1 2018

Q1 2018 results put Vietnam (9.22%) top of the leaderboard of spam sources by country. In second place, just 0.64 p.p. behind, came the US (8.55%). The rating’s frequent leader China (7.87%) slipped to third, while India (7.10%) and Germany (6.35%) claimed fourth and fifth. The Top 10 is rounded off by Iran (2.51%).

Spam email size

Spam email size, Q4 2017 and Q1 2018

In Q1 2018, the share of very small emails (up to 2 KB) in spam increased by 19.79 p.p. to 81.62%. Meanwhile,the proportion of emails between 5 and 10 KB in size fell (by 6.05 p.p.) against the previous quarter to 4.11%.

The number of emails between 10 and 20 KB also decreased (by 4.91 p.p.). Likewise, there were fewer emails sized 20 to 50 KB—this quarter they made up just 2.72% of the total, which represents a drop of 6.81 p.p. compared to the previous reporting period.

Malicious attachments in email Top 10 malware families

Top 10 malware families, Q1 2018

The most widespread malware family in email traffic this quarter was Trojan-PSW.Win32.Fareit (7.01%), with Backdoor.Java.QRat (6.71%) and Worm.Win32.WBVB (5.75%) completing the Top 3. Fourth place went to Backdoor.Win32.Androm (4.41%), and Trojan.PDF.Badur (3.56%) rounds off the Top 5.

Countries targeted by malicious mailshots

Distribution of Mail Anti-Virus triggers by country, Q1 2018

Germany (14.67%) was this quarter’s leader by number of Mail Anti-Virus triggers, followed by Russia on 6.37% and Britain with a score of 5.43%. Fourth and fifth positions were occupied by Italy (5.40%) and the UAE (4.30%).

Statistics: phishing

In Q1 2018, the Anti-Phishing module prevented 90,245,060 attempts to direct users to scam websites. The share of unique users attacked made up 9.6% of all users of Kaspersky Lab products worldwide.

Geography of attacks

The country with the largest percentage of users affected by phishing attacks in Q1 2018 was Brazil (19.07%, -1.72 p.p.).

Geography of phishing attacks*, Q1 2018

 * Number of users on whose computers Anti-Phishing was triggered as a percentage of the total number of Kaspersky Lab users in that country

Second came Argentina (13.30%), and third place was taken by Venezuela (12.90%). Fourth and fifth went to Albania (12.56%) and Bolivia (12.32%).

Country %
Brazil 19.07
Argentina 13.30
Venezuela 12.90
Albania 12.56
Bolivia 12.32
Réunion 11.88
Belarus 11.62
Georgia 11.56
France 11.40
Portugal 11.26

Top 10 countries by percentage of users attacked by phishers

Organizations under attack Rating of categories of organizations attacked by phishers

The rating of attacks by phishers on different categories of organizations is based on detections by Kaspersky Lab’s heuristic Anti-Phishing component.  It is activated every time the user attempts to open a phishing page, either by clicking a link in an email or a social media message, or as a result of malware activity. When the component is triggered, a banner is displayed in the browser warning the user about a potential threat.

In Q1 2018, the Global Internet Portals category again took first place with 23.7% (-2.56 p.p.).

Distribution of organizations affected by phishing attacks by category, Q1 2018

However, the combined financial category—banks (18.25%), online stores (17.26%), payment systems (8.41%)—still accounted for almost half of all attacks (43.92%), which is up 4.46 p.p. against the previous quarter . The next categories in descending order were Government Organizations (4.75%), Social Networks and Blogs (4.11%), Telecommunications Companies (2.47%), IT Companies (1.55%), Messengers (0.66%), Online Games (0.43%), and Airlines (0.07%).


The quarter’s main topic, one that we will likely return to many times this year, is personal data. It remains one of the most sought-after wares in the world of information technology for app and service developers, owners of various agencies, and, of course, cybercriminals. Unfortunately, many users still fail to grasp the need to protect their personal information and don’t pay attention to who and how their data is transferred in social media.

Cybercriminal interest in personal data is confirmed by our analysis of spam traffic, where one of the main topics remains mail phishing employing a range of social and technical engineering methods. Throughout the quarter, we observed fake notifications on behalf of social media and popular services, bank phishing, and “Nigerian prince” emails.

The GDPR, set to come on stream in late May, is intended to correct the situation regarding personal data, at least in the EU . Time will tell how effective it is. But one thing is clear: even before its introduction, the new regulation is being actively exploited as a topic by cybercriminals and many others. Regrettably, the GDPR is unlikely to fix the situation.

In Q1 2018, the average share of..

Read Full Article
Visit website
  • Show original
  • .
  • Share
  • .
  • Favorite
  • .
  • Email
  • .
  • Add Tags 

Kaspersky Lab’s many years of cyberthreat research would suggest that any device with access to the Internet will inevitably be hacked. In recent years, we have seen hacked toys, kettles, cameras, and irons. It would seem that no gadget has escaped the attention of hackers, yet there is one last bastion: “smart” devices for animals. For example, trackers to monitor their location. Such gadgets can have access to the owner’s home network and phone, and their pet’s location.

This report highlights the potential risks for users and manufacturers. In it, we examine several trackers for potential vulnerabilities. For the study, we chose some popular models that have received positive reviews:

Technologies used: Bluetooth LE

The four trackers in the study use Bluetooth Low Energy (BLE), which in many cases is the weak spot in the device’s protective armor. Let’s take a closer look at this technology. BLE is an energy-saving Bluetooth specification widely used in IoT devices. What we’re interested in is the lack of authentication and the availability of services and characteristics.

Unlike “classic” Bluetooth, where peer devices are connected using a PIN code, BLE is aimed at non-peer devices, one of which may not have a screen or keyboard. Thus, PIN code protection is not implemented in BLE — authentication depends entirely on the developers of the device, and experience shows that it is often neglected.

The second feature of interest to us is the availability of services, characteristics, and descriptors. They form the basis for data transfer between devices in the BLE specification. As we already noted, BLE works with non-peer devices, one of which (the one that does the connecting) is usually a smartphone. The other device, in our case, is a tracker. After connecting to it, several BLE services are available to the smartphone. Each of them contains characteristics which in turn may have descriptors. Both characteristics and descriptors can be used for data transfer.

Hence, the correct approach to device security in the case of BLE involves pre-authentication before characteristics and descriptors are made available for reading and writing. Moreover, it is good practice to break the link shortly after connecting if the pre-authentication stage is not passed. In this case, authentication should be based on something secret that is not accessible to the attacker—for example, the first part of the data can be encrypted with a specific key on the server (rather than the app) side. Or transmitted data and the MAC address of the connected device can be confirmed via additional communication channels, for example, a built-in SIM card.

Kippy Vita

This tracker transfers GPS coordinates to the server via its built-in SIM card, and the pet’s location is displayed in the mobile app. The tracker does not interface “directly” with the smartphone. We could not detect any problems in the device itself, so we turned our focus to the mobile apps.

Here, too, everything looked pretty good: SSL Pinning was implemented, unlike in any other app we tested. Moreover, the Android app encrypts important data before saving it to its own folder.

The only problem we did detect was that the app for Android logs data that is transmitted to the server. This data can include the user’s password and login, as well as an authentication token.

Output of the Kippy Vita app with user login and password

Despite the fact that not all apps can read logs (only system apps or ones with superuser rights), it is still a major security issue.

Registered CVE:

Link AKC

This tracker monitors the pet’s location via GPS and transfers coordinates via the built-in SIM card. What’s more, it can interface with the owner’s phone directly — via Bluetooth LE. And this means that it is always ready to connect devices, which makes a good starting point for the study.

We were pleasantly surprised by Link AKC: the developers did everything right in terms of securing the connection to the smartphone. We couldn’t find any major problems, which is rare for devices with BLE support.

After the smartphone connects to the device and discovers services, it should enable notifications (that is, inform the tracker of expected changes) in two characteristics and a descriptor (otherwise the tracker breaks the link). After that Link AKC is ready to receive commands. They should contain the user ID; if the user does not have rights to use the tracker, the command is not executed. This maintains control over access rights. Even using the ID obtained from the tested device, we could not make the gadget execute a command from another smartphone—it appears that the tracker checks the smartphone’s MAC address.

However, the device cannot be described as completely secure. In the app for Android, we found that the developers had forgotten to disable logging. As a result, the app transfers lots of data to logcat, including:

  • the app’s authorization token, which if intercepted can be used to sign into the service and discover the pet’s location:

  • User registration data, including name and email address:

  • Device coordinates:

Starting with Android 4.1, only some system apps or apps with superuser rights can read the logs of other programs. It is also possible to gain access when connecting the smartphone to a computer, but this requires Android developer mode to be activated.

Despite these restrictions, it is still a problem: attackers can get hold of data to access the victim’s account, even if the likelihood of this happening is small.

On top of that, the Android app does not verify the server’s HTTPS certificate, exposing it to man-in-the-middle (MITM) attacks. For a successful attack, attackers need only install their own certificate on the smartphone (which is quite simple to do), allowing them to intercept all transmitted data, including passwords and tokens used for account access:

The Link AKC app for Android is vulnerable to MITM attacks

The authorization token is also stored in unencrypted form in the app folder. Although superuser rights are needed to access it, it is still not the best place to store important data.

The authorization token is stored in unencrypted form

Registered CVE:


In terms of functionality, Nuzzle is like the previous tracker: It too uses a SIM card to transmit the pet’s GPS coordinates and can directly connect to a smartphone via BLE. But on the latter point, Nuzzle performed less well than Link AKC: the lack of authorization and access control means that the device is ready to interface with any smartphone. This lets an attacker take control of the device, just like the owner. For example, it can quickly discharge the battery by turning on the light bulb (for which the value of just one attribute needs changing).

An attacker can receive data from the device as soon as a connection is made. Data is available in two characteristics: one contains telemetry information, including device location, while the other provides device status information (in particular, temperature and battery charge).

What is worse, the continuous reading of data from the telemetry characteristic results in the device being “lost”: to save battery power, the gadget does not transmit coordinates via the mobile network if they have already been sent via BLE. Thus, it is possible to conceal the location of the pet simply by connecting to the tracker using a smartphone.

We detected another security hole in the process of updating the device firmware. The integrity control was found to be easy to bypass. Basically, the firmware consists of two files with the extensions DAT and BIN. The first contains information about the firmware, including the checksum (CRC16) used in the integrity control, and the second contains the firmware itself. All it takes to install modified software on the tracker is to change the checksum in the DAT file.

AT commands in Nuzzle firmware

To cripple the device, we didn’t even need to analyze the firmware: it is not encrypted or packed, so just by opening it in a hex editor we were able to find the AT commands and the host used to send data by means of the SIM card. After we changed several bytes in the host, updated the firmware checksum, and uploaded it to the device, the tracker stopped working.

As in the case of Link AKC, the Nuzzle app for Android does not check the server certificate, and the authentication token and user email address are stored in the app folder in unencrypted form.

Unencrypted authorization token and user email address

Registered CVE:


Two TrackR devices featured in our study: Bravo and Pixel. These “trinkets” differ from previous devices in that their tracking range (if indeed they are intended to track pets) is limited to 100 meters: unlike other models, they have no GPS module or SIM card, and the only link to them is via Bluetooth LE. Their main purpose is to locate keys, remote controls, etc. around the apartment. However, the developers have equipped the devices with an option that lets them partially track the movements of something: the trackers location can be  transmitted “via” the smartphones of other TrackR app users. If the app is running on the smartphone, it will transfer data to the service about all “trinkets” detected nearby, together with the smartphone coordinates. Therein lies the first defect: anyone can sign into the mobile app and send fake coordinates.

We managed to identify a few more problems, but as it turned out, most of them had already been discovered by our colleagues at Rapid7. Although their research was published more than a year ago, some vulnerabilities had yet to be fixed at the time of penning this article.

For instance, the devices have no authentication when connecting via Bluetooth LE, which means they are open to intruders. An attacker could easily connect and turn on the audio signal, for example, simply by changing the value of one characteristics. This could let an attacker find the animal before its owner does or run down the tracker battery.

Structure of TrackR services and attributes

Besides, the app for Android does not verify server certificates, meaning that an MITM attack could lead to the interception of the password, authentication token, user email address, and device coordinates.

TrackR Android app requests contain an authentication token

On the bright side, the app does not store the authentication token or password in their own folder, which is the proper way to guard against Trojans that use superuser rights to steal data.

Registered CVE:


Unlike most devices we studied, this tracker does not communicate directly with the smartphone—only through its own servers. This approach is secure enough, but we detected some minor issues in the Android app. First, as in other cases, it does not verify the server certificate, which facilitates MITM attacks. What’s more, the app stores the authentication token in unencrypted form:

As well as pet movement data:

It should be noted that this data is not so easy to steal, since other apps cannot read it. But there are Trojans that can steal data from other apps by exploiting superuser rights.

Weenect WE301

This is another tracker that doesn’t interface with the owner’s smartphone directly, but transfers pet coordinates to the server via a built-in SIM card. We didn’t encounter any security issues with this tracker, but problems similar to those in Tractive were detected in the Android version of the app.

First, it does not prevent MITM attacks, allowing attackers to access the user’s account or intercept geoinformation. Second, authentication data is stored in the app folder in unencrypted form, exposing it to Trojans with superuser rights on the device.

Whistle 3

This is one of the most technically interesting trackers in the study. It can transfer GPS coordinates via its built-in SIM card, via Wi-Fi to its server (if the owner provides a Wi-Fi network password), or directly to the owner’s smartphone via BLE.

We looked at Wi-Fi first of all and found that the developers had taken care to secure the connection: The device transmits small portions of data over HTTPS (that is, in encrypted form).

Wi-Fi data transfer is secured using HTTPS

Next, we checked the BLE connection and found many security issues. The first is the lack of proper authentication. After connecting, the device waits for a certain sequence of actions to be performed, which could be described as pre-authentication. The sequence is so simple that a third party can easily reproduce it. All it takes is to connect to the device, transfer two characteristics to WRITE_TYPE_NO_RESPONSE mode, request a change in the size of transmitted data (MTU), turn on notifications for one characteristics, and transfer a certain number to another characteristics.

Now the tracker is ready to receive and execute commands that do not contain a user ID, which means that anyone can send them. For example, it is possible to send an initiateSession command, and in response the device will send an unencrypted set of data, including the device coordinates. What’s more, if this command is continuously transmitted, the gadget will not send location data via the SIM card, since it will assume that such data has already been received “directly.” Thus, it is possible to “hide” the tracker from its owner.

There is one more problem: the tracker transmits data to the server without any authentication. This means that anyone can substitute it, altering the coordinates in the process.

The app transmits data received from the tracker via BLE

The Android app uses the HTTPS protocol (which is good), but does not verify the server certificate.

MITM attacks can intercept user data

Not only that, the smartphone app stores user data in unencrypted form in its own folder, exposing it to theft by a Trojan with superuser rights. However, authentication data is stored correctly.

Tracker coordinates from the app database

Note that the Android app writes data to logcat. As mentioned above, despite the fact that other app logs can read only some system utilities or apps with superuser rights, there is no need to write important data to the log.

The Android app can log user and pet data (activity, email address, name, owner’s phone number), as well as one of the used tokens

Registered CVE:


GPS trackers have long been applied successfully in many areas, but using them to track the location of pets is a step beyond their traditional scope of application for this, they need to be upgraded with new “user communication interfaces” and “trained” to work with cloud services, etc. If security is not properly addressed, user data becomes accessible to intruders, endangering both users and pets.

Research results: four trackers use Bluetooth LE technology to communicate with the owner’s smartphone, but only one does so correctly. The rest can receive and execute commands from anyone. Moreover, they can be disabled or hidden from the owner—all that’s required is proximity to the tracker.

Just one of the tested Android apps verifies the certificate of its server, without relying solely on the system. As a result, they are vulnerable to MITM attacks—intruders can intercept transmitted data by “persuading” victims to install their certificate.

Read Full Article
Visit website
  • Show original
  • .
  • Share
  • .
  • Favorite
  • .
  • Email
  • .
  • Add Tags 

In April 2018, Kaspersky Lab published a blogpost titled ‘Roaming Mantis uses DNS hijacking to infect Android smartphones’. Roaming Mantis uses Android malware which is designed to spread via DNS hijacking and targets Android devices. This activity is located mostly in Asia (South Korea, Bangladesh and Japan) based on our telemetry data. Potential victims were redirected by DNS hijacking to a malicious web page that distributed a Trojanized application spoofed Facebook or Chrome that is then installed manually by users. The application actually contained an Android Trojan-Banker.

Soon after our publication it was brought to our attention that other researchers were also focused on this malware family. There was also another publication after we released our own blog. We’d like to acknowledge the good work of our colleagues from other security companies McAfee and TrendMicro covering this threat independently. If you are interested in this topic, you may find the following articles useful:

In May, while monitoring Roaming Mantis, aka MoqHao and XLoader, we observed significant changes in their M.O. The group’s activity expanded geographically and they broadened their attack/evasion methods. Their landing pages and malicious apk files now support 27 languages covering Europe and the Middle East. In addition, the criminals added a phishing option for iOS devices, and crypto-mining capabilities for the PC.

27 languages: targeting the world

In our previous blogpost we mentioned that a user attempting to connect to any websites while using a hijacked DNS, will be redirected to malicious landing pages on the rogue server. The landing page displays a popup message that corresponds to the language settings of the device and which urges the user to download a malicious apk file named ‘facebook.apk’ or ‘chrome.apk’.
Kaspersky Lab confirmed several languages hardcoded in the HTML source of the landing page to display the popup message.

The attackers substantially extended their target languages from four to 27, including European and Middle Eastern languages. And yet, they keep adding comments in Simplified Chinese.
But, of course, this multilingualism is not limited to the landing page. The most recent malicious apk (MD5:”fbe10ce5631305ca8bf8cd17ba1a0a35″) also was expanded to supports 27 languages.

The landing page and malicious apk now support the following languages:

  • Arabic
  • Bulgarian
  • Bengali
  • Czech
  • German
  • English
  • Spanish
  • Hebrew
  • Hindi
  • Armenian
  • Indonesian
  • Italian
  • Japanese
  • Georgian
  • Korean
  • Malay
  • Polish
  • Portuguese
  • Russian
  • Serbo-Croatian
  • Thai
  • Tagalog
  • Turkish
  • Ukrainian
  • Vietnamese
  • Traditional Chinese
  • Simplified Chinese

We believe the attacker made use of an easy method to potentially infect more users, by translating their initial set of languages with an automatic translator.

Apple phishing site for iOS device

Previously, this criminal group focused on Android devices only. They have apparently changed their monetizing strategy since then. The attackers now target iOS devices as well, using a phishing site to steal user credentials. When a user connects to the landing page via iOS devices, the user is redirected to ‘http://security.apple.com/’:

A legitimate DNS server wouldn’t be able to resolve a domain name like that, because it simply doesn’t exist. However, a user connecting via a compromised router can access the landing page because the rogue DNS service resolves this domain to the IP address 172.247.116[.]155. The final page is a phishing page mimicking the Apple website with the very reassuring domain name ‘security.apple.com’ in the address bar of the browser.

The phishing site steals user ID, password, card number, card expiration date and CVV. The HTML source of the phishing site also supports 25 languages.

The supported languages are almost the same as on the landing pages and malicious apk files – only Bengali and Georgian are missing from the phishing site.

Web crypto mining for PC

Looking at the HTML source code of the landing page, we also discovered a new feature: web mining via a special script executed in the browser. More details about web miners can be found in our blogpost ‘Mining is the new black‘.

Coinhive is the most popular web miner used by cybercriminals around the world. When a user connects to the landing page from a PC, the CPU usage will drastically increase because of the crypto mining activity in the browser.

Real C2 destination is hidden in email subject

Older malicious apk samples include a legitimate website, accounts and a regular expression for retrieving the real C2 address, which the malware connects to by using a web socket. This process for obtaining its C2 changes in more recent samples, further described below:

MD5 f3ca571b2d1f0ecff371fb82119d1afe 4d9a7e425f8c8b02d598ef0a0a776a58 fbe10ce5631305ca8bf8cd17ba1a0a35
Date March 29 2018 April 7 2018 May 14 2018
File name chrome.apk facebook.apk $random_num{8}.apk
Legitimate web http://my.tv.sohu[.]com/user/%s https://www.baidu[.]com/p/%s/detail n/a
Email n/a n/a @outlook.com
Accounts 329505231
Encrypted dex \assets\db \assets\data.sql \assets\data.sql
Encoding Base64 Base64 + zlib compression Base64 + zlib compression

Older samples retrieved the next C2 by accessing the legitimate website, extracting a Chinese string from a specific part of the HTML code, and decoding it. This scheme has been changed in the recent sample. Instead of using HTML protocol, it now uses email protocol to retrieve the C2.

The malware connects to an email inbox using hardcoded outlook.com credentials via POP3. It then obtains the email subject (in Chinese) and extracts the real C2 address using the string “abcd” as an anchor.
The old and new decoding functions are exactly the same.

We decoded the following next stage C2 servers:

  • 220.136.78[.]40
  • 220.136.73[.]107
Backdoor command “ping”

Kaspersky Lab observed that the previous malicious apk (MD5:f3ca571b2d1f0ecff371fb82119d1afe) had 18 backdoor commands to confirm victims’ environments and to control devices.
According to our analysis, the recent malicious apk (MD5:fbe10ce5631305ca8bf8cd17ba1a0a35) now implements 19 backdoor commands: “ping” was added.

The backdoor commands in the recent sample are as follows:

  • sendSms
  • setWifi
  • gcont
  • lock
  • bc
  • setForward
  • getForward
  • hasPkg
  • setRingerMode
  • setRecEnable
  • reqState
  • showHome
  • getnpki
  • http
  • onRecordAction
  • call
  • get_apps
  • show_fs_float_window
  • ping NEW

This additional command calls the OS ping command with the IP address of the C2 server. By running this, the attackers validate the availability of the server, packet travel time or detect network filtering in the target network. This feature can also be used to detect semi-isolated research environments.

Auto-generating apk file and filename

Roaming Mantis uses a very simple detection evasion trick on the malicious server. It entails the landing page generating a filename for the malicious apk file using eight random numbers.

Aside from the filename, we also observed that all the downloaded malicious apk files are unique due to package generation in real time as of May 16, 2018. It seems the actor added automatic generation of apk per download to avoid blacklisting by file hashes. This is a new feature. According to our monitoring, the apk samples downloaded on May 8, 2018 were all the same.
However, the malicious apk still contains a loader inside ‘classes.dex’ and an encrypted payload inside ‘\assets\data.sql’ that are identical to those in the previous variants. For security researchers, we have added MD5 hashes of the decrypted payloads without hashes of the whole apk files in the IoC of this report, as well as a few full apk hashes that were uploaded to VirusTotal.

Rapidly improving malicious apk and landing pages

Since our first report, Roaming Mantis has evolved quickly. The update history shows how rapidly the threat has been growing:

The actors behind it have been quite active in improving their tools. As seen in the graph below, which shows the unique detected user counts per day according to KSN data, the count increased on May 5. That date is very close to the update date of the new features on the landing pages.

Geographical expansion

Kaspersky Lab products detect Roaming Mantis’s malicious apk files as ‘Trojan-Banker.AndroidOS.Wroba’. Below is the data from Kaspersky Security Network (KSN) based on the verdict ‘Trojan-Banker.AndroidOS.Wroba.al’ from May 1 to May 10, 2018.

It’s clear from this that South Korea, Bangladesh and Japan are no longer the worst affected countries; instead, Russia, Ukraine and India bore the brunt. According to data gathered between February 9 and April 9, the unique user count was 150. It’s worth mentioning that the most recent data shows more than 120 users of Kaspersky Lab products were affected in just 10 days.
Also, it’s important to note that what we see in the KSN data is probably a tiny fraction of the overall picture. There are two reasons for that:

  1. Some users may be using other AV products or no products at all.
  2. Roaming Mantis, after all, uses DNS hijacking, which prevents even our customers from reporting a detection. However, some devices made it through – probably due to switching to cellular data or connecting to another Wi-Fi network.

The Roaming Mantis campaign evolved significantly in a short period of time. The earliest report of this attack was made public by researchers from McAfee in August 2017. At that time, the Roaming Mantis distribution method was SMS and there was one target: South Korea. When we first reported this attack in April 2018, it had already implemented DNS hijacking and expanded its targets to the wider Asian region.
In our report of April this year, we called it an active and rapidly changing threat. New evidence shows a dramatic expansion in the target geography to include countries from Europe, the Middle East and beyond by supporting 27 languages in total. The attackers have also gone beyond Android devices by adding iOS as a new target, and recently started targeting PC platforms – the landing page PC users are redirected to is now equipped with the Coinhive web miner.
The evasion techniques used by Roaming Mantis have also become more sophisticated. Several examples of recent additions described in this post include a new method of retrieving the C2 by using the email POP protocol, server side dynamic auto-generation of changing apk file/filenames, and the inclusion of an additional command to potentially assist in identifying research environments, have all been added.
The rapid growth of the campaign implies that those behind it have a strong financial motivation and are probably well-funded.

For our previous findings, please refer to the Securelist post Roaming Mantis uses DNS hijacking to infect Android smartphones.

Kaspersky products detect this malware as:

  • HEUR:Trojan-Banker.AndroidOS.Wroba

Kaspersky Lab products block the Coinhive web miner for PC.


Malicious hosts:

  • 43.240.14[.]44
  • 118.168.201[.]70 NEW
  • 118.168.202[.]125 NEW
  • 128.14.50[.]147
  • 172.247.116[.]155 NEW
  • 220.136.73[.]107 NEW
  • 220.136.76[.]200
  • 220.136.78[.]40 NEW
  • 220.136.111[.]66
  • 220.136.179[.]5
  • 220.136.182[.]72 NEW
  • shaoye11.hopto[.]org
  • haoxingfu01.ddns[.]net

Malicious apks:

  • 03108e7f426416b0eaca9132f082d568
  • 07eab01094567c6d62a73f7098634eb8 NEW
  • 1cc88a79424091121a83d58b6886ea7a
  • 2a1da7e17edaefc0468dbf25a0f60390
  • 31e61e52d38f19cf3958df2239fba1a7
  • 34efc3ebf51a6511c0d12cce7592db73
  • 4d9a7e425f8c8b02d598ef0a0a776a58
  • 531714703557a58584a102ecc34162ff NEW
  • 904b4d615c05952bcf58f35acadee5c1
  • 9f94c34aae5c7d50bc0997d043df032b NEW
  • a21322b2416fce17a1877542d16929d5
  • b84b0d5f128a8e0621733a6f3b412e19
  • bd90279ad5c5a813bc34c06093665e55
  • cc1e4d3af5698feb36878df0233ab14a NEW
  • ff163a92f2622f2b8330a5730d3d636c
  • 808b186ddfa5e62ee882d5bdb94cc6e2
  • ee0718c18b2e9f941b5d0327a27fbda1 NEW


  • 13c8dda30b866e84163f82b95008790a NEW
  • 19e3daf40460aea22962d98de4bc32d2
  • 1b984d8cb76297efa911a3c49805432e NEW
  • 36b2609a98aa39c730c2f5b49097d0ad
  • 3ba4882dbf2dd6bd4fc0f54ec1373f4c
  • 46c34be9b3ff01e73153937ef35b0766 NEW
  • 5145c98d809bc014c3af39415be8c9ac NEW
  • 6116dc0a59e4859a32caddaefda4dbf4 NEW
  • 8a4ed9c4a66d7ccb3d155f85383ea3b3
  • a5d2403b98cddcd80b79a4658df4d147 NEW
  • b43335b043212355619fd827b01be9a0
  • b4152bee9eca9eb247353e0ecab37aa5 NEW
  • b7afa4b2dafb57886fc47a1355824199
  • bf5538df0688961ef6fccb5854883a20 NEW
  • f89214bfa4b4ac9000087e4253e7f754
  • 6cac4c9eda750a69e435c801a7ca7b8d
  • e56cccd689a9e354cb539bb069733a43 NEW
  • fe0198f4b3d9dc501c2b7db2750a228b NEW

Decrypted payload (dex file) from \assets\data.sql:

  • 1bd7815bece1b54b7728b8dd16f1d3a9
  • 28ef823d10a3b78f8840310484e3cc69 NEW
  • 307d2780185ba2b8c5ad4c9256407504
  • 3e01b64fb9fe9605fee7c07e42907a3b NEW
  • 3e4bff0e8ed962f3c420692a35d2e503
  • 3ed3b8ecce178c2e977a269524f43576 NEW
  • 57abbe642b85fa00b1f76f62acad4d3b
  • 6e1926d548ffac0f6cedfb4a4f49196e
  • 6d5f6065ec4112f1581732206539e72e NEW
  • 7714321baf6a54b09baa6a777b9742ef
  • 7aa46b4d67c3ab07caa53e8d8df3005c
  • a0f88c77b183da227b9902968862c2b9
  • b964645e76689d7e0d09234fb7854ede
Read Full Article
Visit website
  • Show original
  • .
  • Share
  • .
  • Favorite
  • .
  • Email
  • .
  • Add Tags 

Q1 figures

According to KSN:

  • Kaspersky Lab solutions blocked 796,806,112 attacks launched from online resources located in 194 countries across the globe.
  • 282,807,433 unique URLs were recognized as malicious by Web Anti-Virus components.
  • Attempted infections by malware designed to steal money via online access to bank accounts were logged on the computers of 204,448 users.
  • Ransomware attacks were registered on the computers of 179,934 unique users.
  • Our File Anti-Virus logged 187,597,494 unique malicious and potentially unwanted objects.
  • Kaspersky Lab products for mobile devices detected:
    • 1,322,578 malicious installation packages
    • 18,912 installation packages for mobile banking Trojans
    • 8,787 installation packages for mobile ransomware Trojans
Mobile threats Q1 events

In Q1 2018, DNS-hijacking, a new in-the-wild method for spreading mobile malware on Android devices, was identified. As a result of hacked routers and modified DNS settings, users were redirected to IP addresses belonging to the cybercriminals, where they were prompted to download malware disguised, for example, as browser updates. That is how the Korean banking Trojan Wroba was distributed.

This malicious resource shows a fake window while displaying the legitimate site in the address bar

It wasn’t a drive-by-download case, since the success of the attack largely depended on actions by the victim, such as installing and running the Trojan. But it’s interesting to note that some devices (routers) were used to attack other devices (smartphones), all sprinkled with social engineering to make it more effective.

However, a far greater splash in Q1 was caused by the creators of a seemingly legitimate app called GetContact.

Some backstory to begin with. Various families and classes of malicious apps are known to gather data from infected devices: it could be a relatively harmless IMEI number, phone book contents, SMS correspondence, or even WhatsApp chats. All the above (and much more besides) is personal information that only the mobile phone owner should have control over. However, the creators of GetContact concocted a license agreement giving them the right to download the user’s phone book to their servers and grant all their subscribers access to it. As a result, anyone could find out what name GetContact users had saved their phone number under, often with sad consequences. Let’s hope that the app creators had the noble intention of protecting users from telephone spam and fraudulent calls, but simply chose the wrong means to do so.

Mobile threat statistics

In Q1 2018, Kaspersky Lab detected 1,322,578 malicious installation packages, down 11% against the previous quarter.

Number of detected malicious installation packages, Q2 2017 – Q1 2018

Distribution of detected mobile apps by type

Distribution of newly detected mobile apps by type, Q4 2017 and Q1 2018

Among all the threats detected in Q1 2018, the lion’s share belonged to potentially unwanted RiskTool apps (49.3%); compared to the previous quarter, their share fell by 5.5%. Members of the RiskTool.AndroidOS.SMSreg family contributed most to this indicator.

Second place was taken by Trojan-Dropper threats (21%), whose share doubled. Most detected files of this type came from the Trojan-Dropper.AndroidOS.Piom family.

Advertising apps, which ranked second in Q4 2017, dropped a place—their share decreased by 8%, accounting for 11% of all detected threats.

On a separate note, Q1 saw a rise in the share of mobile banking threats. This was due to the mass distribution of Trojan-Banker.AndroidOS.Faketoken.z.

TOP 20 mobile malware

Note that this malware rating does not include potentially dangerous or unwanted programs such as RiskTool and Adware.

  Verdict %*
1 DangerousObject.Multi.Generic 70.17
2 Trojan.AndroidOS.Boogr.gsh 12.92
3 Trojan.AndroidOS.Agent.rx 5.55
4 Trojan-Dropper.AndroidOS.Lezok.p 5.23
5 Trojan-Dropper.AndroidOS.Hqwar.ba 2.95
6 Trojan.AndroidOS.Triada.dl 2.94
7 Trojan-Dropper.AndroidOS.Hqwar.i 2.51
8 Trojan.AndroidOS.Piom.rfw 2.13
9 Trojan-Dropper.AndroidOS.Lezok.t 2.06
10 Trojan.AndroidOS.Piom.pnl 1.78
11 Trojan-Dropper.AndroidOS.Agent.ii 1.76
12 Trojan-SMS.AndroidOS.FakeInst.ei 1.64
13 Trojan-Dropper.AndroidOS.Hqwar.gen 1.50
14 Trojan-Ransom.AndroidOS.Zebt.a 1.48
15 Trojan.AndroidOS.Piom.qmx 1.47
16 Trojan.AndroidOS.Dvmap.a 1.40
17 Trojan-SMS.AndroidOS.Agent.xk 1.35
18 Trojan.AndroidOS.Triada.snt 1.24
19 Trojan-Dropper.AndroidOS.Lezok.b 1.22
20 Trojan-Dropper.AndroidOS.Tiny.d 1.22

* Unique users attacked by the relevant malware as a percentage of all users of Kaspersky Lab’s mobile antivirus that were attacked.

As before, first place in our TOP 20 went to DangerousObject.Multi.Generic (70.17%), the verdict we use for malware detected using cloud technologies. Cloud technologies work when the anti-virus databases lack data for detecting a piece of malware, but the cloud of the anti-virus company already contains information about the object. This is basically how the latest malicious programs are detected.

In second place was Trojan.AndroidOS.Boogr.gsh (12.92%). This verdict is given to files recognized as malicious by our system based on machine learning.

Third was Trojan.AndroidOS.Agent.rx (5.55%). Operating in background mode, this Trojan’s task is to covertly visit web pages as instructed by its C&C.

Fourth and fifth places went to the Trojan matryoshkas Trojan-Dropper.AndroidOS.Lezok.p (5.2%) and Trojan-Dropper.AndroidOS.Hqwar.ba (2.95%), respectively. Note that in Q1 threats like Trojan-Dropper effectively owned the TOP 20, occupying eight positions in the rating. The main tasks of such droppers are to drop a payload on the victim, avoid detection by security software, and complicate the reverse engineering process. In the case of Lezok, an aggressive advertising app acts as the payload, while Hqwar can conceal a banking Trojan or ransomware.

Sixth place in the rating was taken by the unusual Trojan Triada.dl (2.94%) from the Trojan.AndroidOS.Triada family of modular-designed malware, which we have written about many times. The Trojan was notable for its highly sophisticated attack vector: it modified the main system library libandroid_runtime.so so that malicious code started when any debugging output was written to the system event log. Devices with the modified library ended up on store shelves, thus ensuring that the infection began early. The capabilities of Triada.dl are almost limitless: it can be embedded in apps already installed and pinch data from them, and it can show the user fake data in “clean” apps.

The Trojan ransomware Trojan-Trojan-Ransom.AndroidOS.Zebt.a (1.48%) finished 14th. It features a quaint set of functions, including hiding the icon at startup and requesting device administrator rights to counteract deletion. Like other such mobile ransomware, the malware is distributed under the guise of a porn app.

Another interesting resident in the TOP 20 is Trojan-SMS.AndroidOS.Agent.xk (1.35%), which operates like the SMS Trojans of 2011. The malware displays a welcome screen offering various services, generally access to content. At the bottom in fine print it is written that the services are fee-based and subscription to them is via SMS.

Geography of mobile threats

Map of attempted infections using mobile malware in Q1 2018 (percentage of attacked users in the country)

TOP 10 countries by share of users attacked by mobile malware:

  Country* %**
1 China 34.43
2 Bangladesh 27.53
3 Nepal 27.37
4 Ivory Coast 27.16
5 Nigeria 25.36
6 Algeria 24.13
7 Tanzania 23.61
8 India 23.27
9 Indonesia 22.01
10 Kenya 21.45

* Excluded from the rating are countries with relatively few users of Kaspersky Lab’s mobile antivirus (under 10,000).
** Unique users attacked in the country as a percentage of all users of Kaspersky Lab’s mobile antivirus in the country.

In Q1 2018, China (34.43%) topped the list by share of mobile users attacked. Note that China is a regular fixture in the TOP 10 rating by number of attacked users: It came sixth in 2017, and fourth in 2016. As in 2017, second place was claimed by Bangladesh (27.53%). The biggest climber was Nepal (27.37%), rising from ninth place last year to third.

Russia (8.18%) this quarter was down in 39th spot, behind Qatar (8.22%) and Vietnam (8.48%).

The safest countries (based on proportion of mobile users attacked) are Denmark (1.85%) and Japan (1%).

Mobile banking Trojans

In the reporting period, we detected 18,912 installation packages for mobile banking Trojans, which is 1.3 times more than in Q4 2017.

Number of installation packages for mobile banking Trojans detected by Kaspersky Lab, Q2 2017 – Q1 2018

Verdict %*
1 Trojan-Banker.AndroidOS.Asacub.bj 12.36
2 Trojan-Banker.AndroidOS.Svpeng.q 9.17
3 Trojan-Banker.AndroidOS.Asacub.bk 7.82
4 Trojan-Banker.AndroidOS.Svpeng.aj 6.63
5 Trojan-Banker.AndroidOS.Asacub.e 5.93
6 Trojan-Banker.AndroidOS.Hqwar.t 5.38
7 Trojan-Banker.AndroidOS.Faketoken.z 5.15
8 Trojan-Banker.AndroidOS.Svpeng.ai 4.54
9 Trojan-Banker.AndroidOS.Agent.di 4.31
10 Trojan-Banker.AndroidOS.Asacub.ar 3.52

* Unique users attacked by the relevant malware as a percentage of all users of Kaspersky Lab’s mobile antivirus that were attacked by banking threats.

The most popular mobile banking Trojan in Q1 was Asacub.bj (12.36%), nudging ahead of second-place Svpeng.q (9.17%). Both these Trojans use phishing windows to steal bank card and authentication data for online banking. They also steal money through SMS services, including mobile banking.

Note that the TOP 10 mobile banking threats in Q1 is largely made up of members of the Asacub (4 out of 10) and Svpeng (3 out of 10) families. However, Trojan-Banker.AndroidOS.Faketoken.z also entered the list. This Trojan has extensive spy capabilities: it can install other apps, intercept incoming messages (or create them on command), make calls and USSD requests, and, of course, open links to phishing pages.

Geography of mobile banking threats in Q1 2018 (percentage of attacked users)

TOP 10 countries by share of users attacked by mobile banking Trojans

  Country* %**
1 Russia 0.74
2 USA 0.65
3 Tajikistan 0.31
4 Uzbekistan 0.30
5 China 0.26
6 Turkey 0.22
7 Ukraine 0.22
8 Kazakhstan 0.22
9 Poland 0.17
10 Moldova 0.16

* Excluded from the rating are countries with relatively few users of Kaspersky Lab’s mobile antivirus (under 10,000).
** Unique users attacked by mobile banking Trojans in the country as a percentage of all users of Kaspersky Lab’s mobile antivirus in this country.

The Q1 2018 rating was much the same as the situation observed throughout 2017: Russia (0.74%) remained top.

The US (0.65%) and Tajikistan (0.31%) took silver and bronze, respectively. The most popular mobile banking Trojans in these countries were various modifications of the Trojan-Banker.AndroidOS.Svpeng family, as well Trojan-Banker.AndroidOS.Faketoken.z.

Mobile ransomware Trojans

In Q1 2018, we detected 8,787 installation packages for mobile ransomware Trojans, which is just over half the amount seen in the previous quarter and 22 times less than in Q2 2017. This significant drop is largely because attackers began to make more use of droppers in an attempt to hinder detection and hide the payload. As a result, such malware is detected as a dropper (for example, from the Trojan-Dropper.AndroidOS.Hqwar family), even though it may contain mobile ransomware or a “banker.”

Number of installation packages for mobile ransomware Trojans detected by Kaspersky Lab (Q2 2017 – Q1 2018)

Note that despite the decline in their total number, ransomware Trojans remain a serious threat — technically they are now far more advanced and dangerous. For instance, Trojan-Trojan-Ransom.AndroidOS.Svpeng acquires device administrator rights and locks the smartphone screen with a PIN if an attempt is made to remove them. If no PIN is set (could also be a graphic, numeric, or biometric lock), the device is locked. In this case, the only way to restore the smartphone to working order is to reset the factory settings.

The most widespread mobile ransomware in Q1 was Trojan-Ransom.AndroidOS.Zebt.a — it was encountered by more than half of all users. In second place was Trojan-Ransom.AndroidOS.Fusob.h, having held pole position for a long time. The once popular Trojan-Ransom.AndroidOS.Svpeng.ab only managed fifth place, behind Trojan-Ransom.AndroidOS.Egat.d and Trojan-Ransom.AndroidOS.Small.snt. Incidentally, Egat.d is a pared-down version of Zebt.a, both have the same creators.

Geography of mobile ransomware Trojans in Q1 2018 (percentage of attacked users)

TOP 10 countries by share of users attacked by mobile ransomware Trojans:

  Country* %**
1 Kazakhstan 0.99
2 Italy 0.64
3 Ireland 0.63
4 Poland 0.61
5 Belgium 0.56
6 Austria 0.38
7 Romania 0.37
8 Hungary 0.34
9 Germany 0.33
10 Switzerland 0.29

* Excluded from the rating are countries where the number of users of Kaspersky Lab’s mobile antivirus is relatively small (fewer than 10,000)
** Unique users in the country attacked by mobile ransomware Trojans as a percentage of all users of Kaspersky Lab’s mobile antivirus in the country.

First place in the TOP 10 again went to Kazakhstan (0.99%); the most active family in this country was Trojan-Ransom.AndroidOS.Small. Second came Italy (0.64%), where most attacks were the work of Trojan-Ransom.AndroidOS.Zebt.a, which is also the most popular mobile ransomware in third-place Ireland (0.63%).

Vulnerable apps used by cybercriminals

In Q1 2018, we observed some major changes in the distribution of exploits launched against users. The share of Microsoft Office exploits (47.15%) more than doubled compared with the average for 2017. This is also twice the quarterly score of the permanent leader in recent years — browser exploits (23.47%). The reason behind the sharp increase is clear: over the past year, many different vulnerabilities have been found in Office applications, like in Adobe Flash before that. But recently the share of Flash exploits has been decreasing (2.57% in Q1), since Adobe and Microsoft are doing all they can to hinder the exploitation of Flash Player.

Distribution of exploits used in attacks by type of application attacked, Q1 2018

The most frequently used vulnerability in Microsoft Office in Q1 was CVE-2017-11882 — a stack overflow-type vulnerability in Equation Editor, a rather old component in the Office suite. Attacks using this vulnerability make up approximately one-sixth of all exploit-based attacks. This is presumably because CVE-2017-11882 exports are fairly reliable. Plus, the bytecode processed by Equation Editor allows the use of various obfuscations, which increases the chances of bypassing the protection and launching a successful attack (Kaspersky Lab’s Equation disassembler easily handles all currently known obfuscations). Another vulnerability found in Equation Editor this quarter was CVE-2018-0802. It too is exploited, but less actively. The following exploits for logical vulnerabilities in Office found in 2017 were also encountered: CVE-2017-8570, CVE-2017-8759, CVE-2017-0199. But even their combined number of attacks does not rival CVE-2017-11882.

As for zero-day exploits in Q1, CVE-2018-4878 was reported by a South Korean CERT and several other sources in late January. This is an Adobe Flash vulnerability originally used in targeted attacks (supposedly by the Scarcruft group). At the end of the quarter, an exploit for it appeared in the widespread GreenFlash Sundown, Magnitude, and RIG exploit kits. In targeted attacks, a Flash object with the exploit was embedded in a Word document, while exploit kits distribute it via web pages.

Large-scale use of network exploits using vulnerabilities patched by the MS17-010 update (those that exploited EternalBlue and other vulnerabilities from the Shadow Brokers leak) also continued throughout the quarter. MS17-010 exploits account for more than 25% of all network attacks that we registered.

Malicious programs online (attacks via web resources)

The statistics in this chapter are based on Web Anti-Virus, which protects users when malicious objects are downloaded from malicious/infected web pages. Malicious websites are specially created by cybercriminals; web resources with user-created content (for example, forums), as well as hacked legitimate resources, can be infected.

Online threats in the financial sector Q1 events

In early 2018, the owners of the Trojan Dridex were particularly active. Throughout its years-long existence, this malware has acquired a solid infrastructure. Today, its main line of activity is compromising credentials for online banking services with subsequent theft of funds from bank accounts. Its accomplice is fellow banking Trojan Emotet. Discovered in 2014, this malware also belongs to a new breed of banking Trojans developed from scratch. However, it was located on the same network infrastructure as Dridex, suggesting a close link between the two families. But now Emotet has lost its banking functions and is used by attackers as a spam bot and loader with Dridex as the payload. Early this year, it was reported that the encryptor BitPaymer (discovered last year) was developed by the same group behind Dridex. As a result, the malware was rebranded FriedEx.

Q1 saw the arrest of the head of the criminal group responsible for the Carbanak and Cobalt malware attacks, it was reported by Europol. Starting in 2013, the..

Read Full Article
Visit website
  • Show original
  • .
  • Share
  • .
  • Favorite
  • .
  • Email
  • .
  • Add Tags 

Targeted attacks and malware campaigns Skygofree:  sophisticated mobile surveillance

In January, we uncovered a sophisticated mobile implant that provides attackers with remote control of infected Android devices.  The malware, called Skygofree (after one of the domains it uses), is a targeted cyber-surveillance tool that has been in development since 2014.  The malware is spread by means of spoofed web pages that mimic leading mobile providers.  The campaign is ongoing and our telemetry indicates that there have been several victims, all in Italy.  We feel confident that the developer of Skygofree is an Italian IT company that works on surveillance solutions.

The latest version of Skygofree includes functionality that has so far not been seen in the wild.  Features include the ability to eavesdrop on conversations when the victim moves into a specific location; using Accessibility Services to capture WhatsApp messages and the ability to force an infected device to Wi-Fi networks controlled by the attackers.  The malware includes multiple exploits for root access and is capable of stealing pictures and videos, capturing call records, SMS, geo-location, calendar events and business-related data stored in the device’s memory.  The Skygofree implant puts itself in the list of ‘protected apps’, so that it doesn’t get switched off when the screen is off (this is to work around a battery-saving technique that has been implemented by one of the top device vendors.)

Our investigation also uncovered several spyware tools for Windows that form an implant for stealing sensitive data from a target computer.  The version we found was created at the start of 2017:  at the moment, we do not know if this implant has been used in the wild.

Since then we have also found a version for iOS that uses a rogue MDM (Mobile Device Management) server in order to infect devices.

Olympic Destroyer… but who did the ‘destroying’?

The issue of attribution was thrown into sharp relief following the malware attack on the Olympic infrastructure just before the opening of the games in February.  Olympic Destroyer shut down display monitors, killed Wi-Fi and took down the Olympics web site – preventing visitors from to printing tickets.  The attack also affected other organizations in the region – for example, ski gates and ski lifts were disabled at several South Korean ski resorts.

Olympic Destroyer is a network worm, the main purpose of which is to deliver and start a wiper payload that tries to destroy files on remote network shares in the following 60 minutes. In the meantime, the main module collects user passwords from the browser and Windows storage and crafts a new generation of the worm that contains old and freshly-collected compromised credentials.  This new generation worm is pushed to accessible local network computers and starts using the PsExec tool, drawing on the stolen 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 services on the system and reboots the computer.  Those files on the network shares that it was able to wipe within 60 minutes remain destroyed.  The malware doesn’t use any persistence and even contains protection against recurring reinfection.

One of the most notable aspects of this incident was the ‘attribution hell’ that followed.  In the days after the attack, research teams and media companies around the world variously attributed the attack to Russia, China and North Korea – based on a number of features previously attributed to cyber-espionage and sabotage groups allegedly based in these countries or working for the governments of these countries.

Our own researchers were also trying to understand which group was behind the attack.  At one stage during our research, we discovered something that seemed to indicate that the Lazarus group was behind the attack.  We found a unique trace left by the attackers that exactly matched a previously known Lazarus malware component.  However, the lack of obvious motive and inconsistencies with known Lazarus TTPs (tactics, techniques and procedures) that we found during our on-site investigation at a compromised facility in South Korea led us to look again at this artefact.  When we did so, we discovered that the set of features didn’t match the code – it had been forged to perfectly match the fingerprint used by Lazarus.  So we concluded that the ‘fingerprint’ was a very sophisticated false flag, intentionally placed inside the malware in order to give threat hunters the impression that they had found a ‘smoking gun’ and diverting them from a more accurate attribution.

The problems associated with attribution must be taken seriously.  Given how politicised cyberspace has recently become, incorrect attribution could lead to severe consequences; and it’s possible that threat actors might try to manipulate the opinion of the security community in order to influence the geo-political agenda.

Sofacy turns eastwards

Sofacy (aka APT28, Fancy Bear and Tsar Team) is a highly active and prolific cyber-espionage group that Kaspersky Lab has been tracking for many years.  In February, we published an overview of Sofacy activities in 2017, revealing a gradual moved away from NATO-related targets at the start of 2017, towards targets in the Middle East, Central Asia and beyond.  Sofacy uses spear-phishing and watering-hole attacks to steal information, including account credentials, sensitive communications and documents.  This threat actor also makes use of zero-day vulnerabilities to deploy its malware

Sofacy uses different tools for different target profiles.  Early in 2017, the group’s ‘Dealer’s Choice’ campaign was used to target military and diplomatic organizations (mainly in NATO countries and Ukraine).

Later in the year, the group used other tools from its arsenal, ‘Zebrocy’ and ‘SPLM’, to target a broader range of organizations, including science and engineering centers and press services, with more of a focus on Central Asia and the Far East.

Sophisticated threat actors such as Sofacy continually develop the tools they use.  The group maintains a high level of operational security and focuses on making its malware hard to detect.  In the case of groups such as Sofacy, once any signs of their activity have been found in a network, it’s important to review logins and unusual administrator access on systems, thoroughly scan and sandbox incoming attachments, and maintain two-factor authentication for services such as e-mail and VPN access. The use of APT intelligence reports, threat hunting tools such as YARA and advanced detection solutions such as KATA (Kaspersky Anti Targeted Attack Platform) will help you to understand their targeting and provide powerful ways of detecting their activities.

Our research shows that Sofacy is not the only threat actor operating in the Far East and this sometimes results in a target overlap between very different threat actors.  We have seen cases where Sofacy’s Zebrocy malware has competed for access to victim’s computers with the Russian-speaking Mosquito Turla clusters; and where its SPLM backdoor has competed with the traditional Turla and Chinese-speaking Danti attacks. The shared targets included government administration, technology, science and military-related organizations in or from Central Asia.

The most intriguing overlap is probably that between Sofacy and the English-speaking threat actor behind The Lamberts. The connection was discovered after researchers detected the presence of Sofacy on a server that threat intelligence had previously identified as compromised by Grey Lambert malware.  The server belongs to a Chinese conglomerate that designs and manufactures aerospace and air defense technologies.  However, in this case the original SPLM delivery vector remains unknown. This raises a number of hypothetical possibilities, including the fact that Sofacy could be using a new and as yet undetected exploit or a new strain of its backdoor, or that Sofacy somehow managed to harness Grey Lambert’s communication channels to download its malware. It could even be a false flag, planted during the previous Lambert infection.  We think that the most likely answer is that an unknown new PowerShell script or legitimate but vulnerable web app was exploited to load and execute the SPLM code.

Slingshot: a route[r] into the network

One of the presentations at this year’s Kaspersky Security Analyst Summit was a report on a sophisticated cyber-espionage platform that has targeted victims in the Middle East and Africa since 2012.

Slingshot uses an unusual (and, as far as we know, unique) attack vector.  Many of the victims were attacked by means of compromised MikroTik routers.  The exact method for compromising the routers is not clear, but the attackers have found a way to add a malicious DLL to the device.  This DLL is a downloader for other malicious files that are then stored on the router.  When a system administrator logs in to configure the router, the router’s management software downloads and runs a malicious module on the administrator’s computer.

Slingshot loads a number of modules onto the victim’s computer, including two huge and powerful ones:  Cahnadr, a kernel mode module, and GollumApp, a user mode module.  The two modules are connected and support each other in gathering information, persistence and data exfiltration.  GollumApp is the most sophisticated of the modules:  it contains nearly 1,500 user-code functions and provides most of the routines for persistence, file system control and C2 (Command-and-Control) communications.  Cahnadr (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 a blue screen – a remarkable achievement.  Cahnadr, written in pure C language, provides full access to the hard drive and operating memory, notwithstanding device security restrictions, and carries out integrity control of various system components to avoid debugging and security detection.

Slingshot incorporates a number of techniques to help it evade detection.  These include encrypting all strings in its modules, calling system services directly in order to bypass security-product hooks, using a number of anti-debugging techniques and selecting which process to inject depending on the installed and running security solution processes.

Further information on targeted attack activity in the first quarter of 2018 can be found in the APT trends report for Q1 2018.

Malware stories A Spectre is haunting Europe – and anywhere else with vulnerable CPUs

Two severe vulnerabilities affecting Intel CPUs were reported early in 2018. Dubbed ‘Meltdown’ and ‘Spectre’, they respectively allow an attacker to read memory from any process and from its own process.  The vulnerabilities have been around since at least 2011.

Rumours of a new attack on Intel CPUs emerged at the start of December 2017 when e-mails on the LKML (Linux kernel mailing list) appeared about adding the KAISER patches to the Linux kernel.  These patches, designed to separate the user address space from the kernel address space, were originally intended to ‘close all hardware side channels on kernel address information’. It was the impact of this seemingly drastic measure, with its clear performance impact, that had prompted the rumours.

This attack, now known as Meltdown (CVE-2017-5754), is able to read data from any process on the host system.  While code execution is required, this can be obtained in various ways – for example, through a software bug or by visiting a malicious website that loads JavaScript code that executes the Meltdown attack.  This means that all the data residing in memory (passwords, encryption keys, PINs, etc.) could be read if the vulnerability is exploited properly.  Meltdown affects most Intel CPUs and some ARM CPUs.

Vendors were quick to publish patches for the most popular operating systems.  The Microsoft update, released on 3 January, was not compatible with all anti-virus programs – possibly resulting in a BSoD (Blue Screen of Death) on incompatible systems.  So updates could only be installed if an anti-virus product had first set a specific registry key, to indicate that there were no compatibility problems.

Spectre (CVE-2017-5753 and CVE-2017-5715) is slightly different.  Unlike Meltdown, this attack also works on other architectures (such as AMD and ARM).  Also, Spectre is only able to read the memory space of the exploited process, and not that of any process.  More importantly, aside from some counter-measures in some browsers, no universal solution is readily available for Spectre.

It became clear in the weeks following the reports of the vulnerabilities that they are not easily fixable.  Spectre in particular opened new ways of exploitation that might affect different software in the months and years to come.  Most of the released patches have reduced the attack surface, mitigating against known ways of exploiting them, but do not eradicate it completely.  Since the problem is fundamental to the working of the vulnerable CPUs, it’s likely that vendors will have to deal with new ways of exploiting the vulnerabilities for years to come.

O smart new world…

These days we’re surrounded by smart devices.  This includes everyday household objects such as TVs, smart meters, thermostats, baby monitors and children’s toys.   But it also includes cars, medical devices, CCTV cameras and parking meters.  We’re even seeing the emergence of smart cities.  However, this offers a greater attack surface to anyone looking to take advantage of security weaknesses – for whatever purpose.  Securing traditional computers is difficult.  But things are more problematic with the Internet of Things, where lack of standardization leaves developers able to ignore security, or to consider it as an afterthought.  There are plenty of examples to illustrate this.

We’ve looked before at vulnerabilities in smart devices around the home.  But some of our researchers recently explored the possibility that a smart hub might be vulnerable to attack.  A smart hub lets you control the operation of other smart devices in the home, receiving information and issuing commands.  Smart hubs might be controlled through a touch screen, or through a mobile app or web interface.  If it’s vulnerable, it would potentially provide a single point of failure.  While the smart hub our researchers investigated didn’t contain significant vulnerabilities, there were logical mistakes that were enough to allow our researchers to obtain remote access.

Researchers at Kaspersky Lab ICS CERT recently checked a popular smart camera, to see how well protected it is from hackers.  Smart cameras are now part of everyday life.  Many now connect to the cloud, allowing someone to monitor what’s happening at a remote location –to check on pets, for security surveillance, etc.  The model our researchers investigated is marketed as an all-purpose tool – suitable for use as a baby monitor, or as part of a security system.  The camera is able to see in the dark, follow a moving object, stream footage to a smartphone or tablet and play back sound through a built-in speaker.  Unfortunately, the camera turned out to have 13 vulnerabilities – almost as many as it has features – that could allow an attacker to change the administrator password, execute arbitrary code on the device, build a botnet of compromised cameras or stop it functioning completely.

Before buying any connected device, it’s important to keep security in mind.

  • Consider if you really need the device. If you do, check the functions available and disable any that you don’t need, to reduce your attack surface.
  • Look online for information about any vulnerabilities that have been reported.
  • Check to see if it’s possible to update the firmware on the device.
  • Always change the default password and replace it with a unique, complex password.
  • Don’t share serial numbers, IP addresses and other sensitive data relating to the device online.

You can use the free Kaspersky IoT Scanner to check your Wi-Fi network and tell you if the devices connected to it are safe.

Potential problems are not limited to consumer devices.  Recently, Ido Naor, a researcher from our Global Research and Analysis Team and Amihai Neiderman, then at Azimuth Security, discovered a vulnerability in an automation device for a gas station.  This device was directly connected to the Internet and was responsible for managing every component of the station, including fuel dispensers and payment terminals.  Even more alarming, the web interface for the device was accessible with default credentials.  Further investigation revealed that it was possible to shut down all fueling systems, cause fuel a leakage, change the price, circumvent the payment terminal (in order to steal money), capture vehicle license plates and driver identities, execute code on the controller unit and even move freely across the gas station network.

It’s no less important for vendors to improve their security approach to ensure that security is considered when products are being designed.  Kaspersky Lab, as a member of the ITU-T Study Group 20, was a contributor to the development of Recommendation ITU-T T.4806, designed to classify security issues, examine potential threats and determine how cyber-security measures can support the safe execution of IoT systems tasks.  This applies mostly to safety-critical IoT systems such as industrial automation, automotive systems, transportation, smart cities, and wearable and standalone medical devices.

IoT-medicine under siege

Technology is driving improvements in healthcare.  It has the power to transform the quality and reduce the cost of health and care services. It can also give patients and citizens more control over their care, empower carers and support the development of new medicines and treatments.  However, new healthcare technologies and mobile working practices are producing more data than ever before, at the same time providing more opportunities for data to be lost or stolen.  We’ve highlighted the issues several times over the last few years – for example, in the articles ‘Hospitals are under attack in 2016‘, ‘The mistakes of smart medicine‘ and ‘Connected medicine and its diagnosis‘.

The number of medical data breaches continues to increase:

Over the last year we’ve continued to track the activities of cybercriminals, looking at how they penetrate medical networks, how they find data on publicly available medical resources and how they exfiltrate it.  This includes open ports:

And the services that sit behind them:

More than 60 per cent of medical organizations had some kind of malware on their computers:

We saw even more attacks on organizations closely connected to hospitals, clinics and doctors – that is, in the pharmaceutical industry:

It’s vital that medical facilities remove all nodes that process personal medical data, update software and remove applications that are no longer needed, and do not connect expensive medical equipment to the main LAN.  You can find more detailed tips here.

Crypto-currency mining is the new black

In the legitimate economy, capital tends to flow into areas where it will be most profitable.  It’s no different with cybercrime.  Malware development is focused in areas that are likely to be more lucrative.  So it’s no surprise that, as crypto-currencies become a mainstream..

Read Full Article
Visit website
  • Show original
  • .
  • Share
  • .
  • Favorite
  • .
  • Email
  • .
  • Add Tags 

This paper discusses our project that involved searching for vulnerabilities in implementations of the OPC UA protocol. In publishing this material, we hope to draw the attention of vendors that develop software for industrial automation systems and the industrial internet of things to problems associated with using such widely available technologies, which turned out to be quite common. We hope that this article will help software vendors achieve a higher level of protection from modern cyberattacks. We also discuss some of our techniques and findings that may help software vendors control the quality of their products and could prove useful for other software security researchers.

Why we chose the OPC UA protocol for our research

The IEC 62541 OPC UA (Object Linking and Embedding for Process Control Unified Automation) standard was developed in 2006 by the OPC Foundation consortium for reliable and, which is important, secure transfer of data between various systems on an industrial network. The standard is an improved version of its predecessor – the OPC protocol, which is ubiquitous in modern industrial environments.

It is common for monitoring and control systems based on different vendors’ products to use mutually incompatible, often proprietary network communication protocols. OPC gateways/servers serve as interfaces between different industrial control systems and telemetry, monitoring and telecontrol systems, unifying control processes at industrial enterprises.

The previous version of the protocol was based on the Microsoft DCOM technology and had some significant limitations inherent to that technology. To get away from the limitations of the DCOM technology and address some other issues identified while using OPC, the OPC Foundation developed and released a new version of the protocol.

Thanks to its new properties and well-designed architecture, the OPC UA protocol is rapidly gaining popularity among automation system vendors. OPC UA gateways are installed by a growing number of industrial enterprises across the globe. The protocol is increasingly used to set up communication between components of industrial internet of things and smart city systems.

The security of technologies that are used by many automation system developers and have the potential to become ubiquitous among industrial facilities across the globe is one the highest-priority areas of research for Kaspersky Lab ICS CERT. This was our main reason to do an analysis of OPC UA.

Another reason was that Kaspersky Lab is a member of the OPC Foundation consortium and we feel responsible for the security of technologies developed by the consortium. Getting ahead of the story, we can say that, following the results of our research, we received an invitation to join the OPC Foundation Security Working Group and gratefully accepted it.

OPC UA protocol

Originally, OPC UA was designed to support data transport for two data types: the traditional binary format (used in previous versions of the standard) and SOAP/XML. Today, data transfer in the SOAP/XML format is considered obsolete in the IT world and is almost never used in modern products and services. The prospects of it being widely used in industrial automation systems are obscure, so we decided to focus our research on the binary format.

If packets exchanged by services running on the host are intercepted, their structure can easily be understood. There are four types of messages transmitted over the OPC UA protocol:

  • OPEN

The first message is always HELLO (HEL). It serves as a marker for the start of data transfer between the client and the server. The server responds by sending the ACKNOWLEDGE (ACK) message to the client. After the initial exchange of messages, the client usually sends the message OPEN, which means that the data transmission channel using the encryption method proposed by the client is now open. The server responds by sending the message OPEN (OPN), which includes the unique ID of the data channel and shows that the server agrees to the proposed encryption method (or no encryption).

Now the client and the server can start exchanging messages –MESSAGE (MSG). Each message includes the data channel ID, the request or response type, a timestamp, data arrays being sent, etc. At the end of the session, the message CLOSE (CLO) is sent, after which the connection is terminated.

OPC UA is a standard that has numerous implementations. In our research, we only looked at the specific implementation of the protocol developed by the OPC Foundation.

The initial stage

We first became interested in analyzing the OPC UA protocol when the Kaspersky Lab ICS CERT team was conducting security audits and penetration tests at several industrial enterprises. All of these enterprises used the same industrial control system (ICS) software. With the approval of the customers, we analyzed the software for vulnerabilities as part of the testing.

It turned out that part of the network services in the system we analyzed communicated over the OPC UA protocol and most executable files used a library named “uastack.dll”.

The first thing we decided to do as part of analyzing the security of the protocol’s implementation was to develop a basic “dumb” mutation-based fuzzer.

“Dumb” fuzzing, in spite of being called “dumb”, can be very useful and can in some cases significantly improve the chances of finding vulnerabilities. Developing a “smart” fuzzer for a specific program based on its logic and algorithms is time-consuming. At the same time, a “dumb” fuzzer helps quickly identify trivial vulnerabilities that can be hard to get at in the process of manual analysis, particularly when the amount of code to be analyzed is large, as was the case in our project.

The architecture of the OPC UA Stack makes in-memory fuzzing difficult. For the functions that we want to check for vulnerabilities to work correctly, the fuzzing process must involve passing properly formed arguments to the function and initializing global variables, which are structures with a large number of fields. We decided not to fuzz-test functions directly in memory. The fuzzer that we wrote communicated with the application being analyzed over the network.

The fuzzer’s algorithm had the following structure:

  • read input data sequences
  • perform a pseudorandom transformation on them
  • send the resulting sequences to the program over the network as inputs
  • receive the server’s response
  • repeat

After developing a basic set of mutations (bitflip, byteflip, arithmetic mutations, inserting a magic number, resetting the data sequence, using a long data sequence), we managed to identify the first vulnerability in uastack.dll. It was a heap corruption vulnerability, successful exploitation of which could enable an attacker to perform remote code execution (RCE), in this case, with NT AUTHORITY/SYSTEM privileges. The vulnerability we identified was caused by the function that handled the data which had just been read from a socket incorrectly calculating the size of the data, which was subsequently copied to a buffer created on a heap.

Upon close inspection, it was determined that the vulnerable version of the uastack.dll library had been compiled by the product’s developers. Apparently, the vulnerability was introduced into the code in the process of modifying it. We were not able to find that vulnerability in the OPC Foundation’s version of the library.

The second vulnerability was found in a .NET application that used the UA .NET Stack. While analyzing the application’s traffic in wireshark, we noticed in the dissector that some packets had an is_xml bit field, the value of which was 0. In the process of analyzing the application, we found that it used the XmlDocument function, which was vulnerable to XXE attacks for .NET versions 4.5 and earlier. This means that if we changed the is_xml bit field’s value from 0 to 1 and added a specially crafted XML packet to the request body (XXE attack), we would be able to read any file on the remote machine (out-of-bound file read) with NT AUTHORITY/SYSTEM privileges and, under certain conditions, to perform remote code execution (RCE), as well.

Judging by the metadata, although the application was part of the software package on the ICS that we were analyzing, it was developed by the OPC Foundation consortium, not the vendor, and was an ordinary discovery server. This means that other products that use the OPC UA technology by the OPC Foundation may include that server, making them vulnerable to the XXE attack. This makes this vulnerability much more valuable from an attacker’s viewpoint.

This was the first step in our research. Based on the results of that step, we decided to continue analyzing the OPC UA implementation by the OPC Foundation consortium, as well as products that use it.

OPC UA analysis

To identify vulnerabilities in the implementation of the OPC UA protocol by the OPC Foundation consortium, research must cover:

  • The OPC UA Stack (ANSI C, .NET, JAVA);
  • OPC Foundation applications that use the OPC UA Stack (such as the OPC UA .NET Discovery Server mentioned above);
  • Applications by other software developers that use the OPC UA Stack.

As part of our research, we set ourselves the task to find optimal methods of searching for vulnerabilities in all three categories.

Fuzzing the UA ANSI C Stack

Here, it should be mentioned that there is a problem with searching for vulnerabilities in the OPC UA Stack. OPC Foundation developers provide libraries that are essentially a set of exported functions based on a specification, similar to an API. In such cases, it is often hard to determine whether a potential security problem that has been discovered is in fact a vulnerability. To give a conclusive answer to that question, one must understand how the potentially vulnerable function is used and for what purpose – i.e., a sample program that uses the library is necessary. In our case, it was hard to make conclusions on vulnerabilities in the OPC UA Stack without looking at applications in which it was implemented.

What helped us resolve this problem associated with searching for vulnerabilities was open-source code hosted in the OPC Foundation’s repository on GitHub, which includes a sample server that uses the UA ANSI C Stack. We don’t often get access to product source code in the course of analyzing ICS components. Most ICS applications are commercial products, developed mostly for Windows and released with a licensing agreement the terms of which do not include access to the source code. In our case, the availability of the source code helped find errors both in the server itself and in the library. The UA ANSI C Stack source code was helpful for doing manual analysis of the code and for fuzzing. It also helped us find out whether new functionality had been added to a specific implementation of the UA ANSI C Stack.

The UA ANSI C Stack (like virtually all other products by the OPC Foundation consortium) is positioned as a solution that is not only secure, but is also cross-platform. This helped us our during fuzzing, because we were able to build a UA ANSI С Stack together with the sample server code published by the developers in their GitHub account, on a Linux system with binary source code instrumentation and to fuzz-test that code using AFL.

To accelerate fuzzing, we overloaded the networking functions –socket/sendto/recvfrom/accept/bind/select/… – to read input data from a local file instead of connecting to the network. We also compiled our program with AddressSanitizer.

To put together an initial set of examples, we used the same technique as for our first “dumb” fuzzer, i.e., capturing traffic from an arbitrary client to the application using tcpdump. We also added some improvements to our fuzzer – a dictionary created specifically for OPC UA and special mutations.

It follows from the specification of the binary data transmission format in OPC UA that it is sufficiently difficult for AFL to mutate from, say, the binary representation of an empty string in OPC UA (“\xff\xff\xff\xff”) to a string that contains 4 random bytes (for example, “\x04\x00\x00\x00AAAA”). Because of this, we implemented our own mutation mechanism, which worked with OPC UA internal structures, changing them based on their types.

After building our fuzzer with all the improvements included, we got the first crash of the program within a few minutes.

An analysis of memory dumps created at the time of the crash enabled us to identify a vulnerability in the UA ANSI C Stack which, if exploited, could result at least in a DoS condition.

Fuzzing OPC Foundation applications

Since, in the previous stage, we had performed fuzzing of the UA ANSI C Stack and a sample application by the OPC Foundation, we wanted to avoid retesting the OPC UA Stack in the process of analyzing the consortium’s existing products, focusing instead on fuzzing specific components written on top of the stack. This required knowledge of the OPC UA architecture and the differences between applications that use the OPC UA Stack.

The two main functions in any application that uses the OPC UA Stack are OpcUa_Endpoint_Create and OpcUa_Endpoint_Open. The former provides the application with information on available channels of data communication between the server and the client and a list of available services. The OpcUa_Endpoint_Open function defines from which network the service will be available and which encryption modes it will provide.

A list of available services is defined using a service table, which lists data structures and provides information about each individual service. Each of these structures includes data on the request type supported, the response type, as well as two callback functions that will be called during request preprocessing and post-processing (preprocessing functions are, in most cases, “stubs”). We included converter code into the request preprocessing function. It uses mutated data as an input, outputting a correctly formed structure that matches the request type. This enabled us to skip the application startup stage, starting an event loop to create a separate thread to read from our pseudo socket, etc. This enabled us to accelerate our fuzzing from 50 exec/s to 2000 exec/s.

As a result of using our “dumb” fuzzer improved in this way, we identified 8 more vulnerabilities in OPC Foundation applications.

Analyzing third-party applications that use the OPC UA Stack

Having completed the OPC Foundation product analysis stage, we moved on to analyzing commercial products that use the OPC UA Stack. From the ICS systems we worked with during penetration testing and analyzing the security status of facilities for some of our customers, we selected several products by different vendors, including solutions by global leaders of the industry. After getting our customers’ approval, we began to analyze implementations of the OPC UA protocol in these products.

When searching for binary vulnerabilities, fuzzing is one of the most effective techniques. In previous cases, when analyzing products on a Linux system, we used source code binary instrumentation techniques and the AFL fuzzer. However, the commercial products using the OPC UA Stack that we analyzed are designed to run on Windows, for which there is an equivalent of the AFL fuzzer called WinAFL. Essentially, WinAFL is the AFL fuzzer ported to Windows. However, due to differences between the operating systems, the two fuzzers are different in some significant ways. Instead of system calls from the Linux kernel, WinAFL uses WinAPI functions and instead of static source code instrumentation, it uses the DynamoRIO dynamic instrumentation of binary files. Overall, these differences mean that the performance of WinAFL is significantly lower than that of AFL.

To work with WinAFL in the standard way, one has to write a program that will read data from a specially created file and call a function from an executable file or library. Then WinAFL will put the process into a loop using binary instrumentation and will call the function many times, getting feedback from the running program and relaunching the function with mutated data as arguments. That way, the program will not have to be relaunched every time with new input data, which is good, because creating a new process in Windows consumes significant processor time.

Unfortunately, this method of fuzzing couldn’t be used in our situation. Owing to the asynchronous architecture of the OPC UA Stack, the processing of data received and sent over the network is implemented as call-back functions. Consequently, it is impossible to identify a data-processing function for each type of request that would accept a pointer to the buffer containing the data and the size of the data as arguments, as required by the WinAFL fuzzer.

In the source code of the WinAFL fuzzer, we found comments on fuzzing networking applications left by the developer. We followed the developer’s recommendations on implementing network fuzzing with some modifications. Specifically, we included the functionality of communication with the local networking application in the code of the fuzzer. As a result of this, instead of executing a program, the fuzzer sends payload over the network to an application that is already running under DynamoRIO.

However, with all our efforts, we were only able to achieve the fuzzing rate of 5 exec/s. This is so slow that it would take too long to find a vulnerability even with a smart fuzzer like AFL.

Consequently, we decided to go back to our “dumb” fuzzer and improve it.

  1. We improved the mutation mechanism, modifying the data generation algorithm based on our knowledge of the types of data transferred to the OPC UA Stack.
  2. We created a set of examples for each service supported (the python-opcua library, which includes functions for interacting with virtually all possible OPC UA services, proved very helpful in this respect).
  3. When using a fuzzer with dynamic binary instrumentation to test multithreaded applications such as ours, searching for new branches in the application’s code is a sufficiently complicated task, because it is difficult to determine which input data resulted in a certain behavior of the application. Since our fuzzer communicated to the application over the network and we could establish a clear connection between the server’s response and the data sent to it (because communication took place within the limits of one session), there was no need for us to address this issue. We implemented an algorithm which determined that a new execution path has been identified simply when a new response that had not been observed before was received from the server.

As a result of the improvements described above, our “dumb” fuzzer was no longer all that “dumb”, and the number of executions per second grew from 1 or 2 to 70, which is a good figure for network fuzzing. With its help, we identified two more new vulnerabilities that we had been unable to identify using “smart” fuzzing.


As of the end of March 2018, the results of our research included 17 zero-day vulnerabilities in the OPC Foundation’s products that had been identified and closed, as well as several vulnerabilities in the commercial applications that use these products.

We immediately reported all the vulnerabilities identified to developers of the vulnerable software products.

Throughout our research, experts from the OPC Foundation and representatives of the development teams that had developed the commercial products promptly responded to the vulnerability information we sent to them and closed the vulnerabilities without delays.

In most cases, flaws in third-party software that uses the OPC UA Stack were caused by the developers not using functions from the API implemented in the OPC Foundation’s uastack.dll library properly – for example, field values in the data structures transferred were interpreted incorrectly.

We also determined that, in some cases, product vulnerabilities were caused by modifications made to the uastack.dll library by developers of commercial software. One example is an insecure implementation of functions designed to read data from a socket, which was found in a commercial product. Notably, the original implementation of the function by the OPC Foundation did not include this error. We do not know why the commercial software developer had to modify the data reading logic. However, it is obvious that the developer did not realize that the additional checks included in the OPC Foundation’s implementation are important because the security function is built on them.

In the process of analyzing commercial software, we also found out that developers had borrowed code from OPC UA Stack implementation examples, copying that code to their applications verbatim. Apparently, they assumed that the ОРС Foundation has made sure that these code fragments were secure in the same way that it had ensured the security of code used in the library. Unfortunately, that assumption turned out to be wrong.

Exploitation of some of the vulnerabilities that we identified results in DoS conditions and the ability to execute code remotely. It is important to remember that, in industrial systems, denial-of-service vulnerabilities pose a more serious threat than in any other software. Denial-of-service conditions in telemetry and telecontrol systems can cause enterprises to suffer financial losses and, in some cases, even lead to the disruption and shutdown of the industrial process. In theory, this could cause harm to expensive equipment and other physical damage.


The fact that the OPC Foundation is opening the source code of its projects certainly indicates that it is open and committed to making its products more secure.

At the same time, our analysis has demonstrated that the current implementation of the OPC UA Stack is not only vulnerable but also has a range of significant fundamental problems.

First, flaws introduced by developers of commercial software that uses the OPC UA Stack indicate that the OPC UA Stack was not designed for clarity. Unfortunately, an analysis of the source code confirms this. The current implementation of the protocol has plenty of pointer calculations, insecure data structures, magic constants, parameter validation code copied between functions and other archaic features scattered throughout the code. These are features that developers of..

Read Full Article
Visit website
  • Show original
  • .
  • Share
  • .
  • Favorite
  • .
  • Email
  • .
  • Add Tags 

In late April 2018, a new zero-day vulnerability for Internet Explorer (IE) was found using our sandbox; more than two years since the last in the wild example (CVE-2016-0189). This particular vulnerability and subsequent exploit are interesting for many reasons. The following article will examine the core reasons behind the latest vulnerability, CVE-2018-8174.

Searching for the zero day

Our story begins on VirusTotal (VT), where someone uploaded an interesting exploit on April 18, 2018. This exploit was detected by several AV vendors including Kaspersky, specifically by our generic heuristic logic for some older Microsoft Word exploits.

Virustotal scan results for CVE-2018-8174

After the malicious sample was processed in our sandbox system, we noticed that a fully patched version of Microsoft Word was successfully exploited. From this point we began a deeper analysis of the exploit. Let’s take a look at the full infection chain:

Infection chain

The infection chain consists of the following steps:

  • A victim receives a malicious Microsoft Word document.
  • After opening the malicious document, a second stage of the exploit is downloaded; an HTML page containing VBScript code.
  • The VBScript code triggers a Use After Free (UAF) vulnerability and executes shellcode.
Initial analysis

We’ll start our analysis with the initial Rich Text Format (RTF) document, that was used to deliver the actual exploit for IE. It only contains one object, and its contents are obfuscated using a known obfuscation technique we call “nibble drop“.

Obfuscated object data in RTF document

After deobfuscation and hex-decoding of the object data, we can see that this is an OLE object that contains a URL Moniker CLSID. Because of this, the exploit initially resembles an older vulnerability leveraging the Microsoft HTA handler (CVE-2017-0199).

URL Moniker is used to load an IE exploit

With the CVE-2017-0199 vulnerability, Word tries to execute the file with the default file handler based on its attributes; the Content-Type HTTP header in the server’s response being one of them. Because the default handler for the “application/hta” Content-Type is mshta.exe,it is chosen as the OLE server to run the script unrestricted. This allows an attacker to directly call ShellExecute and launch a payload of their choice.

However, if we follow the embedded URL in the latest exploit, we can see that the content type in the server’s response is not “application/hta”, which was a requirement for CVE-2017-0199 exploitation, but rather “text/html”. The default OLE server for “text/html” is mshtml.dll, which is a library that contains the engine, behind Internet Explorer.

WINWORD.exe querying registry for correct OLE server

Furthermore, the page contains VBScript, which is loaded with a safemode flag set to its default value, ‘0xE’. Because this disallows an attacker from directly executing a payload, as was the case with the HTA handler, an Internet Explorer exploit is needed to overcome that.

Using a URL moniker like that to load a remote web page is possible, because Microsoft’s patch for Moniker-related vulnerabilities (CVE-2017-0199, CVE-2017-8570 and CVE-2017-8759) introduced an activation filter, which allows applications to specify which COM objects are restricted from instantiating at runtime.

Some of the filtered COM objects, restricted from creating by IActivationFilter in MSO.dll

At the time of this analysis, the list of filtered CLSIDs consisted of 16 entries. TheMSHTML CLSID ({{25336920-03F9-11CF-8FD0-00AA00686F13}}) is not in the list, which is why the MSHTML COM server is successfully created in Word context.

This is where it becomes interesting. Despite a Word document being the initial attack vector, thevulnerability is actually in VBScript, not in Microsoft Word. This is the first time we’ve seen a URL Moniker used to load an IE exploit, and we believe this technique will be used heavily by malware authors in the future. This technique allows one to load and render a web page using the IE engine, even if default browser on a victim’s machine is set to something different.

The VBScript in the downloaded HTML page contains both function names and integer values that are obfuscated.

Obfuscated IE exploit

Vulnerability root cause analysis

For the root cause analysis we only need to look at the first function (‘TriggerVuln’) in the deobfuscated version which is called right after ‘RandomizeValues’ and ‘CookieCheck’.

Vulnerability Trigger procedure after deobfuscation

To achieve the desired heap layout and to guarantee that the freed class object memory will be reused with the ‘ClassToReuse’ object, the exploit allocates some class objects. To trigger the vulnerability this code could be minimized to the following proof-of-concept (PoC):

CVE-2018-8174 Proof Of Concept

When we then launch this PoC in Internet Explorer with page heap enabled we can observe a crash at the OLEAUT32!VariantClear function.

Access Violation on a call to freed memory

Freed memory pointer is reused when the second array (ArrB) is destroyed

With this PoC we were able to trigger a Use-after-free vulnerability; both ArrA(1) and ArrB(1) were referencing the same ‘ClassVuln’ object in memory. This is possible because when “Erase ArrA” is called, the vbscript!VbsErase function determines that the type of the object to delete is a SafeArray, and then calls OLEAUT32!SafeArrayDestroy.

It checks that the pointer to a tagSafeArray structure is not NULL and that its reference count, stored in the cLocks field is zero, and then continues to call ReleaseResources.

VARTYPE of ArrA(1) is VT_DISPATCH, so VBScriptClass::Release is called to destruct the object

ReleaseResources, in turn will check the fFeatures flags variable, and since we have an array of VARIANTs, it will subsequently call VariantClear; a function that iterates each member of an array and performs the necessary deinitialization and calls the relevant class destructor if necessary. In this case, VBScriptClass::Release is called to destroy the object correctly and handle destructors like Class_Terminate, since the VARTYPE of ArrA(1) is VT_DISPATCH.

Root cause of CVE-2018-8174 – ‘refCount’ being checked only once, before TerminateClass function

This ends up being the root cause of the vulnerability. Inside the VBScriptClass::Release function, the reference count is checked only once, at the beginning of the function. Even though it can be (and actually is, in the PoC) incremented in an overloaded TerminateClass function, no checks will be made before finally freeing the class object.

Class_Terminate is a deprecated method, now replaced by the ‘Finalize’ procedure. It is used to free acquired resources during object destruction and is executed as soon as object is set to nothing and there are no more references to that object. In our case, the Class_Terminate method is overloaded, and when a call to VBScriptClass::TerminateClass is made, it is dispatched to the overloaded method instead. Inside of that overloaded method, another reference is created to the ArrA(1) member. At this point ArrB(1) references ArrA(1), which holds a soon to be freed ClassVuln object.

Crash, due to calling an invalid virtual method when freeing second object

After the Class_Terminate sub is finished, the object at Arr(1) is freed, but ArrB(1) still maintains a reference to that freed class object. When the execution continues, and ArrB is erased, the whole cycle repeats, except that this time, ArrB(1) is referencing a freed ClassVuln object, and so we observe a crash when one of the virtual methods in the ClassVuln vtable is called.


In this write up we analyzed the core reasons behind CVE-2018-8174, a particularly interesting Use-After-Free vulnerability that was possible due to incorrect object lifetime handling in the Class_Terminate VBScript method. The exploitation process is different from what we’ve seen in exploits for older vulnerabilities (CVE-2016-0189 and CVE-2014-6332) as the Godmode technique is no longer used. The full exploitation chain is as interesting as the vulnerability itself, but is out of scope of this article.

With CVE-2018-8174 being the first public exploit to use a URL moniker to load an IE exploit in Word, we believe that this technique, unless fixed, will be heavily abused by attackers in the future, as It allows you force IE to load ignoring the default browser settings on a victim’s system.

We expect this vulnerability to become one of the most exploited in the near future, as it won’t be long until exploit kit authors start abusing it in both drive-by (via browser) and spear-phishing (via document) campaigns. To stay protected, we recommend applying latest security updates, and using a security solution with behavior detection capabilities.

In our opinion this is the same exploit which Qihoo360 Core Security Team called “Double Kill” in their recent publication. While this exploit is not limited to browser exploitation, it was reported as an IE zero day, which caused certain confusion in the security community.

After finding this exploit we immediately shared the relevant information with Microsoft and they confirmed that it is in fact CVE-2018-8174.

This exploit was found in the wild and was used by an APT actor. More information about that APT actor and usage of the exploit is available to customers of Kaspersky Intelligence Reporting Service. Contact: intelreports@kaspersky.com


Kaspersky Lab products successfully detect and block all stages of the exploitation chain and payload with the following verdicts:

  • HEUR:Exploit.MSOffice.Generic – RTF document
  • PDM:Exploit.Win32.Generic – IE exploit – detection with Automatic Exploit Prevention technology
  • HEUR:Exploit.Script.Generic – IE exploit
  • HEUR:Trojan.Win32.Generic – Payload
  • b48ddad351dd16e4b24f3909c53c8901 – RTF document
  • 15eafc24416cbf4cfe323e9c271e71e7 – Internet Explorer exploit (CVE-2018-8174)
  • 1ce4a38b6ea440a6734f7c049f5c47e2 – Payload
  • autosoundcheckers[.]com
Read Full Article
Visit website
  • Show original
  • .
  • Share
  • .
  • Favorite
  • .
  • Email
  • .
  • Add Tags 

The Process Doppelgänging technique was first presented in December 2017 at the BlackHat conference. Since the presentation several threat actors have started using this sophisticated technique in an attempt to bypass modern security solutions.

In April 2018, we spotted the first ransomware employing this bypass technique – SynAck ransomware. It should be noted that SynAck is not new – it has been known since at least September 2017 – but a recently discovered sample caught our attention after it was found to be using Process Doppelgänging. Here we present the results of our investigation of this new SynAck variant.

Anti-analysis and anti-detection techniques Process Doppelgänging

SynAck ransomware uses this technique in an attempt to bypass modern security solutions. The main purpose of the technique is to use NTFS transactions to launch a malicious process from the transacted file so that the malicious process looks like a legitimate one.

Part of the procedure that implements Process Doppelgänging

Binary obfuscation

To complicate the malware analysts’ task, malware developers often use custom PE packers to protect the original code of the Trojan executable. Most packers of this type, however, are effortlessly unpacked to reveal the original unchanged Trojan PE file that’s suitable for analysis.

This, however, is not the case with SynAck. The Trojan executable is not packed; instead, it is thoroughly obfuscated prior to compilation. As a result, the task of reverse engineering is considerably more complicated with SynAck than it is with other recent ransomware strains.

The control flow of the Trojan executable is convoluted. Most of the CALLs are indirect, and the destination address is calculated by arithmetic operation from two DWORD constants.

All of the WinAPI function addresses are imported dynamically by parsing the exports of system DLLs and calculating a CRC32-based hash of the function name. This in itself is neither new nor particularly difficult to analyze. However, the developers of SynAck further complicated this approach by obscuring both the address of the procedure that retrieves the API function address, and the target hash value.

Let’s illustrate in detail how SynAck calls WinAPI functions. Consider the following piece of disassembly:

This code takes the DWORD located at 403b13, subtracts the constant 78f5ec4d, with the result 403ad0, and calls the procedure at this address.

This procedure pushes two constants (N1 = ffffffff877bbca1 and N2 = 2f399204) onto the stack and passes the execution to the procedure at 403680 which will calculate the result of N1 xor N2 = a8422ea5.

This value is the hash of the API function name that SynAck wants to call. The procedure 403680 will then find the address of this function by parsing the export tables of system DLLs, calculating the hash of each function name and comparing it to the value a8422ea5. When this API function address is found, SynAck will pass the execution to this address.

Notice that instead of a simple CALL in the image above it uses the instructions PUSH + RET which is another attempt to complicate analysis. The developers of SynAck use different instruction combinations instead of CALL when calling WinAPI functions:

push reg
jmp reg
mov [rsp-var], reg
jmp qword ptr [rsp-var]

To counter these attempts by the malware developers, we created an IDAPython script that automatically parses the code, extracts the addresses of all intermediate procedures, extracts the constants and calculates the hashes of the WinAPI functions that the malware wants to import.

We then calculated the hash values of the functions exported from Windows system DLLs and matched them against the values required by SynAck. The result was a list showing which hash value corresponds to which API function.

Part of the list of API functions imported by SynAck and their hashes

Our script then uses this list to save comments in the IDA database to indicate which API is going to be called by the Trojan. Here is the code from the example above after deobfuscation.

Disassembly screen – note the comment with the target API function name

Hex-Rays decompilation screen – again, the API function names are recognized

Language check

At an early stage of execution the Trojan performs a check to find out whether it has been launched on a PC from a certain list of countries. To do this, it lists all the keyboard layouts installed on the victim’s PC and checks against a list hardcoded into the malware body. If it finds a match, SynAck sleeps for 300 seconds and then just calls ExitProcess to prevent encryption of files belonging to a victim from these countries.

Part of the procedure that stops the Trojan if the language check is not passed

Part of the procedure that checks the keyboard layouts on the infected PC

Directory name validation

Shortly after the language check, which can be considered fairly common among modern ransomware, SynAck performs a check on the directory where its executable is started from. If there’s an attempt to launch it from an ‘incorrect’ directory, the Trojan won’t proceed and will just exit instead. This measure has been added by the malware developers to counter automatic sandbox analysis.

As with API imports, the Trojan doesn’t store the strings it wants to check; instead it stores their hashes – a tactic that hinders efforts to find the original strings.

SynAck contains nine hashes; we have been able to brute-force two of them:

0x05f9053d == hash("output")
0x2cd2f8e2 == hash("plugins")

In the process we found a lot of collisions (gibberish strings that give the same hash value as the meaningful ones).

Cryptographic scheme

Like other ransomware, SynAck uses a combination of symmetric and asymmetric encryption algorithms. At the core of the SynAck algorithm lies the hybrid ECIES scheme. It is composed of ‘building blocks’ which interact with each other: ENC (symmetric encryption algorithm), KDF (key derivation function), and MAC (message authentication code). The ECIES scheme can be implemented using different building blocks. To calculate a key for the symmetric algorithm ENC, this scheme employs the ECDH protocol (Diffie-Hellman over a chosen elliptic curve).

The developers of this Trojan chose the following implementation:


KDF: PBKDF2-SHA1 with one iteration


ECDH curve: standard NIST elliptic curve secp192r1


This is the function that implements the ECIES scheme in the SynAck sample.

Input: plaintext, input_public_key

Output: ciphertext, ecies_public_key, MAC

  1. The Trojan generates a pair of asymmetric keys: ecies_private_key and ecies_public_key;
  2. Using the generated ecies_private_key and input_public_key the Trojan calculates the shared secret according to the Diffie-Hellman protocol on an elliptic curve:
ecies_shared_secret = ECDH(ecies_private_key, input_public_key)
  1. Using the PBKDF2-SHA1 function with one iteration, the Trojan derives two byte arrays, key_enc and key_mac, from ecies_shared_secret. The size of key_enc is equal to the size of the plaintext;
  2. The plaintext is XORed byte to byte with the key_enc;
  3. The Trojan calculates the MAC (message authentication code) of the obtained ciphertext using the algorithm HMAC-SHA1 with key_mac as the key.

At the first step the Trojan generates a pair of private and public keys: the private key (session_private_key) is a 192-bit random number and the public key (session_public_key) is a point on the standard NIST elliptic curve secp192r1.

Then the Trojan gathers some unique information such as computer and user names, OS version info, unique infection ID, session private key and some random data and encrypts it using a randomly generated 256-bit AES key. The encrypted data is saved as the encrypted_unique_data buffer.

To encrypt the AES key, the Trojan uses the ECIES-XOR-HMAC-SHA1 function (see description above; hereafter referred to as the ECIES function). SynAck passes the AES key as the plaintext parameter and the hardcoded cybercriminal’s master_public_key as input_public_key. The field encrypted_aes_key contains the ciphertext returned by the function, public_key_n is the ECIES public key and message_authentication_code is the MAC.

At the next step the Trojan forms the structure cipher_info.

struct cipher_info
uint8_t encrypted_unique_data[240];
uint8_t public_key_n[49];
uint8_t encrypted_aes_key[44];
uint8_t message_authentication_code[20];

It is shown in the image below.

Encrypted initialization information

This data is then encoded in base64 and written into the ransom note.

Ransom note

As we can see, the criminals ask the victim to include this encoded text in their message.

File encryption

The content of each file is encrypted by the AES-256-ECB algorithm with a randomly generated key. After encryption, the Trojan forms a structure containing information such as the encryption label 0xA4EF5C91, the used AES key, encrypted chunk size and the original file name. This information can be represented as a structure:

struct encryption_info
uint32_t label = 0xA4EF5C91;
uint8_t aes_key[32];
uint32_t encrypted_chunk_size;
uint32_t reserved;
uint8_t original_name_buffer[522];

The Trojan then calls the ECIES function and passes the encryption_info structure as the plaintext and the previously generated session_public_key as the input_public_key. The result returned by this function is saved into a structure which we dubbed file_service_structure. The field encrypted_file_info contains the ciphertext returned by the function, ecc_file_key_public is the ECIES public key and message_authentication_code is the MAC.

struct file_service_structure
uint8_t ecc_file_key_public[49];
encryption_info encrypted_file_info;
uint8_t message_authentication_code[20];

This structure is written to the end of the encrypted file. This results in an encrypted file having the following structure:

struct encrypted_file
uint8_t encrypted_data[file_size - file_size % AES_BLOCK_SIZE];
uint8_t original_trailer[file_size % AES_BLOCK_SIZE];
uint64_t encryption_label = 0x65CE3D204A93A12F;
uint32_t infection_id;
uint32_t service_structure_size;
file_service_structure service_info;

The encrypted file structure is shown in the image below.

Encrypted file structure

After encryption the files will have randomly generated extensions.

Directory after encryption

Other features Termination of processes and services

Prior to file encryption, SynAck enumerates all running processes and all services and checks the hashes of their names against two lists of hardcoded hash values (several hundred combined). If it finds a match, the Trojan will attempt to kill the process (using the TerminateProcess API function) or to stop the service (using ControlService with the parameter SERVICE_CONTROL_STOP).

To find out which processes it wants to terminate and which services to stop, we brute-forced the hashes from the Trojan body. Below are some of the results.

Processes Services
Hash Name Hash Name
0x9a130164 dns.exe 0x11216a38 vss
0xf79b0775 lua.exe 0xe3f1f130 mysql
0x6475ad3c mmc.exe 0xc82cea8d qbvss
0xe107acf0 php.exe 0xebcd4079 sesvc
0xf7f811c4 vds.exe 0xf3d0e358 vmvss
0xcf96a066 lync.exe 0x31c3fbb6 wmsvc
0x167f833f nssm.exe 0x716f1a42 w3svc
0x255c7041 ssms.exe 0xa6332453 memtas
0xbdcc75a9 w3wp.exe 0x82953a7a mepocs
0x410de6a4 excel.exe
0x9197b633 httpd.exe
0x83ddb55a ilsvc.exe
0xb27761ed javaw.exe
0xfd8b9308 melsc.exe
0xa105f60b memis.exe
0x10e94bcc memta.exe
0xb8de9e34 mepoc.exe
0xeaa98593 monad.exe
0x67181e9b mqsvc.exe
0xd6863409 msoia.exe
0x5fcab0fe named.exe
0x7d171368 qbw32.exe
0x7216db84 skype.exe
0xd2f6ce06 steam.exe
0x68906b65 store.exe
0x6d6daa28 vksts.exe
0x33cc148e vssvc.exe
0x26731ae9 conime.exe
0x76384ffe fdhost.exe
0x8cc08bd7 mepopc.exe
0x2e883bd5 metray.exe
0xd1b5c8df mysqld.exe
0xd2831c37 python.exe
0xf7dc2e4e srvany.exe
0x8a37ebfa tabtip.exe

As we can see, SynAck seeks to stop programs related to virtual machines, office applications, script interpreters, database applications, backup systems, gaming applications and so on. It might be doing this to grant itself access to valuable files that could have been otherwise used by the running processes.

Clearing the event logs

To impede possible forensic analysis of an infected machine, SynAck clears the event logs stored by the system. To do so, it uses two approaches. For Windows versions prior to Vista, it enumerates the registry key SYSTEM\CurrentControlSet\Services\EventLog and uses OpenEventLog/ClearEventLog API functions. For more modern Windows versions, it uses the functions from EvtOpenChannelEnum/EvtNextChannelPath/EvtClearLog and from Wevtapi.dll.

Ransom note on logon screen

SynAck is also capable of adding a custom text to the Windows logon screen. It does this by modifying the LegalNoticeCaption and LegalNoticeText keys in the registry. As a result, before the user signs in to their account, Windows shows a message from the cybercriminals.

Windows logon screen with ransom text

Attack statistics

We have currently only observed several attacks in the USA, Kuwait, Germany, and Iran. This leads us to believe that this is targeted ransomware.

Detection verdicts




Read Full Article
Visit website

Read for later

Articles marked as Favorite are saved for later viewing.
  • Show original
  • .
  • Share
  • .
  • Favorite
  • .
  • Email
  • .
  • Add Tags 

Separate tags by commas
To access this feature, please upgrade your account.
Start your free month
Free Preview