Backdoors in D-Link’s backyard

“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):

/index.cgi?<…>&res_buf

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

Spam and phishing in Q1 2018

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.

GDPR

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%).

Conclusion

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 spam in global email traffic was 51.82%, down 4.63 p.p. against Q4 2017; the Anti-Phishing module blocked 90,245,060 attempts to direct users to fraudulent pages; and Brazil (19.07%, -1.72 p.p.) had the largest share of users attacked by phishers.

Based on the quarter results, it is safe to predict that scammers will continue to exploit “fashionable” topics,  two of which are cryptocurrencies and new ICOs. Given that these topics have begun to attract interest from the general public, a successful attack can reap vast rewards.

TA18-141A: Side-Channel Vulnerability Variants 3a and 4

Systems Affected

CPU hardware implementations

Overview

On May 21, 2018, new variants—known as 3A and 4—of the side-channel central processing unit (CPU) hardware vulnerability were publically disclosed. These variants can allow an attacker to obtain access to sensitive information on affected systems.

Description

CPU hardware implementations—known as Spectre and Meltdown—are vulnerable to side-channel attacks. Meltdown is a bug that “melts” the security boundaries normally enforced by the hardware, affecting desktops, laptops, and cloud computers. Spectre is a flaw that an attacker can exploit to force a CPU to reveal its data.

Variant 3a is a vulnerability that may allow an attacker with local access to speculatively read system parameters via side-channel analysis and obtain sensitive information.

Variant 4 is a vulnerability that exploits “speculative bypass.” When exploited, Variant 4 could allow an attacker to read older memory values in a CPU’s stack or other memory locations. While implementation is complex, this side-channel vulnerability could allow less privileged code to

  • Read arbitrary privileged data; and
  • Run older commands speculatively, resulting in cache allocations that could be used to exfiltrate data by standard side-channel methods.

Corresponding CVEs for Side-Channel Variants 1, 2, 3, 3a, and 4 are found below:

  • Variant 1: Bounds Check Bypass – CVE-2017-5753
  • Variant 2: Branch Target Injection – CVE-2017-5715
  • Variant 3: Rogue Data Cache Load – CVE-2017-5754
  • Variant 3a: Rogue System Register Read – CVE-2018-3640  
  • Variant 4: Speculative Store Bypass – CVE-2018-3639

Impact

Side-Channel Vulnerability Variants 3a and 4 may allow an attacker to obtain access to sensitive information on affected systems.

Solution

Mitigation

NCCIC recommends users and administrators

  • Refer to their hardware and software vendors for patches or microcode,
  • Use a test environment to verify each patch before implementing, and
  • Ensure that performance is monitored for critical applications and services.
    • Consult with vendors and service providers to mitigate any degradation effects, if possible.
    • Consult with Cloud Service Providers to mitigate and resolve any impacts resulting from host operating system patching and mandatory rebooting, if applicable.

The following table contains links to advisories and patches published in response to the vulnerabilities. This table will be updated as information becomes available.

Link to Vendor Information Date Added
AMD May 21, 2018
ARM May 21, 2018
Microsoft May 21, 2018
Redhat May 21, 2018

References

Revisions

  • May 21, 2018: Initial version

This product is provided subject to this Notification and this Privacy & Use policy.

IT threat evolution Q1 2018. Statistics

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 criminal group attacked more than 40 organizations, causing damage to the financial industry estimated at more than EUR 1 billion. The main attack vector was to penetrate the target organization’s network by sending employees spear-phishing messages with malicious attachments. Having penetrated the internal network via the infected computers, the cybercriminals gained access to the ATM control servers, and through them to the ATMs themselves. Access to the infrastructure, servers, and ATMs allowed the cybercriminals to dispense cash without the use of bank cards, transfer money from the organisation to criminal accounts, and inflate bank balances with money mules being used to collect the proceeds.

Financial threat statistics

These statistics are based on detection verdicts of Kaspersky Lab products received from users who consented to provide statistical data. As of Q1 2017, the statistics include malicious programs for ATMs and POS terminals, but do not include mobile threats.

In Q1 2018, Kaspersky Lab solutions blocked attempts to launch one or more malicious programs designed to steal money from bank accounts on the computers of 204,448 users.

Number of unique users attacked by financial malware, Q1 2018

Geography of attacks

To evaluate and compare the risk of being infected by banking Trojans and ATM/POS malware worldwide, for each country we calculated the share of users of Kaspersky Lab products that faced this threat during the reporting period out of all users of our products in that country.

Geography of banking malware attacks in Q1 2018 (percentage of attacked users)

TOP 10 countries by percentage of attacked users

Country* % of users attacked**
1 Cameroon 2.1
2 Germany 1.7
3 South Korea 1.5
4 Libya 1.5
5 Togo 1.5
6 Armenia 1.4
7 Georgia 1.4
8 Moldova 1.2
9 Kyrgyzstan 1.2
10 Indonesia 1.1

These statistics are based on Anti-Virus detection verdicts received from users of Kaspersky Lab products who consented to provide statistical data.
Excluded are countries with relatively few Kaspersky Lab’ product users (under 10,000).
** Unique users whose computers were targeted by banking Trojans as a percentage of all unique users of Kaspersky Lab products in the country.

TOP 10 banking malware families

TOP 10 malware families used to attack online banking users in Q1 2018 (by share of attacked users):

Name Verdicts* % of attacked users**
1 Zbot Trojan.Win32. Zbot 28.0%  
2 Nymaim Trojan.Win32. Nymaim 20.3%  
3 Caphaw Backdoor.Win32. Caphaw 15.2%  
4 SpyEye Backdoor.Win32. SpyEye 11.9%  
5 NeutrinoPOS Trojan-Banker.Win32.NeutrinoPOS 4.5%  
6 Emotet Backdoor.Win32. Emotet 2.4%  
7 Neurevt Trojan.Win32. Neurevt 2.3%  
8 Shiz Backdoor.Win32. Shiz 2.1%  
9 Gozi Trojan.Win32. Gozi 1.9%  
10 ZAccess Backdoor.Win32. ZAccess 1.3%  

* Detection verdicts of Kaspersky Lab products. The information was provided by Kaspersky Lab product users who consented to provide statistical data.
** Unique users attacked by this malware as a percentage of all users attacked by financial malware.

In Q1 2018, TrickBot departed the rating to be replaced by Emotet (2.4%), also known as Heodo. Trojan.Win32.Zbot (28%) and Trojan.Win32.Nymaim (20.3%) remain in the lead, while Trojan.Win32.Neurevt (2.3%), also known as Betabot, suffered a major slide. Meanwhile, Caphaw (15.2%) and NeutrinoPOS (4.5%) climbed significantly, as did their Q1 activity.

Cryptoware programs

Q1 events

Q1 2018 passed without major incidents or mass cryptoware epidemics. The highlight was perhaps the emergence and widespread occurrence of a new Trojan called GandCrab. Notable features of the malware include:

  • Use of C&C servers in the .bit domain zone (this top-level domain is supported by an alternative decentralized DNS system based on Namecoin technology)
  • Ransom demand in the cryptocurrency Dash

GandCrab was first detected in January. The cybercriminals behind it used spam emails and exploit kits to deliver the cryptoware to victim computers.

The RaaS (ransomware as a service) distribution model continues to attract malware developers. In February, for example, there appeared a new piece of ransomware called Data Keeper, able to be distributed by any cybercriminal who so desired. Via a special resource on the Tor network, the creators of Data Keeper made it possible to generate executable files of the Trojan for subsequent distribution by “affilate program” participants. A dangerous feature of this malware is its ability to automatically propagate inside a local network. Despite this, Data Keeper did not achieve widespread distribution in Q1.

One notable success in the fight against cryptoware came from Europe: with the assistance of Kaspersky Lab, Belgian police managed to locate and confiscate a server used by the masterminds behind the Trojan Cryakl. Following the operation, Kaspersky Lab was given several private RSA keys required to decrypt files encrypted with certain versions of the Trojan. As a result, we were able to develop a tool to assist victims.

Number of new modifications

In Q1 2018, there appeared several new cryptors, but only one, GandCrab, was assigned a new family in our classification. The rest, which are not widely spread, continue to be detected with generic verdicts.

Number of new cryptoware modifications, Q2 2017 – Q1 2018

The number of new modifications fell sharply against previous quarters. The trend indicates that cybercriminals using this type of malware are becoming less active.

Number of users attacked by Trojan cryptors

During the reporting period, Kaspersky Lab products blocked cryptoware attacks on the computers of 179,934 unique users. Despite fewer new Trojan modifications, the number of attacked users did not fall against Q3.

Number of unique users attacked by cryptors, Q1 2018

Geography of attacks

TOP 10 countries attacked by Trojan cryptors

Country* % of users attacked by cryptors**
1 Uzbekistan 1.12
2 Angola 1.11
3 Vietnam 1.04
4 Venezuela 0.95
5 Indonesia 0.95
6 Pakistan 0.93
7 China 0.87
8 Azerbaijan 0.75
9 Bangladesh 0.70
10 Mongolia 0.64

* Excluded are countries with relatively few Kaspersky Lab users (under 50,000).
** Unique users whose computers were attacked by Trojan cryptors as a percentage of all unique users of Kaspersky Lab products in the country.

The makeup of the rating differs markedly from 2017. That said, most positions were again filled by Asian countries, while Europe did not have a single representative in the TOP 10 countries attacked by cryptors.

Despite not making the TOP 10 last year, Uzbekistan (1.12%) and Angola (1.11%) came first and second. Vietnam (1.04%) moved from second to third, Indonesia (0.95%) from third to fifth, and China (0.87%) from fifth to seventh, while Venezuela (0.95%) climbed from eighth to fourth.

TOP 10 most widespread cryptor families

Name Verdicts* % of attacked users**
1 WannaCry Trojan-Ransom.Win32.Wanna 38.33  
2 PolyRansom/VirLock Virus.Win32.PolyRansom 4.07  
3 Cerber Trojan-Ransom.Win32.Zerber 4.06  
4 Cryakl Trojan-Ransom.Win32.Cryakl 2.99  
5 (generic verdict) Trojan-Ransom.Win32.Crypren 2.77  
6 Shade Trojan-Ransom.Win32.Shade 2.61  
7 Purgen/GlobeImposter Trojan-Ransom.Win32.Purgen 1.64  
8 Crysis Trojan-Ransom.Win32.Crusis 1.62  
9 Locky Trojan-Ransom.Win32.Locky 1.23  
10 (generic verdict) Trojan-Ransom.Win32.Gen 1.15  

* Statistics are based on detection verdicts of Kaspersky Lab products. The information was provided by Kaspersky Lab product users who consented to provide statistical data.
** Unique Kaspersky Lab users attacked by a particular family of Trojan cryptors as a percentage of all users attacked by Trojan cryptors.

This quarter, the rating is again topped by WannaCry (38.33%), extending its already impressive lead. Second place was claimed by PolyRansom (4.07%), also known as VirLock, a worm that’s been around for a while. This malware substitutes user files with modified instances of its own body, and places victim data inside these copies in an encrypted format. Statistics show that a new modification detected in December immediately began to attack user computers.

The remaining TOP 10 positions are taken by Trojans already known from previous reports: Cerber, Cryakl, Purgen, Crysis, Locky, and Shade.

Countries that are sources of web-based attacks: TOP 10

The following statistics show the distribution by country of the sources of Internet attacks blocked by Kaspersky Lab products on user computers (web pages with redirects to exploits, sites containing exploits and other malicious programs, botnet C&C centers, etc.). Any unique host could be the source of one or more web-based attacks.

To determine the geographical source of web-based attacks, domain names are matched against their actual domain IP addresses, and then the geographical location of a specific IP address (GEOIP) is established.

In Q1 2018, Kaspersky Lab solutions blocked 796,806,112 attacks launched from Internet resources located in 194 countries worldwide. 282,807,433 unique URLs were recognized as malicious by Web Anti-Virus components. These indicators are significantly higher than in previous quarters. This is largely explained by the large number of triggers in response to attempts to download web miners, which came to prominence towards the end of last year and continue to outweigh other web threats.

Distribution of web attack sources by country, Q1 2018

This quarter, Web Anti-Virus was most active on resources located in the US (39.14%). Canada, China, Ireland, and Ukraine dropped out of TOP 10 to be replaced by Luxembourg (1.33%), Israel (0.99%), Sweden (0.96%), and Singapore (0.91%).

Countries where users faced the greatest risk of online infection

To assess the risk of online infection faced by users in different countries, for each country we calculated the percentage of Kaspersky Lab users on whose computers Web Anti-Virus was triggered during the quarter. The resulting data provides an indication of the aggressiveness of the environment in which computers operate in different countries.

This rating only includes attacks by malicious programs that fall under the Malware class; it does not include Web Anti-Virus detections of potentially dangerous or unwanted programs such as RiskTool or adware.

Country* % of attacked users**
1 Belarus 40.90
2 Ukraine 40.32
3 Algeria 39.69
4 Albania 37.33
5 Moldova 37.17
6 Greece 36.83
7 Armenia 36.78
8 Azerbaijan 35.13
9 Kazakhstan 34.64
10 Russia 34.56
11 Kyrgyzstan 33.77
12 Venezuela 33.10
13 Uzbekistan 31.52
14 Georgia 31.40
15 Latvia 29.85
16 Tunisia 29.77
17 Romania 29.09
18 Qatar 28.71
19 Vietnam 28.66
20 Serbia 28.55

These statistics are based on detection verdicts returned by the Web Anti-Virus module that were received from users of Kaspersky Lab products who consented to provide statistical data.
* Excluded are countries with relatively few Kaspersky Lab users (under 10,000).
** Unique users targeted by Malware-class attacks as a percentage of all unique users of Kaspersky Lab products in the country.

On average, 23.69% of Internet user computers worldwide experienced at least one Malware-class attack.

Geography of malicious web attacks in Q1 2018 (percentage of attacked users)

The countries with the safest surfing environments included Iran (9.06%), Singapore (8.94%), Puerto Rico (6.67%), Niger (5.14%), and Cuba (4.44%).

Local threats

Local infection statistics for user computers are a very important indicator: they reflect threats that have penetrated computer systems by infecting files or removable media, or initially got on the computer in an encrypted format (for example, programs integrated in complex installers, encrypted files, etc.).

Data in this section is based on analyzing statistics produced by Anti-Virus scans of files on the hard drive at the moment they were created or accessed, and the results of scanning removable storage media.

In Q1 2018, our File Anti-Virus detected 187,597,494 malicious and potentially unwanted objects.

Countries where users faced the highest risk of local infection

For each country, we calculated the percentage of Kaspersky Lab product users on whose computers File Anti-Virus was triggered during the reporting period. These statistics reflect the level of personal computer infection in different countries.

The rating includes only Malware-class attacks. It does not include File Anti-Virus detections of potentially dangerous or unwanted programs such as RiskTool or adware.

Country* % of attacked users**
1 Uzbekistan 57.03
2 Afghanistan 56.02
3 Yemen 54.99
4 Tajikistan 53.08
5 Algeria 49.07
6 Turkmenistan 48.68
7 Ethiopia 48.21
8 Mongolia 46.84
9 Kyrgyzstan 46.53
10 Sudan 46.44
11 Vietnam 46.38
12 Syria 46.12
13 Rwanda 46.09
14 Laos 45.66
15 Libya 45.50
16 Djibouti 44.96
17 Iraq 44.65
18 Mauritania 44.55
19 Kazakhstan 44.19
20 Bangladesh 44.15

These statistics are based on detection verdicts returned by OAS and ODS Anti-Virus modules received from users of Kaspersky Lab products who consented to provide statistical data. The data include detections of malicious programs located on user computers or removable media connected to computers, such as flash drives, camera and phone memory cards, or external hard drives.
* Excluded are countries with relatively few Kaspersky Lab users (under 10,000).
** Unique users on whose computers Malware-class local threats were blocked, as a percentage of all unique users of Kaspersky Lab products in the country.

On average, 23.39% of computers globally faced at least one Malware-class local threat in Q1.

The figure for Russia was 30.92%.

The safest countries in terms of infection risk included Estonia (15.86%), Singapore (11.97%), New Zealand (9.24%), Czech Republic (7.89%), Ireland (6.86%), and Japan (5.79%).

IT threat evolution Q1 2018

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 feature of society, we’ve seen a growth in the number of malicious crypto-currency miners.  In 2017, we blocked malicious miners on the computers of 2.7 million Kaspersky Lab customers – compared to 1.87 million in 2016.  This is now beginning to eclipse ransomware as a way of making money illegally.

As the name suggests, crypto-currency miners are programs designed to hijack the victim’s CPU in order to mine crypto-currencies.  Like ransomware, the business model is simple:  infect victim’s computer, use the processing power of their CPU or GPU to generate coins and earn real-world money through legal exchanges and transactions.  Unlike ransomware, it’s not obvious to the victim that they are infected – most people seldom use most of their computer’s processing power; and miners harness the 70 to 80 per cent that is not being used for anything else.

Crypto-miners are installed – on the computers of consumers and businesses alike – alongside adware, cracked games and pirated content.  It’s becoming easy for cybercriminals to create miners, because of ready to use partner programs, open mining pools and miner-builders.  Another method is web mining, where cybercriminals insert a script into a compromised web site that mines crypto-currencies while the victim browses the site.  Other criminal groups are more selective, using exploits to install miners on the servers of large companies, rather than trying to infect lots of individuals.

Some of the ways cybercriminals install malicious miners in the network of corporate victims are very sophisticated, resembling the methods of APT attackers.  Our researchers identified a case where the attackers used a process-hollowing technique.  The infection starts with the download of a potentially unwanted application (PUA) that contains the miner.   This miner installer drops the legitimate Windows utility ‘msiexec’ with a random name, which downloads and executes a malicious module from a remote server.   The next step is to install a malicious scheduler task that drops the body of the miner. This executes the legitimate system process and uses a process-hollowing technique whereby the legitimate process code is switched for malicious code.  A special system critical flag is set for this new process:  if the victim tries to kill this process, Windows reboots.


Using such techniques, we estimate that mining botnets generated more than $7,000,000 in the second half of 2017.

You can find tips on securing businesses from malicious miners here.

Our data in their hands

Personal data is valuable.  This is evident from the regular news reports of data breaches.  These include the theft of huge amounts of data and the re-use of stolen credentials.  However, the recent scandal involving the use, by Cambridge Analytica, of Facebook data is a reminder that personal information is not just valuable to cybercriminals.

In many cases, personal data is the price people pay to obtain a product or service – ‘free’ browsers, ‘free’ e-mail accounts, ‘free’ social network accounts, etc.  But not always.  Increasingly, we’re surrounded by smart devices that are capable of gathering details on the minutiae of our lives.  Earlier this year, one journalist turned her apartment into a smart home in order to measure how much data was being collected by the firms that made the devices.  Since we generally pay for such devices, the harvesting of data can hardly be seen as the price we pay for the benefits they bring in these cases.

The issues surrounding security and privacy of data continue to make headlines, not least as we approach 25 May, 2018 and the implementation of the EU General Data Protection Regulation.  It will, of course, be interesting to see what impact the legislation has.  But we should not forget that we should all consider what data we share, with whom, and how it might be used.  It’s vital to take steps to secure our data, by using unique, complex passwords for each account and by using two-factor authentication where it’s available.

OPC UA security analysis

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:

  • HELLO
  • OPEN
  • MESSAGE
  • CLOSE

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.

Results

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.

Conclusion

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 modern software tend to eliminate from their code, largely to make their products more secure. At the same time, the code is not very well documented, which makes errors more likely to be introduced in the process of using or modifying it.

Second, OPC UA developers clearly underestimate the trust software vendors have for all code provided by the OPC Foundation consortium. In our view, leaving vulnerabilities in the code of API usage examples is completely wrong, even though API usage examples are not included in the list of products certified by the OPC Foundation.

Third, we believe that there are quality assurance issues even with products certified by the OPC Foundation.

It is likely that use fuzz testing techniques similar to those described in this paper are not part of the quality assurance procedures used by OPC UA developers – this is demonstrated by the statistics on the vulnerabilities that we have identified.

The open source code does not include code for unit tests or any other automatic tests, making it more difficult to test products that use the OPC UA Stack in cases when developers of these products modify their code.

All of the above leads us to the rather disappointing conclusion that, although OPC UA developers try to make their product secure, they nevertheless neglect to use modern secure coding practices and technologies.

Based on our assessment, the current OPC UA Stack implementation not only fails to protect developers from trivial errors but also tends to provoke errors –we have seen this in real-world examples. Given today’s threat landscape, this is unacceptable for products as widely used as OPC UA. And this is even less acceptable for products designed for industrial automation systems.

The King is dead. Long live the King!

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.

Conclusion

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: [email protected]

Detection

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

IOCs

  • b48ddad351dd16e4b24f3909c53c8901 – RTF document
  • 15eafc24416cbf4cfe323e9c271e71e7 – Internet Explorer exploit (CVE-2018-8174)
  • 1ce4a38b6ea440a6734f7c049f5c47e2 – Payload
  • autosoundcheckers[.]com