LMTV TribeLab | TRANSUM Revisited (by Paul Offord)
Hey Network - Leave the Packets Alone! (by Chris Greer)

A Closer Look at UDP Sessions (by Dr. Jin Qian)

A Closer Look at UDP (User Datagram Protocol) Sessions

For many network and security professionals, analyzing network packets for trouble-shooting and security investigation is a daily routine.  One of the most common actions in the analysis is to “follow” a TCP session: display all the packets belonging to a TCP session.

It's well known that a TCP session consists of all the TCP packets that have the same tuple:  from a client IP and port  to a server IP and port or, conversely, from a server IP and port to a client IP and port.   For a UDP session, many professionals will likely think that the same principle will work for UDP, just as in the case of TCP, but unfortunately, that is not the case.  A UDP session is only defined by the client IP and port.  As a result, packets from the same UDP session can be to/from different server IP and port pairs.

 Super graphic and discussion from https://elguber.wordpress.com/

Some readers may wonder why this communication method for UDP sessions is the way it is. The answer lies in the network programming: when an application needs to communicate using UDP, it will bind to a local IP and port. After the binding, this socket can send to and receive from any server and port pair. In other words, all the packets from/to the local IP and port will be relevant to the same UDP-based application.

With this understanding, let's look at two network scenarios.


DNS Transactions are very important for the functioning of today's networking.  Many PCs are configured with at least two DNS servers.  So how does the system use the two DNS servers?  After it's triggered, the DNS resolver on the PC will send a DNS query to the primary DNS server, and if it doesn't get an answer, it will then send the DNS request to the secondary DNS server in the same UDP session (hence the same local IP and port).   If you imagine the same concept for UDP sessions as that of TCP sessions, you might miss the fact that there is a retransmission of the DNS query because the server IP addresses are different. It will appear to an analyzer, like Wireshark, for example, as two separate sessions, when in fact it is the same session.

TFTP session is a popular protocol used mainly by some devices to acquire the configuration file or boot images.  Many network and security professional may not be aware that the message exchange occurs in the following manner:

  • client sends a TFTP request to download/upload a file from, for example, to
  • the server will send a packet from, for example, to client (note that the server uses a port other than 69 for the reply)
  • The Client and Server will use this tuple to exchange messages for the rest of the session.

Wireshark can follow both TCP and UDP sessions, however, it defines the UDP session the same as if it were a TCP session, and hence can not capture all the packets belonging to a UDP session. In particular, Following UDP session on Wireshark will not be able to catch all the packets for a TFTP session or a DNS session, because, again, it sees it as a separate session.

CapStar Packet Analyzer (CPA) was designed with the more accurate concept of sessions for TCP and for UDP.  As a result, one can use it to grab the complete DNS session or TFTP session.  Next, we are going to show how this more accurate capability can be used in the detection of malware traffic.

The pcap in question is from the Barracuda Labs Threatglass site. The malware in this pcap exhibited an interesting pattern:  the client tried to phone home (C&C server) by sending UDP packets to a whole subnet (only a few packets are shown here):

How do we detect the presence of such behavior in a (potentially big) pcap file?  As mentioned earlier, CPA accurately understands the UDP session; but, how does it detect the case where there are so many UDP server IP addresses involved?  This is where the statefulness of the CapStar language and analytics become very useful in packet analysis. For each session, be it TCP or UDP, one can define and make use of per-session variables. We use the variable to keep track of the number of different server IP addresses in this session.   Here is the CPA analytic:

uint prevSrvip;

int ipChanges;


    if (side == CLIENT) {

        if (session.serverIp != session.prevSrvip ) {

            session.ipChanges ++;

            session.prevSrvip = session.serverIp;

            if (session.ipChanges == 20) return 1;



In the above script, we used two per-session variables:  prevSrvip, ipChanges.  The first one will keep track of the previously used server IP address in this session, the second one will track of server IP changes in this session.  When the number of server IP changes reaches 20, we “return 1” to instruct CPA to save and display the packet. Running the above script/analytic on the pcap results in 3 packets.  In this case, they indicate that the malware has scanned the same subnet for C&C server at different times. 

Granted, the above scripts is a simple illustrative example that uses the number of server IP address change to do the detection. In theory, we could have a false positive when/if a client is sending to two server IP addresses alternatively. This technique will work most of the time, but if you truly need to keep track of the number of unique server IP addresses in a session, CPA supports complex per-session variables such as a hashmap which will give you exactly what you need. 

If you are interested in learning more about Capstar Packet Analyzer and how it can dramatically increase your investigation productivity, and, of course, solve interesting and challenging network packet analysis problems -

please drop us a note at info@capstarforensics.com


PJin Ouin portrait_20160229

Author - Dr. Jin Qian had worked in telecommunication and application and server performance for many years before working in the exciting field of network security. In his articles and work he applies the same principles of making hard things easy and makes technology more accessible for professionals of varied backgrounds and levels. Jin’s belief on fighting cyber criminals is to empower cyber warriors to be more adaptive and agile than the hackers even if the hackers may be more experienced in the programming attacks and malware.

"The Ultimate Goal of Technology is Simplicity!" TAO 2008


Some great articles and a video on understanding TCP - From Experts like Betty DuBois, D.C. Palter and Tony Fortunato