In late June 2021, QRaptor and Yandex discovered an active botnet behind a series of worldwide DDoS attacks, named Meris (Latvian for plague). The botnet would quickly become famous for the sheer load of requests per second it was able to generate. According to Cloudflare, Meris was capable of a 17.2M requests per second throughput. At that time, MikroTik devices were being compromised and turned into bots using the infamous and all-powerful CVE-2018-14847 which we still see used in the wild on a daily basis—despite the patch being released in 2018. At its peak, Meris was estimated to have compromised over 230,000 devices.
In September 2021, Rostelecom announced they had “sinkholed” part of the Meris botnet. However, in early March 2022, Imperva wrote a blog about a DDoS attack reaching 2.5M requests per second apparently claimed by the notorious ransomware group REvil. According to Imperva, it is highly likely the Meris botnet was used to carry out this DDoS attack. With the supposed re-emergence of Meris we are left to wonder, has Meris survived the sinkhole?
Nozomi Networks researchers conducted further analysis to uncover the core of the Meris botnet capabilities and began connecting the dots. From roughly 2018-2021 the Glupteba botnet, the backbone of Meris botnet, has been used to infect and turn hundreds of thousands of MikroTik devices (routers, switchers, etc.) into nefarious internet relays. One of the main Glupteba modules used is called WindiGo (aka RanaumBot), which uses the Winbox payload, a proprietary protocol used to configure MikroTik devices. Since Winbox is the root of Meris, it makes sense to take a deeper dive into its functionality. In this blog, we give a technical analysis of WindiGo and how it exploits CVE-2018-14847 to access MikroTik routers, provide recommendations, and share Indicators of Compromise (IoCs) you can use to protect your networks.
WindiGo Port Scanning
Upon execution, WindiGo starts by scanning networks to find MikroTik devices with an accessible Winbox port (8291/tcp). Because Winbox is a MikroTik proprietary protocol used to configure MikroTik devices, it uses the Winbox application, which is a configuration frontend. While conducting our analysis, we identified four different scanning behaviors in the following samples:
- c4ea89b8795bd7ee97594ca62e1e9c5189e338ba1765a819cf54bd2f89922768
- 5191548b8edf4b98e623f055f5205e2db17aa220c28928b1da1c3a9ba1a75ee0
- 9d790a4377414a1e96b329fbf7741e90c8c8099d5e5996d718f663a79bb43037
- 7f3f983368989fdd9216cdd6b5a6c6063442cf3dbed5b4055b47b04ccb2fbdbb
The first variant randomly scans 4096 IP addresses. The second variant scans the private network classes A, B and C but also the Internet Assigned Numbers Authority (IANA) reserved address space 100.64.0.0/10, which is likely an attempt to compromise Internet Service Providers (ISPs) and other service provider systems from within their perimeter.
The third variant scans some public networks in addition to the private ones, most of them belonging to telecommunication companies and internet registries in the US and Europe such as AT&T, T-Mobile and RIPE; telecommunication companies in Brazil, Vietnam, and China are also being targeted. Interestingly, two network blocks stand out, the first one belongs to the United States Army Information System Command and the second to the United States Department of Defense Network Information Center.
The last variant receives the scan target by fetching /api/request-cidr?uuid=<UUID>on its Command & Control (C2) server. Figures 1,2 and 3 depict the differences in the main scanning loops.
Winbox CVE-2018-14847 Exploit
Once the scanning starts, if a network device responds to a TCP handshake on the Winbox port then the malware attempts to exploit CVE-2018-14847. This vulnerability leverages an arbitrary file read on MikroTik devices and is used to retrieve the device users’ credential store known as the user.dat file. The sample assembles Winbox packets on the fly with most of the packet data hardcoded within the sample and only small chunks dynamically patched. Figure 4 shows the first Winbox packet being sent to the device to exploit CVE-2018-14847.
As seen in Figure 5, the path traversal becomes apparent in the assembled payload, simplified to /flash/rw/store/user.dat.
Exploiting the vulnerability results in the device user.dat file containing the credential store being leaked. We can see below, in Figure 6, the credential store being acquired by the malware. This file contains the accounts registered on the device, usernames, and their encrypted passwords.
Credential Decryption
Under normal circumstances, additional steps are required to retrieve the passwords from its hashed form, typically through a dictionary or brute force attack. However, on these older MikroTik devices the password is not hashed but encrypted. First a key is derived by linking the username and some “static salt”, then the result is hashed to produce a key with which the password is XORed. We will skip the cryptography implication of this scheme and move straight to the decryption output in the malware. Figures 7 and 8 shows breaking, right after the decryption function execution, and capturing of the decrypted password on the stack.
The malware also contains its own dictionary of usernames and passwords. The dictionary is relatively small, consisting of 24 usernames and 220 passwords for a total of roughly 5,300 possible combinations. These static credentials are used if the password harvesting step fails, typically because the MikroTik router is not vulnerable. Surprisingly the stolen credentials are appended to the bottom of the dictionary as shown in Figure 9. This means that before trying the credentials stolen from the device, the malware will first try to log on using its thousands of static credentials, which is rather inefficient.
Scheduled Task Execution
At this point, the malware attempts to register a scheduled task on the device, regardless of whether the password extraction was successful or not. The first infection vector occurs via the Winbox protocol; if the infection fails for whatever reasons (wrong username and password, network communication failure, etc.) the malware fallbacks to SSH and finally to the web API. In any case, the task being added is always the same, as seen in Figure 10.
MicroTik Device Compromise
This scheduled task is executed once the device boots and then subsequently every 10 minutes. The task will attempt to download a script from the C2 and execute it on the device. These scripts would disable some management service such as Telnet and the web interface, then enable a SOCKS proxy to turn the device into an all-purpose internet relay.
At this point it is game over, the device has become a proxy server ready to be used by threat actors to carry out attacks in an anonymized way.
Recommendations
First, network routers and other network devices should not be openly connected to the internet. In this case, the attackers came from inside the network perimeter itself—so it’s important to avoid connecting management interfaces with user and application networks. Use proper network segmentation via a dedicated management network or a Zero Trust policy to provide a robust defense against such threats.
If you’re using MikroTik devices within your environment, you should make sure that they are up-to-date. The CVE-2018-14847 vulnerability was fixed by Mikrotik right after its public disclosure. Review the devices’ configurations and ensure strong passwords are being used. Remember, a fully patched device will not protect you from a weak or leaked password!
Finally, ensure you have full visibility of your entire network, by utilizing an asset management tool and an IDS. Alerts on any suspicious network connections and infiltrations will at least give you a chance to detect and mitigate the threat before it causes severe damage. This will also enable and support your security team to effectively respond to the threat.
IOCs
