When a spoofed probe reaches an exposed IP camera on UDP 3702, the camera answers a stranger it was never meant to talk to, and the reply lands on the victim many times larger than the request. That is a WS-Discovery amplification attack, and a thorough DDoS test exercises it as one of the IoT-fuelled reflection vectors. It pairs the two properties that define the whole reflection and amplification family: a forged source so the flood hides its origin, and a reply far bigger than the probe that provoked it.
What makes WS-Discovery amplification specific
WS-Discovery, Web Services Dynamic Discovery, is how devices announce themselves on a local network without being configured to find each other. IP cameras built to the ONVIF standard, network printers, and similar appliances use it to advertise their presence. It speaks SOAP over UDP on port 3702, and it was designed to be spoken on a LAN, never across the internet.
The abuse is the standard reflection move with an IoT twist. The attacker sends a small SOAP Probe with the victim's address forged as the source, and the device replies with a much larger XML description of itself, aimed at the victim. What makes the vector its own is the size of that reply and the population answering it: researchers have measured amplification factors reaching roughly 153 times the probe on crafted requests, and counted on the order of 630,000 WS-Discovery devices reachable on the public internet.
The vector had a defining moment. In 2019 Akamai documented WS-Discovery being used in live DDoS campaigns, including a flood that peaked around 35 Gbps, one of the first times a protocol meant purely for local device discovery was turned into internet-scale attack capacity. It joined a long line of UDP services, from DNS to memcached, that were never meant to face the internet and were left exposed anyway.
Why it matters under attack
The traffic itself offers nothing to filter on. It is well-formed SOAP from thousands of real cameras and printers, each answering what it thinks is a legitimate discovery probe, so there is no malicious sender to block by reputation and no payload signature to catch. The volume has to be absorbed upstream rather than identified and dropped.
None of the levers that would end it are ones the victim controls. WS-Discovery should never be reachable from outside a LAN, yet default-open IoT firmware exposes it constantly, and the same missing source-address validation (BCP 38) that feeds every reflection vector lets the spoofed probes leave their origin networks in the first place. Both fixes belong to other operators, which is why the technique persists.
What a DDoS test measures
With the cure sitting on hardware you do not own, the only thing left to gauge at the target is how much reflected load it can soak up. A test shapes a controlled load resembling reflected WS-Discovery replies and records how much the edge or scrubbing tier swallows before goodput starts to fall, and how many seconds the flood keeps reaching the origin before mitigation engages.
It is worth aiming the same question inward: does any device on your own estate answer on UDP 3702 from outside? An exposed camera turns your network into someone else's weapon and a source of outbound traffic that can get your prefixes throttled, so the amplification factor you assume in capacity planning should match what a real reflector set can actually deliver. The same absorb-do-not-block reasoning applies to every open UDP service left facing the internet, which Understanding DDoS Attack Vectors works through in turn.