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.

Table of Contents

Requirements and Supporting Material
Host Information from Dynamic Host Configuration Protocol (DHCP) Traffic
Host Information from NetBIOS Name Service (NBNS) Traffic
Device Models and Operating System (OS) from HTTP Traffic
Identifying Users in an Active Directory (AD) Environment
Default Windows Hostnames
Conclusion
Additional Resources

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.

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.

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.

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.

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.

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.

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.

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.

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

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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

• Wireshark Tutorial: Changing Your Column Display - Unit 42, Palo Alto Networks
• Wireshark Tutorial: Display Filter Expressions - Unit 42, Palo Alto Networks
• Wireshark Tutorial: Exporting Objects From a Pcap - Unit 42, Palo Alto Networks
• Wireshark Tutorial: Decrypting HTTPS Traffic - Unit 42, Palo Alto Networks
• Wireshark Tutorial: Wireshark Workshop Videos Now Available - Unit 42, Palo Alto Networks
• Full list of Wireshark Tutorials and Quizzes - Unit 42, Palo Alto Networks