ASERT Threat Summary

Date: November 16, 2021
Severity: Warning
Distribution: TLP: WHITE 
Categories: Availability
Contributors: Chris Conrad, Jon Belanger, John Kristoff, Bill McDonough, Marco Gioanola, Chad Robertson, Alexander Lyamin.

Executive Summary

In September of 2021, internet security firm QRator published a weblog post describing an Internet of Things (IoT) botnet consisting of compromised Mikrotik routers which, beginning in June of 2021, have been used to launch several high-profile HTTP and HTTPs-based application-layer DDoS attacks. These DDoS attacks are notable for their use of HTTP pipelining (which allows multiple HTTP requests to be made over a single TCP connection), as well as for their relatively high attack volumes of several million HTTP and/or HTTPs requests-per-second (RPS). QRator named this botnet Mēris, which is the Latvian word for plague.
Subsequent to the initial reports of the Mēris botnet, NETSCOUT's ASERT determined that a second, distinct DDoS-capable IoT botnet is also present in the same general population of unpatched, exploitable Mikrotik routers. This second Mikrotik-based IoT botnet has been dubbed Dvinis, which is the Latvian word for twin.
To date, HTTP and HTTPs application-layer DDoS attacks appear to be the sole attack vectors employed by these botnets. It is unclear whether either bots have the capability to launch additional types of DDoS attacks.

Note: Observed HTTP and HTTPs DDoS attacks originating from the Dvinis botnet do not make use of HTTP pipelining, and that there is a distinctive double-‘//’ at the end of targeted URIs in Dvinis-generated synthetic DDoS attack traffic.

Key Findings

• Both Mēris and Dvinis take advantage of the same population of exploitable Mikrotik routers to exist and thereby launch DDoS attacks.
• These bots differ from each other in the use of HTTP Pipelining, as well as what the bot configures on the compromised Mikrotik router as noted in our previous blog, A Tale of Two Botnets.
• Mēris and Dvinis can both be mitigated using industry Best Current Practices (BCPs) and by disabling HTTP Pipelining on applicable devices and practicing good network hygiene to eliminate exploitable Mikrotik devices from networks.

Analysis

While the reported attacks associated with Mēris were not trivial in terms of volume, none of then have achieved high water marks or record-breaking numbers from NETSCOUTs observations and DDoS attacks launched by both the Mēris and Dvinis botnets have been successfully mitigated by network operators. The total numbers of Mēris and Dvinis nodes, as well as the potential number of exploitable Mikrotik routers which can potentially be compromised and subsumed into the these botnets, are unclear at this time. However, ~4,800 Mēris bots and ~3,500 Dvinis bots have been observed actively participating in DDoS attacks against our customers.

In a related weblog post, Mikrotik stated that the exploitable routers which have been incorporated into these botnets are representative of an older population of devices which were previously compromised in 2018.

Collateral Impact

High-volume DDoS attacks can congest peering, transit, core, distribution, and access links, disrupting bystander internet traffic along with legitimate traffic destined for the intended target. Shared networking, computing, storage, and ancillary supporting infrastructure can be negatively impacted. These factors can result in significant collateral damage footprints.

The collateral impact of DDoS attacks launched via the Mēris and Dvinis botnets can be significant for unknowing operators of the compromised Mikrotik routers which comprise the botnet. Legitimate network traffic sourced from or destined to networks within the coverage cone of these botted routers can be negatively impacted under such circumstances. Account credentials and other sensitive information passing through compromised routers may be stolen and leveraged by attackers.

Failure to remove or remediate compromised routers which are abused to launch DDoS attacks can lead to affected network operators filtering all network traffic originating from networks where such systems are deployed. Unintentional overblocking of legitimate network traffic can occur when insufficiently granular mitigation methods are employed. Such overblocking must be evaluated in the light of actions necessary to bring about partial service recovery of targeted servers/applications/services/networks.

Mitigating Factors

DDoS attack traffic can be mitigated via the implementation of industry-standard best current practices (BCPs) such as situationally-appropriate network access control policies; network infrastructure-based reaction mechanisms such as flowspec; and intelligent DDoS mitigation systems (IDMS's) such as NETSCOUT Arbor Sightline, TMS, and AED/APS.

Collateral impact to abusable, botted routers can motivate network operators and/or end-customers to remove or remediate affected systems.

HTTP and HTTPs application-layer DDoS attack traffic can be mitigated via the implementation of industry-standard BCPs such as situationally-appropriate network access control policies, network infrastructure-based reaction mechanisms such as flowspec, and IDMS's such as NETSCOUT Arbor Sightline, TMS, and AED.
Due to their requirement for the establishment of a full TCP three-way handshake, DDoS attacks utilizing these specific vectors cannot be spoofed, which allows source-based mitigation mechanisms to be employed by defenders. 

HTTP pipelining is not supported by any current mainstream Web browsers, and such traffic may generally be filtered by defenders unless it is being used in the context of customized applications and/or services. Additionally, HTTP pipelining may generally be disabled on most Web servers, load balancers, revers proxies, and other relevant systems unless it it being used in specific contexts such as those described above.

Recommended Actions

Network operators should perform reconnaissance to identify and remove or remediate abusable Mikrotik routers deployed on their networks and/or the networks of their customers. In their initial weblog post describing the Mēris botnet, Internet security company Qrator included instructions for identifying potentially-compromised Mikrotik devices; Mikrotik also posted details of vulnerable software versions. The NETSCOUT ASERT weblog post provides further classifiers for identifying Mēris and Dvinis botnet nodes.

All relevant network infrastructure, architectural and operational BCPs should be implemented by network operators. 

HTTP pipelining should be disabled on Web servers, load balancers, reverse proxy servers, and other applicable systems which do not utilize it for specific, bespoke applications/services.

Organizations with business-critical public-facing internet properties should ensure that all relevant network infrastructure, architectural and operational BCPs have been implemented, including situationally-specific network access policies which only permit internet traffic via required IP protocols and ports. Deconflation of internet traffic associated with internet servers/services/applications from internet traffic generated by users on access networks is strongly recommended. Likewise, traffic originated by internet-facing servers which is unrelated to serving incoming requests (DNS lookups, outbound file transfers, etc.) should be sourced from separate interfaces and IP addresses from those used to service incoming application-/service-related traffic.

DDoS defenses for all public-facing internet properties and supporting infrastructure should be implemented in a situationally-appropriate manner, including periodic testing to ensure that any changes to organization’s servers/services/applications are incorporated into its DDoS defense plan. Organic, on-site intelligent DDoS mitigation capabilities should be combined with cloud or transit-based upstream DDoS mitigation services in order to ensure maximal responsiveness and flexibility during an attack.

It is imperative that organizations operating mission-critical public-facing internet properties and/or infrastructure ensure that all servers/services/application/datastores/infrastructure elements are protected against DDoS attack, and are included in periodic, realistic tests of the organization’s DDoS mitigation plan. In many instances, we have encountered situations in which obvious elements such as public-facing Web servers were adequately protected, but authoritative DNS servers, application servers, and other critical service delivery elements were neglected, thus leaving them vulnerable to attack.

If deemed necessary, flowspec can potentially be used in some circumstances to mitigate HTTP and HTTPs application-layer DDoS attacks, but it is important to ensure that reaction access-control list (ACL) stanzas are configured in such a way to minimize the risk of overblocking. In the context of this specific attack vector, the use of IDMS's such as NETSCOUT's TMS or AED is preferred in order to allow for more granular attack traffic mitigation.

All potential DDoS attack mitigation measures described in this Summary *MUST* be tested and customized in a situationally-appropriate manner prior to deployment on production networks.

Applicable NETSCOUT Arbor Solutions: Arbor Sightline, Arbor TMS, Arbor AED, Arbor Cloud

References

https://www.netscout.com/blog/asert/tale-two-botnets
https://blog.qrator.net/en/meris-botnet-climbing-to-the-record_142/
https://blog.mikrotik.com/security/meris-botnet.html
https://en.wikipedia.org/wiki/HTTP_pipelining
https://www.netscout.com/product/arbor-sightline
https://www.netscout.com/product/arbor-threat-mitigation-system
https://www.netscout.com/product/arbor-aed-aem

ASERT Threat Summary: Mēris and Dvinis DDoS Botnets, Mitigation Recommendations - November 2021 - v1.0