Analyzing packet captures

One of the best sources of evidence during an incident is packet captures. Dissecting them can uncover data exfiltration, exploits, and command and control.

A great deal of Chapter 5 covered the various methods to obtain packet captures from a range of sources and a variety of locations. Packet captures contain a great deal of information that is potentially valuable to incident response analysts. Some of this information includes source and destination IP addresses, domains and ports, and the content of communications between hosts. In some instances, incident response analysts can reconstruct actual files, such as text documents and images. The main drawback is the sheer amount of data that is involved.

Sample packet captures

This chapter refers to several preconfigured packet captures. These packet captures have been taken directly from http://malware-traffic-analysis.net/ by permission of the author. This site contains several packet capture exercises, where incident response analysts can practice locating indicators of compromise. It should be noted, though, that these captures may contain malware. You should only examine the live packet captures in a properly configured sandbox (see Chapter 16) or another system not connected to a production environment.

Command-line tools

Several command-line tools can be utilized when analyzing network packet captures. During more in-depth or lengthy incident response engagements, analysts may gather several packet capture files. It may be beneficial to combine these multiple packet captures into a single file to make analysis easier. The Mergecap application does just that by combining several packet capture files. Mergecap is offered as part of the SANS SIFT workstation and can be executed using the following command:

sansforensics@siftworkstation: ~$ mergecap packetcapture1.pcap packetcapture2.pcap

Another command-line tool that is useful in analyzing packet captures is Editcap. Editcap allows analysts to manipulate the packet capture files into smaller segments for easier review. For example, an analyst may only want to look at captures that are broken up into 50,000 packet segments. This would be helpful if an analyst has a large packet capture and dividing would make searching easier. To do this, the analyst would type the following into the command line:

sansforensics@siftworkstation: ~$ editcap -F pcap -c evidence.pcap split.pcap

In the preceding command, editcap took the evidence.pcap evidence file and divided it into 50,000 packet segments. Another technique that Editcap can be leveraged for is to divide a larger packet capture into time segments. For example, if analysts want to divide a packet capture into 10-minute segments, they can type the following:

sansforensics@siftworkstation: ~$ editcap -F pcap-t+600 evidence.pcap split.pcap

Analysts may also find that, in some circumstances, they may want to isolate domain name registration traffic. This is due in large part to a variety of adversarial actions such as C2 traffic, data exfiltration, and the possible redirection to compromised websites, often leveraging vulnerabilities in the DNS system. The dnstop application parses packet capture files and ascertains the sources and count of DNS queries from internal hosts. To install it on a Linux system, you can use the following command:

dfir@ubuntu:~$ sudo apt-get install dnstop

This command will download and install dnstop. In the following example, the packet capture was taken from the Malware Traffic Analysis site located at https://www.malware-traffic-analysis.net/2022/03/21/index2.html. If an incident response analyst wants to determine whether any IP addresses were sending outbound DNS queries for packet capture, they can simply execute the following command:

dfir@ubuntu:~/Documents/Packet Captures$ dnstop 2022-03-21-Hancitor-with-Cobalt-Strike-and-Mars-Stealer.pcap

The output of the preceding command is as follows:

Figure 9.2 – DNS query count

Real Intelligence Threat Analytics

One challenge with working with packet captures is the sheer amount of data that is involved. A 24-hour packet capture from even a modest-sized network presents problems. One technique is to use tools that focus on key data points. For example, beaconing traffic associated with Command and Control is a critical piece of data to find as it is the link the adversary has to the internal network.

One tool that can assist is Active Countermeasure’s Real Intelligence Threat Analytics (RITA). This command-line tool uses behavioral analytics to identify patterns that are indicative of beaconing behavior so that an analyst can focus on a specific IP address or domain name. A key feature of this tool is its ability to process large packet captures, such as one obtained over 24 hours. This allows analysts to locate even very low and slow Command and Control traffic.

Installing RITA is very straightforward. In this case, RITA has been installed on an Ubuntu desktop. First, make a directory for RITA. Second, download the installation script from the GitHub site at https://github.com/activecm/rita/releases/tag/v4.5.1. Next, make the file executable by running the following command:

dfir@ubuntu:~/rita$ sudo chmod +x ./install.sh

Next, execute the install script by running the following:

dfir@ubuntu:~/rita$ ./install.sh

The installation script will install the necessary dependencies, such as the Mongo database structure and the packet capture analysis tool Zeek.

Zeek

Zeek is a network monitoring and analysis tool that is used with RITA. For more information regarding Zeek, go to https://docs.zeek.org/en/lts/.

The next step is processing the packet capture. In this case, two packet captures were taken from the Malware Traffic Analysis post at https://malware-traffic-analysis.net/2022/01/27/index.html and were merged into a single file. This file was moved into the RITA directory. The following command points Zeek to the packet capture so that it can be processed into the various log files:

dfir@ubuntu:~/rita$ zeek -C -r IcedId.pcap 

Checking the files in the directory shows the processed log files:

Figure 9.3 – Zeek log files

After processing the packet capture with Zeek, the log files need to be imported into a database, IcedID, that RITA can read with the following command:

dfir@ubuntu:~/rita$ rita import *.log IcedID

Once this command is run, the results should look as follows:

Figure 9.4 – RITA Zeek log import

To access the help menu for RITA, enter the following:

dfir@ubuntu:~/rita$ rita

This will produce the following commands and associated results:

Figure 9.5 – RITA features

Let’s go ahead and see if there are any packets indicating beaconing behavior. Run the show-beacons command against the database that was previously created by running the IcedID database:

dfir@ubuntu:~/rita$ rita show-beacons IcedID

This produces the following:

Figure 9.6 – RITA Beacon analysis

In Figure 9.6, RITA is indicating that the internal IP address 10.1.28.101 has established 234 connections to the IP address 149.255.35.174. One result that is of note is the first number, 0.838, found at the beginning of the results line. This score indicates the confidence level RITA has in these results, from 0 to 1. In this case, there’s nearly 84% confidence that the traffic is beaconing behavior.

Another option is to run the show-beacons-fqdn command, which will show the domain names of systems:

dfir@ubuntu:~/rita$ rita show-beacons-fqdn IcedID

This produces much of the same results but indicates that the Command and Control server has a domain name of driverpackcdn.com, as shown here:

Figure 9.7 – RITA Beacon Fully Qualified Domain Name

As we can see, RITA allows analysts to focus on specific IP addresses and domain names as potentially malicious without having to dig through gigabytes of packet data. From here, they can pivot directly to the connections that are critical in GUI-based tools, which we will focus on next.

NetworkMiner

GUI-based tools that separate packet capture data are easier to navigate than command-line tools. One such tool is NetworkMiner, which is available at https://www.netresec.com/?page=NetworkMiner. This tool is available as a commercial or community tool, with the community tool having more limited functionality. Despite this, the community edition does have some key features that are useful in analyzing packet captures.

In this demonstration, we will examine the PCAP file associated with a Hancitor infection, which can be downloaded from https://malware-traffic-analysis.net/2022/03/21/index2.html. Load the PCAP data by going to File and selecting Open. Navigate to the packet capture and click Open. NetworkMiner will process the PCAP and display the hosts found in the packet capture:

Figure 9.8 – NetworkMiner GUI

The next tab, Files, shows the files that were contained within the packet capture:

Figure 9.9 – NetworkMiner’s Files tab

If you drill down further into the Files tab, you will see there are a few entries that stand out. The far-left column indicates the frame number. In this case, frame number 47 contains an entry for the b123.exe file that was downloaded from bor4omkin.ru with an IP address of 45.8.124.233:

Figure 9.10 – Suspect files

In addition to visualizing files that were contained within the packet capture, NetworkMiner also extracts them and places them in the AssembledFiles directory, broken down by IP address. This allows analysts to quickly identify suspect files and analyze them.

NetworkMiner is a useful tool for an initial review of packet captures. It provides details about the files, DNS queries, sessions, and other key data points. The main advantage that can be leveraged is its ability to quickly focus on key data points so that analysts can focus on specific areas, without having to dig through an entire packet capture to find the key evidence items.

Arkime

Arkime is an open source packet capture and search system that allows analysts and responders to examine large network packet captures. By default, Arkime organizes the packet captures into the various sessions contained within the capture. Arkime can be utilized as a network monitoring system that can be leveraged by importing packets into the Elasticsearch infrastructure. From here, responders can examine network activity in near-real time. Another method that Arkime can be leveraged for is loading offline packet captures for indexing.

Installation instructions for Arkime can be found on GitHub at https://raw.githubusercontent.com/arkime/arkime/master/release/README.txt. Arkime can be installed on a variety of Linux desktop or server platforms. The server option provides larger teams with the ability to share data concerning packet captures, as well as evaluate running captures. Desktop installations are an option for responders that will be handling offline data and who do not need to share the results.

In this section, we will use Arkime to analyze a packet capture from a system related to a phishing attack. This packet capture can be found at https://malware-traffic-analysis.net/2022/02/25/2022-02-25-Emotet-epoch4-with-spambot-activity.pcap.zip.

First, create a directory in Arkime for offline packet captures. This can be done in the home directory. Next, transfer the packet capture using SFTP to the offline packet capture directory. Finally, use the Arkime capture binary, which can be found in the /opt/arkime/bin directory, to process the packet capture using the following command:

arkime@arkime:/opt/arkime/bin$ sudo ./capture -r /home/offlinecaps/2022-02-25-Emotet-epoch4-with-spambot-activity.pcap

The preceding command takes the 2022-02-25-Emotet-epoch4-with-spambot-activity.pcap file and processes it so that it can be reviewed with the GUI. An important thing to note is the -r parameter, which only processes a single capture. If there are multiple captures, the binary can be run with the -R parameter set, which recursively processes all the packet captures in the directory. Figure 9.11 shows the packet capture being processed:

Figure 9.11 – Arkime PCAP import

Once completed, open a web browser and navigate to the IP address of the server or workstation with port 8005. This will open the Arkime interface. In the top left, set the time to All. Once the time has been set, the following view will appear:

Figure 9.12 – Arkime GUI dashboard

Arkime is a feature-rich platform. The following steps provide an overview of some of the features available in examining offline packet captures:

1. An examination of the packet capture from the dashboard identifies several different sessions where the internal system at 10.2.25.101 is communicating with external IP addresses. To narrow down the search results to internet traffic over HTTP, the following search query should be entered into the search bar:

Figure 9.13 – HTTP port 80 query

2. This shows that there were two TCP sessions with a destination port of 80. These sessions can be sorted by any of the fields present in the dashboard. One key piece of data that is useful is the bytes that are transferred as part of the session. Large deltas between bytes sent and received may indicate data exfiltration if the bytes sent are larger or, in the case of this capture, bytes received, which can indicate a file transfer, as seen in these entries:

Figure 9.14 – HTTP session data

3. The far right of the dashboard contains URIs and associated information concerning the sessions. For example, a check of the sessions over HTTP indicates that the local host navigated to what appears to be a Windows update site:

Figure 9.15 – Arkime URI data

4. Arkime provides additional information for the session in the same session row as the information URI related to the Windows Update. Clicking on the green plus sign box opens the following page:

Figure 9.16 – Session data

5. Further down, under the HTTP heading, is valuable data concerning the connection:

Figure 9.17 – HTTP session data

6. Another feature that is useful with Arkime is the ability to visualize connections. At the top of the Arkime web application is Connections. If you click on Connections, the following will appear:

Figure 9.18 – Arkime connections graph

Next, let’s have a look at how to reset Arkime.

How do I reset Arkime?

At the end of the analysis, there are two ways to clear the existing data in preparation for subsequent analysis. The first is to deploy Arkime on a virtualization platform such as VMware. Here, you can create a new installation and then capture a snapshot of the new installation. Once the analysis is complete, you can revert to the fresh installation snapshot.

Another method is to either rerun the init or wipe command. The steps are as follows:

1. Leave Elasticsearch running.
2. Shut down all running viewer or capture processes so that no new data is recorded.
3. To delete all the SPI data stored in Elasticsearch, use the db.pl script with either the init or wipe command. The only difference between the two commands is that wipe leaves the added users so that they don’t need to be re-added:

   /opt/arkime/db/db.pl http://ESHOST:9200 wipe

4. Delete the PCAP files. The PCAP files are stored on the filesystem in raw format. You need to do this on all of the capture machines:

   /bin/rm -f /opt/arkime/raw/*

The major advantage to Arkime is the ability to view the network traffic in a flow view. For a more detailed packet-by-packet view, the best tool to leverage is Wireshark, which we will cover next.

Wireshark

Wireshark is one of the most popular packet capture analysis tools available to incident response analysts. In addition to the ability to capture packets, a great many other features are available. As entire volumes and training courses are built around this platform, it is impossible to identify every feature. Therefore, this chapter will focus on some of the key features of Wireshark that are most applicable to an incident investigation.

Wireshark resources

Arguably, Wireshark is the packet analyzer of choice for IT and security professionals. Due to the ubiquity of the application, there are a wide variety of resources available for additional training on Wireshark and its capabilities. The Wireshark site at https://www.wireshark.org/ contains a great deal of information. Furthermore, the site at https://www.chappell-university.com/ contains exercises and training packet captures to hone skills regarding analysis.

Additionally, Lisa Bock, who authored Learn Wireshark, provided an in-depth treatment of Wireshark in her book, which is available at https://www.packtpub.com/product/learn-wireshark-fundamentals-of-wireshark/9781789134506.

Because Wireshark is a feature-rich tool, some settings lend themselves more to network traffic analysis that are outside incident response activities. As a result, some changes need to be made to better assist the incident response analyst with performing packet capture analysis concerning an incident investigation:

• Time: The time setting in Wireshark provides several options. These include the time of the packet since 1/1/1970 or since the start of the packet capture. One of these options, which can be useful in an incident investigation, is the date and time when the individual packets were captured. This allows analysts to correlate the date and time of other suspicious or malicious activity with the date and time of specific traffic within the packet capture. To enable this, navigate to View and then to Time Display Format. From there, choose one of the time options, such as Date and Time or Day or Time of Day. Another option to consider is utilizing the UTC options. This is very useful if the internal network utilizes UTC rather than local time. The time can also be set to nanoseconds.
• Name resolution: The name resolution setting allows analysts to toggle between seeing the IP addresses of the source and destination hosts and hostname resolution. This is useful if an analyst is examining a packet capture and wants to determine if any suspicious hostnames have been found. For example, if the packet capture is open, you will see various IP addresses:

Figure 9.19 – Wireshark IP address view

To determine the hostnames, navigate to View and then Name Resolution. Click on Resolve Network Addresses. Wireshark will then resolve the IP addresses to hostnames:

Figure 9.20 – Wireshark domain name view

• Colorize packet list: This feature allows analysts to toggle between a blank background of the packet list or to allow Wireshark to color-code the packets:

Figure 9.21 – Wireshark – Coloring Rules Classic

For this chapter, an exploration of Wireshark will be done while utilizing a packet capture that can be found on Malware Traffic Analysis at https://malware-traffic-analysis.net/2022/04/14/index.html. This packet capture includes downloading a copy of the Qakbot malware, along with Cobalt Strike. For this chapter, several key elements of the packet capture will be identified. Before examining the packet capture, Wireshark was configured so that the date and time are visible, and so that the hostnames were identified.

The following are some of the features in Wireshark that provide key pieces of information from the packet capture:

• Display filters: One of the most important features is the ability to filter packet captures on a wide range of services and ports. Filters can also be utilized on the source and destination IP addresses. For example, an incident response analyst would like to filter traffic on the system’s source domain name: DESKTOP-S9U1NBH.local. By right-clicking on the IP address in the packet capture window and navigating to Apply as Filter and then Selected, the analyst can select the IP address as a filter. This filter then appears in the filter bar with the ip.src==10.4.14.101 syntax, which displays the following:

Figure 9.22 – Source address filter

• Host identification: Another key aspect of analyzing packet captures is to identify the localhost, if applicable. Considering that this packet capture is from a single host, identifying the hostname, IP address, and MAC address is straightforward. By double-clicking on the individual packet, a great deal of information can be found:

Figure 9.23 – Packet data

• Physical connection identification: In this packet, the analyst can identify the source of the traffic from the Ethernet II and Internet Protocol Version 4 (IPV4) lines. Examination of the packet indicates both the source and destination MAC addresses as well. The preceding data also shows that this is an HTTP packet with the destination port set to the standard port 80.
• Protocol identification: In this case, there was a good deal of HTTP connections, due to the activity of the user. As a result, the primary transmission of the malware was quite possibly through an HTTP connection. Wireshark has several filters that allow analysts to limit the packet capture results with specific parameters. In the top green dialog box, enter http. Pay attention while entering this in the filter, as several different filters will be available. Once the filter has been typed in, click the right-facing arrow located at the far right of the dialog box. Wireshark will now limit the view of packets to those that are utilizing the HTTP protocol:

Figure 9.24 – HTTP packet view

• Hostname identification: After parsing through the packet capture source and destination hostnames, one hostname appears to be suspicious. This host, geobram.com, may be a suspect URL. Another feature of Wireshark is the ability to follow the TCP or HTTP stream of communication between the source and destination hosts. If you right-click on the rozhan-hse.com hostname, the following will appear:

Figure 9.25 – Follow HTTP Stream

A second window will appear; click on HTTP Stream and a third window will appear. This window contains the HTTP packets in a format that can be read. The incident response analyst can review this output to determine what types of files may have been sent or received:

Figure 9.26 – HTTP packet data

• Packet stream examination: An examination of the Follow TCP Stream output indicates that an HTTP GET command is reaching out to the NO_2950435796.zip file. An analyst may want to extract this file for analysis. Click on File and then Export Objects, and then HTTP; a window will appear listing all of the files associated with the HTTP connections. This list can be sorted on any of the fields at the top of the window. In this case, select the hostname and scroll down until the suspected URL is located:

Figure 9.27 – Wireshark – Export – HTTP object list

From here, the analyst can click on the file and save it onto the local system for later analysis. Chapter 12 will take select files and evaluate them for malicious code.

Wireshark is a powerful tool for conducting a detailed analysis of packet captures. The ability to drill down to individual packets and dissect them allows analysts to gain a very detailed sense of what is contained within the traffic running to and from external hosts, as well as to and from internal hosts. This visibility can afford the analyst possible insight into how an infected host communicates with an external host, or even identify other hosts that may have become compromised.