F5 Labs analyzes threats and attacks based on multiple diverse data sources, one being the F5 Security Operations Center (SOC), which provides F5 Silverline DDoS mitigation services to customers and clients. The SOC recently stopped a large DDoS attack that peaked at over 840 Gbps against a financial services institution. The organization shared its data with F5 Labs so we could provide insights into large-scale DDoS attacks. Our analysis showed some interesting data about what a recent large DDoS attack looks like and how it was sourced:
- Peak traffic was 840 Gbps.
- Clients from 42 different countries experienced the attack.
- Attackers used a combination of SYN flooding, RST flooding, UDP reflection, and ICMP flooding.
- Client platforms ranged from embedded systems and Windows machines to Linux servers.
Sudden and Large
On Monday, June 21, 2021, at 3:04 AM Coordinated Universal Time (UTC), the SOC detected the start of a large DDoS attack against a target in the financial services industry. During the attack, legitimate traffic pass-through remained at normal levels, about 25 Mbps. At its highest peak, the attack caused 33,599 times the normal amount of traffic.
Eight Minutes and Two Peaks
After the start of the attack, traffic rose rapidly over the next two minutes to the first peak at approximately 400 Gbps. It then fell off to 125 Gbps, until about 3:07 AM UTC, when it ramped up again, sharply, to a second peak of 840 Gbps by 3:10 AM UTC. A minute and a half later, it returned to normal levels (Figure 1).
The two peaks appeared to be caused by the attackers targeting the company’s domain name, rather than a specific IP address. The customer uses a round robin DNS system with two IP addresses, each with a 90-second TTL (time-to-live). As the attackers’ DNS resolutions shifted with the round robin, for a brief period both IP addresses were attacked simultaneously, which corresponds to the second peak.
We may speculate that this effect is due to the attackers using tools that were multithreaded, and as the DNS result changed, the number of threads increased, but this is not something we can prove.
Standard Attacks—Just a Lot of Them
The attack traffic was quite pedestrian in its content. Attackers used a combination of TCP and UDP vectors, with TCP vectors including both SYN and RST flooding. UDP vectors were primarily DNS request reflections. Additionally, we observed some ICMP traffic, which the attackers may not have actually generated but was a side effect of the other traffic.
Other than dealing with the scale of the attack, straightforward mitigations were used by the SOC to protect the customer: blocking UDP at the edge network, and using a combination of various TCP flood protections, some purely volume based, some using standard SYN cookie techniques, and some tracking specific client traffic on a per-client basis.
Client Analysis
The attack traffic was observed in several Silverline datacenters around the world. This indicates that the traffic came from many different devices in many different countries and used typical Internet routing to reach the target.
F5 Labs, with the help of Silverline staff, retrieved a small sample of attacking IP addresses to investigate this attack further. While the data set we obtained was quite small (only 282 unique IP addresses) it nevertheless revealed some interesting information. It is important to note that this small data sample was limited to the IP addresses that appeared on specific device logs in Silverline’s infrastructure. It is likely that our sample is less than 0.1% of the total number of attacking IP addresses. No data is available for UDP-based traffic, since that traffic was mitigated prior to the network position where this sample was gathered.
In terms of the number of connections these 282 IP addresses showed, the data again is quite limited. We observed 1,304 TCP connections and 680 ICMP connections over the course of the attack time period.
Unity and Diversity
The top 10 countries by total traffic were the United States, China, South Korea, Germany, the Netherlands, Taiwan, Japan, the United Kingdom, Hong Kong, and Australia, which accounted for 80.6% of the traffic observed (Figure 2). These are all countries with robust and modern Internet connectivity.
The other 19.4% of the traffic observed was much more diverse. It included traffic from several countries in Western and Eastern Europe but also traffic from such rarities as Botswana, Kazakhstan, Iran, Iraq, Namibia, and Rwanda (see Figure 3).
Similar patterns were observed in the number of unique IP addresses from each country, with very nearly the same top 10 countries accounting for 77.3% of the attacking IP addresses (Figure 4) and the other 22.7% coming from a similarly diverse set of other nations (Figure 5).
We looked at the netblock owners for the specific IP addresses we analyzed and found that the majority of the attacking IP addresses were part of netblocks owned by “MICROSOFT-CORP-MSN-AS_BLOCK,” with a total of 47 IP addresses (16.6%). In total, over 102 different netblock owners were present, and 63 of those involved only one IP address.
What We Know About the Client IP Addresses
We managed to research many of the attacking IP addresses. Although quite a few had gone offline or were lacking information, we were able to break them down a bit further. Of the IP addresses for which we could obtain further data, eight were identified as Linux, two as Windows 7 or 8, one as a Windows Server 2008 instance, and 35 as “MikroTik RouterOS 6.44.1.”
While this is by no means a comprehensive, or even very accurate, sample, it did lead us to speculate that the attackers were using some specific vulnerability in MikroTik RouterOS. The version of the MikroTik RouterOS seen here has several publicly available vulnerabilities that could possibly lead to compromise under the right circumstances. However, it is also very possible that the attackers simply used authentication brute force against open ports, or some combination of the two, to compromise these devices. For those interested in further investigating this vector, we recommend the 2020 paper “Characterising Attacks Targeting Low-Cost Routers: A MikroTik Case Study (Extended).”1
Conclusion
In this specific, real-world example, a large DDoS attack was observed to use standard, known techniques, ostensibly because such techniques still work quite well. The collection of attacking IP addresses was formed from devices from around the world, likely a botnet created mainly from client computers, router software, and occasional servers.
This leads us to conclude that for the organizers of this botnet, the Internet is “flat,” that is, the devices don’t matter much, nor do the capabilities of the individual devices or even the overall Internet infrastructure present. Instead, it is merely a matter of scale—as many devices as possible, regardless of their characteristics or location.
That such an approach can generate a coordinated attack of nearly a terabit a second should give us all pause. The scale of attacks and their frequency is rising (see DDoS Attack Trends for 2020) and will likely continue to grow.
Recommendations
F5 Labs recommends the following techniques at a minimum to address DDoS.
- Track levels of traffic to establish a baseline.
- Set up an alert for unusual traffic (high amounts of TCP RST, for example).
- For common DDoS vectors, review what mitigations you have available.
- Consider using third-party services to provide additional bandwidth and mitigation capabilities.
