Cybersecurity Tutorials

Wireshark Tutorial: Identifying Hosts and Users

Clock Icon 10 min read

This post is also available in: 日本語 (Japanese)

Executive Summary

When a host within an organization's network is infected or otherwise compromised, responders need to quickly identify the affected host and user. In some organizations, this could involve reviewing a packet capture (pcap) of network traffic generated by the affected host.

This tutorial uses Wireshark to identify host and user data in pcaps. This is the third in a series of tutorials that provide tips and tricks to help security professionals more effectively use Wireshark. This article was first published in March 2019 and is being updated for 2023.

Related Unit 42 Topics pcap, Wireshark, Wireshark Tutorial

Requirements and Supporting Material

To fully understand this tutorial, readers should have reviewed the material in our previous tutorials on customizing Wireshark’s column display and using display filter expressions. Requirements also include a recent version of Wireshark, at least version 3.6.2 or later.

This tutorial features Wireshark version 4.0.8 with a customized column display from our previous tutorials. We strongly recommend using the most recent version of Wireshark available for your operating system (OS).

To follow this tutorial, readers should have a basic understanding of network traffic.

The pcaps used for this tutorial are in a password-protected ZIP archive located at our GitHub repository. Download the file named Wireshark-tutorial-identifying-hosts-and-users-5-pcaps.zip. Use infected as the password and extract the five pcaps, as shown below in Figure 1.

Image 1 is a screenshot of the Palo Alto Networks Unit 42 Wireshark tutorials GitHub. A black arrow indicates to hit the download button on the page. A second black arrow points to the “password required” popup after selecting the zip file in the downloads folder. The password is entered. A final black arrow points to the contents of the zip file.
Figure 1. Acquiring the pcaps for this tutorial.

The five extracted pcaps are:

  • Wireshark-tutorial-identifying-hosts-and-users-1-of-5.pcap
  • Wireshark-tutorial-identifying-hosts-and-users-2-of-5.pcap
  • Wireshark-tutorial-identifying-hosts-and-users-3-of-5.pcap
  • Wireshark-tutorial-identifying-hosts-and-users-4-of-5.pcap
  • Wireshark-tutorial-identifying-hosts-and-users-5-of-5.pcap

Host Information from Dynamic Host Configuration Protocol (DHCP) Traffic

Any host generating traffic within a network should have three identifiers: a MAC address, an IP address and a hostname.

Our first pcap for this tutorial is Wireshark-tutorial-identifying-hosts-and-users-1-of-5.pcap. This pcap is based on traffic to and from an Ethernet address at f8:ff:c2:04:a5:7b.

Using our basic web filter, we can correlate the IP address at 172.16.1[.]38 with its associated MAC address at f8:ff:c2:04:a5:7b, as shown below in Figure 2.

Image 2 is a Wireshark screenshot where the Src column is highlighted by a black rectangle. An arrow highlights the source MAC address in the lower pane. Another arrow highlights the source IP address.
Figure 2. Correlating an IP address with a MAC address.

DHCP traffic might reveal the hostname using this IP address. First, type dhcp in the Wireshark filter bar to filter for DHCP traffic, as shown below in Figure 3.

Image 3 is a Wireshark screenshot of the dhcp filter traffic.
Figure 3. Filtering on DHCP traffic in Wireshark.

Select the first frame in the results, the one that displays DHCP Request in the Info column. Then go to the frame details section and expand the line for Dynamic Host Configuration Protocol (Request), as shown below in Figure 4.

Image 4 is a Wireshark screenshot. The filter is dhcp. A certain row is selected (dark blue) in the top pane as indicated by an arrow. This expands the information in the bottom pane to show the Dynamic Host Configuration Protocol line.
Figure 4. Expanding the Dynamic Host Configuration Protocol line from a DHCP request.

Scroll down the frame details section, then expand the lines for Option: (50) Requested IP Address and Option: (12) Host Name as indicated below in Figure 5. This reveals the client’s MAC address at f8:ff:c2:04:a5:7b with hostname jeremiahs-MBP and a requested IP address of 172.16.1[.]38.

Image 5 is a Wireshark screenshot of dhcp traffic. Highlighted in red from top to bottom is: the client MAC address, the requested IP address, and the host name which is Jeremiahs-MBP.
Figure 5. Correlating the MAC address, IP address and hostname from DHCP traffic.

By default, Wireshark attempts to resolve the first 3 bytes of a MAC address to a vendor identification. In Figure 5, the vendor identification of the MAC address shows Apple_. That and the hostname ending with MBP indicate this might be an Apple MacBook Pro. This pcap also contains traffic to various Apple domains, further indicating this is an Apple host.

However, mobile devices often anonymize MAC addresses and users can easily change these to spoof different vendors. Due to anonymization and spoofing, we should never base host identification solely on a MAC address.

Host Information from NetBIOS Name Service (NBNS) Traffic

Depending on how frequently a DHCP lease is renewed, we might not have DHCP traffic in our pcap. Fortunately, we can use NBNS traffic to identify hostnames for computers running Microsoft Windows or Apple hosts running macOS.

Filter on nbns for our first pcap and review details under the Info column. This should reveal the same hostname we previously found in the DHCP traffic, displaying JEREMIAHS-MBP, as noted below in Figure 6.

Image 6 is a Wireshark screenshot. The filter is set to nbns. Black arrows indicate how to find the host name from the traffic, Jeremiahs-MBP.
Figure 6. Finding the hostname from NBNS traffic in our first pcap.

To examine NBNS traffic from a Windows host, open our second pcap Wireshark-tutorial-identifying-hosts-and-users-2-of-5.pcap and filter on nbns.

This pcap is from a MAC address at 78:c2:3b:b8:93:e8 using an internal IP address of 172.16.1[.]101. The Windows hostname is DESKTOP-HVKYP4S as shown below in Figure 7.

Image 7 is a Wireshark screenshot. The source column is highlight with a black retable. The MAC address is indicated in the lower pane starting with the line Ethernet II. The IP address is indicated in both the Src column and in the lower pane. The host are is also dettifiable under Additional records in the lower pane.
Figure 7. Correlating the MAC address, IP address and hostname filtering on NBNS traffic.

Device Models and Operating System (OS) from HTTP Traffic

Unencrypted HTTP traffic to a web browser can reveal the OS. This information is contained in the User-Agent line from the HTTP request headers.

However, use this method with caution. Certain browser extensions or a tool like cURL can easily change or spoof the User-Agent line in HTTP traffic. Various malware samples over the past several years have also spoofed the User-Agent line in their command and control traffic.

In 2023, this method has become unreliable because browser developers are reducing information contained in the User-Agent line, so most up-to-date web browsers no longer report the actual OS version used by the host.

While increasingly unreliable, this method can still help identify the platform type (Windows, Apple device, Linux or Android) from browser-generated unencrypted HTTP traffic.

Open our third pcap Wireshark-tutorial-identifying-hosts-and-users-3-of-5.pcap in Wireshark. A Windows host generated this traffic in an environment with both IPv4 and IPv6 enabled.

We can find unencrypted web traffic to a web browser by filtering on http.accept_language. This reveals all HTTP requests with an Accept-Language header line commonly generated by web browsers.

This filter avoids web traffic generated by the OS and other applications, so we can focus on any unencrypted HTTP traffic generated by a browser. The results reveal several unencrypted HTTP GET requests to outdoornebraska[.]gov over TCP port 80 as shown below in Figure 8.

Image 8 is a Wireshark screenshot. The traffic filter is http.accept_language. This shows unencrypted traffic to a web browser.
Figure 8. Filtering on our third pcap for unencrypted HTTP traffic to a web browser.

Select any of the HTTP GET requests to outdoornebraska[.]gov and follow the TCP stream, as shown below in Figure 9.

Image 9 is a Wireshark screenshot. he traffic filter is http.accept_language. By selecting a row (dark blue) from the menu the end user can select Follow and then TCP stream.
Figure 9. Following the TCP stream for an HTTP GET request to outdoornebraska[.]gov.
This TCP stream has HTTP request headers with a User-Agent line shown in Figure 10. This User-Agent line was generated by the Microsoft Edge web browser version 110.0.1587.69 from a Windows 11 host on March 10, 2023.

Image 10 is a screenshot of the Wireshark TCP stream window. Highlighted by a black rectangle and an arrow is the User-Agent string.
Figure 10. TCP stream with the User-Agent line generated by Microsoft Edge.

Note the following string in the User-Agent line above in Figure 10:

(Windows NT 10.0; Win64; x64)

Windows NT 10.0 represents either Windows 10 or Windows 11. For User-Agent lines, these Windows NT strings represent different versions of Microsoft Windows noted below in Table 1.

Windows NT version Windows OS Version
Windows NT 5.1 Windows XP
Windows NT 6.0 Windows Vista
Windows NT 6.1 Windows 7
Windows NT 6.2 Windows 8
Windows NT 6.3 Windows 8.1
Windows NT 10.0 Windows 10 or Windows 11

Table 1. “Windows NT” lines and the associated versions of Microsoft Windows.

Why does Windows NT 10.0 represent either Windows 10 or Windows 11 in Table 1? As part of a User-Agent reduction effort, developers for web browsers like Chrome, Edge and Firefox have frozen the Windows version number in their User-Agent lines at Windows NT 10.0. Starting sometime in 2023, the most current versions of Google’s Chrome browser will now report any version of Windows as Windows NT 10.0 in the User-Agent line.

This has also happened with Apple’s macOS, where User-Agent lines generated by web browsers in current versions of macOS have been frozen to report macOS as Catalina (version 10.15.7) in the HTTP request headers.

As noted earlier, unencrypted HTTP traffic from our third pcap was generated using the Microsoft Edge web browser version 110.0.1587.69. From the same TCP stream shown earlier in Figure 9, the final characters of the User-Agent line are Edg/110.0.1587.69 as indicated below in Figure 11. The Chromium-based version of Microsoft Edge uses the truncated term Edg as an identifier.

Image 11 is a screenshot of the Wireshark TCP stream window. Highlighted by a black rectangle and an arrow is the User-Agent string. The final characters identify the web browser (Edg/110.0.1587.69) which in this case is Microsoft Edge.
Figure 11. TCP stream with the User-Agent line and its final characters that identify the web browser.

User-Agent lines generated by Google Chrome or Chromium-based web browsers like Microsoft Edge include strings for Safari and AppleWebKit. This is most likely to ensure compatibility when viewing pages optimized for Apple’s Safari web browser.

Unencrypted HTTP web traffic generated by Android devices might also reveal the brand name and model of the device.

Open our fourth pcap Wireshark-tutorial-identifying-hosts-and-users-4-of-5.pcap in Wireshark. Use our basic web filter, select the first HTTP GET request for www.pcapworkshop[.]net and follow the TCP stream as illustrated below in Figure 12.

Image 12 is a Wireshark screenshot. The filter is set to (http.request or tls.handshael.type eq 1) and !(ssdp). The filter selection is “Basic.” One of the rows in the traffic is selected. Follow > TCP Stream is selected from the menu.
Figure 12. Our fourth pcap filtered Wireshark, where we follow a TCP stream.

This activity was captured from a Google Pixel Android phone, and the web traffic to www.pcapworkshop[.]net was generated using Google’s Chrome browser for Android phones and tablets. The TCP stream for this web traffic is shown below in Figure 13, highlighting the User-Agent line that identifies the device and browser.

Image 13 is a screenshot of the Wireshark TCP stream window. Highlighted by a black rectangle and an arrow is the User-Agent string. Identified in the string is Linux; Android 13; Pixel 4a (5G).
Figure 13. TCP stream with the User-Agent line generated by Chrome running on a Pixel phone.

Collected on May 14, 2023, this traffic reveals (Linux; Android 13; Pixel 4a (5G)) in the User-Agent line. Current versions of Chrome will now report this same device as (Linux; Android 10; K) because of Google’s User-Agent reduction effort.

While User-Agent reduction applies to Android devices running Chrome or Chromium-based browsers, we did not notice any reduction when using the Safari browser on an Apple mobile device.

Open our fifth pcap Wireshark-tutorial-identifying-hosts-and-users-5-of-5.pcap in Wireshark. Use our basic web filter, select the first HTTP GET request for www.pcapworkshop[.]net and follow the TCP stream as shown below in Figure 14.

Image 14 is a Wireshark screenshot. The filter is set to (hhtp.request or tls.handshael.type eq 1) and !(ssdp). The filter selection is “Basic.” The pcapworkshop[.]net row in the traffic is selected. Follow > TCP Stream is selected from the menu.
Figure 14. Our fifth pcap filtered Wireshark, where we follow a TCP stream.
This activity was captured from an Apple iPhone running iOS 16.4.1, and the web traffic to www.pcapworkshop[.]net was generated using Apple’s Safari mobile web browser on April 10, 2023. The TCP stream for this web traffic is shown below in Figure 15, highlighting the User-Agent line that identifies the device and OS version.

Image 15 is a screenshot of the Wireshark TCP stream window. Highlighted by a black rectangle and an arrow is the User-Agent string. Identified in the string is iPhone; CPU iPhone OS 16_4_1 like Mac OS X.
Figure 15. TCP stream with the User-Agent line generated by Safari running on an iPhone.

Since more websites are using HTTPS, this method of host identification has become increasingly difficult, because HTTP headers and content are not visible in encrypted HTTPS traffic. However, for those who find unencrypted HTTP web traffic during their investigation, this method can provide more information to help identify a host.

Identifying Users in an Active Directory (AD) Environment

Perhaps the most important information when resolving an incident is determining the user associated with an infected host. For Windows clients in an AD environment, we can determine the user from user account names in Kerberos traffic.

Let’s return to our third pcap Wireshark-tutorial-identifying-hosts-and-users-3-of-5.pcap and open it in Wireshark.

This pcap is from a Windows host in the following AD environment:

  • Domain: www.pcapworkshop[.]net
  • Network segment: 172.16.1[.]0/24 (172.16.1[.]0 - 172.16.1[.]255)
  • Domain controller IP: 172.16.1[.]16
  • Domain controller hostname: PCAPWORKSHOP-DC
  • Segment gateway: 172.16.1[.]1
  • Broadcast address: 172.16.1[.]255
  • Windows client: 172.16.1[.]141

While this is an environment with both IPv4 and IPv6 enabled, the Kerberos traffic is IPv4 only.

Open the pcap in Wireshark and filter on kerberos.CNameString. Select the first frame. Go to the frame details section and expand the lines, as shown in Figure 16. Select the line with CNameString: desktop-hsjd5r8$ and apply it as a column.

Image 16 is a Wireshark screenshot. The filter is set to kerberos.CNameString. In the lower pane, Kerberos is indicated by a black arrow as well as other information. The CNameString is selected and the option Apply as Column is selected.
Figure 16. Finding the CNameString value and applying it as a column.

This will create a new column titled CNameString. Scroll down to the last frames in the column display. The CNameString column reveals a user account name for rene.mccollum in traffic between the domain controller at 172.16.1[.]16 and the Windows client at 172.16.1[.]141, as noted below in Figure 17.

Image 17 is a Wireshark screenshot. The filter is set to kerberos.CNameString. The new column CNameString is highlighted by a black rectangle.
Figure 17. Finding the Windows user account name in our newly created CNameString column.

Besides Kerberos traffic, we might find a first and last name or other identifiers of the user in Lightweight Directory Access Protocol (LDAP) traffic. Use the following Wireshark filter:

ldap contains "CN=Users"

This should reveal the string "CN=Rene McCollum, under the Info column, as shown below in Figure 18.

Image 18 is a Wireshark screenshot. The filter is set to ldap contains “CN=Users”. These filtered users are highlighted within a black rectangle.
Figure 18. Finding the first and last name in LDAP traffic.

Default Windows Hostnames

The default hostname for Windows 10 and Windows 11 computers is a 15-character string that starts with DESKTOP- and ends with seven random alpha-numeric characters.

Search for this identifier in our third pcap using ip contains "DESKTOP-" in the Wireshark filter. This finds the plaintext ASCII string DESKTOP- in any traffic at the IP layer or higher. For example, this search would find if the string appears in TCP from SMB or Kerberos activity, but it also includes traffic that uses UDP like DNS or DHCP.

After applying this filter, review the Info column, as shown below in Figure 19.

Image 19 is a Wireshark screenshot where the filter is set to ip contains “DESKTOP-“. Black arrows highlight the rows where ANY DESKTOP can be spotted in the traffic.
Figure 19. Searching for a default Windows 10 or Windows 11 hostname.

This search is case sensitive, and this identifier also appears as a lower-case string in our pcap.

An even better way to find the DESKTOP- string is to clear the Wireshark filter and use the Find Packet function under Wireshark’s Edit menu, as shown below in Figure 20.

Image 20 is a screenshot of the Wireshark Edit menu. Find Packet has been selected.
Figure 20. Using the Find Packet feature in Wireshark.

This brings up Wireshark’s search panel immediately under the search filter bar. Select “Packet Details” and “String” as our search options before typing desktop- as the search string. See Figure 21 for an example.

Image 21 is a Wireshark screenshot of packet details. Red arrows point to the Packet details dropdown menu, the String dropdown menu and the Find button. The filter used is desktop-. In the lower pane, a red arrow points to the Queries dropdown that indulges the DESKTOP line in the packet details.
Figure 21. Finding the string “desktop-” in the packet details.

Each time we click the Find button in our search panel, the string is highlighted in the frame details section, as noted above in Figure 21.

Conclusion

Properly identifying hosts and users from network traffic is essential when investigating an infected host. Following the methods from this tutorial, we can better utilize Wireshark to help identify affected hosts and users.

Our next tutorial in this series reviews how to export objects from a pcap.

Additional Resources

Enlarged Image