What Is an SSDP Amplification Attack? | UPnP and IoT DDoS Explained

An SSDP amplification attack is a reflection-based DDoS technique that abuses the Simple Service Discovery Protocol, part of Universal Plug and Play (UPnP), by sending spoofed discovery requests to internet-exposed UPnP devices — commonly home routers, IP cameras, smart TVs, and other IoT hardware — which respond with device-description data sent directly to a spoofed victim, generating moderate but broadly available amplification traffic.

TL;DR: SSDP amplification sends a spoofed M-SEARCH discovery request to UPnP-enabled devices exposed on the public internet. Each device replies with an XML device-description response, achieving a modest amplification factor (roughly 7x–30x) compared to DNS or NTP, but the vector remains attractive because tens of millions of IoT devices are needlessly reachable on UDP port 1900 worldwide. Mitigation centers on network segmentation — UPnP should never respond to WAN-side requests — combined with BCP38 to reduce spoofing and consumer/ISP-level blocking of inbound port 1900 traffic.

Last updated: 2026-08-27

SSDP amplification became a prominent DDoS vector around 2014, coinciding with the broader wave of UDP-based reflection attacks (NTP, DNS) that dominated that period. Unlike NTP amplification, which was largely resolved by patching server software, SSDP amplification has proven more persistent because the vulnerable population is not a relatively small set of server operators but a vast, decentralized base of consumer IoT devices — home routers, network-attached storage, smart TVs, printers, and media servers — many of which are never patched, monitored, or even acknowledged as network-facing services by their owners. Public reporting has repeatedly identified tens of millions of UPnP-enabled devices reachable on UDP port 1900 from the public internet, a population that has proven difficult to meaningfully reduce over the past decade.

What Is SSDP and UPnP?

Universal Plug and Play (UPnP) is a set of networking protocols that allow devices on a local network to automatically discover each other and negotiate services — for example, a smart TV discovering a media server, or a game console automatically opening a port on a router for peer-to-peer play. The Simple Service Discovery Protocol (SSDP) is the discovery component of UPnP, and it operates over UDP port 1900, using HTTP-like request and response messages layered on UDP rather than TCP.

SSDP is designed for local network use: a device sends an M-SEARCH request to the multicast address 239.255.255.250:1900, and other UPnP devices on the same LAN respond describing the services they offer. The protocol was never designed to be exposed to the public internet — its abuse as a DDoS vector stems entirely from devices and routers that incorrectly answer SSDP requests arriving from the WAN side.

How SSDP Amplification Works

Step 1: Attacker sends a spoofed M-SEARCH request to an internet-exposed
        UPnP device, with the source IP forged as the victim's address

Attacker → Exposed UPnP Device: M-SEARCH * HTTP/1.1
                                  HOST: 239.255.255.250:1900
                                  MAN: "ssdp:discover"
                                  ST: ssdp:all
                                  (src=192.0.2.10 [victim], ~110 bytes)

Step 2: The device responds with an HTTP-like description of its services,
        sent to the spoofed source address

UPnP Device → Victim: HTTP/1.1 200 OK
                       CACHE-CONTROL: max-age=1800
                       LOCATION: http://192.168.1.1:5000/rootDesc.xml
                       ... (multiple headers and service descriptors,
                       up to ~750 bytes, possibly multiple response packets
                       per M-SEARCH depending on device and ST value)

Step 3: The attacker repeats via thousands of exposed UPnP devices found
        via internet-wide scans (e.g., Shodan, masscan)

10,000 devices × steady query rate × ~750 bytes response
  = aggregate volumetric flood converging on the victim

Some devices respond to a single M-SEARCH with multiple SSDP response packets — one for each service type they advertise — which can push the effective amplification for a given device somewhat higher than a simple one-request-one-response ratio would suggest, though still modest relative to NTP or DNS.

Why IoT Devices Are Disproportionately Exposed

Several structural factors specific to consumer and IoT hardware make SSDP amplification persistently available even as awareness of the vector has grown:

• Default-on UPnP configuration. Most consumer routers and IoT devices ship with UPnP enabled by default, and many never prompt the owner to review or disable it.
• No patch culture for consumer hardware. Unlike server software, consumer routers, cameras, and smart TVs are rarely patched by their owners, and many vendors stop issuing firmware updates well before the device is retired from service.
• Misconfigured WAN-facing bindings. SSDP is only supposed to answer LAN-side multicast queries, but firmware bugs or misconfiguration on some devices cause them to also respond to unicast queries arriving from the WAN interface, exposing them to internet-wide scanning.
• Scale of the IoT population. Estimates of internet-connected IoT devices number in the tens of billions, and even a small percentage misconfigured to expose SSDP represents a very large absolute pool of reflectors.

Amplification Factor Comparison

SSDP’s amplification factor is the lowest among the widely abused UDP reflection vectors — meaningfully below DNS, CLDAP, and NTP. Its continued relevance comes not from per-request efficiency but from the sheer number of available reflectors: DDoS-for-hire services and botnet operators favor SSDP when they need a large, geographically diverse pool of reflectors that is unlikely to be patched or taken offline, even though each individual request contributes relatively less amplification than other vectors.

SSDP Amplification and DDoS-for-Hire Services

SSDP amplification is a commonly offered attack method on booter and IP stresser platforms precisely because the reflector pool — misconfigured home routers and IoT devices — is continually replenished as new devices are manufactured, sold, and connected with default UPnP settings, unlike server-side vulnerabilities that get patched and shrink over time. See DDoS Booters and IP Stressers for more on how these commercial attack platforms combine multiple amplification vectors.

Detection Signals

# Inspect for SSDP response traffic on the wire
tcpdump -n 'udp port 1900' -A

# Correlate NetFlow for UDP/1900 responses without matching outbound queries
nfdump -r flows.nf 'proto udp and src port 1900' -o extended

# Check whether a device on your own network responds to WAN-side SSDP queries
# (only run against infrastructure you own or are authorized to test)
python3 -c "
import socket
msg = 'M-SEARCH * HTTP/1.1\r\nHOST:239.255.255.250:1900\r\nMAN:\"ssdp:discover\"\r\nST:ssdp:all\r\nMX:2\r\n\r\n'
s = socket.socket(socket.AF_INET, socket.SOCK_DGRAM)
s.sendto(msg.encode(), ('<target-ip>', 1900))
s.settimeout(3)
print(s.recvfrom(4096))
"

Mitigation Techniques

Disable UPnP on WAN-facing interfaces

The most direct fix for device owners and operators: ensure UPnP/SSDP only listens on and responds to the local network interface, never the WAN interface. Most consumer router firmware includes a setting to disable UPnP entirely, or to restrict it to LAN-only operation; enabling this setting removes the device from the reflector pool.

Network segmentation for IoT devices

Enterprises and service providers should place IoT devices on isolated VLANs or subnets with egress filtering that blocks outbound SSDP responses (and other UPnP traffic) from reaching the public internet, preventing devices on the managed network from being recruited as reflectors even if UPnP is enabled locally for legitimate use.

ISP-level blocking of inbound port 1900

Internet service providers can block or rate-limit inbound UDP/1900 traffic at their network edge for residential and small-business connections, since legitimate SSDP traffic should never need to cross the WAN boundary in the first place — it is a local-network-only protocol by design.

BCP38 / Ingress Filtering (RFC 2827)

Because SSDP amplification depends on IP spoofing to redirect device responses to the victim, BCP38 (RFC 2827) ingress filtering at the attacker’s network would prevent the spoofed query from leaving the attacker’s own network in the first place. As with all spoofing-dependent reflection attacks, this defense must be applied upstream by the networks originating attack traffic.

Rate limiting and response correlation at the target

Organizations being targeted by SSDP-amplified traffic can rate-limit inbound UDP/1900 and correlate incoming responses against previously sent outbound queries, discarding unsolicited SSDP responses without needing to block the protocol at the ISP level.

Upstream scrubbing and distributed absorption

Given the scale of the available reflector pool, SSDP-amplified floods can still reach volumes exceeding a target’s own uplink, even with a comparatively modest per-request amplification factor. Absorption at a distributed edge or scrubbing provider remains the practical mitigation for the target. See Blackhole Routing vs. Scrubbing for architectural approaches.

Common Mistakes

How to Implement on Azion

Azion’s distributed network can help absorb and filter SSDP-amplification traffic before it reaches an origin, while preventing your own devices from being abused as reflectors remains a device- and network-configuration responsibility independent of any edge provider:

• DDoS Protection provides always-on detection and mitigation for volumetric UDP traffic, including SSDP-amplified floods, absorbing it across Azion’s distributed infrastructure rather than at your origin.
• Network Shield can apply network-level rules to identify and filter anomalous UDP/1900 traffic patterns consistent with SSDP reflection, depending on configuration.
• Firewall enables custom rules for rate limiting and protocol-based filtering at the network layer.
• WAAP combines network and application-layer protections for organizations facing multi-vector campaigns that pair volumetric amplification with application-layer abuse.

If your organization manages IoT devices or consumer-facing network hardware, disabling WAN-facing UPnP and segmenting IoT traffic remains a necessary complementary step, since it addresses whether your own infrastructure can be weaponized against others rather than whether your applications are protected from incoming attacks.

Related Resources

• What Is a DDoS Attack?
• DDoS Attack Types
• What Is IP Spoofing?
• What Is DNS Amplification?
• What Is a Botnet?
• Azion DDoS Protection

Frequently Asked Questions

What is an SSDP amplification attack? An SSDP amplification attack sends a spoofed discovery request (M-SEARCH) to a UPnP-enabled device exposed on the public internet, which replies with a device-description response sent directly to the spoofed victim address. Aggregated across many exposed devices, this generates a volumetric flood against the victim.

What is SSDP and why do IoT devices respond to internet-wide queries? SSDP (Simple Service Discovery Protocol) is the discovery component of UPnP, designed to let devices on a local network find each other automatically. It should only ever answer requests from the local network, but firmware misconfiguration or default-on settings on many consumer routers and IoT devices cause them to also answer unicast SSDP queries arriving from the WAN side, exposing them to internet-wide abuse.

What is the amplification factor for SSDP attacks? SSDP typically produces amplification factors in the range of roughly 7x to 30x, depending on the device and how many service types it advertises in response to a single query. This is modest compared to NTP (up to ~556x) or DNS (up to ~70x), but SSDP remains widely used because of the very large number of available reflectors.

Why is SSDP amplification still common if its amplification factor is low? The attack’s persistence comes from the size of the available reflector pool rather than per-request efficiency. Tens of millions of consumer routers, cameras, and other IoT devices remain reachable on UDP port 1900 worldwide, and unlike server software vulnerabilities, this population is not meaningfully reduced by patching since most consumer devices are never updated.

Can a firewall stop an SSDP amplification attack against me? A firewall at the target’s network can rate-limit or filter inbound UDP/1900 traffic and correlate responses against previously sent outbound queries, reducing impact. It cannot prevent the attack from being generated in the first place — that requires the exposed IoT devices being abused as reflectors to have UPnP disabled on their WAN interfaces, which is outside the target’s control unless the target also happens to operate those devices.

How do I check if my own devices are exposed to SSDP abuse? Send an M-SEARCH request to the device’s public IP address on UDP port 1900 from an external test host you control, and check whether it responds. If it does, UPnP is incorrectly bound to the WAN interface and should be disabled or restricted to LAN-only operation immediately. Only test devices you own or are explicitly authorized to test.

How does SSDP amplification relate to IoT botnets like Mirai? They are related but distinct problems. SSDP amplification abuses a device’s UPnP discovery service to reflect traffic without needing to compromise the device at all — it is misuse of a legitimate feature. IoT botnets like Mirai require actually infecting the device with malware, typically via default credentials, and then commanding it to send traffic directly. A single misconfigured device could theoretically be abused by both methods independently.

Does BCP38 stop SSDP amplification attacks? BCP38 (RFC 2827) ingress filtering, applied at the network where the attack traffic originates, would prevent the spoofed query from ever reaching the exposed UPnP devices, since the attack depends entirely on IP spoofing to redirect responses to the victim. Adoption of BCP38 remains incomplete globally, which is part of why SSDP amplification persists as a viable vector.

What ports does SSDP amplification use? SSDP operates over UDP port 1900. Attack traffic in an SSDP amplification incident consists of UDP packets with source port 1900, arriving at the victim from a large number of distinct IoT device IP addresses, typically without any corresponding outbound discovery request from the victim’s network.

Can network segmentation prevent my organization’s IoT devices from being used as SSDP reflectors? Yes. Placing IoT devices on isolated VLANs with egress filtering that blocks outbound SSDP responses from reaching the public internet prevents those devices from being recruited as reflectors, even if UPnP remains enabled for legitimate local-network discovery within the segment.

Sources:

• CISA|US-CERT. “UDP-Based Amplification Attacks.” Alert TA14-017A.
• IETF. “Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing.” RFC 2827 (BCP38). 2000.
• UPnP Forum. “UPnP Device Architecture 2.0” and “SSDP” specifications.
• NIST SP 800-94. “Guide to Intrusion Detection and Prevention Systems (IDPS).”