This blog presents the answers for our February 2023 Unit 42 Wireshark quiz. The information is ideal for security professionals who investigate suspicious network activity in an Active Directory (AD) environment, but everyone is welcome to review. To get the most benefit, readers should understand basic network traffic concepts and be familiar with Wireshark.
If you’d like to view the version without answers, please see the standalone quiz post.
Scenario, Requirements and Quiz Material
Quiz Questions
Quiz Answers
Pcap Analysis: Victim Details
Pcap Analysis: Identifying the Malware
Pcap Analysis: Post-infection Traffic
Pcap Analysis: Follow-up Spambot Activity
Pcap Analysis: Follow-up VNC Activity
Pcap Analysis: ARP Scanning
Pcap Analysis: File Transfer Over SMB
Conclusion
Indicators of Compromise
Additional Resources
The pcap for this month’s Wireshark quiz is from an AD environment, and it contains real-world traffic from a simulated enterprise setting. Details of the local area network (LAN) from the pcap follow.
Our investigation for this month’s quiz requires Wireshark. This blog utilizes a recent version of Wireshark, and we recommend at least version 3.x.
Participants should have some basic knowledge of network traffic fundamentals. We also recommend readers customize their Wireshark display to better analyze web traffic. A list of tutorials and videos is available. As always, we recommend using Wireshark in a non-Windows environment like BSD, Linux or macOS when analyzing malicious Windows-based traffic.
To obtain the pcap, visit our GitHub repository. Download the ZIP archive and extract the pcap. Use infected as the password to unlock the ZIP archive.
This month’s Wireshark quiz asks participants to write an incident report on the activity, as described in the February 2023 standalone quiz post. The incident report should consist of three sections:
The incident report should look similar to the following write-up.
Executive Summary:
On 2023-02-03 at 17:04 UTC, a Windows computer used by Damon Bauer was infected with Qakbot (Qbot) malware. The Qakbot infection may have spread to the domain controller.
Victim Details:
IoCs:
Malicious network traffic
Malware:
Our analysis assumes you have customized Wireshark according to our tutorials or workshop videos.
First, determine the victim’s details.
The common internal, non-routable IP address from this pcap is 10.0.0[.]149. To find it, use the basic web filter provided in our Wireshark tutorials, or type the following in your Wireshark filter bar:
(http.request or tls.handshake.type eq 1) and !(ssdp)
The results in the column display should show the source IP address as 10.0.0[.]149. The frame details section provides a corresponding MAC address of 00:21:5d:9e:42:fb as shown in Figure 1.
Network Basic Input/Output System (NetBIOS) Name Service (NBNS) traffic or Server Message Block (SMB) traffic may also provide a victim’s Windows host name. Use the following filter in Wireshark:
nbns or smb or smb2
The default host name for a Windows 10 or Windows 11 computer is a 15-character string. The name starts with DESKTOP- and is followed by an alphanumeric string of seven additional ASCII characters. We find DESKTOP-E7FHJS4 in the column display and frame details as shown in Figure 2.
Kerberos authentication traffic generated when a user logs in may provide a Windows user account name in the pcap. Filter on kerberos.CNameString and scroll to the end of the results in your column display. Select one of the last few frames in the column display. Go to the frame details section and expand the Kerberos line. Keep expanding values until you find the CNameString that has a value of damon.bauer, as shown in Figure 3.
As stated in our tutorial on identifying hosts and users, you can select the CNameString value and apply it as a column in your Wireshark display. The result is a CNameString column as shown above in Figure 3.
After gathering the victim’s details, determine when the malicious traffic started. First, check unencrypted HTTP traffic for any unusual URLs. Modify our basic web filter by removing tls.handshake.type eq 1, so we only see the HTTP requests over TCP port 80. Your Wireshark filter will look like this:
http.request and !(ssdp)
The filter reveals only two results in our Wireshark column display. The second result is an HTTP GET request to cacerts.digicert[.]com, which is typical traffic generated by the operating system or seen during routine web browsing.
The first result is an HTTP GET request to an IP address, which is highly suspicious.
Follow the TCP stream on that suspicious HTTP GET request to 128.254.207[.]55 for 86607.dat. The TCP stream window shows minimal request headers, and the server returns a Windows executable (.exe) or DLL file as shown in Figure 4.
Use the File → Export Objects → HTTP menu path to export 86607.dat from the pcap as shown in Figure 5.
In a Linux or macOS environment, we can easily check the file type of this exported object using a terminal window and the file command. The file command reveals that 86607.dat is a Windows DLL file, as shown in Figure 6. Check the SHA256 hash using the shasum -a 256 command, also shown in Figure 6.
Searching the SHA256 hash on VirusTotal reveals that several vendors detect this file as malware. This file has also been submitted to MalwareBazaar and identified as Qakbot. The URL hosting this file is also identified as Qakbot on URLhaus.
This type of unencrypted HTTP request is usually the first malicious traffic from a Qakbot infection. The HTTP request for 86607.dat happened on Feb. 3, 2023 at 5:04 p.m. UTC, which is our start time for this infection.
In February 2020, we published a Wireshark tutorial on examining Qakbot infection traffic. Qakbot has evolved since then, but many characteristics remain the same. Current identifiers for Qakbot post-infection activity include:
Please note that threat actors often contact legitimate websites to check an infected host’s internet connectivity. For example, Qakbot has used www.openssl[.]org for connectivity checks during the past several years, and the site is not malicious.
Qakbot often leads to:
We might see any combination from those three activities. For example, we reported Cobalt Strike and VNC activity from a Qakbot-infected host in January 2023.
To find HTTPS traffic sent directly to an IP address, use the following Wireshark filter:
tls.handshake.type eq 1 and !(tls.handshake.extension.type eq 0)
This reveals HTTPS web traffic without any associated domain, as shown in Figure 7.
Use the Statistics → Endpoints menu path and review filtered results for all IPv4 addresses, as shown in Figure 8.
The results consist of four IP addresses. One is the internal IP address of our infected Windows host. The other three are Qakbot servers for command and control (C2) traffic. The three Qakbot C2 server addresses are:
Confirm these are Qakbot C2 servers by reviewing their HTTPS certificate data from the pcap. Use the following filters, one for each IP address:
Use the above filter for 102.156.32[.]143 and select the frame result. Expand the frame details following the certificate fields until you reach the rdnSequence section for the certificate issuer (shown in Figure 9).
Certificate issuer data for HTTPS traffic from the server at 102.156.32[.]143 is:
These appear to be random characters in most of the fields for the certificate issuer. We should find similar certificate issuer data for 208.187.122[.]74 as shown in Figure 10.
Certificate issuer data for HTTPS traffic from the server at 208.187.122[.]74 is:
As shown in Figure 11, the certificate issuer data from 5.75.205[.]43 is different from the other two Qakbot C2 servers:
This certificate does not have random characters in the issuer fields, and it lists vipsauna[.]com in the organizationName and commonName fields. The traffic is not actually from vipsauna[.]com, and this appears to be a self-signed certificate.
Registered since 2012, the domain vipsauna[.]com has not resolved to any IP address for the past several years. This same certificate issuer has also been noted from at least one other Qakbot C2 IP address in 2022.
Another identifier of Qakbot activity is traffic over TCP port 65400. To review it, use the following Wireshark filter:
tcp.port eq 65400 and tcp.flags eq 0x0002
The results should look similar to Figure 12.
This traffic uses 23.111.114[.]52 for its IP address. The TCP stream reveals the infected host’s identification string and public IP address within the first 80 bytes of traffic. In this case, the identification string is jzbxct683972, and the public IP address is 71.167.93[.]52. Of note, this information was altered in the pcap to help sanitize network traffic for this month’s exercise. These are neither the actual identification string nor the real-world public IP address.
Various reports have linked Qakbot to different ransomware groups. Qakbot has most recently been associated with the Black Basta ransomware gang. On a Qakbot-infected host, ransomware groups use tools like Cobalt Strike to gain a foothold, map the internal network and perform lateral movement.
The AD environment used for this month’s pcap does not provide a high-value target for ransomware groups. However, Qakbot infections in this type of environment can still lead to follow-up actions like Cobalt Strike malware, VNC activity and spambot traffic.
For this month’s exercise, our pcap from the Qakbot infection contains probable spambot activity and VNC traffic.
To check a pcap for possible spambot activity, filter on smtp in Wireshark. This results in several lines of unencrypted SMTP traffic in the Wireshark column display (shown in Figure 13).
Windows clients in an AD environment should not establish connections with several different public email servers in a short period of time. This is an indicator of spambot activity. Determine how many SMTP connections occurred with the following Wireshark filter:
smtp.req.command contains "EHLO"
Your results should look similar to Figure 14.
The filter reveals our infected Windows host contacted at least five email servers in approximately 10 to 11 minutes. But this only represents SMTP traffic that is either unencrypted or encrypted after establishing the SMTP connection. The following Wireshark filter presents more accurate indicators of spambot activity:
tls.handshake.type eq 1 and (tcp.port eq 25 or tcp.port eq 465 or tcp.port eq 587
Your results should look similar to Figure 15.
This Wireshark filter looks for TLS connections over the three most common TCP ports used in SMTP traffic: port 25, port 465 and port 587. As Figure 15 shows, our new filter reveals at least 25 email servers contacted in approximately 19 to 20 minutes. This is more clearly an indicator of spambot activity.
Check if any emails were sent over unencrypted SMTP traffic by using the File → Export Object → IMF menu path as shown in Figure 16. Unfortunately, in this case, no spambot emails are available to export.
VNC is a graphical desktop sharing system that uses the remote framebuffer (RFB) protocol to control another computer. Over a network, someone running VNC transmits keyboard and mouse input to a targeted computer and receives graphical updates from the targeted computer’s screen.
VNC has legitimate use cases, but threat actors occasionally use VNC to maliciously control an infected Windows host. Such VNC traffic can be found in this month’s pcap.
For the past several months, VNC activity from Qakbot infections has used 78.31.67[.]7 over TCP port 443. Use the following filter in Wireshark to find this traffic:
ip.addr eq 78.31.67[.]7 and tcp.flags eq 0x0002
This filter reveals the start of two TCP streams for VNC traffic as shown in Figure 17.
VNC traffic in the pcap consists of two TCP streams. The first stream contains a sequence of 13 bytes that continually repeat with some minor variations. The second stream is noticeably larger and contains RFB content. The ASCII characters VNC appear about 40 bytes into the second TCP stream.
These traffic patterns are typical for VNC traffic from Qakbot infections.
Address resolution protocol (ARP) scans are occasionally used by threat actors to discover other active IP addresses in a compromised network.
ARP scanning happens at the MAC address layer, where a MAC address sends ARP queries to the broadcast MAC address at ff:ff:ff:ff:ff:ff for all IP addresses within a network segment. The goal is to determine if any other IP addresses are assigned to a MAC address.
ARP queries from a Windows client for sequential IP addresses in a network segment indicate ARP scanning.
In this month’s pcap starting from 7:22 p.m. UTC, the infected host at 00:21:4d:9e:42:fb broadcasts ARP queries for every IP address in the network segment, starting with 10.0.0[.]254 and sequentially working down to 10.0.0[.]2. The only addresses not included in the ARP scan are known IP addresses like:
To find this traffic, use the following Wireshark filter:
arp and eth.dst eq ff:ff:ff:ff:ff:ff
The results should look similar to Figure 18.
During the ARP scan, if the infected Windows host finds any other active IP addresses on the network segment, it sends a ping echo request over ICMP. If the targeted address responds, the infected Windows host then probes it by attempting to connect over various TCP or UDP ports.
For this month’s pcap, the only other IP addresses are the domain controller and the network segment gateway. No other clients or servers are active in this AD environment.
Filter on icmp to see the infected Windows host ping the domain controller and the network segment gateway. Filter on ip.addr eq 10.0.0[.]1 to view TCP and UDP ports probed by our infected Windows host.
ARP scanning and subsequent probing of any active IP addresses is not limited to Qakbot infections. We have seen similar activity from hosts infected with Bumblebee, IcedID, Emotet and other malware families.
Server Message Block (SMB) protocol enables file transfers between Windows hosts. The ultimate goal of threat actors who have gained access to a Windows client in an AD environment is to gain administrative access to the environment’s domain controller.
In an AD environment, the Windows client routinely communicates with the domain controller as part of normal system operations. However, certain types of activity like file transfers over SMB can be suspect.
To find file transfers over SMB, use the File → Export Objects → SMB... menu path as shown in Figure 19.
This reveals normal file activity, but we also see some suspicious files as highlighted in Figure 20.
Windows EXE or DLL files in SMB traffic can be suspicious, but this activity can also represent a legitimate use case. For example, Windows Server Update Service (WSUS) deploys Microsoft updates from servers within an AD environment. WSUS generates file transfers over SMB traffic consisting of EXE and other files.
But randomly named EXE or DLL files are highly suspicious. These types of files from the export SMB object list follow.
(Read: hostname - file size - file name)
The above list contains file names with seemingly random letters, and they are associated with the domain controller. They have either a .dll file extension or a .dll.cfg file extension.
From the export SMB object list window, select each of these files and export them from the pcap. In a macOS or a Linux environment, check the file types and SHA256 hashes using a terminal window as shown in Figure 21.
The 105 byte .bin.cfg files are data binaries, and the 1,761 KB .dll files are all Windows DLL files with a SHA256 hash of 713207d9d9875ec88d2f3a53377bf8c2d620147a4199eb183c13a7e957056432. This is the same SHA256 hash for the initial Qakbot DLL sent over HTTP traffic at the beginning of the infection.
These Qakbot DLL files are listed with the domain controller in the export SMB object list. Our infected Windows host apparently sent these files to the domain controller. This implies the domain controller may have a vulnerability that allows malicious file transfer.
To better understand the SMB traffic used for these file transfers, filter on smb2 and scroll through the results. While reviewing SMB traffic, examine the Info column in your Wireshark column display. The frame details section contains additional data to further illustrate activity from the Info column.
In a real-world scenario with similar activity, analysts would also investigate the domain controller. However, our pcap only contains traffic to and from the infected Windows client. We do not have traffic from the domain controller to the internet or to other hosts.
Further investigation is not required for this month’s Wireshark quiz. But the pcap will remain available for additional review if participants want to hone their traffic analysis skills.
This blog provides answers to our Unit 42 Wireshark quiz for February 2023. We reviewed traffic from the pcap and presented an incident report based on the infection.
Many organizations lack access to full packet capture in their IT environment. As a result, security professionals may lack experience in reviewing network traffic. Training material like this Wireshark quiz can help. Pcap analysis is a useful skill that helps us better understand malicious activity. Incident reports help investigators organize their findings in a more easily digestible format, and security professionals with incident report-writing experience are better able to recognize similar activity. A well-written report helps other people within your organization take appropriate steps to prevent the incident from happening again.
You can also read the original post, without answers, for this month’s Unit 42 Wireshark quiz.
Palo Alto Networks customers receive protections from this type of malware through Cortex XDR and our Next-Generation Firewall with Cloud-Delivered Security Services including WildFire and Advanced Threat Prevention.
If you think you may have been compromised or have an urgent matter, contact the Unit 42 Incident Response team or call:
Infrastructure
Sign up to receive the latest news, cyber threat intelligence and research from us