Getting Started with Wireshark
As a pentester, always get involved in different projects from different clients and no matter what the objective is, having the knowledge and the proper tool to perform the task will save a lot of time, and avoid some headaches. This article will try to aid for those scenarios where a network analysis should be performed. We will focus in one of the most important tools for a pentester: Wireshark.
For most of the engagements a pen tester could perform, there is always a network component, and being able to see, analyze and store all the network transactions is essential to understand network behaviors and evidence all the performed tasks. For such objectives, Wireshark is what was promised, and more. Looking for a formal definition of Wireshark, as stated in the official website (http://www.wireshark.org/faq.htm), it is a free open-source network protocol analyzer. What does this mean? It means that Wireshark will capture all the traffic it can hear from the selected network interface, parse it and present it to the user in a friendly manner. Within the captures packets, Wireshark will allow us to perform several tasks, such as analyze network problems, get network statistics, and even detect network intrusion attempts. Wireshark runs in most of the operating system available in the market, including Windows, OS X, Linux and UNIX, and it as two different interfaces, allowing users to adapt it to their own requirements; it could be executed in a GUI (Graphic User Interface) or CLI (Command Line Interface). The installation process is really simple, no matter if it’s being performed on Windows, or *nix based systems. Besides Wireshark, the Winpcap library (libpcap in *nix) will be needed to be installed also. If the Windows GUI version is executed, the following screen will be presented:
The main screen is divided in 3 tabs. The one in the left side is related to the capture options, and the list of interfaces in which Wireshark may be able to listen and capture traffic. The middle tab shows the saved Wireshark sessions; and the right one is for the online content, such as the user guide and official website. We will focus on the Capture tab, as the other two are self-explanatory.
In order to capture traffic, we need to specify to Wireshark which network interface(s) we would like to listen. Currently, most computers have more than one network interface, so in case we are unsure of which is the proper one to listen, Wireshark provides an interface list. This option will show all the network interfaces in the computer and the packet count on each of them (The count starts when we access this option). This will make easier to identify the active interfaces, and probably the one with the most count of packets is the one we would like to capture. Clicking on “Details” button, will provide even more information of each network interfaces.
Once proper network interface is identified, just select it in the main screen and click on the “Start” button.Once the Wireshark starts to capture, will show a screen like the following: Figure 3.
This screen is divided in 3 rows, each of this showing different information. The top row is the packet list pane; the middle row is the packet details pane and the bottom one is the packet bytes pane. Let’s talk about each one of them:
Packet list pane (1)
This pane displays all the packets that are being captured during the current session; in case of a previously stored session, it will display all the packets that were saved on that session. Each of the lines within this pane corresponds to one packet that was captured. By selecting one of them, the packet details pane and packet bytes pane will be updated to reflect the content of the selected packet. The default pane configuration contains 7 columns, displaying the following attributes:
• No.: The number of the packet in the capture file. This number is related to the current session only, and is incremented by one for each packet.
• Time: The timestamp of the packet. The default configuration shows the amount of seconds since the beginning of the current session. This value could be changed to reflect the proper date and time instead, such as the UTC time.
• Source: The IP address from where this packet came from. In case that no IP address was available (ARP packets, for example), the name and part of the device’s MAC address is displayed.
• Destination: The IP address where this packet is going to. In case of Broadcast packets, the legend
“Broadcast” is displayed. And similar to “Source” field, if no IP address was available, the name and part of the device’s MAC address is displayed.
• Protocol: Display the protocol used, in a short name version, or abbreviation, if a short name is not
available
• Length: Display the packet length
• Info: Provides additional information about the packet content, such as TCP header fields
More columns could be added as required, depending on the information the user may need to gather, as Wireshark provides the functionality to add custom columns, using the packet fields available. In order to add a column, just right-click on a column name and select the option “Column preferences”. A dialog window will show up with a drop-down list, containing a list of predefined columns. Within this list, a “custom” option is available to define personal filters.
Going back to the packet list pane, by right-clicking on this window, it is possible to access a menu of tasks to perform, including options to filter packets, follow streams, and copy the packets in TXT or CSV formats. One of the functions that can be very helpful if the user is working with TCP or UDP protocols is the Follow TCP Stream or Follow UDP Steam. This function will display the data from a TCP or UDP stream in the way that the application layer understands it. By selecting this function, an automated filter will be applied within the packet list, and a dialog window will show a reconstruction of the messages that were sent and received within this stream.
This window will display the requests to the server in red color, and the responses from the server in blue color. This function is very helpful if the user wants to find some clear text within a particular connection, such as user credentials, or even website cookies. Within this window, there is a search button, to find a particular string within the stream. Also, it is possible to change the character representation between ASCII, EBDCID, hexadecimal, C arrays, or even the raw data
Packet details pane (2)
This pane shows the protocols and protocol fields of the selected packet using a tree structure, which can be expanded and collapsed. Every tree parent is related to a different network layer. This pane will disassemble the packet and display the content of the different layers that compose it. It will parse and show the values of the different fields in each of the protocols involved. In this structure, information like the MAC address of the devices involved and the source and destination port could be observed. By right-clicking on this pane, it is possible to access a menu of tasks similar to the one displayed in the packet list pane.
Packet bytes pane (3)
This pane is divided in 3 different columns to show the raw data of the selected packet, using a hexadecimal notation:
• The left column displays the offset in the packet data;
• The middle column displays the packet data in hexadecimal representation
• The right column displays the corresponding ASCII codification, or the dot “.” character, if there is no ASCII codification to display.
By right-clicking on this pane, it is possible to change the codification from hexadecimal to binary.
Before starting capturing packets, there are two things to analyze.
The first one would like to talk about is the capture options, as this allows to specify the behavior that Wireshark will have related to the captures. Let’s enumerate the most important options available:
• Capture on all interfaces: allows Wireshark to capture on all network interfaces, or to select multiple network interfaces to listen, using the interfaces list that appears above
• Use promiscuous mode on all interfaces: this option allows specifying if Wireshark should activate the promiscuous mode setting in all the network interfaces. We will review this setting later.
• Capture Filter: this field could be used to specify a filter to be applied in all the selected interfaces to listen. This filter will prevent unwanted packets to be captured and stored in the current session; if this field is not completed, no filters will be applying to the interfaces. By clicking in the “Capture filter” button, a dialog will open and show a list of saved filters, giving to the user the alternative to add or delete more filters. This filter is not the same filter that appears in the Wireshark main screen, while a session is in progress. That filter will be explained later.
• File: this field could be used to specify the filename where the session will be stored; if this field is not completed, the session will be stored in a temporary file. By clicking on “Browse” button, a dialog will appear, allowing the user to browse the file system and select the destination of the file.
• Use multiple files: Wireshark has the ability to store the session across multiple files, depending on the criteria provided. By selecting this, four new options will appear as shown below:
• Next file every n mebibyte(s): Specify the maximum size in MiB of the capture file. Once this size is reached, a new file is created.
• Next file every n minute(s): Specify the maximum time a capture file will be used. After this time is reached, a new file is created.
• Ring buffer with n files: Specify the number of files that will be part of a ring buffer. This ring buffer allows to rotate the captures within this number of files.
• Stop capture after n file(s): Specify the maximum number of files that Wireshark will use to store the current session. If this value is reached, the capture will stop.
• Stop Capture Automatically After: this section contains 3 different options to automatically stop the
packets captures.
• n packets: Specify the maximum amount of packets that Wireshark will capture before stopping.
• n mebibyte (s): Specify the maximum amount of MiB that Wireshark will capture before stopping.
• n minute (s): Specify the maximum amount of time that Wireshark will capture packets before
stopping.
• Update list of packets in real time: this option allows the user to specify if Wireshark will update the
packet list pane while the capture is still active, or to not display the packets until the capture is stopped. If this option is enabled, Wireshark will use one process to capture the packets and a different process to display the packets in the packet list pane.
• Automatically scroll in live capture: this option allows the user to specify if Wireshark will perform an automated scroll while new packets are being captured. If this is not enabled, the new packets will not be shown in the packet list pane until the user scroll down.
• Hide capture info dialog: this option allows the user to specify if the info dialog will be displayed meanwhile a capture is in progress. The info dialog will show statistics of the protocols captured, and the time since the capture started
• Resolve MAC Addresses: this option allows the user to specify if the devices MAC address captured
should be resolved into names.
• Resolve network-layer names: this option allows the user to specify if the network-layer names captured should be resolved into names.
• Resolve transport-layer name: this option allows the user to specify if the transport-layer names captured should be translated into protocols.
• Use external network name resolver: this option allows the user to specify if the name resolution will be performed through DNS lookups or not.
The second thing like to analyze before starting to capture packets is the necessity of configuring the
network interface in promiscuous mode. Let’s start with a short review of what is promiscuous mode and then identify whether this is needed or not. If we consider a network environment connected through a hub device, all the packets that came from one host will be sent to all the other hosts within the same network (similar to what happens in a wireless network environment). Every host that receives the packet compares the destination MAC address of the packet to the MAC address of its own network interface. If both MAC addresses match, then the network interface captures the packet and processes it. If the MAC addresses do not match, then the packet is discarded. If the promiscuous mode is enabled, every packet that arrives to the network interface, no matter what its MAC address is, it will be captured from the network. This allows us to capture all traffic that travel in the network. Now that we defined the promiscuous mode, let’s use a more realistic scenario. Today it is not common to find hubs connecting networks; even it is getting difficult if you want to buy a hub in
a computer store. Today’s network uses switches to transmit messages only to the destination, avoiding flooding the network with unnecessary packets, and making it more difficult to sniff traffic. With a switching network, enabling the promiscuous mode will not have any effect, as we are not receiving traffic that is not intended to us. Considering this scenario, if we want to capture all the packets that travel across the network, we probably need to do one of the following: perform and ARP poisoning or connects to a mirroring port. These topics are out of the scope of this article, but I wanted to give a real world scenario before continuing.
Going back to our topic, the main concern is if it is required to listen in promiscuous mode, or not.
There is not correct answer, as it depends of the nature of the tasks to be performed. In case of a network administration that wants to inspect all the traffic that travel across the network, then yes, the promiscuous mode will be necessary. But, if we consider a penetration tester that only wants to identify the traffic between his computer and a website, or a particular server, then this mode is not required, and enabling it will provide a lot of unnecessary traffic.
Now that we have enough information to adapt the Wireshark to our necessities, it is time to start the
sniffing. Once the capturing process is running, the packet list pane will display a lot of traffic, probably more than the desired one. This is when another of the big features of Wireshark comes to play. This tool provides an extensive set of filter options, allowing the user to display only the packets that he wants to see. The filter toolbar is above the packet list pane. By clicking on the “Expression” button, a dialog box will open with a complete list of filters that Wireshark is able to manage.
This list is a very good point to start for those who do not have expertise using Wireshark, as the user can easily select the fields he wants to use in the filters; and it is an excellent way to learn how to write those filters. This dialog is composed of 5 fields, as follows:
• Field Name: this field contains a list of protocols in a tree structure. Every protocol that has fields that could apply as filters are displayed at the top level of the tree. By expanding the protocol tree, the user will be able to get a list of the field names available for that protocol.
• Relation: this is the operator that will apply to this filter. The operators could be logical or comparison. Once a relation is chosen, the user will be able to complete one of the following 3 fields, related to the values.
• Value: this field contains the value that should be compared within the one in the packet, in order to
Wireshark be able to match it. Between will appear the type of value (Character, string, number, etc.).
• Predefined values: for particular protocols and fields, there is a list of predefined values from where the user must select which is the desired one.
• Range: for some protocols it is possible to add a range of values to match with.
Within the filter toolbar there are 3 buttons that perform the following:
• The “Clear” button removes all the filters applied to the packet list pane.
• The “Apply” button use the filter typed in the text box.
• The “Save” button store the filter for a future use.
The text box in the left side of the toolbar could be used to write and apply filters. Instead of looking through the list of filters, the user could easily write the desired ones, if the proper syntax and names are known. Be aware that these filters are case sensitive; for instance, it is not the same thing writing “ip”, than “IP”. The filter contains 3 different items that compose the syntax. There is one field (usually a packet field), one operator and one value. One exception for this syntax is that the operator “is present”, does not require a value to be compare with, as it returns true if the field is present within the packet. For example, if we want to filter only packets from or to the IP address 192.168.0.1, will use the following filter
ip == 192.168.0.1
There is a list of the most common operators used in the filters
Comparison operators
Operator C-like Description
eq == equal to
ne != not equal to
ge >= greater than or equal to
gt > greater than
le <= less than or equal to
lt < less than
matches matches to
contain contains
is present is present
Logical operators
Operator C-like Description
and && AND logical operation
or || OR logical operation
xor ^^ XOR logical operation
not ! NOT logical operation
[...] [...] Substring operator
For some popular filters, instead of writing the ports used for that protocol, the user could write the protocol name instead. For example, it can be written http in the filter textbox, instead of the following rule (this is assuming that in the current session, there are no other http servers in ports besides 80 and 443)
tcp.port == 80 || tcp.port == 443
The list of popular protocols that could be used instead of filtering within the ports used is presented:
arp, bootp, smtp, pop3, dns, smb, ldap, ftp, icmp, imap, nbss
Wireshark also allows the definition of advanced filters that could be used to match specific bytes positions within the required fields. These bytes could be defined by the use of an offset and bytes length. The proper syntax for the advanced filters is shown below, followed by an operator and value to match with:
Packet field or protocol[offset:length]
For example, if I want to filter all the ip packets that contains in the bytes 10 and 11 the values 0x30 and 0x45, the filter will be
ip[10:2] == 30:45
The next list contains some examples of useful filters.
• ip: displays only ip packets.
• tcp.port eq 23 or ftp: displays only packets of ftp and telnet protocols.
• ip.src==192.168.0.0/24 and ip.dst==192.168.0.0/24: displays packets sent between hosts in the same network 192.168.0.0
• ip.addr == 192.168.0.0/24: displays packets from or to the IP range selected. Be aware that this is not the same than the previous one. This filter will display traffic from the LAN to an external host, and vice versa.
• smb || nbns || dcerpc || nbss || dns: displays packets that is usually associated with Windows hosts.
• ls_ads.opnum==0x09: displays packets associated with the Sasser worm.
• eth.addr[0:3]==00:06:5B: displays those packets where the MAC address starts with 0x00, 0x06 and 0x5B. This is useful to filter packets that came from a particular vendor’s network interface.
• http.request.uri matches “le.com$”: displays HTTP packets where the last characters in the URI field are “le.com”.
• not broadcast and not multicast: displays all packets, except broadcast and multicast.
• ether host AA:BB:CC:DD:EE:FF: displays all Ethernet packets that goes to and from the network interface that has that MAC address.
Now that we know how to capture traffic and filter all the undesired packets, it is time to see what we could do with the traffic captured. Wireshark includes a sophisticated traffic analyzer and decoder. As more devices are being connected to personal and business networks, traffic analysis is becoming more important. From identifying a network misuse, to detect an intrusion, the ability to analyze the traffic is crucial for network administrators and security officers. Wireshark provides several functionalities for a better understanding of the traffic captured. These functionalities could be found within the toolbar, in the “statistics” menu. The most important ones will be explained below:
• Summary: this function provides general statistics about the current session. This information includes the timestamps of the first and last packets captured, information about the file where the session it is being saved, and statistics about all the traffic captured, such as amount of packets, average packets per second, and average bytes per second.
• Protocol Hierarchy: this function displays a tree structure of all the protocols captured in the current session. The hierarchy is based on the OSI network model. It will also provide some statistics of amount of packets and size per protocol. Be aware that usually, each packet has more than one protocol (each of them at a different OSI layer) and there are some situations where the same protocol could appear more than once in the same packet. Wireshark will count each of these occurrences as different packets.
• Conversations: this function displays a list of all the conversations captured and statistics for each of one, within the current session. A conversation is the traffic that is sent and received between two specific endpoints. The available tabs within this dialog box will be enabled depending the type of traffic captured and will show the number of conversations captured in the label; if no conversations were captured for a specific protocol, the tab will be greyed out.
• Endpoints: this function displays a list of all the endpoints captured and statistics for each of one, within the current session. An endpoint is each end of a conversation, which means that for each conversation we have identified, there are two endpoints. The available tabs within this dialog box will be enabled depending on the type of traffic captured, and will show the number of endpoints captured in the label; if no endpoints were captured for a specific protocol, the tab will be greyed out.
• IO Graphs: This function displays a customizable graphic. It has up to five different filters that could be applied to be represented in the graphic with a different color. By clicking on the graph, will show the selected packet in the Wireshark main window.
• WLAN Traffic: This function displays statistics of the captured wireless traffic within the current session. In the network overview section, statistics for each of the wireless networks (BSSIDs) will be displayed. By selecting a particular network, this will display information for each client connected to that wireless network and statistics for each of these.
Another good feature of Wireshark is the ability to intercept and reassemble VoIP packets. This functionality is located in the “Telephony” menu within the toolbar. This menu contains different VoIP protocols that could be used to filter packets in the packet list pane, and display only the desired one. Wireshark currently supports the following VoIP signaling protocols, including:
• SIP: Session Initiation Protocol (SIP) is a signaling protocol used to set up, manage and end VoIP
calls, and multimedia conferences. This protocol includes methods such as INVITE and ACCEPT, and responses that indicate if the call was accepted, if it needs to be redirected, or error codes to indicate an abnormal situation.
• H323: is a standard that defines the protocol to provide call signaling and control for multimedia
communication sessions.
• ISUP: ISDN User Part is part of the signaling protocol SS7, used to establish and release phone calls within the PSTN (Public Switched Telephone Network).
• MGCP: Media Gateway Control Protocol (MGCP) is a protocol used to control media gateways that lay on IP networks and are connected to the PSTN.
• Unistim: Unified Networks IP Stimulus is a telecommunications protocol designed by Nortel, used in communications between IP Phones and IP PBX (Private branch exchange).
Wireshark also supports the RTP protocol (Real-Time Transport Protocol) which is the protocol used to actual transmits packets in real time over an IP network. The type of packets supported by this protocol includes audio, video or data, over multicast or unicast network services. It is commonly used in streaming, telephony and even television services. It is used within RTCP (RTP Control Protocol) which monitor transmission statics and quality of service. Now, going back to the “Telephony” menu, the user will see a list of protocols available to select. Once a protocol is selected, a new window will appear, displaying, in most cases, the streams or packet counters depending on the selected protocol. This menu also contains one option that is “VoIP Calls”. By selecting this option, a new window will appear, listing all the calls that were found during the captured session. Different attributes of the calls will be displayed, such as:
• Start Time: start time of the call.
• Stop Time: stop time of the call.
• Initial Speaker: the IP address from the device that initiated the call.
• From: depending on the signaling protocol used, it will display a telephone number or a terminal ID.
• To: depending on the signaling protocol used, it will display a telephone number or a terminal ID.
• Protocol: the protocol used to signal the call.
• Packets: number of packets that were sent and received during the call.
• State: the current state of the call. This value could be:
• CALL SETUP: indicates that the call is being setup.
• RINGING: only for MGCP protocol, indicates that the call is ringing.
• IN CALL: indicates that the call is in place.
• CANCELLED: indicates that the call was canceled before being connected.
• COMPLETED: indicates that the call was ended normally.
• REJECTED: indicates that the call was rejected by the addressee.
• UNKNOWN: indicates that the call is in unknown state.
• Comment: additional comments for the call. If the protocol H323 is being used, this field will indicate if Fast Start or/and H245 Tunneling is being used.
It is possible to filter all the packets for a particular call in the Wireshark packet list pane. In order to do so, within the VoIP window, the user just needs to select the desired call and click on the “Prepare Filter” button. Wireshark will automatically filter only the traffic that is being involved in that particular call. The “flow” button will present a graph analysis of the selected call. This analysis includes which packets were sent and received, at what time this was done, and which protocols were used in each of these packets.
Wireshark also provides a functionality to play the RTP packets captured, that could be accessed from the “Player” button. This option will open a dialog window displaying the actors involved in the call in separate lines and the user could play the reconstruction of the call from each part in a separate way or all the parts together (Figure 9).
If you have captured RTP stream packets, but not the SIP packets, it is probably that Wireshark may not recognize the traffic as RTP. For this scenario, Wireshark provides functionality, allowing the user to try and decode the RTP outside of conversations.
• Finally, but not least important, it’s the ability to decrypt SSL (Secure Socket Layer) traffic. As you may know, SSL is a protocol that provides confidentiality and message integrity through a symmetric and asymmetric algorithm, and it is widely used on public and private networks. It can be used to encapsulate application layer protocols such as HTTP, SMTP, FTP, and so on. Let’s give a quick overview to the SSL handshake, to understand how Wireshark is able to perform this decryption. The client start a connection to an SSL service by sending a ClientHello message, and includes its own SSL client configuration, including the protocol version and cipher settings
• The server receives this message and replies with a ServerHello message, including its own SSL server configuration, including the protocol version, cipher settings, and the server certificate
• The client authenticates the server certificate against the certificate authority. It also generates a master key, encrypts it with the server certificate, and sends to it
• The client and the server use the master key to generate a symmetric session key that will be used to
encrypt and decrypt the information exchanged, and to verity its integrity. The way the symmetric session key is generated depends on the method used for key exchange (Diffie-Hellman, RSA, ECDH, etc.)
This is a quick explanation of how the SSL handshake is being performed. There are more factors involved, but for the purpose of decrypting traffic with Wireshark, this gives a good overview.
There is one warning must say before continuing. Wireshark is not able to decrypt ALL SSL traffic that travel across the network. The SSL protocol provides integrity, and there is no way to decrypt its content. There are a few techniques that could be used to crack this protocol, but only works on specific conditions. Wireshark performs the decryption by having the private key that is being used to encrypt the traffic. There are also a couple more of requirements needed to perform this. The communication must use RSA key to encrypt the data, and the capture must include the handshake process (ClientHello and ServerHello requests).
Within this information Wireshark is able to decrypt the SSL traffic. In order to perform this, the user needs to access the Wireshark preferences, under the “Edit” menu. A dialog window will appear with a tree structure on the left side. Expand the “Protocol” tree, scroll down and select SSL. In the right side of the window, an edit button will appear. By clicking this, a new dialog window will appear; click in “new” within this window; and a new one will be presented, requiring the following information:
• IP address: is the IP address of the server that provides the SSL certificate to the client. Wildcard IP
address could be used (0.0.0.0)
• Port: is the port used by the server to provide the encrypted service. Wildcard port could be used (0)
• Protocol: is the protocol that was encrypted by SSL. Considering a web traffic (HTTPs), the protocol encrypted was HTTP
• Key File: requires the location of the key file. The key must be in PEM or PKCS12 formats
• Password: is the password that was used to protect the key file, if any
After this configuration was saved, just start a new capture, and if everything was completed properly, Wireshark will decrypt all the SSL traffic that was encrypted using the selected certificate
As a pentester, always get involved in different projects from different clients and no matter what the objective is, having the knowledge and the proper tool to perform the task will save a lot of time, and avoid some headaches. This article will try to aid for those scenarios where a network analysis should be performed. We will focus in one of the most important tools for a pentester: Wireshark.
For most of the engagements a pen tester could perform, there is always a network component, and being able to see, analyze and store all the network transactions is essential to understand network behaviors and evidence all the performed tasks. For such objectives, Wireshark is what was promised, and more. Looking for a formal definition of Wireshark, as stated in the official website (http://www.wireshark.org/faq.htm), it is a free open-source network protocol analyzer. What does this mean? It means that Wireshark will capture all the traffic it can hear from the selected network interface, parse it and present it to the user in a friendly manner. Within the captures packets, Wireshark will allow us to perform several tasks, such as analyze network problems, get network statistics, and even detect network intrusion attempts. Wireshark runs in most of the operating system available in the market, including Windows, OS X, Linux and UNIX, and it as two different interfaces, allowing users to adapt it to their own requirements; it could be executed in a GUI (Graphic User Interface) or CLI (Command Line Interface). The installation process is really simple, no matter if it’s being performed on Windows, or *nix based systems. Besides Wireshark, the Winpcap library (libpcap in *nix) will be needed to be installed also. If the Windows GUI version is executed, the following screen will be presented:
The main screen is divided in 3 tabs. The one in the left side is related to the capture options, and the list of interfaces in which Wireshark may be able to listen and capture traffic. The middle tab shows the saved Wireshark sessions; and the right one is for the online content, such as the user guide and official website. We will focus on the Capture tab, as the other two are self-explanatory.
In order to capture traffic, we need to specify to Wireshark which network interface(s) we would like to listen. Currently, most computers have more than one network interface, so in case we are unsure of which is the proper one to listen, Wireshark provides an interface list. This option will show all the network interfaces in the computer and the packet count on each of them (The count starts when we access this option). This will make easier to identify the active interfaces, and probably the one with the most count of packets is the one we would like to capture. Clicking on “Details” button, will provide even more information of each network interfaces.
Once proper network interface is identified, just select it in the main screen and click on the “Start” button.Once the Wireshark starts to capture, will show a screen like the following: Figure 3.
This screen is divided in 3 rows, each of this showing different information. The top row is the packet list pane; the middle row is the packet details pane and the bottom one is the packet bytes pane. Let’s talk about each one of them:
Packet list pane (1)
This pane displays all the packets that are being captured during the current session; in case of a previously stored session, it will display all the packets that were saved on that session. Each of the lines within this pane corresponds to one packet that was captured. By selecting one of them, the packet details pane and packet bytes pane will be updated to reflect the content of the selected packet. The default pane configuration contains 7 columns, displaying the following attributes:
• No.: The number of the packet in the capture file. This number is related to the current session only, and is incremented by one for each packet.
• Time: The timestamp of the packet. The default configuration shows the amount of seconds since the beginning of the current session. This value could be changed to reflect the proper date and time instead, such as the UTC time.
• Source: The IP address from where this packet came from. In case that no IP address was available (ARP packets, for example), the name and part of the device’s MAC address is displayed.
• Destination: The IP address where this packet is going to. In case of Broadcast packets, the legend
“Broadcast” is displayed. And similar to “Source” field, if no IP address was available, the name and part of the device’s MAC address is displayed.
• Protocol: Display the protocol used, in a short name version, or abbreviation, if a short name is not
available
• Length: Display the packet length
• Info: Provides additional information about the packet content, such as TCP header fields
More columns could be added as required, depending on the information the user may need to gather, as Wireshark provides the functionality to add custom columns, using the packet fields available. In order to add a column, just right-click on a column name and select the option “Column preferences”. A dialog window will show up with a drop-down list, containing a list of predefined columns. Within this list, a “custom” option is available to define personal filters.
Going back to the packet list pane, by right-clicking on this window, it is possible to access a menu of tasks to perform, including options to filter packets, follow streams, and copy the packets in TXT or CSV formats. One of the functions that can be very helpful if the user is working with TCP or UDP protocols is the Follow TCP Stream or Follow UDP Steam. This function will display the data from a TCP or UDP stream in the way that the application layer understands it. By selecting this function, an automated filter will be applied within the packet list, and a dialog window will show a reconstruction of the messages that were sent and received within this stream.
This window will display the requests to the server in red color, and the responses from the server in blue color. This function is very helpful if the user wants to find some clear text within a particular connection, such as user credentials, or even website cookies. Within this window, there is a search button, to find a particular string within the stream. Also, it is possible to change the character representation between ASCII, EBDCID, hexadecimal, C arrays, or even the raw data
Packet details pane (2)
This pane shows the protocols and protocol fields of the selected packet using a tree structure, which can be expanded and collapsed. Every tree parent is related to a different network layer. This pane will disassemble the packet and display the content of the different layers that compose it. It will parse and show the values of the different fields in each of the protocols involved. In this structure, information like the MAC address of the devices involved and the source and destination port could be observed. By right-clicking on this pane, it is possible to access a menu of tasks similar to the one displayed in the packet list pane.
Packet bytes pane (3)
This pane is divided in 3 different columns to show the raw data of the selected packet, using a hexadecimal notation:
• The left column displays the offset in the packet data;
• The middle column displays the packet data in hexadecimal representation
• The right column displays the corresponding ASCII codification, or the dot “.” character, if there is no ASCII codification to display.
By right-clicking on this pane, it is possible to change the codification from hexadecimal to binary.
Before starting capturing packets, there are two things to analyze.
The first one would like to talk about is the capture options, as this allows to specify the behavior that Wireshark will have related to the captures. Let’s enumerate the most important options available:
• Capture on all interfaces: allows Wireshark to capture on all network interfaces, or to select multiple network interfaces to listen, using the interfaces list that appears above
• Use promiscuous mode on all interfaces: this option allows specifying if Wireshark should activate the promiscuous mode setting in all the network interfaces. We will review this setting later.
• Capture Filter: this field could be used to specify a filter to be applied in all the selected interfaces to listen. This filter will prevent unwanted packets to be captured and stored in the current session; if this field is not completed, no filters will be applying to the interfaces. By clicking in the “Capture filter” button, a dialog will open and show a list of saved filters, giving to the user the alternative to add or delete more filters. This filter is not the same filter that appears in the Wireshark main screen, while a session is in progress. That filter will be explained later.
• File: this field could be used to specify the filename where the session will be stored; if this field is not completed, the session will be stored in a temporary file. By clicking on “Browse” button, a dialog will appear, allowing the user to browse the file system and select the destination of the file.
• Use multiple files: Wireshark has the ability to store the session across multiple files, depending on the criteria provided. By selecting this, four new options will appear as shown below:
• Next file every n mebibyte(s): Specify the maximum size in MiB of the capture file. Once this size is reached, a new file is created.
• Next file every n minute(s): Specify the maximum time a capture file will be used. After this time is reached, a new file is created.
• Ring buffer with n files: Specify the number of files that will be part of a ring buffer. This ring buffer allows to rotate the captures within this number of files.
• Stop capture after n file(s): Specify the maximum number of files that Wireshark will use to store the current session. If this value is reached, the capture will stop.
• Stop Capture Automatically After: this section contains 3 different options to automatically stop the
packets captures.
• n packets: Specify the maximum amount of packets that Wireshark will capture before stopping.
• n mebibyte (s): Specify the maximum amount of MiB that Wireshark will capture before stopping.
• n minute (s): Specify the maximum amount of time that Wireshark will capture packets before
stopping.
• Update list of packets in real time: this option allows the user to specify if Wireshark will update the
packet list pane while the capture is still active, or to not display the packets until the capture is stopped. If this option is enabled, Wireshark will use one process to capture the packets and a different process to display the packets in the packet list pane.
• Automatically scroll in live capture: this option allows the user to specify if Wireshark will perform an automated scroll while new packets are being captured. If this is not enabled, the new packets will not be shown in the packet list pane until the user scroll down.
• Hide capture info dialog: this option allows the user to specify if the info dialog will be displayed meanwhile a capture is in progress. The info dialog will show statistics of the protocols captured, and the time since the capture started
• Resolve MAC Addresses: this option allows the user to specify if the devices MAC address captured
should be resolved into names.
• Resolve network-layer names: this option allows the user to specify if the network-layer names captured should be resolved into names.
• Resolve transport-layer name: this option allows the user to specify if the transport-layer names captured should be translated into protocols.
• Use external network name resolver: this option allows the user to specify if the name resolution will be performed through DNS lookups or not.
The second thing like to analyze before starting to capture packets is the necessity of configuring the
network interface in promiscuous mode. Let’s start with a short review of what is promiscuous mode and then identify whether this is needed or not. If we consider a network environment connected through a hub device, all the packets that came from one host will be sent to all the other hosts within the same network (similar to what happens in a wireless network environment). Every host that receives the packet compares the destination MAC address of the packet to the MAC address of its own network interface. If both MAC addresses match, then the network interface captures the packet and processes it. If the MAC addresses do not match, then the packet is discarded. If the promiscuous mode is enabled, every packet that arrives to the network interface, no matter what its MAC address is, it will be captured from the network. This allows us to capture all traffic that travel in the network. Now that we defined the promiscuous mode, let’s use a more realistic scenario. Today it is not common to find hubs connecting networks; even it is getting difficult if you want to buy a hub in
a computer store. Today’s network uses switches to transmit messages only to the destination, avoiding flooding the network with unnecessary packets, and making it more difficult to sniff traffic. With a switching network, enabling the promiscuous mode will not have any effect, as we are not receiving traffic that is not intended to us. Considering this scenario, if we want to capture all the packets that travel across the network, we probably need to do one of the following: perform and ARP poisoning or connects to a mirroring port. These topics are out of the scope of this article, but I wanted to give a real world scenario before continuing.
Going back to our topic, the main concern is if it is required to listen in promiscuous mode, or not.
There is not correct answer, as it depends of the nature of the tasks to be performed. In case of a network administration that wants to inspect all the traffic that travel across the network, then yes, the promiscuous mode will be necessary. But, if we consider a penetration tester that only wants to identify the traffic between his computer and a website, or a particular server, then this mode is not required, and enabling it will provide a lot of unnecessary traffic.
Now that we have enough information to adapt the Wireshark to our necessities, it is time to start the
sniffing. Once the capturing process is running, the packet list pane will display a lot of traffic, probably more than the desired one. This is when another of the big features of Wireshark comes to play. This tool provides an extensive set of filter options, allowing the user to display only the packets that he wants to see. The filter toolbar is above the packet list pane. By clicking on the “Expression” button, a dialog box will open with a complete list of filters that Wireshark is able to manage.
This list is a very good point to start for those who do not have expertise using Wireshark, as the user can easily select the fields he wants to use in the filters; and it is an excellent way to learn how to write those filters. This dialog is composed of 5 fields, as follows:
• Field Name: this field contains a list of protocols in a tree structure. Every protocol that has fields that could apply as filters are displayed at the top level of the tree. By expanding the protocol tree, the user will be able to get a list of the field names available for that protocol.
• Relation: this is the operator that will apply to this filter. The operators could be logical or comparison. Once a relation is chosen, the user will be able to complete one of the following 3 fields, related to the values.
• Value: this field contains the value that should be compared within the one in the packet, in order to
Wireshark be able to match it. Between will appear the type of value (Character, string, number, etc.).
• Predefined values: for particular protocols and fields, there is a list of predefined values from where the user must select which is the desired one.
• Range: for some protocols it is possible to add a range of values to match with.
Within the filter toolbar there are 3 buttons that perform the following:
• The “Clear” button removes all the filters applied to the packet list pane.
• The “Apply” button use the filter typed in the text box.
• The “Save” button store the filter for a future use.
The text box in the left side of the toolbar could be used to write and apply filters. Instead of looking through the list of filters, the user could easily write the desired ones, if the proper syntax and names are known. Be aware that these filters are case sensitive; for instance, it is not the same thing writing “ip”, than “IP”. The filter contains 3 different items that compose the syntax. There is one field (usually a packet field), one operator and one value. One exception for this syntax is that the operator “is present”, does not require a value to be compare with, as it returns true if the field is present within the packet. For example, if we want to filter only packets from or to the IP address 192.168.0.1, will use the following filter
ip == 192.168.0.1
There is a list of the most common operators used in the filters
Comparison operators
Operator C-like Description
eq == equal to
ne != not equal to
ge >= greater than or equal to
gt > greater than
le <= less than or equal to
lt < less than
matches matches to
contain contains
is present is present
Logical operators
Operator C-like Description
and && AND logical operation
or || OR logical operation
xor ^^ XOR logical operation
not ! NOT logical operation
[...] [...] Substring operator
For some popular filters, instead of writing the ports used for that protocol, the user could write the protocol name instead. For example, it can be written http in the filter textbox, instead of the following rule (this is assuming that in the current session, there are no other http servers in ports besides 80 and 443)
tcp.port == 80 || tcp.port == 443
The list of popular protocols that could be used instead of filtering within the ports used is presented:
arp, bootp, smtp, pop3, dns, smb, ldap, ftp, icmp, imap, nbss
Wireshark also allows the definition of advanced filters that could be used to match specific bytes positions within the required fields. These bytes could be defined by the use of an offset and bytes length. The proper syntax for the advanced filters is shown below, followed by an operator and value to match with:
Packet field or protocol[offset:length]
For example, if I want to filter all the ip packets that contains in the bytes 10 and 11 the values 0x30 and 0x45, the filter will be
ip[10:2] == 30:45
The next list contains some examples of useful filters.
• ip: displays only ip packets.
• tcp.port eq 23 or ftp: displays only packets of ftp and telnet protocols.
• ip.src==192.168.0.0/24 and ip.dst==192.168.0.0/24: displays packets sent between hosts in the same network 192.168.0.0
• ip.addr == 192.168.0.0/24: displays packets from or to the IP range selected. Be aware that this is not the same than the previous one. This filter will display traffic from the LAN to an external host, and vice versa.
• smb || nbns || dcerpc || nbss || dns: displays packets that is usually associated with Windows hosts.
• ls_ads.opnum==0x09: displays packets associated with the Sasser worm.
• eth.addr[0:3]==00:06:5B: displays those packets where the MAC address starts with 0x00, 0x06 and 0x5B. This is useful to filter packets that came from a particular vendor’s network interface.
• http.request.uri matches “le.com$”: displays HTTP packets where the last characters in the URI field are “le.com”.
• not broadcast and not multicast: displays all packets, except broadcast and multicast.
• ether host AA:BB:CC:DD:EE:FF: displays all Ethernet packets that goes to and from the network interface that has that MAC address.
Now that we know how to capture traffic and filter all the undesired packets, it is time to see what we could do with the traffic captured. Wireshark includes a sophisticated traffic analyzer and decoder. As more devices are being connected to personal and business networks, traffic analysis is becoming more important. From identifying a network misuse, to detect an intrusion, the ability to analyze the traffic is crucial for network administrators and security officers. Wireshark provides several functionalities for a better understanding of the traffic captured. These functionalities could be found within the toolbar, in the “statistics” menu. The most important ones will be explained below:
• Summary: this function provides general statistics about the current session. This information includes the timestamps of the first and last packets captured, information about the file where the session it is being saved, and statistics about all the traffic captured, such as amount of packets, average packets per second, and average bytes per second.
• Protocol Hierarchy: this function displays a tree structure of all the protocols captured in the current session. The hierarchy is based on the OSI network model. It will also provide some statistics of amount of packets and size per protocol. Be aware that usually, each packet has more than one protocol (each of them at a different OSI layer) and there are some situations where the same protocol could appear more than once in the same packet. Wireshark will count each of these occurrences as different packets.
• Conversations: this function displays a list of all the conversations captured and statistics for each of one, within the current session. A conversation is the traffic that is sent and received between two specific endpoints. The available tabs within this dialog box will be enabled depending the type of traffic captured and will show the number of conversations captured in the label; if no conversations were captured for a specific protocol, the tab will be greyed out.
• Endpoints: this function displays a list of all the endpoints captured and statistics for each of one, within the current session. An endpoint is each end of a conversation, which means that for each conversation we have identified, there are two endpoints. The available tabs within this dialog box will be enabled depending on the type of traffic captured, and will show the number of endpoints captured in the label; if no endpoints were captured for a specific protocol, the tab will be greyed out.
• IO Graphs: This function displays a customizable graphic. It has up to five different filters that could be applied to be represented in the graphic with a different color. By clicking on the graph, will show the selected packet in the Wireshark main window.
• WLAN Traffic: This function displays statistics of the captured wireless traffic within the current session. In the network overview section, statistics for each of the wireless networks (BSSIDs) will be displayed. By selecting a particular network, this will display information for each client connected to that wireless network and statistics for each of these.
Another good feature of Wireshark is the ability to intercept and reassemble VoIP packets. This functionality is located in the “Telephony” menu within the toolbar. This menu contains different VoIP protocols that could be used to filter packets in the packet list pane, and display only the desired one. Wireshark currently supports the following VoIP signaling protocols, including:
• SIP: Session Initiation Protocol (SIP) is a signaling protocol used to set up, manage and end VoIP
calls, and multimedia conferences. This protocol includes methods such as INVITE and ACCEPT, and responses that indicate if the call was accepted, if it needs to be redirected, or error codes to indicate an abnormal situation.
• H323: is a standard that defines the protocol to provide call signaling and control for multimedia
communication sessions.
• ISUP: ISDN User Part is part of the signaling protocol SS7, used to establish and release phone calls within the PSTN (Public Switched Telephone Network).
• MGCP: Media Gateway Control Protocol (MGCP) is a protocol used to control media gateways that lay on IP networks and are connected to the PSTN.
• Unistim: Unified Networks IP Stimulus is a telecommunications protocol designed by Nortel, used in communications between IP Phones and IP PBX (Private branch exchange).
Wireshark also supports the RTP protocol (Real-Time Transport Protocol) which is the protocol used to actual transmits packets in real time over an IP network. The type of packets supported by this protocol includes audio, video or data, over multicast or unicast network services. It is commonly used in streaming, telephony and even television services. It is used within RTCP (RTP Control Protocol) which monitor transmission statics and quality of service. Now, going back to the “Telephony” menu, the user will see a list of protocols available to select. Once a protocol is selected, a new window will appear, displaying, in most cases, the streams or packet counters depending on the selected protocol. This menu also contains one option that is “VoIP Calls”. By selecting this option, a new window will appear, listing all the calls that were found during the captured session. Different attributes of the calls will be displayed, such as:
• Start Time: start time of the call.
• Stop Time: stop time of the call.
• Initial Speaker: the IP address from the device that initiated the call.
• From: depending on the signaling protocol used, it will display a telephone number or a terminal ID.
• To: depending on the signaling protocol used, it will display a telephone number or a terminal ID.
• Protocol: the protocol used to signal the call.
• Packets: number of packets that were sent and received during the call.
• State: the current state of the call. This value could be:
• CALL SETUP: indicates that the call is being setup.
• RINGING: only for MGCP protocol, indicates that the call is ringing.
• IN CALL: indicates that the call is in place.
• CANCELLED: indicates that the call was canceled before being connected.
• COMPLETED: indicates that the call was ended normally.
• REJECTED: indicates that the call was rejected by the addressee.
• UNKNOWN: indicates that the call is in unknown state.
• Comment: additional comments for the call. If the protocol H323 is being used, this field will indicate if Fast Start or/and H245 Tunneling is being used.
It is possible to filter all the packets for a particular call in the Wireshark packet list pane. In order to do so, within the VoIP window, the user just needs to select the desired call and click on the “Prepare Filter” button. Wireshark will automatically filter only the traffic that is being involved in that particular call. The “flow” button will present a graph analysis of the selected call. This analysis includes which packets were sent and received, at what time this was done, and which protocols were used in each of these packets.
Wireshark also provides a functionality to play the RTP packets captured, that could be accessed from the “Player” button. This option will open a dialog window displaying the actors involved in the call in separate lines and the user could play the reconstruction of the call from each part in a separate way or all the parts together (Figure 9).
If you have captured RTP stream packets, but not the SIP packets, it is probably that Wireshark may not recognize the traffic as RTP. For this scenario, Wireshark provides functionality, allowing the user to try and decode the RTP outside of conversations.
• Finally, but not least important, it’s the ability to decrypt SSL (Secure Socket Layer) traffic. As you may know, SSL is a protocol that provides confidentiality and message integrity through a symmetric and asymmetric algorithm, and it is widely used on public and private networks. It can be used to encapsulate application layer protocols such as HTTP, SMTP, FTP, and so on. Let’s give a quick overview to the SSL handshake, to understand how Wireshark is able to perform this decryption. The client start a connection to an SSL service by sending a ClientHello message, and includes its own SSL client configuration, including the protocol version and cipher settings
• The server receives this message and replies with a ServerHello message, including its own SSL server configuration, including the protocol version, cipher settings, and the server certificate
• The client authenticates the server certificate against the certificate authority. It also generates a master key, encrypts it with the server certificate, and sends to it
• The client and the server use the master key to generate a symmetric session key that will be used to
encrypt and decrypt the information exchanged, and to verity its integrity. The way the symmetric session key is generated depends on the method used for key exchange (Diffie-Hellman, RSA, ECDH, etc.)
This is a quick explanation of how the SSL handshake is being performed. There are more factors involved, but for the purpose of decrypting traffic with Wireshark, this gives a good overview.
There is one warning must say before continuing. Wireshark is not able to decrypt ALL SSL traffic that travel across the network. The SSL protocol provides integrity, and there is no way to decrypt its content. There are a few techniques that could be used to crack this protocol, but only works on specific conditions. Wireshark performs the decryption by having the private key that is being used to encrypt the traffic. There are also a couple more of requirements needed to perform this. The communication must use RSA key to encrypt the data, and the capture must include the handshake process (ClientHello and ServerHello requests).
Within this information Wireshark is able to decrypt the SSL traffic. In order to perform this, the user needs to access the Wireshark preferences, under the “Edit” menu. A dialog window will appear with a tree structure on the left side. Expand the “Protocol” tree, scroll down and select SSL. In the right side of the window, an edit button will appear. By clicking this, a new dialog window will appear; click in “new” within this window; and a new one will be presented, requiring the following information:
• IP address: is the IP address of the server that provides the SSL certificate to the client. Wildcard IP
address could be used (0.0.0.0)
• Port: is the port used by the server to provide the encrypted service. Wildcard port could be used (0)
• Protocol: is the protocol that was encrypted by SSL. Considering a web traffic (HTTPs), the protocol encrypted was HTTP
• Key File: requires the location of the key file. The key must be in PEM or PKCS12 formats
• Password: is the password that was used to protect the key file, if any
After this configuration was saved, just start a new capture, and if everything was completed properly, Wireshark will decrypt all the SSL traffic that was encrypted using the selected certificate