Amplification attacks are one of the most common distributed denial of service (DDoS) attack vectors. These attacks are typically categorized as flooding or volumetric attacks, where the attacker succeeds in generating more traffic than the target can process, resulting in exhausting its resources due to the amount of traffic it receives. In this blog, we start by surveying the anatomy and landscape of amplification attacks, while providing statistics from Azure on most common attack vectors, volumes, and distribution. We then describe some of the countermeasures taken in Azure to mitigate amplification attacks. ## DDoS amplification attacks, what are they? Reflection attacks involve three parties: an attacker, a reflector, and a target. The attacker spoofs the IP address of the target to send a request to a reflector (e.g., open server, middlebox) that responds to the target, a virtual machine (VM) in this case. For the attack to be amplified the response should be larger than the request, resulting in a reflected amplification attack. The attacker’s motivation is to create the largest reflection out of the smallest requests. Attackers achieve this goal by finding many reflectors and crafting the requests that result in the highest amplification. ![The diagram illustrates how the attacker pushes a reflection attack to a target virtual machine that is hosted in Azure.](https://www.microsoft.com/security/blog/uploads/securityprod/2022/05/figure-1b-reflected-amplification-attack.png)Figure 1. Reflected amplification attack The root cause for reflected amplification attacks is that an attacker can force reflectors to respond to targets by spoofing the source IP address. If spoofing was not possible, this attack vector would be mitigated. Lots of effort has thus been made on disabling IP source address spoofing, and many organizations prevent spoofing nowadays so that attackers cannot leverage their networks for amplification attacks. Unfortunately, a significant number of organizations still allow source spoofing. The [Spoofer project]() shows that a third of the IPv4 autonomous systems allow or partially allow spoofing. ## UDP and TCP amplification attacks Most attackers utilize UDP to launch amplification attacks since reflection of traffic with spoofed IP source address is possible due to the lack of proper handshake. While UDP makes it easy to launch reflected amplification attacks, TCP has a 3-way handshake that complicates spoofing attacks. As a result, IP source address spoofing is restricted to the start of the handshake. Although the TCP handshake allows for reflection, it does not allow for easy amplification since TCP SYN+ACK response is not larger than TCP SYN. Moreover, since the TCP SYN+ACK response is sent to the target, the attacker never receives it and can’t learn critical information contained in the TCP SYN+ACK needed to complete the 3-way handshake successfully to continue making requests on behalf of the target. ![The diagram illustrates how an attacker conducts a reflection attack in TCP. The attacker sends through SYN, then the reflector reflects packets restransmitted through SYN + ACK combination, which then sends an out-of-state SYN + ACK attack to the target virtual device.](https://www.microsoft.com/security/blog/uploads/securityprod/2022/05/figure-2b-reflection-attack-in-tcp.png)_Figure 2. Reflection attack in TCP _ In recent years, however, reflection and amplification attacks based on TCP have started emerging. Independent research found [newer TCP reflected amplification vectors]() that utilize middleboxes, such as nation-state censorship firewalls and other deep packet inspection devices, to launch volumetric floods. Middleboxes devices may be deployed in asymmetric routing environments, where they only see one side of the TCP connection (e.g., packets from clients to servers). To overcome this asymmetry, such middleboxes often implement non-compliant TCP stack. Attackers take advantage of this misbehavior - they do not need to complete the 3-way handshake. They can generate a sequence of requests that elicit amplified responses from middleboxes and can reach infinite amplification in some cases. The industry has started witnessing these kinds of attacks from censorship and enterprise middle boxes, such as firewalls and IDPS devices, and we expect to see this trend growing as attackers look for more ways to create havoc utilizing DDoS as a primary weapon. Carpet bombing is another example of a reflected amplification attack. It often utilizes UDP reflection, and in recent years TCP reflection as well. With carpet bombing, instead of focusing the attack on a single or few destinations, the attacker attacks many destinations within a specific subnet or classless inter-domain routing (CIDR) block (for example /22). This will make it more difficult to detect the attack and to mitigate it, since such attacks can fly below prevalent baseline-based detection mechanisms. ![This diagram shows how an attacker uses reflectors to send spoofed packets to many target devices within a specific subnet hosted in Azure.](https://www.microsoft.com/security/blog/uploads/securityprod/2022/05/figure-3b-carpet-bombing.png)_Figure 3. Carpet bombing attack _ One example of TCP carpet bombing is TCP SYN+ACK reflection, where attacker sends spoofed SYN to a wide range of random or pre-selected reflectors. In this attack, amplification is a result of reflectors that retransmit the TCP SYN+ACK when they do not get a response. The amplification of the TCP SYN+ACK response itself may not be large, and it depends on the number of retransmissions sent by the reflector. In Figure 3, the reflected attack traffic towards each of the target virtual machines (VMs) may not be enough to bring them down, however, collectively, the traffic may well overwhelm the targets’ network. ## UDP and TCP amplification attacks in Azure In Azure, we continuously work to mitigate inbound (from internet to Azure) and outbound (from Azure to internet) amplification attacks. In the last 12 months, we mitigated approximately 175,000 UDP reflected amplification attacks. We monitored more than 10 attack vectors, where the most common ones are NTP with 49,700 attacks, DNS with 42,600 attacks, SSDP with 27,100 attacks, and Memcached with 18,200 attacks. These protocols can demonstrate amplification factors of up to x4,670, x98, x76 and x9,000 respectively. ![This pie chart shows the volume of UDP- reflected amplification attacks observed in Azure from April 1, 2021, to March 31, 2022. The highest volume observed is 28% through NTP, while the least volume observed is 2% through Open VPN.](https://www.microsoft.com/security/blog/uploads/securityprod/2022/05/Fig4b-UDP-reflected-amplication-attacks-1024x572.png)_Figure 4. UDP reflected amplification attacks observed from April 1, 2021, to March 31, 2022_ We measured the maximum attack throughput in packets per second for a single attack across all attack vectors. The highest throughput was a 58 million packets per second (pps) SSDP flood in August last year, in a short attack campaign that lasted 20 minutes on a single resource in Azure. ![This bar chart shows the packets per second flooding observed from April 1, 2021, to March 31, 2022 in Azure. The tallest bar represents the maximum observed throughput of 58 million packets per second SSDP flooding, while the shortest bar represents below 10M packets per second CharGEN flooding.](https://www.microsoft.com/security/blog/uploads/securityprod/2022/05/Fig5b-Maximum-pps-single-attack-1024x534.png)_Figure 5. Maximum pps recorded for a single attack observed from April 1, 2021, to March 31, 2022 _ TCP reflected amplification attacks are becoming more prevalent, with [new attack vectors discovered](). We encounter these attacks on Azure resources utilizing diverse types of reflectors and attack vectors. One such example is a TCP reflected amplification attack of TCP SYN+ACK on an Azure resource in Asia. Attack reached 30 million pps and lasted 15 minutes. Attack throughput was not high, however there were approximately 900 reflectors involved, each with retransmissions, resulting in a high pps rate that can bring down the host and other network infrastructure elements. ![This line chart shows the TCP SYN+ACK amplification attack volume on a single resource as seen on Azure. The line chart shows a spike reaching 30 million packets per second with a 15 minute duration. The 15-minute window illustrates the packets per second volume going down in the middle of the 15-minute window, and tapers off abruptly at the end of the 15-minute window.](https://www.microsoft.com/security/blog/uploads/securityprod/2022/05/Fig6-TCP-SYN-ACK-amplification-attack-628bc049edfcc.png)_Figure 6. TCP SYN+ACK amplification attack volume on an Azure resource in Asia_ We see many TCP SYN+ACK retransmissions associated with the reflector that doesn’t get the ACK response from the spoofed source. Here is an example of such a retransmission: ![This screenshot shows a TCP SYN+ACK retransmission that doesn't get the ACK response. The screenshot highlights the information from source to destination and through which protocol it passes.](https://www.microsoft.com/security/blog/uploads/securityprod/2022/05/Fig6b.png) The retransmitted packet was sent 60 seconds after the first. ## Mitigating amplification attacks in Azure Reflected amplification attacks are here to stay and pose a serious challenge for the internet community. They continue to evolve and exploit new vulnerabilities in protocols and software implementations to bypass conventional countermeasures. Amplification attacks require collaboration across the industry to minimize their effect. It is not enough to mitigate such attacks at a certain location, with a pinpoint mitigation strategy. It requires intertwining of network and DDoS mitigation capabilities. Azure’s network is one of the largest on the globe. We combine multiple DDoS strategies across our network and DDoS mitigation pipeline to combat reflected amplification DDOS attacks. On the network side, we continuously optimize and implement various traffic monitoring, traffic engineering and quality of service (QoS) techniques to block reflected amplification attacks right at the routing infrastructure. We implement these mechanisms at the edge and core of our wide area networks (WAN) network, as well as within the data centers. For inbound traffic (from the Internet), it allows us to mitigate attacks right at the edge of our network. Similarly, outbound attacks (those that originate from within our network) will be blocked right at the data center, without exhausting our WAN and leaving our network. On top of that, our dedicated DDoS mitigation pipeline continuously evolves to offer advanced mitigation techniques against such attacks. This mitigation pipeline offers another layer of protection, on top of our DDoS networking strategies. Together, these two protection layers provide comprehensive coverage against the largest and most sophisticated reflected amplification attacks. Since reflected amplification attacks are typically volumetric, it is not only enough to implement advanced mitigation strategies, but also to maintain a highly scalable mitigation pipeline to be able to cope with the largest attacks. Our mitigation pipeline can mitigate more than 60Tbps globally, and we continue to evolve it by adding mitigation capacity across all network layers. ## Different attack vectors require different treatment UDP-based reflected amplification attacks are tracked, monitored, detected, and mitigated for all attack vectors. There are various mitigation techniques to combat these attacks, including anomaly detection across attacked IP addresses, L4 protocols, and tracking of spoofed source IPs. Since UDP reflected amplification attacks often create fragmented packets, we monitor IP fragments to mitigate them successfully. TCP-based reflected amplification attacks take advantage of poor TCP stack implementations, and large set of reflectors and targets, to launch such attacks. We adopt our mitigation strategies to be able to detect and block attacks from attackers and reflectors. We employ a set of mitigations to address TCP SYN, TCP SYN+ACK, TCP ACK, and other TCP-based attacks. Mitigation combines TCP authentication mechanisms that identify spoofed packets, as well as anomaly detection to block attack traffic when data is appended to TCP packets to trigger amplification with reflectors. ![The diagram shows how Azure uses mechanisms to stop amplification attacks as soon as a packet leaves a reflector or an attacker. Azure stops spoofed attacks in the following areas: 1. Attacks coming from an attacker-controlled reflector or direct from the attacker that is located outside Azure-protected space, with the attacks going to a target virtual machine or a reflector located inside a Azure; 2. Attacks coming from an attacker located within the Azure-protected space, and the attack is going to the reflector device outside of Azure, or an attack going through a reflector device to target another virtual machine.](https://www.microsoft.com/security/blog/uploads/securityprod/2022/05/figure-7b-amplification-attack-detection.png)_Figure 7. Amplification attack detection _ ## Get started with Azure DDoS Protection to protect against amplification attacks Azure’s DDoS mitigation platform mitigated the [largest ever DDoS attacks]() in history by employing a globally distributed DDoS protection platform that scales beyond 60Tbps. We ensure our platform and customers’ workloads are always protected against DDoS attacks. To enhance our DDoS posture, we continuously collaborate with other industry players to fight reflected amplification attacks. Azure customers are protected against Layer 3 and Layer 4 DDoS attacks as part of protecting our infrastructure and cloud platform. However, Azure DDoS Protection Standard provides comprehensive protection for customers by auto-tuning the detection policy to the specific traffic patterns of the protected application. This ensures that whenever there are changes in traffic patterns, such as in the case of flash crowd event, the DDoS policy is automatically updated to reflect those changes for optimal protection. When a reflected amplification attack is launched against a protected application, our detection pipeline detects it automatically based on the auto-tuned policy. The mitigation policy, that is automatically set for customers, without their need to manually configure or change it, includes the needed countermeasures to block reflected amplification attacks. Protection is [simple to enable]() on any new or existing virtual network and does not require any application or resource changes. Our recently released [Azure built-in policies]() allow for better management of network security compliance by providing great ease of onboarding across all your virtual network resources and configuration of logs. To strengthen the security posture of applications, Azure’s network security services can work in tandem to secure your workloads, where DDoS protection is one of the tools we provide. Organizations that pursue zero trust architecture can [benefit from our services]() to achieve better protection. ## Learn more about Azure DDoS Protection Standard * Azure DDoS Protection [product page](). * Azure DDoS Protection Standard [documentation](). * Azure DDoS Protection Standard [reference architectures](). * DDoS Protection [best practices](). * Azure DDoS [Rapid Response](). * Protect your [on-premises resources](). _**Amir Dahan** and **Syed Pasha** Azure Networking Team_ ## References 1 [The Spoofer project]() 2 [Weaponizing Middleboxes for TCP Reflected Amplification]() The post [Anatomy of a DDoS amplification attack]() appeared first on [Microsoft Security Blog]().

Query Builder