Malware RSS Feed

Detecting Fraud

SANS Tip of the Day - Tue, 06/19/2018 - 01:00
Review your bank, credit card and financial statements regularly to identify unauthorized activity. This is one of the most effective ways to quickly detect if your bank account, credit card or identity has been compromised.

Browse With Encryption

SANS Tip of the Day - Fri, 06/15/2018 - 01:00
When browsing online, encrypting your online activities is one of the best ways to protect yourself. Make sure your online connection is encrypted by making sure HTTPS is in the website address and/or that there is a lock next to it.

Cloud Security

SANS Tip of the Day - Mon, 06/11/2018 - 01:00
One of the most effective steps you can take to protect your cloud account is to make sure you are using two-step verification. In addition, always be sure you know exactly whom you are sharing files with. It is very easy to accidently share your files with the entire Internet when you think you are only sharing them with specific individuals.

Secure Your Home Wi-Fi Router

SANS Tip of the Day - Thu, 06/07/2018 - 01:00
The most effective steps you can take to secure your wireless network at home is to change the default admin password, enable WPA2 encryption and use a strong password for your wireless network.

Securely Deleting Files

SANS Tip of the Day - Wed, 06/06/2018 - 01:00
When you delete a file, that file is actually still on your computer. The only way you can truly and securely remove a file is by wiping it or using some type of secure deletion.


SANS Tip of the Day - Wed, 05/30/2018 - 01:00
Ransomware is a special type of malware. Once it infected your computer, it encrypts all of your files and demands you pay a ransome if you want your files back. Be suspicious of any emails trying to trick you into opening infected attachments or click on malicious links, common sense is your best defense. In addition. backups are often the only way you can recover from ransomware.

Kids and Mobile Devices

SANS Tip of the Day - Mon, 05/28/2018 - 01:00
If you have kids with mobile devices, create a central home charging station in your bedroom. Before the kids go to bed at night, have them put their mobile devices there so they are not tempted to play with them when they should be sleeping.

Trust Your Instincts

SANS Tip of the Day - Wed, 05/23/2018 - 01:00
Ultimately, common sense is your best protection. If an email, phone call or online message seems odd, suspicious or too good to be true, it may be an attack.

What is Malware

SANS Tip of the Day - Mon, 05/21/2018 - 01:00
Malware is software--a computer program--used to perform malicious actions. In fact, the term malware is a combination of the words malicious and software. Cyber criminals install malware on your computers or devices to gain control over them or gain access to what they contain. Once installed, these attackers can use malware to spy on your online activities, steal your passwords and files, or use your system to attack others.

Never Share Your Passwords

SANS Tip of the Day - Tue, 05/15/2018 - 01:00
Never share your passwords with others, including your supervisor or coworkers. Your password is a secret; it only works if only you know it. If anyone else knows your password, you may be responsible for their actions.

IT threat evolution Q1 2018. Statistics

Malware Alerts - Mon, 05/14/2018 - 06:00

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 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 (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 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 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 4.54 9 Trojan-Banker.AndroidOS.Agent.di 4.31 10 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 (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

Malware Alerts - Mon, 05/14/2018 - 06:00

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

Malware Alerts - Thu, 05/10/2018 - 06:00

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

Why we chose the OPC UA protocol for our research

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

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

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

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

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

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

OPC UA protocol

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

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

  • OPEN

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

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


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

The initial stage

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

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

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

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

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

The fuzzer’s algorithm had the following structure:

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

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

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

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

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

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

OPC UA analysis

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

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

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

Fuzzing the UA ANSI C Stack

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

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

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

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

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

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

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

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

Fuzzing OPC Foundation applications

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

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

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

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

Analyzing third-party applications that use the OPC UA Stack

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

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

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

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

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

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

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

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

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


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

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

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

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

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

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

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


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

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

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

Malware Alerts - Wed, 05/09/2018 - 02:00

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

Searching for the zero day

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

Virustotal scan results for CVE-2018-8174

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

Infection chain

The infection chain consists of the following steps:

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

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

Obfuscated object data in RTF document

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

URL Moniker is used to load an IE exploit

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

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

WINWORD.exe querying registry for correct OLE server

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

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

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

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

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

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

Obfuscated IE exploit

Vulnerability root cause analysis

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

Vulnerability Trigger procedure after deobfuscation

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

CVE-2018-8174 Proof Of Concept

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

Access Violation on a call to freed memory

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

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

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

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

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

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

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

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

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

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


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

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

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

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

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

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


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

  • HEUR:Exploit.MSOffice.Generic – RTF document
  • PDM:Exploit.Win32.Generic – IE exploit – detection with Automatic Exploit Prevention technology
  • HEUR:Exploit.Script.Generic – IE exploit
  • HEUR:Trojan.Win32.Generic – Payload
  • b48ddad351dd16e4b24f3909c53c8901 – RTF document
  • 15eafc24416cbf4cfe323e9c271e71e7 – Internet Explorer exploit (CVE-2018-8174)
  • 1ce4a38b6ea440a6734f7c049f5c47e2 – Payload
  • autosoundcheckers[.]com

SynAck targeted ransomware uses the Doppelgänging technique

Malware Alerts - Mon, 05/07/2018 - 06:00

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

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

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

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

Part of the procedure that implements Process Doppelgänging

Binary obfuscation

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Language check

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

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

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

Directory name validation

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

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

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

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

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

Cryptographic scheme

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

The developers of this Trojan chose the following implementation:


KDF: PBKDF2-SHA1 with one iteration


ECDH curve: standard NIST elliptic curve secp192r1


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

Input: plaintext, input_public_key

Output: ciphertext, ecies_public_key, MAC

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

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

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

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

At the next step the Trojan forms the structure cipher_info.

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

It is shown in the image below.

Encrypted initialization information

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

Ransom note

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

File encryption

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

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

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

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

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

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

The encrypted file structure is shown in the image below.

Encrypted file structure

After encryption the files will have randomly generated extensions.

Directory after encryption

Other features Termination of processes and services

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

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

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

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

Clearing the event logs

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

Ransom note on logon screen

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

Windows logon screen with ransom text

Attack statistics

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

Detection verdicts




Who’s who in the Zoo

Malware Alerts - Thu, 05/03/2018 - 06:00

ZooPark is a cyberespionage operation that has been focusing on Middle Eastern targets since at least June 2015. The threat actors behind the operation infect Android devices using several generations of malware, with the attackers including new features in each iteration. We label them from v1-v4, with v4 being the most recent version deployed in 2017. From the technical point of view, the evolution of ZooPark has shown notable progress: from the very basic first and second versions, the commercial spyware fork in its third version and then to the complex spyware that is version 4. This last step is especially interesting, showing a big leap from straightforward code functionality to highly sophisticated malware.

Evolution of ZooPark malware features

We have observed two main distribution vectors for ZooPark – Telegram channels and watering holes. The second one was the preferred vector: we found several news websites that have been hacked by the attackers to redirect visitors to a downloading site that serves malicious APKs. Some of the themes observed in campaign include “Kurdistan referendum”, “TelegramGroups” and “Alnaharegypt news”, among others.

Target profile has evolved during the last years of campaign, focusing on victims in Egypt, Jordan, Morocco and Lebanon.

If you would like to learn more about our intelligence reports or request more information on a specific report, contact us at:

 Read the full “Who’s who in the Zoo. Cyberespionage operation targets Android users in the Middle East.” report

Social Media Privacy Settings

SANS Tip of the Day - Tue, 05/01/2018 - 01:00
Privacy settings on social networks have limited value. They are confusing to configure and change often. Ultimately, if you do not want your parents or boss reading it, do not post it.

DDoS attacks in Q1 2018

Malware Alerts - Thu, 04/26/2018 - 06:00

News overview

In early January, it was reported that an amateur hacker had come close to pulling off a botnet attack using “improvised” materials. Armed with information gleaned from hacker forums, the DIYer created a Trojan using a zero-day exploit in Huawei routers and released it online. The attack was soon nipped in the bud, but the wannabe cybercriminal could not be traced.

Other slightly weightier news: first, experts reported growth in the Reaper (or IoTroop) botnet (not to be confused with North Korean hacker group The Reaper), first discovered last quarter; second, IT security resources hinted at the emergence of new “strains” of Mirai and Satori (the latter, known as Okiru, is intended for ARC processors), but so far without details. Moreover, in early February a platform selling JenX botnet services was detected and neutralized. JenX was found to be using a fan server for the video game GTA: San Andreas as its C&C. In terms of power, JenX was nothing to write home about, but the originality of its creators deserves a mention. On the topic of original botnets, another worth noting is DoubleDoor: the first known piece of “wild” malware to bundle two IoT vulnerabilities together.

As for new methods and vulnerabilities, besides the multiget hole in Memcached, last quarter news broke of a vulnerability in WordPress that makes it easy to down a web server. Fortunately, no in-the-wild attacks were observed.

The attack targets for this new weaponry remained largely the same. Profit is still the main motive behind DDoS attacks (the number of attacks on business in Russia alone doubled in 2017), although high-profile “commercial” attacks in the last three months were not so numerous. Within the space of three days in early February, players of Final Fantasy encountered problems signing into certain services. At roughly the same time, BusinessWire experienced similar difficulties lasting more than a week, during which period neither editors nor readers could access the news portal. There was no reported ransom demand, so the motive behind the attack can be assumed to be competition-related.

It would be amiss not to mention a series of attacks that hit GitHub and an unknown service provider in early March, which produced record volumes of garbage traffic — over 1 TB/s. This capacity was achieved by leveraging Memcached, a popular caching service for Linux servers. Interestingly, in some of these attacks the garbage traffic itself contained ransom demands in Monero.

Political motives are less common, but often more visible due to their topicality. The most headlining incident of late was, of course, the threat to sabotage the opening ceremony of the Winter Olympics in early February, most likely through a DDoS offensive. Even before that, in late January, the US Department of Defense repelled an influx of spam, and in late March their Russian counterparts had to survive a DDOS attack. In addition, experts reported that North Korean group The Reaper was extending its reach. Despite not showing any DDoS activity, it could soon start moving in that direction.

Another hard-hitting DDoS attack on major financial institutions in the Netherlands was initially thought to be political, but on closer inspection turned out to be pure hooliganism: Dutch police arrested a teen suspect for causing week-long mayhem at several banks simply to prove that it was possible.

DDoS is also becoming more popular as a means of personal revenge. California, for instance, witnessed the case of David Goodyear, who was found guilty of trying to launch a DDoS attack against an amateur astronomy forum when it blacklisted him for using bad language. True, he can’t be accused of not trying other methods before turning his hand to cybercrime: Goodyear repeatedly registered on the forum under different chat names, but each time earned himself a ban for boorish behavior.

Quarter trends

Due to its capacity and relative accessibility, Memcached was the springboard for last quarter’s most sensational attacks. However, it could prove to be a short-lived trend, and here’s why.

In late February, Kaspersky DDoS Protection support was contacted by a company reporting an unusually high load on its communications channel in what it suspected to be a DDoS attack.

At first glance, the picture did indeed resemble a typical DDoS attack: the channel was clogged up, and users couldn’t access the company’s services. However, our investigation revealed that a CentOS Linux server with a vulnerable Memcached service was installed on one of the client servers. This service, used by the cybercriminals during the attack, generated large amounts of outgoing traffic, overloading the channel. In other words, the client was not the target, but an unwitting accomplice in the DDoS attack: the attackers used its server as an amplifier. After Kaspersky Lab’s recommendations were implemented, the malicious parasitic traffic stopped.

This situation is typical for Memcached attacks: owners of vulnerable servers hijacked during attacks notice the load increase and rush to patch any vulnerabilities not to suffer even more downtime losses. As a result, the number of vulnerable servers that can be utilized for this type of attack is rapidly declining, for which reason Memcached attacks will likely dry up soon.

Still, the picture in Q1 shows that “amplified” attacks, which were on the wane, have again picked up momentum. NTP and DNS-based boosting has practically disappeared, since most vulnerable services have already been patched. Cybercriminals will likely seek out other non-standard amplification methods besides Memcached. Last quarter, for instance, we registered a quite rare (yet effective) type of amplification attack, in which the LDAP service was used as an amplifier. Alongside Memcached, NTP, and DNS, this service has one of the biggest amplification factors. Despite the relatively small number of LDAP servers available, this type of attack could be a hit on the shadow Internet in the coming months.

Statistics for botnet-assisted DDoS attacks Methodology

Kaspersky Lab has extensive experience of combating cyber threats, including DDoS attacks of various complexity types and ranges. Company experts track the actions of botnets by using the DDoS Intelligence system.

As part of the Kaspersky DDoS Protection solution, the DDoS Intelligence system intercepts and analyzes commands sent to bots from C&C servers; it does not require any user devices to be infected or cybercriminals to execute any actual commands.

This report contains DDoS Intelligence statistics for Q1 2018.

In the context of this report, it is assumed that an incident is a separate (single) DDoS-attack if the interval between botnet activity periods does not exceed 24 hours. For example, if one particular web resource was attacked by the same botnet in two waves with an interval of 24 hours or more, the incident is considered as two attacks. Bot requests originating from different botnets but directed at one resource also count as separate attacks.

The geographical locations of DDoS-attack victims and C&C servers used to send commands are determined by their respective IP addresses. The number of unique targets of DDoS attacks in this report is counted by the number of unique IP addresses in the quarterly statistics.

DDoS Intelligence statistics are limited to botnets detected and analyzed by Kaspersky Lab. Note that botnets are just one of the tools for performing DDoS attacks, and that the data presented in this report do not cover every single DDoS attack that occurred during the period under review.

Quarter results
  • In Q1 2018, DDoS attacks were registered against targets in 79 countries (84 in the previous quarter). As ever, the vast majority (95.14%) occurred in the top ten countries.
  • As for attack targets, as usual about half were located in China (47.53%), although the share was somewhat lower against the previous quarter.
  • The number of attacks and targets rose significantly, as did the number of long-duration attacks. The most sustained DDoS attack lasted 297 hours (more than 12 days), making it one of the longest in recent years.
  • The share of Linux botnets fell slightly to 66% against the previous quarter’s 71%.
  • Significant peaks in the number and power of cyberattacks were observed in mid-January and early March, while the mid-quarter period was relatively calm.
Geography of attacks

China easily retained pole position by number of attacks: its share remained almost unchanged, up from 59.18% to 59.42%. The US share (17.83%), the second largest, increased by a more noticeable 1.83%. South Korea again took bronze, but its share fell by more than 2%, from 10.21% to 8%.

Britain (1.30%) moved from fourth to fifth. Tenth place in Q1 2018 went to Russia, whose share decreased from 1.25% to 0.76%. The Netherlands and Vietnam dropped out of the top ten, but Hong Kong (with a solid 3.67% against 0.67% in Q4 2017) and Japan (1.16%) reappeared.

Distribution of DDoS attacks by country, Q1 2018 and Q4 2017

As regards the distribution of attack targets, top spot again belongs to China, although its share declined from 51.84% to 47.53%. Meanwhile, the still second-place US saw its share increase from 19.32% to 24.10%. Third position was taken by South Korea (9.62%). France’s ranking changed significantly: shedding just 0.65% this quarter, it dropped from fifth to ninth place.

The list of top ten most attacked countries said goodbye to Russia and the Netherlands, but welcomed Hong Kong (4.76%) straight into fourth place, and Japan (1.6%) into sixth. Overall this quarter, the total share of top ten countries increased slightly to 94.17% against 92.9% at the end of 2017.

Distribution of unique DDoS-attack targets by country, Q4 2017 and Q1 2018

Dynamics of the number of DDoS attacks

Most Q1 activity occurred in the first and last third. The number of attacks peaked on January 19 (666) and March 7 (687 attacks). This is probably linked to the end of the New Year holidays (the number of attacks began to rise around the second week of January) and the March sales (in connection with International Women’s Day). The quietest days were observed at roughly the same time: January 16 and March 11. The mid-quarter period passed relatively smoothly without significant peaks or noticeable declines.

The calmest day of the week in the latest quarter was Sunday, accounting for just 11.35% of all attacks.

Distribution of DDoS attacks by day of the week, Q4 2017 and Q1 2018

Types and duration of DDoS attacks

The share of SYN-DDOS attacks increased slightly (from 55.63% to 57.3%), but there was no repeat of the situation seen in previous quarters. The share of ICMP attacks almost doubled, from 3.4% to 6.1%. Accordingly, UDP, TCP and HTTP floods were forced to cede some ground: their shares dropped by 1-2% against the previous quarter.

Distribution of DDoS attacks by type, Q1 2018

After some respite at the end of 2017, we saw a return of sustained attacks: the longest lasted 297 hours (12.4 days). And although that falls short of the world record, the magnitude is still considerable. We have to go back to late 2015 for a longer attack.

The share of all other sustained attacks (50 hours or more) increased by more than six times, from 0.10% to 0.63%. At the other end of the spectrum, the share of the shortest attacks (9 hours or less) also grew: if last quarter they accounted for 85.5% of all attacks, now the figure stands at 91.47%. Meanwhile, the number of attacks lasting between 10 hours and three days in the latest quarter almost halved from 14.85% to 7.76%.

Distribution of DDoS attacks by duration (hours), Q4 2017 and Q1 2018

The top ten countries by number of C&C servers last quarter underwent a major reshuffle: Canada, Turkey, Lithuania, and Denmark dropped out, while Italy, Hong Kong, Germany, and Britain climbed upwards. The top three remained practically unchanged: South Korea (30.92%), the US (29.32%), China (8.03%). Only Russia (2.01%), having shared bronze with China in late 2017, slid down to ninth place.

The US share almost doubled, bringing it within touching distance of this ranking’s perennial leader South Korea. In addition, the shares of Italy (6.83%), which last quarter did not even make the top ten, the Netherlands (5.62%), and France (3.61%) increased significantly. This jump was due to a sharp rise in the number of C&C accounts for Darkai (in the US, Italy, the Netherlands, and France) and AESDDoS (in China) bots.

Distribution of botnet C&C servers by country, Q1 2018

The share of Linux botnets last quarter fell slightly compared to the end of 2017, down to 66% from 71%. Accordingly, the share of Windows-based botnets climbed from 29% to 34%.

Correlation between Windows- and Linux-based botnet attacks, Q1 2018


In Q1 2018, we observed a significant increase in both the total number and duration of DDoS attacks against Q4 2017. The new Linux-based botnets Darkai (a Mirai clone) and AESDDoS are largely responsible for this hike. The number of now familiar Xor attacks also rose. Neither did Windows-based botnets remain idle, making some headway against Linux in the total number of attacks. The old Yoyo botnet was particularly lively, almost five times as active.

The number of mixed attacks involving several botnet families also increased. This is a clear continuation of the trend that we spoke about at the end of last year: to optimize outlays, attackers utilize unused parts of botnets to generate garbage traffic, redeploying them across targets.

Amplified attacks returned to the cyber arena, particularly through the Memcached service. However, we expect that server owners will quickly spot the abundance of garbage traffic and patch up the vulnerabilities, which will dent the popularity of attacks of this type. That being the case, DDoS masterminds will likely seek out other amplification methods, one of which could be LDAP services.

Energetic Bear/Crouching Yeti: attacks on servers

Malware Alerts - Mon, 04/23/2018 - 06:00

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

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

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

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

Attack victims

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

Table 1. Compromised servers

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

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

Injected link with the file scheme

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

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

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

Scanned resources

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

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

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

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

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

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

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

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

Toolset used Utilities

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

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

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

Malicious php files

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

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

In the table above:

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

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

All the scripts found are obfuscated.

wso shell – error_log.php

Deobfuscated wso shell – error_log.php

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

Web shell – proxy87.php

Deobfuscated web shell – proxy87.php

Modified sshd

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

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

Compilation is possible on any OS with binary compatibility.

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

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

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

Activity of the attackers on compromised servers

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

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

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

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

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

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

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


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

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


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

PHP files:




PHP file hashes


Yara rules

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

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

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

Shell script for Centos

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

 Energetic Bear/Crouching Yeti: attacks on servers

Tens of thousands per Gram

Malware Alerts - Thu, 04/19/2018 - 06:00

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

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

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

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

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

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

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

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

Grams can be purchased in a selection of cryptocurrencies

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

Withdrawal of funds harvested in Ethereum

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

Suspiciously similar Our Team sections

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

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