Incident response

Network Traffic Analysis for IR: UDP with Wireshark

January 15, 2020 by Howard Poston

Introduction to UDP

The User Datagram Protocol (UDP) is one of the two main protocols that sits between the Internet Protocol (IP) layer and higher-level, specialized protocols like the hypertext transfer protocol (HTTP) and domain name system (DNS).

The other such protocol, Transport Control Protocol (TCP), is designed to provide reliable connections with built-in error handling. It is designed for applications that need to be certain that data reaches its destination intact and do not prioritize traffic latency.

UDP, on the other hand, is intended for applications that prioritize latency over reliability. It is a “fire and forget” protocol, which does not retain state. After a UDP packet is sent, there is no acknowledgement of receipt from the destination and lost packets are not transmitted. As a result, UDP is commonly used in applications where all the data can be contained within a single packet and either packet loss is not a major problem (like in DNS) or high-speed transmissions are necessary (like gaming).

UDP in Wireshark

An extremely common use of the UDP protocol is for DNS traffic. DNS requests and responses are relatively small, and, if something goes wrong and a packet is dropped, it is easy to make another request. As a result, DNS often does not require the reliability guarantees that TCP provides, and the overhead of the TCP handshake is superfluous.

The screenshot above shows the details of a standard UDP packet header. As shown, UDP uses the same port model as TCP, and applications that use both TCP and UDP will often use the same ports in each. The UDP packet header also includes a length value and a checksum for verifying the accuracy of the data that it contains.

UDP analysis for incident response

UDP is primarily intended for carrying other types of traffic. However, some attacks are enabled specifically by the features of the UDP protocol. Two common malicious uses of UDP are for scanning and in DDoS amplification attacks.


Nmap is probably the most widely-used tool for network scanning and reconnaissance. It includes a variety of scan types designed for different use cases.

One of the scan options in Nmap is scanning using UDP packets (TCP is the default). In a UDP scan, Nmap will either send an empty payload (for most ports) or an application-specific payload for ports associated with applications that commonly run on UDP (like DNS). UDP scanning is uncommon because it is slow and few applications run on UDP; however, it is possible to find exploitable ports using UDP, so it is worth a try.

Based on the results of the scan, Nmap classifies it as open, closed or filtered, as shown above. The main ambiguity is if no response is received, since this could either indicate an open port with an application that rejected the request as invalid or a firewall that filtered the request and dropped the packet before it reached the target port.


Identifying UDP scanning in Wireshark is fairly straightforward. The packet capture will contain a large number of UDP packets originating from a small number of ports and attempting to connect to many ports on the target machine.

DDoS amplification

Distributed Denial of Service (DDoS) attacks attempt to take down a target machine or application by overwhelming it with more data than it can process. DDoS attacks can be performed at multiple different levels and can target a variety of possible bottlenecks, including a machine’s network bandwidth, the number of open connections that a computer can hold at once or a particular application’s ability to process data.

One of the common malicious uses of UDP traffic is in DDoS amplification attacks. A DDoS amplifier is a protocol where a small request results in a much larger response. One example of this is DNS, where the entire contents of the request is included within the response, along with all of the response data.

Since UDP is a connectionless protocol, it is possible for an attacker to send traffic while spoofing their IP address to that of another machine. In a DDoS amplification attack, the attacker sends a request to a DDoS amplifier while spoofing their IP address to that of their target. Since the amplifier has no reason to distrust the request, they respond to it, sending a much larger response to the target and amplifying the impact of the attacker’s DDoS attack.

DDoS amplification attacks are difficult to detect in a traffic capture if your machine is the DDoS amplifier, since the amplifier simply responds to “legitimate” requests. On the target side, DDoS amplification attacks are apparent for several different reasons:

  1. Your systems are undergoing a DDoS attack
  2. Traffic captures contain responses with no corresponding request
  3. A large volume of packets (in both size and number) are coming from a small range of source ports (those associated with the DDoS amplifier)

Conclusion: Investigating UDP traffic in Wireshark

As one of the major transport protocols, UDP will show up in a lot of network traffic, but the main focus will be on the upper-level protocols. The main indicators that an attack is occurring are if the volume or behavior of UDP traffic significantly deviates from normal. For both scanning and DDoS amplification, this is typically a disproportionate amount of traffic coming from the same, small number of source ports.



  1. SampleCaptures, Wireshark
  2. Nmap Packet Capture, Blog
  3. UDP Scan (-sU),
Posted: January 15, 2020
Articles Author
Howard Poston
View Profile

Howard Poston is a cybersecurity researcher with a background in cryptography and malware analysis. He has a Master’s degree in Cyber Operations from the Air Force Institute of Technology and two years of experience in cybersecurity R&D at Sandia National Labs. He currently provides consulting and technical content writing for cybersecurity, cryptocurrency, and blockchain.

Notice: Undefined index: visitor_id12882 in /www/resourcesinfosecinstitute_601/public/wp-content/plugins/infosec-user-info/infosec-user-info.php on line 117