UDP Probe Module - zmap/zmap GitHub Wiki

ZMap additionally supports UDP probes, where it will send out an arbitrary UDP datagram to each host, and receive either UDP or ICMP Unreachable responses. ZMap supports four different methods of setting the UDP payload through the --probe-args command-line option. These are 'text' for ASCII-printable payloads, 'hex' for hexadecimal payloads set on the command-line, 'file' for payloads contained in an external file, and 'template' for payloads that require dynamic field generation. In order to obtain the UDP response, make sure that you specify 'data' as one of the fields to report with the -f option.

The example below will send the two bytes 'ST', a PCAnywhere 'status' request, to UDP port 5632.

$ zmap -M udp -p 5632 --probe-args=text:ST -N 100 -f saddr,data -o -

The example below will send the byte '0x02', a SQL Server 'client broadcast' request, to UDP port 1434.

`$ zmap -M udp -p 1434 --probe-args=hex:02 -N 100 -f saddr,data -o -

The example below will send a NetBIOS status request to UDP port 137. This uses a payload file that is included with the ZMap distribution.

$ zmap -M udp -p 137 --probe-args=file:netbios_137.pkt -N 100 -f saddr,data -o -

The example below will send a SIP 'OPTIONS' request to UDP port 5060. This uses a template file that is included with the ZMap distribution.

 $ zmap -M udp -p 5060 --probe-args=template:sip_options.tpl -N 100 -f saddr,data -o -

UDP payload templates are still experimental. You may encounter crashes when more using more than one send thread (-T) and there is a significant decrease in performance compared to static payloads. A template is simply a payload file that contains one or more field specifiers enclosed in a ${} sequence. Some protocols, notably SIP, require the payload to reflect the source and destination of the packet. Other protocols, such as portmapper and DNS, contain fields that should be randomized per request or risk being dropped by multi-homed systems scanned by ZMap.

The payload template below will send a SIP OPTIONS request to every destination:

OPTIONS sip:${RAND_ALPHA=8}@${DADDR} SIP/2.0
Via: SIP/2.0/UDP ${SADDR}:${SPORT};branch=${RAND_ALPHA=6}.${RAND_DIGIT=10};rport;alias
From: sip:${RAND_ALPHA=8}@${SADDR}:${SPORT};tag=${RAND_DIGIT=8}
To: sip:${RAND_ALPHA=8}@${DADDR}
Call-ID: ${RAND_DIGIT=10}@${SADDR}
CSeq: 1 OPTIONS
Contact: sip:${RAND_ALPHA=8}@${SADDR}:${SPORT}
Content-Length: 0
Max-Forwards: 20
User-Agent: ${RAND_ALPHA=8}
Accept: text/plain

In the example above, note that line endings are \r\n and the end of this request must contain \r\n\r\n for most SIP implementations to correcly process it. A working example is included in the examples/udp-payloads directory of the ZMap source tree (sip_options.tpl).

The following template fields are currently implemented:

  • SADDR: Source IP address in dotted-quad format
  • SADDR_N: Source IP address in network byte order
  • DADDR: Destination IP address in dotted-quad format
  • DADDR_N: Destination IP address in network byte order
  • SPORT: Source port in ascii format
  • SPORT_N: Source port in network byte order
  • DPORT: Destination port in ascii format
  • DPORT_N: Destination port in network byte order
  • RAND_BYTE: Random bytes (0-255), length specified with =(length) parameter
  • RAND_DIGIT: Random digits from 0-9, length specified with =(length) parameter
  • RAND_ALPHA: Random mixed-case letters from A-Z, length specified with =(length) parameter
  • RAND_ALPHANUM: Random mixed-case letters from A-Z and digits from 0-9, length specified with =(length) parameter