Network infrastructure devices have been actively exploited by cyber actors [1, 2]. A variety of attacks can be carried out by abusing such devices. In 2018, more than half a million low-cost routers were infected by the VPNFilter malware . With a view to disrupting that malware campaign, the Federal Bureau of Investigation (FBI)  issued an urgent request for users to reboot their routers. In the same year, there were several other campaigns aimed at low-cost routers (e.g. GhostDNS malware, Navidade and SonarDNS) . Infrastructure devices can be used for last-mile access as well as to manage interdomain routing (BGP).
Half of the core routers used in one of the biggest internet exchanges in the world (connecting 1467 autonomous systems)  are manufactured by MikroTik. This manufacturer uses the same operating system (RouterOS) for all their low-cost routers (used by home users and in the core network infrastructure). In order to improve the security of this type of router and set proper defences, it is crucial to understand the risk and characteristics of the attacks that target these routers.
One effective way to investigate attacks targeting devices connected to the internet is to use a honeypot. As demonstrated by Lobato et al. , honeypots are valuable resources for detecting new or unknown attacks targeting a system. The network management and operations community has been using honeypots and similar approaches to improve insight into malicious activities within networks [8, 9, 10, 11]. In this paper, we extend our previous analysis by presenting a long-term investigation of MikroTik-targeted attacks. Although we focus our analysis on MikroTik routers, any other low-cost router could have been used. The main contributions made in this paper are as follows.
We shed light on the global landscape of MikroTik devices. To that end, we investigate (1) how many MikroTik devices are reachable via the internet, (2) what port numbers are most commonly open on such devices, and (3) where such devices are located. This contribution highlights the importance of investigating MikroTik devices and facilitates definition of a realistic MikroTik device honeypot.
We propose a realistic, easily deployed honeypot that mimics low-cost MikroTik routers. The proposed honeypot uses virtualisation to run the system in the cloud and enables remote management and security implementation mechanisms by using a set of modules. Our honeypot image is publicly available on the project website . The study’s first contribution (MikroTik device landscape) enables us to define and deploy a realistic honeypot by indicating (1) where to place the sensors, (2) which port numbers should be open for interaction with attackers, and (3) what ethical issues the design needs to address.
We propose an automated classification of the traffic collected in the honeypot and discuss ways of mitigating attacks of the types identified. The classification facilitates the quantification of the attacks and is based on two databases of manually defined attack signatures. The signatures developed for this study are publicly available on the project website and are compatible with the Berkeley Packet Filter. Finally, we discuss how to mitigate the attacks on MikroTik devices.
We compiled the landscape of MikroTik devices using more than 4 TB of data (from Shodan.io). For the classification of attacks, we used more than 44 million packets and 3.8 million log records.
The remainder of this paper is structured as follows. First, in section 2, we describe the uniqueness of this work in relation to the state of the art. Then, in section 3, we describe the methodology and the results of our survey of the global MikroTik device landscape. In section 4, we describe the design, implementation and limitations of our MikroTik device honeypot. In section 5, we first discuss how we automatically classify the traffic collected in the honeypot. Then we present and discuss our findings based on 120 days of collected data. Finally, in section 6, we discuss our conclusions and the directions that future research is likely to take.
2 Related Work
Honeypots are usually designed to facilitate the improvement of system security by enabling the study of malicious behaviours. Do Carmo et al.  and Nassar et al. , for example, described the use of honeypots for improving the security of VoIP systems. There are other works that, although they do not propose a specific honeypot, set out strategies for detecting malicious behavior by performing network measurements. For example, François et al.  analysed communication behavior patterns to infer potential botnet activities; and Sperotto et al.  showed how flow-based techniques can be used to detect scans, worms, botnets and denial-of-service attacks. Our work is similar to the work described by those authors. However, we focus our attention on low-cost devices that are (also) used in the core infrastructures of networks. Such devices play a crucial role in the networks of developing countries (as described in the next section).
Various papers have also been published analysing vulnerabilities in generic low-cost routers and proposing countermeasures. For example, Niemietz and Schwenk  evaluated home routers and showed how these routers are vulnerable to cross-site scripting attacks and User-Interface (UI) redressing; Mujtaba and Nanda  analysed vulnerabilities in the BGP protocol on low-cost routers; Ghourabi et al.  discussed the abuse of another routing protocol used by low-cost routers, the RIP protocol. While the papers in question focus on generic low- cost routers, only Mazdadi et al.  investigated MikroTik devices. However, the research in question was limited to the analysis of a single attack and did not propose a reproducible way of monitoring and characterising attacks.
Of the previous studies we found, the one most similar to our work is by Baines . He provides insights regarding the global landscape of MikroTik devices and their vulnerabilities. The main difference between his work and ours is that all his observations are based on active scanning of port number 8291. By contrast, we begin by analysing the ports that MikroTik devices actually use in practice. Then we use the findings to create a realistic MikroTik honeypot. We believe that our approach provides a more complete understanding of the landscape and the prevalence of vulnerabilities. We have also classified more attacks than are described in Baines’  work.
Finally, and crucially for our work, most investigations of honeypots involve discussion of the ethical and legal perspectives of using honeypots for research. Sokol and Andrejko discussed the issue of liability in relation to honeypot use. The question of liability can arise if honeypots are exploited by attackers and used to launch attacks. The paper in question discusses the systems that need to be taken into account when designing a honeypot, in order to minimise the risks. Similarly, Hecker et al.  argued for the use of dynamic honeypots instead of low or high-interaction honeypots. We took all the lessons described in those papers into account in the design of our honeypot, with a view to minimising issues.
3 MikroTik Devices Landscape
For investigating the global landscape of MikroTik devices, we rely on the information collected by the Shodan.io project. This project port-scans the entire IPv4 address space. Although other similar projects could be used, e.g. Censys.io, Shodan covers more generic ports (giving a higher chance of port-scanning the particular ports used by MikroTik devices). In order to reduce the amount of traffic generated, Shodan scans only a set of IP addresses and a set of service ports each day. It takes around two weeks to scan the entire IPv4 space. Shodan also tries to retrieve the responses from services running at the relevant IP addresses (i.e. the banners), which are used to, for example, classify the types of service running on the devices (i.e. the products).
Initially, we entered several different queries on Shodan’s online platform: “mikrotik” (1,657,859 results), “product: mikrotik” (3,700,193 results) and “product:mikrotiksmb” (1,323 results). Each result is related to an IP address and an open service port. It means that each product/service port running at an IP address is one single entry in Shodan’s dataset. In order to determine the precise number of devices involved, we would need to merge all the results relating to MikroTik. After noticing that we were unable to download all results (more than 1M) for further analysis, we contacted Shodan’s operators, who granted us access to one month of their dataset.
Dataset and methodology. Each day of Shodan’s scanning yields a file of around 130 GB. We downloaded the data from the period 17 July 2019 to 17 August 2019. In total, more than 4 TB of data was retrieved. We filtered the entire dataset for records that contained the string ‘mikrotik’. Hence, we know that, in every entry in the resulting data subset, the banner (response from a device) definitely relates to a MikroTik device (true positive).
Limitations. First, if a banner from a MikroTik device is empty, neither Shodan nor we are able to classify it, possibly implying in false negative. Second, Shodan does not scan all possible service ports, implying that devices will not be found if they use a particular unscanned port. Third, although Shodan updates their dataset every two weeks (accordingly to the owner of the project), we sought to determine the total number of devices over a one-month period, without flushing the data. The implication is that we did not remove IP addresses that may have ceased to point to MikroTik devices. Finally, we expect that a small number of devices are not discoverable by Shodan because they are, for example, behind NAT systems, or do not answer on any open service port, or are not online at the time of measurement.
Our observations regarding the number of records and the number of IP address per day are presented in Figure 1. After one month we had observed 4,742,944 distinct IP addresses and 6,484,420 distinct records related to MikroTik devices. We observed that both the number of records and the number of IP addresses scanned/found (blue bars) remained similar from day to day, at 500k per day (median 535,260 and 510,173, respectively).
In Figure 1
, we also depict the cumulative number of distinct records (graph up) and IP addresses (graph down); and the number of new records found in a day (relative to the cumulative) (black bars). Contrary to what we expected, the number of new records and IP addresses (relative to the cumulative) is never zero. We believe that the explanation is probably that we did not ‘flush’ our observations. After an interval of two weeks, both the number of new records and the number of new IP addresses seem to stabilise (as Shodan’s owner told us to expect). We believe that the numbers represent the potential turnover of MikroTik devices.
In Table 1, , we list the 10 ports most commonly associated with MikroTik devices. Our first observation is that HTTP (line 3, 6, 8 and 9) runs on various ports, possibly to prevent malicious access. MikroTik routers are usually managed using the HTTP(S) protocol. It is also interesting to note that most of the identified ports are listed as services that run by default on MikroTik devices (i.e. FTP–21, Telnet–23, SSH–22, HTTP–80, HTTPS–443, Bandwidth-test–2000, WinBox–8291, API–8728 and API-SSL– 8729) . However, one of the top ports, 1723, is not open by default. The port must therefore have been opened intentionally by the operators or by hackers that got access to the relevant devices.
Another notable feature of the data in Table I is that the data gathered by Shodan does not include any entries relating to port 8291 (WinBox), 8728 (API) or 8729 (API-SSL). The reason is that Shodan does not scan for those ports. The implication is that the number of devices that we found is potentially smaller than the actual number of MikroTik devices. However, according to Baines , there are at least 565,648 devices (IP addresses) running port 8291 (WinBox), which is mainly used by MikroTik devices. Comparing Baines’ findings, available at , with our one-month analysis, we observed more than 80% overlap (80.17%). The implication is that, although Shodan does not cover port 8291, the majority of MikroTik devices run multiple ports and Shodan is therefore able to detect them.
|Port #||Description||# Records||%|
Finally, in Table 2, we list the 10 countries with the most IP addresses relating to MikroTik devices. This information is important for deciding in which countries our honeypot sensors (described in the next section) should be placed. The ten listed countries represent 64.88% of all MikroTik devices that we found. Note also that 8 out of the 10 countries are considered ‘emerging economies’ (*). The explanation for the prominence of such countries may be that MikroTik devices are known as low-cost routers. They are therefore particularly attractive to ‘emerging economies’ that have a strong incentive to economise when investing in their network infrastructures. That hypothesis is supported by the fact that the top country is Brazil and, according to , half of the core routers in the largest Brazilian Internet Exchange are MikroTik devices.
|Country||# IP add.||%|
The takeaway message. In this section, we observed that the number of MikroTik devices operating around the world is very high. They are located largely in emerging economies, and some are used in the core network infrastructures of such countries.
That observation underscores the importance of the study described in this paper. In addition to the default service ports open on MikroTik devices, a realistic MikroTik honeypot should feature the 10 ports most commonly open, as detailed in Table 1.
4 System design
In this section, we describe the design of our honeypot, consider pertinent deployment aspects and discuss the legal considerations.
4.1 Honeypot design
In the interests of reproducibility and deployability, we designed the honeypot using a system based on paravirtualisation. As depicted in Figure 2, the design features a host system based on Linux that is responsible for running RouterOS. We opted to use version 6.39.3 of RouterOS, since it has not been patched for most of the critical vulnerabilities discovered in recent years. The communication between the host system and RouterOS is performed by a software API developed using three building blocks described in turn below.
Services: the RouterOS system was configured to provide a set of services to external users. Those services were deployed in the honeypot and made accessible via the host system. The host access policy was accordingly updated to enable connection to those services directly. Although RouterOS enables a set of services by default, we have customised the system configuration to make the device more realistic, in line with the findings discussed in section 3. Table 3 shows the list of services enabled in our honeypots. The services marked with an asterisk are not active in the default configuration, but were added in our customisation.
Security: the security module is responsible for controlling access to the RouterOS and managing the connections to the active services. An emulated virtual private network was created by running the virtual machine in a host-only network to separate the traffic to the server from that to the honeypot. That ensured that the honeypot could not gain access to the rest of the server. The honeypot is a high-interaction honeypot. The advantage of a high-interaction honeypot is that the chances of receiving and detecting attacks are higher than with a low-interaction honeypot. The disadvantage is that more damage could be done to the device and proper security measures should therefore be taken to ensure that the router can be reset easily and that the bandwidth is restricted to significantly limit the damage that attackers can do. For this reason, rate limiting was used to limit the total volume of traffic to the testbed to 1 Mbps. Furthermore, the router was restored to its original state every day at midnight to prevent abuse.
Management: our system was designed to collect all inbound and outbound traffic to and from the honeypot. We collected the full packets using the TCPDUMP capture tool for each running sensor and stored them on a centralised server. In addition to the network traffic, we collected the system events (logs) available in the RouterOS running in the honeypot. As described by Mazdadi et al. , it is possible to use the API interface provided by RouterOS to actively retrieve relevant system information, such as DHCP leases, configuration changes, uploaded files, BGP data and more. The tool described in that paper was not available, so a custom script was written to imitate its functionality . Our tool was configured to collect the system events every 5 minutes via the RouterOS API-SSL service on port 8729.
4.2 Honeypots deployment
A total of six honeypots were created in different regions of servers on the Google Cloud Platform. The locations of the honeypots were chosen based on the most common regions for MikroTik devices, as per Table 2. Another factor influencing location was that we wanted the honeypots to cover most of the continents. With that in mind, the regions we settled on were Australia, Brazil, China (Hong Kong), India, the Netherlands and the United States of America.
A central ‘collector’ computer was used to collect the traffic from the six honeypots. This computer implemented routines to collect, filter and parse all the new logs generated by TCPDUMP capture tool as well as the system events from the honeypot. The information gathering process was repeated every hour, so even if the honeypot were compromised and we lost access, we would still have the logs for every complete hour prior to access loss. It is important to note that, in that case, our honeypot would be restored using our clean system snapshot.
4.3 Legal considerations
It is important to consider the applicable legal requirements when designing a honeypot. According to EU law, “a duty to act positively to protect others from damage may exist if the actor creates or controls a dangerous situation” . Hence, a honeypot owner has a responsibility to take appropriate action to secure the honeypot, since a honeypot operation can be seen as a potentially dangerous situation insofar as real-world attacks are attracted.
Research by Sokol and Andrejko  shows that a secure honeypot meeting the requirements laid down by EU law should have the five features mentioned below. We used Sokol and Andrejko’s findings to guide the design of the honeypot used in our research:
Firewall: allow connections only to certain ports.
Dynamic connection redirection mechanism: only trusted connections should have access to services outside the honeypot.
Emulated private virtual network: the honeypot should be run in a restricted private network to restrict attackers.
Testbed: a controlled environment should be used to analyse vulnerabilities in applications.
Control centre: the administrator of the honeypot should monitor connections and quickly respond to incidents.
Limitations. As discussed in this section, our honeypots were placed on a cloud infrastructure (Google Cloud). Some attackers may avoid well-known IP address ranges, such as those used by cloud service providers. Some attackers could also avoid our honeypots because they are not actual routers (not providing last-mile access).
5 Attack Classification, Findings, and Discussion
In this section, we first present our methodology for automating the classification of attacks on MikroTik devices. Then we present our observations over 120 days of data collection.
5.1 Attack Classification Methodology
Our methodology for classifying attacks relies on comparing the collected data with manually created signatures. We created two databases of attacks containing: (1) signatures that cover the majority of Common Vulnerabilities and Exposures (CVE) involving MikroTik devices (as listed by ); and (2) signatures of known attacks that target low-cost routers in general.
For our attack classification, we consider two types of input file collected by our MikroTik honeypots: (1) packet-based network traces (.pcap files) and (2) logs. While .pcap files are used for classifying CVE-MikroTik-related attacks, logs are used for classifying generic attacks. The signatures generated from .pcap data were made compatible with the Berkeley Packet Filter; they are publicly available from the project website111See: http://mikrotik-exposed.org/. All the signatures developed were validated using proof-of-concept vulnerability traffic by Tenable Research , which is the best-known dataset for validating attacks on MikroTik devices.
In order to make full use of the .pcap files, we decrypted any traffic encrypted on the basis of the MikroTik proprietary protocol. For example, packets based on the WinBox protocol were decrypted using the tool proposed by Tenable Research  and any encrypted web traffic was decrypted using the tool proposed by Tenable Research . Figure 3 depicts our entire methodology.
Dataset. We collected 120 days of data (.pcap and logs), from 25 July 2019 to 20 November 2019, relating to traffic targeting our 6 honeypots (in Australia, Brazil, China, India, Netherlands and United States of America). In total, we collected more than 44 million packets (12 million flows) and 3.8 million log records. The authors will be glad to share the entire dataset on request, for research purposes.
Limitations. It is important to stress that we did not focus our classification on the overall backscatter traffic collected by our honeypot, as most previous researchers in this field have done. Instead, we analysed a small, critical portion of the entire dataset, consisting mainly of attack traffic tailored to MikroTik devices. Another limitation is that we were able to generate signatures for only half of the known CVEs. Hence, we covered only some of the attacks tailored to MikroTik devices. Also, more sophisticated attacks may have been missed.
5.2 General Traffic Analysis
Figure 4 shows the timeline of collected data. It combines information from the .pcap files and system log entries representing hostile activities targeting the MikroTik system. The number of flows is not constant, therefore the number of system log events is not constant either. The peaks representing attack campaigns are considered later in this paper. In the meantime, note the correlation between the number of flows and the number of log events in some periods, such as at juncture ③. The correlation indicates that the attack campaign in question successfully generated honeypot system activity.
. A campaign consists of attackers performing multiple offensive actions targeting a specific resource or vulnerability. Such behaviour typically results in outliers in our dataset, as seen at the numbered junctures inFigure 4. In 120 days of analysed data, 4 campaigns stand out. Campaign ① was performed by one unique IP (64.X.X.70) and targeted the MikroTik management service API (8728/TCP). The IP in question hit all our honeypots equally. The campaign probably involved a horizontal scan of the internet to enumerate MikroTik-related services. The next identified campaign was also conducted from one unique IP address (183.X.X.171). In this campaign, several TCP ports were targeted. Notably, all the probes involved in this attack used the same source port 55453/TCP. Since use of the same source port for all flows is not the default behaviour, we suspect the use of a customised and automated tool to perform the scans. The same behaviour can be seen in campaign ③: only one IP address performed a scan using a static source port. Campaign ④ involved brute-forcing attacks targeting the FTP service and was conducted from a single IP address (185.X.X.34). The identification of such campaigns helps us to understand the threat landscape. Although we did not find a correlation between the described campaigns and vulnerability exploitation, the analysis can provide insight regarding the way attackers operate.
Attack dispersal: we investigated how the attackers hit our honeypots. By analysing the IP addresses used and the honeypots targeted, we can determine the attack dispersal. We found that 80% of attackers were associated with a maximum of 2 honeypots. Whereas 67% of source IPs hit only one honeypot.
At the AS level, Figure 5, the attacks are fairly dispersed as well. For example, the most prominent AS (AS 4766: Korea Telecom) is operated by a large ISP in Korea, while the third most prominent AS (AS134763: Chinanet) belongs to an ISP located in China. The second most prominent AS is located in the Seychelles (AS 202425: IP Volume Networks) and seems to be a data centre that provides suspicious services, perhaps a bulletproof service or some service model that offers attacks tailored to MikroTik. Not much information is available regarding the AS’s business model, however; the operators accept only Bitcoin payments.
5.3 MikroTik CVE-Related Attacks
We have identified 3,441 attacks related to CVEs of MikroTik devices. The attacks represent only 0.02% of the total number of flows collected. Although the attacks represent a very small percentage of the total traffic, they were tailored to MikroTik devices. That means that the attacks would have caused more damage to real devices and their users than generic attacks.
The most popular attack vector that we observed was ‘directory transversal’ attack (related to CVE-2018-14847 and CVE-2019-3943). Such attacks enable attackers to access restricted files and directories within the router. By investigating the payload of the attacks, we observed that 98% of them successfully acquired the credentials of administrator accounts. The remainder sought to change the system job scheduled for executing commands. The commands involved are considered in more detail later.
In the next subsection we focus on the successful login attempts made after attackers exploited the vulnerabilities referred to (CVE-2018- 14847 and CVE-2019-3943). Although some vulnerabilities were mapped to signatures, we did not observe any attack that sought to perform remote code execution. For example, MikroTik RouterOS has two vulnerabilities that enable attackers to run arbitrary code or commands in the system (CVE-2018-7445 and CVE-2018-1156). The vulnerabilities involve the NETBIOS protocol and a specific service module triggered by a particular request to port 80/TCP.
5.4 Successful Login
Even though we used a strong and not easily guessed password (16 random letters and digits, with capital and non-capital letters), we observed 983 successful logins, depicted in Figure 6. The figure shows, for each honeypot, the distribution of services associated with successful logins (API, FTP, SSH, Web/HTTP and WinBox). In contrast to the successful logins, we also observed exhaustive attempts to log in to MikroTik-specific services. However, we did not map successful brute force attacks that used our specific password.
The honeypots hosted in the US and Brazil were the ones that were successfully compromised most often. That is interesting, since Brazil is the country with the most discoverable MikroTik devices, as pointed out in section 3.
Logins using the WinBox and HTTP interfaces were preferred by the attackers attracted to our six honeypots. The most plausible explanation for that observation is that the two protocols are the easiest for managing MikroTik devices (via a visual interface). Targeted attacks usually use automated tools to connect to the system and establish a channel with the attacker. Most such tools used for MikroTik devices are based on WinBox or the Web API (HTTP). Attempts made using the FTP and SSH protocols provide a more restrictive interface for managing RouterOS services when compared with MikroTik protocols (e.g. WinBox).
Figure 6 also shows that the distribution of attacks is not uniform across all honeypots. For example, no login attempts were made using Telnet in India, although the method was used elsewhere. The heterogeneous distribution of authentication methods suggests multiple attack vectors, resulting in various automated tools for various attacker modi operandi. The various attack vectors are considered in the next subsection.
5.5 Successful Tunnel Creation
In the work described thus far, we observed that successful login-related attacks (subsection 5.4) occurred after the exploitation of known CVEs (subsection 5.3). Following this chain of attacks, we also observed traffic tunneling-related attacks. The usage of tunnels is a well-known technique in the context of attacks against routers. It involves attempting to redirect, intercept or deny network traffic from/to routers. In our honeypots we observed the most common tunneling protocols, Point-to-Point Tunneling Protocol (PPTP) and Simple Service Discovery Protocol (SSDP) have a similar abnormal modus operandi. The attackers first sign into the system via the WinBox protocol using the correct credentials and then set up a tunneled connection to the outside end-point for exporting traffic. We have identified 3,137 successfully established tunnels, 2,171 of them using PPTP and 966 using SSTP (See Figure 7). PPTP was the most popular. Interestingly the protocol PPTP is known for being insecure. The protocol is old and vulnerable. The traffic can easily be decrypted by malicious third parties in man-in-the-middle attacks. Unlike PPTP, SSTP uses SSL 3.0, providing a strong encryption scheme.
Figure 7 shows the distribution of tunnels across the honeypots, grouped by protocol type. In China, for example, the number of attacks using SSTP is very low compared with other regions. Since all honeypots have both services available, is up to the attacker to choose the protocol. We presume that PPTP is more popular due to easy setup (it does not require SSL configuration). In the next subsection we discuss the attribution of such attacks in detail.
Attributing Successful Tunnel Creation
In Figure 8, we depict the distribution of IP addresses relative to the tunnel endpoint country code. We observe that IP addresses located in the United States, Russia and the Netherlands represent more than 50% of all IP address exploiting traffic tunnels. An interesting case is presented in the US. Out of 664 tunnels endpoints located in US, 80% (531) of them were used only in attacks performed in the US honeypot.
With a view to shedding light on correlations with endpoints, in Figure 9, we present data on the number of times the top 15 IP address were used as tunnel endpoints. Surprisingly, 5 IP addresses are responsible for almost 50% of the total number of tunnels. The IP address 139.X.X.46 was used as an endpoint in all the honeypots and it was used in 116 days of analysis (out of 120 days). It is important to remember that our honeypot was rebuilt/re-initiated every day, forcing an attacker to compromise the system again to establish a tunnel.
5.6 Brute-Force Attacks and Mirai Botnet
As well as attacks tailored to MikroTik, we have investigated brute-force attacks, since MikroTik devices do not have a protection mechanism against such attacks. In the traffic that we collected in our honeypots, the SSH service (22/TCP) was most targeted by brute-force attacks, with 2,287,479 attempts. The Telnet service (23/TCP) was the second most targeted service, with 1,848,845 attempts. By analysing the IPs that were used for scanning on SSH and Telnet, we were able to observe that there is an overlap of 39%. That indicates that 39% of attacks were targeting both services.
A large subset (13%) of brute-force attacks on Telnet used a known signature of the Mirai botnet . Figure 10 shows the number of Telnet attempts by honeypot, grouped into regular brute-force attacks and attacks using the Mirai signature. While there are some variations in the number of regular attacks, the number of Mirai attacks is quite stable (bottom line). That is interesting, insofar as it reveals the level of internet noise caused by compromised IoT devices performing scans.
Mirai is an IoT malware that tries to compromise devices using brute-force attacks and turn them into bots. We observed 101,443 unique IP addresses that were infected by Mirai. Figure 11 shows the distribution of IPs performing Mirai brute-force attacks. IP addresses in China account for more than 25% of attacks. The majority of those IPs belong to Transit providers in China, such as China Telecom, Chunghwa and China Unicom. Since Mirai is tailored to IoT devices, the mapping reveals that many IoT devices operated by end-users (Transit providers) were infected and performing brute-force scans globally.
5.7 Log-Based Analysis for Validating our Observations
With the aim of validating the attack data presented in the previous sections (based on packet-based measurement) and possibly identifying other attacks, in this section we analyse the content of the system event logs from our honeypots. Table 4 summarises some of our findings.
|1||new script scheduled by admin||154|
|2||PPTP server settings changed by admin||63|
|3||L2TP server settings changed by admin||50|
|4||SSTP server settings changed by admin||38|
|5||DNS changed by admin||25|
|6||DHCP client changed||21|
|7||PPTP server settings changed||19|
|8||SSTP server settings changed||19|
|9||L2TP server settings changed||19|
|10||PPP profile <default-encryption>changed by admin||19|
The first observation is that the log files are unstructured, which makes the pattern identification process challenging. Nevertheless, from Table 4 we observe that lines 2, 3, 4, 7, 8 and 9 emphasise changes in the tunneling (discussed in subsection 5.5). The most common event in the system log (Line 1), however, involves an attacker adding a script (crontab) to allow further control of the MikroTik device. The use of scheduled scripts is considered in more detail below. Note that all the events listed in Table 4 happened after successful logins (described in subsection 5.4), which were only possible because attackers exploited known MikroTik CVEs (described in subsection 5.3).
Script scheduled: By analysing the system logs, we identified 154 events where a script was successfully scheduled on the system. To complement the analysis of such events, we also inspected the network traffic for keywords that might reveal the script scheduler. We found 30 new events that were not mapped in the system log. The explanation for that observation is that other scheduled scripts modified the device and made outside connections unavailable. Thus, we were unable to retrieve the log entries for those attacks.
A total of 184 attacks using the script scheduler were discovered. Of those, 175 used the fetch tool to download scripts and run them in the system. The scripts were downloaded from nine different websites, listed in Table 5.
None of the URLs used for downloading were still active when we performed our analysis. Evidently the URLs were created to propagate malicious software and were not third-party compromised systems.
The scheduled scripts contain multiple system actions that are executed in the attacks, besides the system actions instigated by the scripts downloaded using the fetch tool. Table 6 provides an overview of the most commonly executed system actions. The actions usually include enabling the HTTP proxy, changing the DNS and NTP servers, removing existing crontab scripts and closing API access to the router. Other actions include disabling FTP, SOCKS and the built-in packet sniffer. Finally, some attackers also created a new user to maintain easy access to the router.
Cryptocurrency mining: we identified 9 attacks that injected scripts related to cryptocurrency mining. All 9 attacks were performed from one IP address in China and involved the injection of HTML code snippets directly into the router. The code snippets were then used to inject the Coinhive cryptocurrency mining software into the webpages visited. The commands used a common modus operandi: first the attacker enables an HTTP proxy on the router. Then the attacker changes the firewall and NAT settings to redirect all traffic through the proxy. The script is then used to inject the miner into the sites. Finally, the attacker closes the FTP and SOCKS services and the built-in packet sniffer.
DNS redirection: we found several attacks where an attempt was made to change the router’s DNS server (DNS Changer attack). The aim of such an attack is to redirect users to phishing websites and malvertising . We identified 5 IP addresses that were used for such attacks. Most of them were already inactive when this analysis took place. However, one IP was still active (94.X.X.254). The IP address in question belongs to the OpenNIC  initiative. OpenNIC offers an alternative to the DNS root servers currently in use. We could not see a clear motive for the attack, other than overwriting an existing DNS domain. Furthermore, the OpenNIC IP address is classified as an open resolver and could be used in amplification attacks.
5.8 Overall Discussion
Our classification methodology has proven valuable for identifying and classifying attacks tailored to MikroTik devices. In the same way that we used signatures to classify attacks identified in offline data, signatures could be used for active blocking of such attacks. We observed that attacks targeting MikroTik devices follow a chain of problems, which always begin with failure to update MikroTik RouterOS. Since 2011, MikroTik has released a total of 138 stable versions of RouterOS.
All the current 22 CVEs could be resolved simply by updating the RouterOS version. That would, for example, mitigate the revelation of administrator credentials, thus mitigating successful logins and hence the creation of traffic tunnels and so on.
Despite the simplicity of the solution, there are thousands of MikroTik devices with old RouterOS versions. We estimate that more than two million MikroTik devices are still vulnerable to the majority of CVEs. We hope that the findings presented in this paper promote an improvement in the security status of the MikroTik device park.
6 Conclusions and Future Work
In this paper, we have examined attacks targeting MikroTik devices. To investigate such attacks, we developed an automated classification method based on network signatures and system log events. To improve the quality of the results we (1) investigated the global landscape of MikroTik devices using 120 days of data from an internet scanning service (shodan.io); (2) designed a realistic honeypot that mimics the characteristics of a MikroTik RouterOS discoverable over the internet.
To validate our approach, we deployed 6 honeypots and placed them in countries where we had established that such devices are popular. By using the honeypots for 120 days, we collected more than 44 million packets originating from 399,235 unique IP addresses. Using this dataset, we evaluated our proposed classification methodology and identified targeted attacks. In total, we identified 3,441 attempts to exploit well-known vulnerabilities and about 200,000 IPs performing brute-force attacks on our honeypots.
The majority of vulnerability exploitations involve attempting to retrieve the credentials and then use them to manage the system remotely. We have observed various actions that attackers perform on the system, including changes to the packet filter configuration and system event logs. For the authors, one of the most interesting findings is that attackers often seek to establish IP tunneling on compromised devices. They use the tunnels to redirect traffic and secretly monitor/inspect/manipulate the data. We have identified more than 3,000 successfully established tunnels on the honeypots.
The protocol most commonly used for attacks detected in our honeypots was PPTP (173/TCP), a service that is not activated by default on MikroTik devices. Surprisingly, as revealed by our investigation using data from shodan.io, port 173/TCP is the second most commonly used port on MikroTik devices worldwide (984,349 devices). That suggests that either the administrators in question are manually activating the PPTP service, or those devices have been compromised. That question requires further investigation.
In the research described in this paper, only attacks on low-cost MikroTik routers were analysed. In future research, honeypots simulating other brands of low-cost router could be used to discover if there are differences in the characteristics of attacks aimed at different vendors’ products. In the context of any future investigation, consideration should be given to placing honeypots primarily on an access network where a different class of attack might be mapped.
This research was supported partly by EC H2020 GA 830927 (CONCORDIA project) and by SIDN Fund 174058 (DDoSDB project). We are particularly grateful to John Matherly of Shodan.io, who promptly provided us with a unique dataset.
-  US-CERT. Russian state-sponsored cyber actors targeting network infrastructure devices. (ta18-106a)). https://www.us-cert.gov/ncas/alerts/TA18-106A, August 2018. Accessed on 20 September 2019.
-  US-CERT. The increasing threat to network infrastructure devices and recommended mitigations. https://www.us-cert.gov/ncas/alerts/TA16-250A, August 2016. Accessed on 20 September 2019.
-  Norton Symantec. VPNFilter malware now targeting even more router brands. How to check if you’re affected. https://us.norton.com/internetsecurity-emerging-threats-vpnfilter-malware-targets-over-500000-routers.html, 2018.
-  The Federal Bureau of Investigation (FBI). Foreign cyber actors target home and office routers and networked devices worldwide. https://www.ic3.gov/media/2018/180525.aspx, 2018.
-  Catalin Cimpanu. Brazil is at the forefront of a new type of router attack. https://www.zdnet.com/article/brazil-is-at-the-forefront-of-a-new-type-of-router-attack/, 2019.
-  CERT.br. New national initiatives. https://www.cert.br/docs/palestras/certbr-natcsirts2019.pdf, 2019.
-  Antonio Gonzalez Pastana Lobato, Martin Andreoni Lopez, Igor Jochem Sanz, Alvaro A Cardenas, Otto Carlos MB Duarte, and Guy Pujolle. An adaptive real-time architecture for zero-day threat detection. In 2018 IEEE international conference on communications (ICC), pages 1–6. IEEE, 2018.
Rodrigo Do Carmo, Mohamed Nassar, and Olivier Festor.
Artemisa: An open-source honeypot back-end to support security in VoIP domains.In 12th IFIP/IEEE International Symposium on Integrated Network Management, 2011.
-  Mohamed Nassar, Radu State, and Olivier Festor. VoIP honeypot architecture. In 2007 10th IFIP/IEEE International Symposium on Integrated Network Management, 2007.
-  Jérôme François, Shaonan Wang, Thomas Engel, et al. BotTrack: tracking botnets using NetFlow and PageRank. In International Conference on Research in Networking, 2011.
-  Anna Sperotto, Gregor Schaffrath, Ramin Sadre, Cristian Morariu, Aiko Pras, and Burkhard Stiller. An overview of ip flow-based intrusion detection. IEEE communications surveys & tutorials, 12(3):343–356, 2010.
-  João M. Ceron. Mikrotik exposed project website. https://mikrotik-exposed.org/, 2020.
-  Marcus Niemietz and Jörg Schwenk. Owning your home network: Router security revisited. arXiv, June 2015.
-  Muhammad Mujtaba and Priyadarsi Nanda. Analysis of bgp security priyadarsi nanda. In Proceedings of the 9th Australian Information Security Management Conference, pages 204–214, December 2011.
-  Abdallah Ghourabi, Tarek Abbes, and Adel Bouhoula. Honeypot router for routing protocols protection. In 2009 Fourth International Conference on Risks and Security of Internet and Systems, pages 127–130, October 2009.
-  Muhammad Itqan Mazdadi, Imam Riadi, and Ahmad Luthfi. Live Forensics on RouterOS using API Services to Investigate Network Attacks. International Journal of Computer Science and Information Security, 15:406–410, February 2017.
-  Jacob Baines. Help me, vulnerabilities you’re my only hope. https://github.com/tenable/routeros/blob/master/slides/defcon_27_cleaner_wrasse.pdf, 2019.
-  Pavol Sokol and Maros Andrejko. Deploying honeypots and honeynets: Issues of liability. In International Conference on Computer Networks, pages 92–101. Springer, May 2015.
-  Christopher Hecker, Kara L. Nance, and Brian Hay. Dynamic honeypot construction. In Proceedings of the 10th Colloquium for Information Systems Security Education, pages 95–102, June 2006.
-  MikroTik. Mikrotik documentation–manual:ip/services. https://wiki.mikrotik.com/wiki/Manual:IP/Services, 2019.
-  Jacob Baines. Results scanner port 8291. https://github.com/tenable/routeros/blob/master/8291_scanner/results/8291_results_06292019.zip, 2019.
-  Bernhard A. Koch. The ”principles of european tort law”. In ERFA Forum, volume 8, pages 107–124. Springer, March 2007.
-  MikroTik Routeros Security Vulnerabilities. https://www.cvedetails.com/vulnerability-list/vendor_id-12508/product_id-23641/Mikrotik-Routeros.html, 2019. Accessed on 29 April 2019.
-  Tenable Research. [R1] MikroTik RouterOS Multiple Authenticated Vulnerabilities. https://www.tenable.com/security/research/tra-2018-21, August 2018. Accessed on 30 April 2019.
-  Tenable Research. Mikrotik routeros winbox parser. https://github.com/tenable/routeros/tree/master/pcap_parsers/winbox_pcap_parser, April 2019. Accessed on 30 August 2019.
-  Tenable Research. Mikrotik routeros winbox parser. https://github.com/tenable/routeros/tree/master/pcap_parsers/jsproxy_pcap_parser, April 2019. Accessed on 30 August 2019.
-  João M. Ceron, Klaus Steding-Jessen, Cristine Hoepers, Lisandro Zambenedetti Granville, and Cíntia Borges Margi. Improving iot botnet investigation using an adaptive network layer. Sensors, February 2019.
-  Wei Meng, Ruian Duan, and Wenke Lee. Dns changer remediation study. Talk at M3AAWG 27th, 2013.
-  Balaji N. New dns hijacking attack exploiting dlink routers to target netflix, paypal, uber, gmail users. https://gbhackers.com/new-dns-hijacking-attack/, April 2019. Accessed on 22 May 2019.