Emerging UDP amplification vectors:
the protocols behind 2026's record-breaking attacks

Back to Blog

The Amplification Landscape Has Shifted

For years, DDoS mitigation discussions centered on three protocols: DNS, NTP, and memcached. These vectors are well understood, widely documented, and increasingly mitigated through operator patching and upstream filtering. But the attack landscape has not stood still. Threat actors have moved on to lesser-known UDP protocols that offer substantial amplification factors, exploit vast populations of unmanaged IoT devices, and fly under the radar of detection systems tuned exclusively for the "big three."

The numbers tell the story. In April 2025, Cloudflare mitigated a 6.5 Tbps multi-vector attack that combined SSDP, CLDAP, and ESP reflection into a single coordinated flood. None of those three protocols would have generated record-breaking volume on its own. Together, they overwhelmed transit links that had been provisioned to handle "traditional" amplification vectors. This is the new reality: attackers stack multiple mid-tier amplification protocols to achieve throughput that rivals or exceeds what memcached delivered in 2018.

This article examines five emerging and underrated amplification vectors that every network operator should understand in 2026. For each one, we cover the protocol mechanics, the amplification factor, the typical reflector population, real-world incidents, and the detection signatures you need to identify the traffic when it arrives.

WS-Discovery (UDP Port 3702)

Protocol Mechanics

Web Services Dynamic Discovery (WS-Discovery) is a multicast discovery protocol defined in the OASIS WS-Discovery specification. It allows devices on a local network to advertise and discover web services without a central registry. The protocol operates over SOAP (Simple Object Access Protocol) and uses UDP port 3702 for multicast probe and resolve messages.

When a WS-Discovery client sends a Probe message, all matching devices respond with a ProbeMatch containing their service endpoints, metadata, and device descriptions. The protocol was designed for LAN-only use, but a massive number of IoT devices expose UDP port 3702 to the public internet. IP cameras, network printers, NVRs, and smart home hubs are the primary offenders.

Amplification Factor and Reflector Population

WS-Discovery achieves an amplification factor of up to 100x. A single Probe message of approximately 100 bytes can produce a ProbeMatch response exceeding 10,000 bytes, because the SOAP/XML envelope is inherently verbose. Device descriptions include model names, firmware versions, service URIs, device UUIDs, and namespace declarations that inflate the response far beyond what a binary protocol would produce.

Shodan scans reveal over 800,000 devices with UDP port 3702 open to the internet. The majority are consumer IP cameras and NVRs manufactured by companies that ship devices with UPnP and WS-Discovery enabled by default. These devices are rarely patched and almost never firewalled. Their owners typically do not know that the devices are internet-accessible, let alone that they are being used as DDoS reflectors.

# WS-Discovery Probe (spoofed source IP)
# Sent as a unicast UDP packet to port 3702
<?xml version="1.0" encoding="utf-8"?>
<soap:Envelope xmlns:soap="http://www.w3.org/2003/05/soap-envelope"
  xmlns:wsd="http://schemas.xmlsoap.org/ws/2005/04/discovery">
  <soap:Body>
    <wsd:Probe>
      <wsd:Types>wsdp:Device</wsd:Types>
    </wsd:Probe>
  </soap:Body>
</soap:Envelope>

# Request size:    ~100 bytes (minified)
# Response size:   ~8,000-10,000 bytes (full SOAP ProbeMatch)
# Amplification:   up to 100x

Real-World Incidents

WS-Discovery amplification first appeared in large-scale attacks in late 2019 and has grown steadily since. In September 2019, Akamai reported a 35 Gbps WS-Discovery reflection attack targeting a gaming company. By 2024, WS-Discovery had become a standard component in multi-vector attack toolkits. The protocol's high amplification factor and large reflector pool make it attractive for booter services that need to generate volume cheaply.

Detection Signatures

WS-Discovery amplification traffic arrives as UDP packets from source port 3702 containing XML/SOAP payloads. The content is plain-text XML, making it easy to identify in packet captures.

• Flood of inbound UDP from source port 3702
• SOAP/XML content in the payload with WS-Discovery namespace declarations
• Packets typically 1,400 bytes (MTU-fragmented from larger SOAP responses)
• IP fragmentation is common because ProbeMatch responses exceed standard MTU
• Source IPs overwhelmingly from consumer ISP ranges and IoT device networks

# tcpdump filter for WS-Discovery amplification
$ tcpdump -nn 'udp src port 3702' -c 10
08:31:12.440 IP 45.33.21.10.3702 > 198.51.100.10.48201: UDP, length 1400
08:31:12.441 IP 103.22.45.88.3702 > 198.51.100.10.48201: UDP, length 1400
08:31:12.441 IP 61.14.233.17.3702 > 198.51.100.10.48201: UDP, length 1400

# Wireshark display filter
udp.srcport == 3702

# Look for SOAP/XML fragments in payload
$ tcpdump -nn -A 'udp src port 3702' | grep -i 'ProbeMatch'

CLDAP Reflection (UDP Port 389)

Protocol Mechanics

Connection-less Lightweight Directory Access Protocol (CLDAP) is the UDP variant of LDAP, used almost exclusively by Microsoft Active Directory for domain controller location. When a Windows machine boots or a user logs in, the machine broadcasts a CLDAP query on UDP port 389 to find the nearest domain controller. The query is small (a rootDSE search that fits in a single datagram), but the response contains the full set of Active Directory site information, supported LDAP versions, SASL mechanisms, server GUID, and domain naming contexts.

CLDAP was never intended for internet-facing use. Despite this, hundreds of thousands of Windows Server machines expose UDP port 389 to the public internet. Many of these are domain controllers in enterprise environments with misconfigured firewalls or cloud security groups that default to "allow all."

Amplification Factor and Reflector Population

CLDAP achieves an amplification factor of 56x to 70x. A 56-byte CLDAP search request produces a response of 3,100 to 3,900 bytes depending on the Active Directory configuration. Domains with longer names, more sites, or additional supported authentication mechanisms produce larger responses.

Internet-wide scans consistently find between 200,000 and 300,000 CLDAP reflectors. These are overwhelmingly Windows Server machines running Active Directory Domain Services. The reflector population has remained stubbornly stable over the past several years because the organizations running exposed domain controllers often lack the security maturity to identify and remediate the exposure.

# CLDAP rootDSE query structure
# Sent as a raw UDP packet with spoofed source IP to port 389
# BER-encoded LDAP SearchRequest:
#   baseObject: "" (rootDSE)
#   scope: base
#   filter: (objectClass=*)
#   attributes: defaultNamingContext, dnsHostName, supportedLDAPVersion...

# Request size:    ~56 bytes
# Response size:   ~3,100-3,900 bytes
# Amplification:   56-70x

Real-World Incidents

CLDAP reflection was responsible for the largest publicly disclosed DDoS attack before 2025. In February 2020, AWS Shield mitigated a 2.3 Tbps attack that used CLDAP as its primary amplification vector. The attack targeted an AWS customer and was notable for both its volume and the fact that it relied on a single amplification protocol rather than a multi-vector approach.

CLDAP has since become a staple in multi-vector campaigns. In the April 2025 attack that reached 6.5 Tbps, CLDAP was one of three reflection protocols combined to generate the aggregate volume. Attackers value CLDAP because the reflector pool is large, the devices are enterprise servers with high-bandwidth connections (unlike IoT devices on consumer broadband), and the protocol is less likely to be filtered by upstream providers than DNS or NTP.

Detection Signatures

• Flood of inbound UDP from source port 389
• BER/ASN.1 encoded LDAP SearchResultEntry data in the payload
• Response packets typically 3,000 to 4,000 bytes
• Source IPs from enterprise and cloud provider address space (Azure, AWS, on-premise data centers)
• Payload contains readable strings: domain names, "NTLM", "GSSAPI", server hostnames

# tcpdump filter for CLDAP amplification
$ tcpdump -nn 'udp src port 389' -c 10
14:28:55.901 IP 10.20.30.40.389 > 198.51.100.10.52810: UDP, length 3124
14:28:55.902 IP 172.16.0.55.389 > 198.51.100.10.52810: UDP, length 3891
14:28:55.902 IP 10.50.60.70.389 > 198.51.100.10.52810: UDP, length 3340

# Wireshark display filter
udp.srcport == 389 && ldap

# Check /proc/net/snmp for UDP receive errors (Linux)
$ cat /proc/net/snmp | grep Udp:
# A sudden spike in InDatagrams with corresponding RcvbufErrors
# indicates amplification traffic overwhelming the socket buffer

CoAP Reflection (UDP Port 5683)

Protocol Mechanics

The Constrained Application Protocol (CoAP) is a lightweight RESTful protocol designed for resource-constrained IoT devices. Defined in RFC 7252, CoAP runs over UDP port 5683 and provides a request/response model similar to HTTP but with minimal overhead. CoAP is used by sensors, actuators, smart meters, and industrial IoT devices that need machine-to-machine communication on low-power networks.

A CoAP client sends a small GET request (as few as 4 bytes for the header plus a short URI path), and the server responds with the requested resource representation. The protocol supports a .well-known/core discovery endpoint that returns a list of all resources the device exposes, along with their content types, sizes, and interface descriptions. This discovery response is the amplification payload.

Amplification Factor and Reflector Population

CoAP achieves an amplification factor of approximately 34x. A minimal CoAP GET request targeting the /.well-known/core resource is roughly 20 bytes. The response, which enumerates all available resources in CoRE Link Format, typically runs 600 to 700 bytes but can exceed 1,000 bytes on devices that expose many endpoints. Factor calculations vary by device, but 34x is the widely cited average across large-scale scans.

What makes CoAP particularly concerning is its geographic reach and the nature of its reflector population. Research has identified CoAP amplifiers in 155 countries, with approximately 4% of all known amplification-capable devices on the internet being CoAP endpoints. These devices are overwhelmingly embedded systems on wireless broadband connections: cellular IoT gateways, smart utility meters, agricultural sensors, and industrial monitoring equipment. Many are deployed in locations where physical access for patching is impractical.

# CoAP GET request for resource discovery (spoofed source IP)
# Sent as a UDP packet to port 5683
# Header: Ver=1, Type=CON, Code=GET, Message ID=0x1234
# Option: Uri-Path = ".well-known/core"

# Hex representation of a minimal CoAP discovery request:
# 40 01 12 34 bb 2e 77 65 6c 6c 2d 6b 6e 6f 77 6e 04 63 6f 72 65

# Request size:    ~21 bytes
# Response size:   ~600-1,000+ bytes
# Amplification:   ~34x

Real-World Incidents

CoAP amplification entered mainstream attack toolkits in 2023, when multiple booter services added it as an available vector. Because CoAP devices tend to be on cellular and wireless broadband connections with limited upstream bandwidth, individual reflectors contribute less traffic than enterprise servers. But the sheer number of devices compensates: researchers estimate over 600,000 CoAP endpoints are reachable from the public internet, with the population growing as IoT deployments expand.

CoAP is most frequently observed as one component in multi-vector attacks. Its presence in attack traffic often indicates that the attacker is using a booter service that cycles through all available amplification vectors to maximize aggregate volume and complicate filtering.

Detection Signatures

• Flood of inbound UDP from source port 5683
• CoAP response header (version 1, type ACK or NON, response code 2.05 Content)
• Payload in CoRE Link Format: strings containing </>, rt=, ct=, if=
• Packet sizes typically 200 to 1,000 bytes
• Source IPs from mobile carrier and IoT-specific address ranges

# tcpdump filter for CoAP amplification
$ tcpdump -nn 'udp src port 5683' -c 10
06:45:09.112 IP 100.72.18.33.5683 > 198.51.100.10.41902: UDP, length 714
06:45:09.113 IP 100.88.201.5.5683 > 198.51.100.10.41902: UDP, length 622
06:45:09.113 IP 37.120.44.91.5683 > 198.51.100.10.41902: UDP, length 891

# Wireshark display filter
udp.srcport == 5683 && coap

# Identify CoAP by checking the first byte (version + type fields)
$ tcpdump -nn -X 'udp src port 5683' -c 1 | head -20
# First nibble should be 0x6 (version 1, ACK) or 0x5 (version 1, NON)

SSDP in Multi-Vector Attacks (UDP Port 1900)

Protocol Mechanics

The Simple Service Discovery Protocol (SSDP), part of the Universal Plug and Play (UPnP) suite, is not a new amplification vector. It has been used in DDoS attacks since at least 2014. However, SSDP deserves attention in the context of emerging threats because of the role it plays in modern multi-vector campaigns. While individual SSDP amplification tops out at roughly 30x, its reflector pool is enormous (over 5 million devices), and it is consistently combined with other protocols to build attacks that exceed what any single vector could achieve.

SSDP works by responding to M-SEARCH requests with device descriptions that include the device type, manufacturer, model, unique service name, and service location URLs. A single device may send multiple response packets if it advertises several UPnP services, pushing the effective per-device amplification above the raw 30x ratio.

Why SSDP Keeps Showing Up

Three properties make SSDP valuable to attackers in 2026. First, the reflector population is self-replenishing. Every consumer router, smart TV, gaming console, and IoT hub shipped with UPnP enabled adds to the pool. Devices are replaced on a 3 to 5 year cycle, and new devices ship with the same default configuration. Second, SSDP reflectors are distributed across virtually every consumer ISP on the planet, which makes source-based filtering nearly impossible without blocking legitimate customer traffic. Third, SSDP responses are text-based HTTP, which means they blend in with legitimate web traffic at a protocol level and require deeper inspection to distinguish from normal UDP flows.

The April 2025 Record: 6.5 Tbps

In April 2025, Cloudflare disclosed a 6.5 Tbps multi-vector attack that combined SSDP, CLDAP, and ESP (Encapsulating Security Payload) reflection. The attack lasted approximately 45 seconds and targeted infrastructure across multiple continents. SSDP contributed a significant portion of the packet-per-second count, while CLDAP and ESP contributed the bulk of the bandwidth. This attack demonstrated that stacking three "moderate" amplification vectors can produce volume that rivals memcached-class floods without relying on any single protocol that defenders might specifically filter.

# SSDP M-SEARCH request (spoofed source IP)
M-SEARCH * HTTP/1.1
Host: target:1900
Man: "ssdp:discover"
MX: 3
ST: ssdp:all

# Request size:    ~100 bytes
# Response size:   ~3,000 bytes (often multiple responses per device)
# Amplification:   ~30x per device, higher with multi-service devices

Detection Signatures

• Flood of inbound UDP from source port 1900
• HTTP-formatted text with UPnP headers: SERVER:, USN:, LOCATION:, ST:
• Source IPs from consumer broadband address space worldwide
• Packets typically 300 to 500 bytes, but many packets per reflector
• High PPS relative to bandwidth (small packets, massive count)

# tcpdump filter for SSDP amplification
$ tcpdump -nn 'udp src port 1900' -c 10
20:17:44.102 IP 24.56.78.90.1900 > 198.51.100.10.39402: UDP, length 347
20:17:44.102 IP 71.12.34.56.1900 > 198.51.100.10.39402: UDP, length 412
20:17:44.103 IP 98.76.54.32.1900 > 198.51.100.10.39402: UDP, length 389

# Wireshark display filter
udp.srcport == 1900 && ssdp

DVR/CCTV Amplification and Dual-Use Botnets

The Dual Threat

Digital video recorders, network video recorders, and IP cameras occupy a unique position in the DDoS ecosystem. Unlike traditional reflectors that passively amplify spoofed traffic, many DVR and CCTV devices serve a dual role: they function as amplification reflectors through exposed UDP services, and they are simultaneously compromised as botnet members capable of generating direct attack traffic. This dual-use capability makes DVR/CCTV infrastructure one of the most dangerous device classes on the internet.

Amplification Mechanisms

DVR and CCTV devices expose multiple UDP services that can be abused for reflection. The most common are:

• WS-Discovery (port 3702): Most IP cameras implement WS-Discovery for ONVIF device discovery, contributing to the 800,000+ reflector pool described earlier.
• SSDP (port 1900): Many DVRs and NVRs run UPnP for automatic port forwarding and media streaming discovery.
• Proprietary discovery protocols: Several major DVR manufacturers implement custom UDP discovery protocols on non-standard ports (commonly 37810, 37777, or 34567) that respond to broadcast probes with device information. These proprietary protocols can achieve amplification factors of 10x to 20x.
• SNMP (port 161): Devices with default SNMP community strings respond to GetBulk requests with large MIB walks, yielding 6x to 10x amplification.

Botnet Membership

The same firmware vulnerabilities that leave DVR services exposed to the internet also enable remote code execution. Mirai and its descendants (Mozi, BeastMode, Aisuru) have historically targeted DVR and CCTV devices because they run outdated Linux kernels, use default credentials, and are rarely monitored. A single compromised DVR can simultaneously serve as an amplification reflector for one attack and a direct-flood bot for another. Operators have observed devices participating in reflection attacks during the day and switching to direct TCP SYN floods at night, controlled by different botnet operators who have independently compromised the same device.

Detection Signatures

• Inbound UDP from non-standard ports associated with DVR manufacturers (37810, 37777, 34567)
• Payloads containing device model strings, firmware version identifiers, or ONVIF namespace URIs
• Source IPs resolving to consumer ISP ranges with PTR records suggesting residential connections
• Mixed traffic patterns: amplified UDP reflection combined with direct TCP floods from overlapping source IP sets

# tcpdump filter for common DVR discovery ports
$ tcpdump -nn 'udp src port 37810 or udp src port 37777 or udp src port 34567' -c 10
03:22:18.501 IP 187.44.201.33.37810 > 198.51.100.10.29011: UDP, length 892
03:22:18.502 IP 41.205.12.88.37777 > 198.51.100.10.29011: UDP, length 1104
03:22:18.502 IP 119.73.44.12.34567 > 198.51.100.10.29011: UDP, length 756

# Check for overlapping IPs between UDP reflection and TCP direct floods
# This indicates dual-use DVR/CCTV botnets
$ comm -12 <(tcpdump -nn -r attack.pcap 'udp' | awk '{print $3}' | cut -d. -f1-4 | sort -u) \
           <(tcpdump -nn -r attack.pcap 'tcp[tcpflags] & tcp-syn != 0' | awk '{print $3}' | cut -d. -f1-4 | sort -u)

If your network receives amplification traffic from DVR/CCTV source IPs, those same devices may later pivot to direct volumetric or application-layer attacks against your infrastructure. Treat DVR-sourced reflection as an early indicator of broader targeting.

Amplification Vector Comparison

The following table summarizes the emerging vectors covered in this article alongside the three classic protocols for reference:

The key takeaway from this table is that the emerging vectors compensate for lower amplification factors with vastly larger reflector populations. WS-Discovery at 100x with 800,000 reflectors can generate more aggregate attack traffic than NTP at 556x with only 30,000 reflectors. And when attackers combine SSDP's 5 million reflectors with CLDAP's 70x factor and WS-Discovery's 100x factor in a single campaign, the resulting multi-vector flood is both massive and difficult to filter because no single source port dominates the traffic.

Practical Detection: What to Monitor

Kernel Counters

Before you even look at packet captures, your Linux kernel counters will tell you that something is wrong. The /proc/net/snmp file exposes UDP statistics that spike dramatically during amplification attacks:

# Baseline these values and alert on sudden changes
$ cat /proc/net/snmp | grep Udp:
Udp: InDatagrams NoPorts InErrors OutDatagrams RcvbufErrors SndbufErrors
Udp: 28491032     14201   0        12840211     0            0

# During an amplification attack, InDatagrams will spike 10-100x
# RcvbufErrors will climb if the socket buffer overflows
# NoPorts will increase if traffic hits ports with no listening process

# Quick one-liner to watch UDP stats per second
$ watch -n 1 'cat /proc/net/snmp | grep Udp:'

Per-Second PPS and Bandwidth Monitoring

Amplification attacks produce distinctive traffic patterns that are immediately visible in per-second monitoring. The ratio of inbound PPS to outbound PPS will spike dramatically because the victim is receiving millions of unsolicited response packets. Flowtriq's per-second PPS monitoring is designed to catch exactly this pattern: a sudden asymmetric spike in inbound UDP that does not correlate with any outbound request traffic.

Source Port Distribution

During normal operation, inbound UDP traffic arrives from a wide distribution of source ports. During an amplification attack, a single source port (or a small set of source ports) will dominate. If 80% of your inbound UDP is suddenly from source port 3702, you are being hit with WS-Discovery reflection. Flowtriq's protocol classification engine identifies the specific amplification vector by analyzing source port distributions and payload signatures, labeling the attack within seconds of onset.

Combined tcpdump Filter for All Emerging Vectors

# Catch all emerging amplification vectors in a single capture
$ tcpdump -nn -w /tmp/amp-capture.pcap \
  'udp src port 3702 or udp src port 389 or udp src port 5683 or udp src port 1900 or udp src port 37810 or udp src port 37777 or udp src port 34567' \
  -c 10000

# Count packets per source port to identify the dominant vector
$ tcpdump -nn -r /tmp/amp-capture.pcap 'udp' | \
  awk '{split($3,a,"."); print a[length(a)]}' | sort | uniq -c | sort -rn | head

Mitigation Strategies

Source Port Filtering

If your network does not legitimately receive traffic from the amplification source ports, blocking them at the edge is the simplest and most effective defense. Most organizations have no reason to accept inbound UDP from ports 3702, 5683, 37810, 37777, or 34567. CLDAP (port 389) and SSDP (port 1900) may require more careful handling if you have legitimate use cases, but can typically be rate-limited aggressively.

# iptables rules to block emerging amplification source ports
iptables -A INPUT -p udp --sport 3702 -j DROP    # WS-Discovery
iptables -A INPUT -p udp --sport 5683 -j DROP    # CoAP
iptables -A INPUT -p udp --sport 37810 -j DROP   # DVR (Dahua)
iptables -A INPUT -p udp --sport 37777 -j DROP   # DVR (Dahua alt)
iptables -A INPUT -p udp --sport 34567 -j DROP   # DVR (XMEye)

# Rate limit CLDAP and SSDP if you cannot block them entirely
iptables -A INPUT -p udp --sport 389 -m limit --limit 50/sec --limit-burst 100 -j ACCEPT
iptables -A INPUT -p udp --sport 389 -j DROP
iptables -A INPUT -p udp --sport 1900 -m limit --limit 50/sec --limit-burst 100 -j ACCEPT
iptables -A INPUT -p udp --sport 1900 -j DROP

BGP Flowspec

For network operators with BGP Flowspec capability, amplification attacks can be mitigated at the network edge before they reach the target server. Flowspec rules can match on UDP source port and drop or rate-limit traffic across all routers in the path simultaneously.

Upstream Scrubbing with Evidence

When amplification traffic exceeds your link capacity, the only option is upstream mitigation. Flowtriq captures PCAP evidence of the amplification traffic, including source ports, payload samples, and per-second volume graphs. This evidence accelerates the response from upstream scrubbing providers because it removes the guesswork: the provider can see exactly which amplification protocol is being used, what the traffic looks like, and how much bandwidth it is consuming.

Back to Blog

Related Articles