Open Source Guide:  Wireshark Basics for Analyzing Network Packets

Version 6



    Thanks to srini.seethapathy for creating this guide.


    This documents explains valuable features of Wireshark, a free and open source software for analyzing network packets. You may also want to download a free Wireshark reference guide from PacketIQ (not associated with FireEye).




    Wireshark is a network packet analyzer that lets you examine the traffic flowing into and out of your Network. Wireshark is used to troubleshoot networking problems, but it is also an excellent way to learn exactly how the network protocols work. For example, it allows us to see the data that your system sends and receives when you type a web address into a web browser.


    Wireshark also contains a protocol analyzer that understands a massive number of protocols, containing over 78,000 filters. It converts the data stream to a listing of packets flowing in and out of the computer. It allows you to examine an individual packet, and drill down through the layers of encapsulation until the application-level payload is revealed.




    The review of the the protocol stack demonstrates that the protocol analyzer contains data that will assist you with packet analysis and highlight where problems may exist.



    First, you have Frame data (bytes on the wire) which constitutes the information linked to the Frame (Interface ID, Encapsulation Type, Time data, Frame Number, Frame Length, Protocols in Frame, etc...) This data can be used to help troubleshoot Layer 1 issues and situations if the network (Physical Layer) baseline is known.


    Second, you have the Data Link Layer data (Based on Encapsulation Type), which constitutes the information, linked to the data link mode of your system, usually Ethernet, but can include Frame Relay, ATM, or other Layer two technologies. The sections covered in Ethernet are Source Media Access Control Address, Destination Media Access Control Address. Information gathered from Address Resolution


    Protocol (Source MAC Address, and Destination Internet Protocol Address linked to MAC Address, Source and Destination LG and IG bits used to show globally unique address and individual address positions (Extracted from the MAC Address) and then the Ether Type for Ethernet, this is 0x0800.


    Third, you have the Internet-working Layer data. This section includes the IP Version (4 or 6), header length, Differentiated Services, Explicit Congestion Notification (ECN), total length of packet, packet identification, flags (Reserved bit, Don’t Fragment, More Fragments, Fragment Offset, Time To Live, Protocol (TCP/UDP), header checksum, checksum data, source and destination domain to IP link.) Fourth, you have the Transmission Control Protocol layer data, which gives you the source and destination port data, sequence number, acknowledgement number, header length, flags (reserved, nonce, congestion window reduced, ECN-echo, urgent, acknowledgement, push, reset, synchronization, and finish), window size, checksum, and analysis of sequence and acknowledgement Fifth, you have the data, which is sent or as it is called the payload. The data also includes its length.


    Wireshark Environment

    Window Area 1:  Summary At the top is a colorful listing of all of the packets captured. Each line is a summary of a single frame or packet that was captured. The colors represent a coding scheme that can be used to quickly detect the type of packet. For example, the predominant color in the graphic above is light green. Light green is the color for HTTP packets.


    Window Area 2:  Detail When you click on a packet in area 1, the packet structure is shown in area 2. In the screenshot above, the packet shown in dark blue has been selected; therefore area 2 shows more details on that packet.


    Window Area 3:  RAW Data Clicking on a portion of the packet in area two changes the display in area 3. This was done in Figure 8 to select the IP flags field, in Figure 9 the hex of the flags field is selected. Area 3 has two parts. On the left are sixteen columns of twocharacters each. This is the raw hexadecimal code that makes up the packet. On the right is the Unicode version of this hexadecimal code. If you click on an http line in window 2, you might notice English looking get commands or html commands in this right area.



    Making Sense of  Packets



    Wireshark offers many other features, other than the ability to inspect frames. The purpose of the section is to look at various points in the OSI layers, which can act as an aid in troubleshooting network problems. It can also help you to understand what sort of traffic is going over the network. Looking at the above figure, you can see that the first line shows a summary of the frame. The other lines show the data link layer, the network layer, the transport layer, and finally, the actual data contained within the frame. Lets look at each layer in detail.


    Data Link Layer


    DataLink layer,  we can see that it is pretty simple. It contains a destination address and a source address. The data link layer is relatively simple in that it is only concerned with getting a frame to the next adjacent node on the physical medium. The main point of interest is the Organizational Unique Identifier (OUI), which takes up the first three bytes of an Ethernet address. The IEEE assigns the OUI to manufacturers of Ethernet equipment. If you want to take a look at assigned OUIs, the list is maintained at Wireshark makes it easy for you to check on the manufacturer of a card; you can highlight the field (as shown in Figure B) and extract the OUI. You can then plug the number into the website,, and obtain the manufacturer. The Ethernet layer is concerned with node to node.


    Network Layer


    The IP layer is concerned with moving between networks, hence the original meaning of the term internetwork, from whence Internet was derived. Highlighting the network layer shows more details. From figure, we can see the source and destination IP addresses as well as the IP header length (20 bytes in this case).



    We can also see the Differentiated Services (DiffServ) area. This would be where extra information relating to the packet's type of service goes. For most packets on a LAN this is set to zero, which means best effort. There are several other levels, such as Expedited Forwarding, which generally has low loss, low delay, and low jitter. Diff Serv levels can be used when looking to implement a Quality of Service on IP networks.


    Transport Layer


    The transport layer is where applications communicate via the use of ports. Looking at the capture shown in Figure, we can see that the source port is 40519, while the destination port is 5001.


    Other areas of interest are the header length (32 bytes in this case) and the sequence number.  The sequence number generally will change for each packet.


    Application Layer


    The final part of the capture is the data part; this is shown in figure below. Here you will see what data is being sent over the medium. This is where you will find applications such as ssh,http,ftp,etc  being used.

    The size of the data part of the frame is 1448 bytes in this case. There is some overhead due to the headers used by TCP, IP and Ethernet. From Figure E, we can see that the actual frame size is 1514 bytes, whereas the size of the data is 1448 bytes. The overhead in this case is 64 bytes. Of this, 12 bytes is Ethernet, 20 bytes is IP and 32 bytes is TCP.



    Troubleshooting Using Packets




    Filters are, without a doubt, the cornerstones of Wireshark. When a large amount of data is captured, the filters enable you to view only the packets that match your search criteria. Filters can be defined as capture filters and view filters depending on the ruling-syntax of each one. Capture filters directly support the libpcap libraries, just like tcpdump or Snort, and depend on them to define the filters. That is why you can use Wireshark to open files generated by tcpdump or by the applications that use them.


    View filters, on the other hand, follow the nomenclature of the application itself and are used to filter results on packets that have been captured previously. If you are not familiar with these types of rules, the button Filters and Expressions, located on both sides of the search input helps you search for the packets you want using the appropriate syntax.


    Several examples of filters are given below30 to show you the possibilities that these filters offer you both for analyzing traffic and resolving network problems.


    Filter Examples

    Example 1:  UDP Packets

    Suppose that you want to view UDP packets that contain a byte sequence of 0x90, 0x90, 0x90, 0x03 from the 8th byte (that is, just after the header), perhaps because certain malware uses this sequence:





    Example 2:  ICMP Packets

    If you decide to use Wireshark due to a frequent loss in connection with your server for no apparent reason or simply notice a decrease in the transfer rate, you should take a closer look at the appearance frequency of ICMP packets and even filter by fields type/code that could be used in an attack that have these symptoms. The following example shows ICMP Protocol Unreachable or Source Quench error messages, commonly used in Connection-blind-reset or Blind-throughput-reduction attacks, respectively.



    (icmp.type == 3 && icmp.code == 2) || (icmp.type == 4 && icmp.code == 0)

    Example 3:  Retransmissions

    There are also filters that show duplicated packets and corresponding retransmissions. These can make a lot of "noise" in your capture, so you may occasionally need to filter them to obtain a cleaner analysis:



    not tcp.analysis.duplicate_ack and not tcp.analysis.retransmission

    Example 4:  Operator contains

    One of the operators that you can get a lot out of is contains. You can use this operator to search for literal text strings in packets received. That way, if you use the following filter:



    (pop contains "PASS") || (http contains "password")



    The PASS and password string in the respective protocols indicated are filtered. The results are detailed in the following figure, which represents the PDU for the selected packet in hexadecimal format and the unprintable characters are represented with a point:


    Example 5:  Directive frame

    If you want to search the segments that contain a specific string you can use the clause frame:



    frame contains “cmd”

    Example 6:  Standard expressions

    To perform a more specific search, you can use the primitive matches in the same way as contains, with the difference that this accepts the same syntax as the standard expressions in Perl (PCRE) and therefore provides more flexible searches.



    For example, if you want to show all URI resource requests containing the word “login” and “=user” you write:



    http.request.uri matches "login.*=user"



    Using the string ".*" you can specify a random set of characters of unknown length, that can even be 0, amongst other patterns. Knowing the syntax of these expressions could save you a lot of time when you have to locate text patterns. There are a number of sources where you can find all type of filters as well as practical examples for analysing traffic. Some of them are on Wireshark wiki, the Alfon blog  or the Juan Garrido blog.


    Example 7:  Scanning netbios ports

    Here is an example that enables you to detect the behaviour common to worms such as the constant scanning of netbios ports:



    dst port 135 or dst port 445 or dst port 1433 and tcp[tcpfl ags] & (tcp-syn) != 0 and tcp[tcpflags] & (tcp-ack) = 0 and src net

    Example 8:  ARP packets

    Let's look at another example, in this case in a wireless environment where you are performing an audit with the aircrack-ng suite and looking for ARP request packets and their corresponding replies (ARP reply) in ethernet clients and wireless clients for their subsequent injection (attack 2 with airplay):



    (wlan.bssid == 00:11:22:33:44:55 and (frame.pkt_len>=68 and frame.pkt_len le 86) and (wlan.da == ff:ff:ff:ff:ff:ff or == 00:22:33:44:55:66))

    Example 9:  HTTP Objects

    Filters give you excellent tracking information on your communications system, as well as being an ideal compliment to analyse a multitude of attacks. If you have the skills to use them, identifying the source of the problem is a lot easier. An example of this is the http.content_type filter that enables you to extract different data flows that occur during an HTTP connection (text/html, application/zip, audio/mpeg, image/gif, etc.) and is very useful in locating malware, exploits and other attacks embedded in this protocol:



    The graphical version of this filter to recover HTTP objects can be found in File > Export > Object > HTTP, enabling you to save the object you want on your machine.




    Follow TCP Stream


    This excellent utility extracts the data flow established in TCP sessions.


    Suppose you want to analyse the send/response of your Apache for a particular host or that you want to purge the functions of a new software based on sockets or test an application using a fuzzer. For this, all you need to do is select a packet that is part of the flow, right-click and select the option Follow TCP Stream.


    Immediately afterwards, a new window opens displaying the extract of this session and its size, using different colours to show the flow direction of each communication. You also have the option of viewing one direction of the connection, as well as the way in which you want this information represented (EBCDIC, Hex Dump, C Array or Raw).


    The following capture corresponds to an exploit launched against an FTP server FTP trying to generate a buffer overflow in one of its entry parameters, in this case the USER parameter.


    Another example is shown in the following image. This corresponds to a Post request performed by Vinself36, a backdoor that uses HTTP to transport its own blind protocol to avoid the IDS.


    You can see the potential of Wireshark with this functionality and that it is not limited to superficial analysis of TCP connections and can be of great help in other fields of malware analysis37, purging of unknown network protocols, errors, etc.



    Expert Information


    When you have a capture with a high number of packets and you are not searching for a specific situation, rather you want to detect the most significant attacks; you cannot limit your activity to filters. To make the identification process of network anomalies easier, you can use the option Expert Info. The main idea of this tool is to show unusual behavior or anomaly situations on the network, such as retransmissions or fragmentation, techniques used to avoid the IDS or fool the systems. This way, you can identify problems with the network more quickly than if you did it manually for all the set of captured packets.


    This information is only a recommendation. A lack of results does not imply that there are no problems. The number of entries shown depends in large part on the protocol used. Whilst protocols commonly used such as TCP/IP show a lot of detailed information, others do not show anything.


    The Experts Info graphical user interface (GUI) is described below. To open the window, use Analyze > Expert Info or click the circle (grey, cyan, yellow or red) in the lower portion of the window of the application to the left.



    Each entry of the result of the analysis contains the following information: critical, group, protocol and summary.


    Description of Wireshark Color Coding

    Critical LevelColorDescription
    Chat (Normal)GreyThis is normal information that helps you understand what has happened, such as a TCP segment with SYN flag.
    NoteCyanNoteworthy situations outside normal functions. For example, an application returns a common error code such as HTTP 404.
    WarningYellowYou should take special care with packets marked in this way, as it could be an attack attempt; for example, an application returns an error code with a connection problem.
    ErrorRedSerious problems with badly formatted packets.


    Wireshark Group Types

    Header 1Header 2
    ChecksumA checksum is not valid
    SequenceSuspect protocol sequences; for example, the sequence number is not continuous or a retransmission has been detected
    Response CodeProblems with application response codes; for example, the response "HTTP 404 Page not found"
    Request CodeA request to an application. For example, "File Handle == x)". Normally shown as critical code, Chat
    No decryptionIncomplete dissection or data that cannot be decrypted for other reasons
    AssemblingProblems with reassembling. For example, not all fragments exist or an exception has occurred during the process
    ProtocolViolations of protocol specification as for example invalid field values or illegal lengths
    Badly formattedBadly formatted packets or during analysis an error occurs and the analysis aborts