3702/UDP - Pentesting WS-Discovery
Basic Information
The Web Services Dynamic Discovery Protocol (WS-Discovery / WSD) is a multicast discovery protocol used to find services in the local network using SOAP over UDP. It is very common in ONVIF cameras, printers, Windows WSD services, and other embedded/IoT devices.
A target service usually sends: - Hello when it joins the network - Bye when it leaves - ProbeMatch when it answers a discovery Probe - ResolveMatch when it answers a Resolve request
The most relevant offensive detail is that the response usually leaks:
- Types: the advertised device/service class (dn:NetworkVideoTransmitter, wprt:PrintDeviceType, pub:Computer, ...)
- Scopes: useful metadata such as profile, model, MAC, hardware family, location-like labels, or vendor-specific attributes
- XAddrs: the follow-up management endpoint, commonly an HTTP(S) SOAP URL such as http://<ip>/onvif/device_service
Default port: 3702/UDP
IPv4 multicast: 239.255.255.250
IPv6 multicast: ff02::c
PORT STATE SERVICE
3702/udp open|filtered unknown
| wsdd-discover:
| Devices
| Message id: 39a2b7f2-fdbd-690c-c7c9-deadbeefceb3
| Address: http://10.0.200.116:50000
|_ Type: Device wprt:PrintDeviceType
Enumeration
Nmap
- Query a specific host exposing UDP/3702:
nmap -sU -p 3702 --script wsdd-discover <IP> - Discover devices in the current L2 segment via multicast:
sudo nmap --script broadcast-wsdd-discover
The returned XAddrs are usually more valuable than the WS-Discovery response itself because they tell you where to pivot next (ONVIF, printer SOAP endpoints, Windows WCF services, etc.).
Manual Probe (useful when you want full raw XML)
import socket, uuid
probe = f'''<?xml version="1.0" encoding="UTF-8"?><e:Envelope xmlns:e="http://www.w3.org/2003/05/soap-envelope" xmlns:w="http://schemas.xmlsoap.org/ws/2004/08/addressing" xmlns:d="http://schemas.xmlsoap.org/ws/2005/04/discovery" xmlns:dn="http://www.onvif.org/ver10/network/wsdl"><e:Header><w:MessageID>uuid:{uuid.uuid4()}</w:MessageID><w:To>urn:schemas-xmlsoap-org:ws:2005:04:discovery</w:To><w:Action>http://schemas.xmlsoap.org/ws/2005/04/discovery/Probe</w:Action></e:Header><e:Body><d:Probe><d:Types>dn:NetworkVideoTransmitter</d:Types></d:Probe></e:Body></e:Envelope>'''.encode()
s = socket.socket(socket.AF_INET, socket.SOCK_DGRAM)
s.setsockopt(socket.IPPROTO_IP, socket.IP_MULTICAST_TTL, 1)
s.bind(("0.0.0.0", 0))
s.settimeout(3)
s.sendto(probe, ("239.255.255.250", 3702))
while True:
try:
data, addr = s.recvfrom(65535)
print(addr[0], data.decode(errors="ignore"))
except TimeoutError:
break
Useful filters:
- Cameras often answer to dn:NetworkVideoTransmitter
- ONVIF devices commonly expose tds:Device and an XAddrs like http://<ip>/onvif/device_service
- Printers may expose wprt:PrintDeviceType
Packet capture
sudo tcpdump -ni <iface> udp port 3702
sudo tshark -i <iface> -f "udp port 3702" -Y 'xml.tag == "d:ProbeMatch" || xml.tag == "wsdd:ProbeMatch"'
Interesting offensive notes
Multicast is local, but unicast sweeps are still useful
Multicast WS-Discovery usually does not cross routers, so a camera or printer in another VLAN may stay invisible to broadcast-wsdd-discover. In practice, if you already know or can guess the target subnet, sending the same Probe as unicast UDP/3702 to each host is a good way to find devices in routed environments.
Scopes often leak useful metadata
Even when the service is not directly exploitable, Scopes frequently reveal:
- vendor/model family
- MAC addresses
- ONVIF profile support
- product role (video_encoder, printer type, etc.)
- asset naming/location hints
That is very helpful for password spraying prioritization, firmware hunting, and selecting the best post-discovery pivot.
XAddrs are the real target
Treat the WS-Discovery response as a directory service: - ONVIF camera: pivot to the ONVIF SOAP endpoint and then to RTSP/media/profile enumeration - Printer/WSD device: pivot to IPP/HTTP(S)/SOAP admin endpoints - Windows/WCF service: pivot to the published HTTP(S) service URI
Attacks
Rogue responder / service impersonation
In flat networks, a rogue host can answer multicast Probe requests faster than the legitimate device and advertise attacker-controlled XAddrs. This is useful when a management platform auto-discovers devices and then blindly connects to the supplied HTTP(S) endpoint.
Interesting abuse cases: - redirect onboarding workflows to an attacker-controlled ONVIF or SOAP endpoint - capture credentials if the client automatically attempts authentication to the advertised endpoint - coerce operators into connecting to a fake camera/printer/service that mimics expected metadata
If you see auto-enrollment behavior, test whether the client trusts the first responder, whether it validates the endpoint identity, and whether it reuses credentials automatically.
Reflection / amplification DDoS
If UDP/3702 is exposed to the Internet, WS-Discovery can be abused as a reflection/amplification vector because the attacker can spoof the source IP and trigger larger responses from many devices.
From a pentest perspective, finding Internet-exposed WS-Discovery means:
- the device is often badly segmented
- it may be part of a larger camera/IoT fleet with weak hardening
- the same exposed device commonly exposes follow-up management interfaces discovered in XAddrs
Fast device classification in camera-heavy environments
In CCTV environments, WS-Discovery is often the quickest way to separate: - ONVIF-capable cameras - Windows hosts exposing WSD/WCF services - printers and multi-function devices
This makes UDP/3702 a good first-pass recon target before moving into more specific pages such as:
554-8554-pentesting-rtsp.md
pentesting-631-internet-printing-protocol-ipp.md