Cybersecurity Tutorials

Cold as Ice: Answers to Unit 42 Wireshark Quiz for IcedID

Clock Icon 13 min read
Related Products
Advanced Threat Prevention iconAdvanced Threat PreventionAdvanced URL Filtering iconAdvanced URL FilteringAdvanced WildFire iconAdvanced WildFireCloud-Delivered Security Services iconCloud-Delivered Security ServicesCortex XDR iconCortex XDRNext-Generation Firewall iconNext-Generation Firewall

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

Executive Summary

Our introductory blog Cold as Ice: Unit 42 Wireshark Quiz for IcedID provides a packet capture (pcap) from an IcedID infection in April 2023. This blog provides the answers. Also known as Bokbot, IcedID is well-established Windows-based malware that can lead to ransomware. Reviewing the pcap provides an opportunity to analyze IcedID infection traffic.

If you would like to view this quiz without answers, please see our previous blog introducing the standalone quiz.

Palo Alto Networks customers are protected from IcedID and other malware through Cortex XDR and our Next-Generation Firewall with Cloud-Delivered Security Services that include WildFire, Advanced Threat Prevention and Advanced URL Filtering.

Related Unit 42 Topics pcap, Wireshark, Wireshark Tutorial, IcedID, BokBot

Scenario, Requirements and Quiz Material

Traffic for this quiz occurred in an Active Directory (AD) environment during April 2023. The infection is similar to previous IcedID activity tweeted by Unit 42 in March 2023. Details of the Local Area Network (LAN) environment for the pcap follow.

  • LAN segment range: 10.4.19[.]0/24 (10.4.19[.]1 through 10.4.19[.]255)
  • Domain: boogienights[.]live
  • Domain controller IP address: 10.4.19[.]19
  • Domain controller hostname: WIN-GP4JHCK2JMV
  • LAN segment gateway: 10.4.19[.]1
  • LAN segment broadcast address: 10.4.19[.]255

This quiz requires Wireshark, and we recommend using the latest version of Wireshark, since it has more features, capabilities and bug fixes over previous versions.

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 April 2023 ZIP archive and extract the pcap. Use infected as the password to unlock the ZIP archive.

Quiz Questions

For this IcedID infection, we ask participants to answer the following questions previously described in our standalone quiz post:

  • What is the date and time in UTC the infection started?
  • What is the IP address of the infected Windows client?
  • What is the MAC address of the infected Windows client?
  • What is the hostname of the infected Windows client?
  • What is the user account name from the infected Windows host?
  • Is there any follow-up activity from other malware?

Quiz Answers

The AD environment for this pcap contains three Windows clients, but only one was infected with IcedID.

Answers for this Wireshark quiz follow.

  • Malicious traffic for this infection started on April 19, 2023, at 15:31 UTC.
  • Infected Windows client IP address: 10.4.19[.]136
  • Infected Windows client MAC address: 14:58:d0:2e:c5:ae
  • Infected Windows client hostname: DESKTOP-SFF9LJF
  • Infected Windows client user account name: csilva
  • Follow-up activity: BackConnect traffic

Pcap Analysis: IcedID Chain of Events

To understand IcedID network traffic, you should understand the chain of events for an IcedID infection. A flow chart illustrating this chain of events is shown in Figure 1.

Image 1 is a flowchart of the chain of events in the April 2023 IcedID infection. It starts with email and or web-based delivery methods, continues to the IcedID installer, HTTP traffic for the gzip binary, malware created from that binary, and then command and control traffic from the IcedID infection. The initial follow-up activity can include Cobalt sStrike, VNC traffic, and BackConnect.
Figure 1. Flowchart for chain of events in the April 2023 IcedID infection.

Most IcedID infections use a standard variant of IcedID. These infections typically use an EXE or DLL that acts as an installer. This installer generates an unencrypted HTTP GET request that retrieves a gzip-compressed binary. The installer then converts this binary into malware used for a persistent IcedID infection.

The newly created, persistent IcedID generates HTTPS traffic to communicate with command and control (C2) servers. The C2 activity can lead to BackConnect traffic, Cobalt Strike and Virtual Network Computing (VNC) activity.

If the infected host is part of a high-value environment, an IcedID infection would likely lead to ransomware.

Pcap Analysis: Infection Vector

Using Wireshark customized from our tutorials, apply a basic web filter to see if anything stands out. Review the results in your column display. Look for unencrypted HTTP traffic over TCP port 80 directly to an IP address without an associated domain. This is a common characteristic in the chain of events for various malware infections.

At 15:31:08 UTC, the host at 10.4.19[.]136 generated an HTTP GET request to hxxp://80.77.25[.]175/main.php as shown below in Figure 2.

Image 2 is a screenshot of suspicious HTTP traffic in Wireshark that goes directly to an IP address, which is highlighted with an arrow.
Figure 2. Suspicious HTTP traffic directly to an IP address shown in Wireshark.

Follow the TCP stream for this HTTP GET request, as shown in Figure 3. This should generate a window for TCP stream 32, as shown in Figure 4.

Image 3 shows the menu selection to follow the TCP stream for the suspicious HTTP GET request.
Figure 3. Following TCP stream for suspicious HTTP GET request.
Image 4 is the TCP stream window in Wireshark. Indicated with two arrows is the first line of the HTTP GET request and highlighted by the black box is the location.
Figure 4. TCP stream for the suspicious HTTP GET request and response.

Figure 4 reveals HTTP request headers that contain a User-Agent string ending with Edg/112.0.1722.48. This string indicates the traffic was likely generated by the Microsoft Edge browser. However, web traffic generated by malware can spoof different User-Agent strings, and some browser extensions also have this ability, so we cannot be certain this was actually Microsoft Edge.

The HTTP response headers in Figure 4 show a 302 code, redirecting traffic to the following URL:

hxxps://firebasestorage.googleapis[.]com/v0/b/serene-cathode-377701.appspot.com/o/XSjwp6O0pq%2FScan_Inv.zip?alt=media&token=a716bdce-1373-44ed-ae89-fdabafa31c61

This Firebase Storage URL has been reported as malicious by at least seven security vendors on VirusTotal, and it appears in URLhaus tagged as IcedID. Fortunately, Google has taken the URL offline, and it is no longer active.

To further refine our search, add the client’s IP address 10.4.19[.]136 to the basic web filter as shown below in Figure 5. This reveals HTTPS traffic to firebasestorage.googleapis[.]com shortly after traffic to the initial URL at hxxp://80.77.25[.]175/main.php.

Image 5 is a screenshot of the HTTPS traffic to firebasestorage.googleapis[.]com after the initial suspicious URL. Highlighted in green in the screenshot is the command to insert into Wireshark. Two arrows indicate the request and the suspicious URLs.
Figure 5. HTTPS traffic to firebasestorage.googleapis[.]com after the initial suspicious URL.
Follow the TCP stream for the initial frame showing fire in the Wireshark column display. The TCP stream reveals 273 KB of data sent from the server to the Windows host, as shown below in Figure 6. This indicates a file might have been sent to the Windows host.

Image 6 is the TCP stream window showing the 275 kB of data sent from firebasestorage.googleapis[.]com to the Windows host. This is highlighted by an arrow in a menu that shows the entire conversation.
Figure 6. TCP stream showing 275 KB of data sent from firebasestorage.googleapis[.]com to the Windows host.
While the Firebase Storage URL is tagged as IcedID on URLhaus, this only indicates a distribution method for the IcedID installer. Based on this pcap, the victim opened a link that led to the Firebase Storage URL, and that URL delivered a file for an IcedID installer.

The URLhaus entry for this Firebase Storage URL reveals the ZIP archive it previously hosted, as shown in Figure 7.

Image 7 is a screenshot of the URLhaus entry for the firebasestorage URL. The screenshot shows the payload delivery, when it was first seen, the file name and file type, and the signature, which is IcedID.
Figure 7. URLhaus entry for our firebasestorage URL shows it delivered a zip archive.

The ZIP archive was submitted to Malware Bazaar. The archive is password-protected with the ASCII string 1235, and it contains a file named Scan_Inv.exe. This Windows executable file is an IcedID installer.

Pcap Analysis: IcedID Traffic

An IcedID loader first generates an unencrypted HTTP GET request over TCP port 80 to a domain using GET / without any further URL. This returns a gzip binary used by the installer to create the persistent malware on the victim’s host.

To find the gzip binary, use the same basic web filter with the victim’s IP address noted earlier in Figure 5. Scroll down to an HTTP GET request to skigimeetroc[.]com at 15:35:39 UTC and follow the TCP stream as shown below, in Figure 8.

Image 8 is a screenshot of the menu selection to follow the TCP stream for IcedID installers initial HTTP GET request. Highlighted in green is the filter to enter into Wireshark.
Figure 8. Following the TCP stream for IcedID installer’s initial HTTP GET request.

This is TCP stream 53 from the pcap, as shown below in Figure 9. The HTTP request headers for traffic generated by the IcedID installer have no User-Agent string. Note the cookie sent in the request headers in Figure 9.

Image 9 is the TCP stream window in Wireshark. Highlighted with a black box is the cookie data. Highlighted with an arrow is the gzip binary.
Figure 9. HTTP GET request generated by the IcedID installer.

The cookie line follows:

Cookie: __gads=422998217:1:1808:131; _gid=A0CA96894E9D; _u=4445534B544F502D534646394C4A46:6373696C7661:46353431423635424230383346354633; __io=21_1181811818_1193560798_2439418475; _ga=1.591597.1635208534.1022; _gat=10.0.22621.64

Cookie parameters for the HTTP GET request caused by this IcedID installer follow:

  • __gads= IcedID campaign identifier and information from the infected host.
  • _gid= Value calculated using MAC address of the infected host.
  • _u= ASCII text representing hex values of the victim’s hostname, Windows user account name and another undetermined value.
  • __io= Domain identifier from the infected host’s security identifier (SID).
  • _ga= Information based on the infected host’s CPU.
  • _gat= Windows version. For example, 10.0.22621.64 is an identifier for 64-bit Windows 11 version 22H2 and 10.0.19045.64 is an identifier for 64-bit Windows 10 version 22H2.

These cookie parameters are unique to IcedID infections. You can identify this traffic as IcedID without understanding the values. However, the _u= parameter reveals the victim’s hostname and Windows user account name. This information is very useful for our investigation. These hex values translate to a hostname of DESKTOP-SFF9LJF and a Windows user account name of csilva, as shown below in Figure 10.

Image 10 shows two hex value translations. The hex value highlighted in yellow translates to DESKTOP-SFF9LJF. The hex value highlighted in blue translates to csilva.
Figure 10. Using the _u= cookie parameter to determine the victim’s hostname and Windows user account name.

After retrieving the gzip binary, an IcedID installer creates persistent IcedID malware that takes over the infection. The infected Windows host then starts generating HTTPS traffic to IcedID C2 servers.

These C2 servers use different domain names and IP addresses than the initial domain contacted by the IcedID installer. IcedID’s HTTPS C2 traffic starts within a minute or two after the installer retrieves the gzip binary, and this activity uses at least two domains with random alphabetic names.

Our pcap reveals HTTPS traffic from the infected host to two domains after skigimeetroc[.]com at 15:35:39 UTC. These HTTPS C2 servers are askamoshopsi[.]com on 104.168.53[.]18 and skansnekssky[.]com on 217.199.121[.]56.

To find these servers, use the same basic web filter with the victim’s IP address noted earlier in Figure 5. HTTPS traffic starting at 15:36:41 UTC reveals these domains, as shown below in Figure 11.

Image 11 is a screenshot of the Wireshark traffic for the command and control IcedID servers. Highlighted with a black box is the IcedID installer that retrieve the gzip binary.
Figure 11. HTTPS C2 traffic after HTTP request by the IcedID installer.

Both C2 servers at askamoshopsi[.]com and skansnekssky[.]com use self-signed certificates for their HTTPS traffic. Self-signed certificates for HTTPS traffic will generate warnings about potential security risks when the site is viewed in any modern web browser.

Why do web browsers display warnings about websites that use self signed certificates? Because these are not validated by a Certificate Authority. Criminals can generate self-signed certificates that impersonate an existing company, or they can use generic values for the certificate issuer. Without a validated certificate, web browsers cannot be sure a website is what it says it is.

Figure 12 shows what the server at askamoshopsi[.]com looked like when we attempted to view it with the Firefox web browser. This warning allows users to view the server’s self-signed certificate.

Image 12 is two screenshots of Mozilla Firefox windows, showing a warning for the potential security risk of the invalid certificate. It also shows the certificate for the localhost.
Figure 12. Attempting to view the web server at askamoshopsi[.]com using Firefox.
As shown above in Figure 12, the certificate uses values like Internet Widgits Pty Ltd for the issuer’s Organization name and Some-State for the State/Province name. Values for self-signed certificates used by IcedID C2 servers are the same default values seen when using OpenSSL to create a certificate in Xubuntu as shown below in Figures 13 and 14.

Image 13 is the Xubuntu terminal x509 certificate creation for a web server using OpenSSL.
Figure 13. Creating an x509 certificate for a web server using OpenSSL in Xubuntu.
Image 14 is the Xubuntu terminal default values for the x509 certificate creation. Highlighted with arrows are the country name two letter code, which is Australia, the state, or province, name, and the organization name, which is Internet Widgets Pty Ltd.
Figure 14. Default values when creating an x509 certificate for a web server using OpenSSL in Xubuntu.

Since Internet Widgits Pty Ltd is a default value for a self-signed certificate in HTTPS traffic, and this value is sometimes seen in C2 traffic for malware. This should be more closely examined if it’s found when investigating a suspected malware infection. We can easily check any pcap for this value using the following Wireshark filter:

x509sat.uTF8String eq "Internet Widgits Pty Ltd"

The results from our pcap reveal the same IP addresses used by IcedID C2 servers for askamoshopsi[.]com at 104.168.53[.]18 and skansnekssky[.]com at 217.199.121[.]56. Expand the frame details for any of the results to find the same certificate issuer data, as shown in Figure 15.

Image 15 is a Wireshark screenshot. Highlighted in green is the command to put into the search bar. The results, highlighted by arrows, are the transport layer security, the certificate, including size, and the issuer of the certificate. Highlighted in a black box are the IDs that showed in the Xubuntu terminal.
Figure 15. Self-signed certificate by IcedID C2 servers using Internet Widgits Pty Ltd as the Organization name shown in Wireshark.

This certificate data is not unique to IcedID. The same values for self-signed certificates are also seen in HTTPS C2 traffic by other malware families like Bumblebee.

Pcap Analysis: BackConnect Traffic

Undetected IcedID infections lead to follow-up activity like BackConnect traffic.

For the past several months, BackConnect traffic caused by IcedID was easy to detect because it occurred over TCP port 8080. However, as early as April 11, 2023, BackConnect activity for IcedID changed to TCP port 443, making it harder to find.

This BackConnect activity from IcedID Unit 42 tweeted on April 11, 2023 used an IP address of 193.149.176[.]100 over TCP port 443. Filter for that IP address in Wireshark and combine it with tcp.flags eq 0x0002 as shown below, in Figure 16. This reveals the beginning of three streams.

Image 16 is a Wireshark command, highlighted in green, showing how to filter in Wireshark for the BackConnect traffic in the packet capture.
Figure 16. Filtering in Wireshark for BackConnect traffic in our pcap.

Follow the TCP stream for the first result, which is TCP stream 950. This stream reveals encoded or otherwise encrypted TCP traffic, as shown in Figure 17.

Image 17 is a TCP stream terminal window in Wireshark showing the BackConnect activity.
Figure 17. The first TCP stream for BackConnect activity.

Go back to the Wireshark filter used to reveal the TCP streams to 193.149.176[.]100. Follow the TCP stream for the second frame in the results, which is TCP stream 951. This reveals encoded or encrypted data followed by a command to reveal all hosts under the domain controller for boogienights[.]live as shown below, in Figure 18.

Image 18 is a TCP stream terminal window in Wireshark showing the BackConnect traffic with a command to and the results enumerating the Active Directory environment.
Figure 18. BackConnect traffic with a command to and results enumerating the victim’s AD environment.

The response to this command enumerates the victim’s AD environment, showing three clients logged in to the domain:

  • DESKTOP-JAL4D68
  • DESKTOP-RETP4BU
  • DESKTOP-SFF9LJF

Go back to the Wireshark filter used to reveal the TCP streams to 193.149.176[.]100. Follow the TCP stream for the last frame in the results, which is TCP stream 953. This lists disk drives on the victim client, and it provides a directory listing for each of these drives, as shown below in Figure 19.

The C:\ drive is the victim’s system drive. Z:\ is likely a mapped drive from a server’s shared directory that does not contain any files.

"Image 19 is a TCP stream terminal window in Wireshark showing the BackConnect traffic. A highlighted black box shows where the attacker sends a DISK command. The victim returns the disk drive list. The attacker then changes the directory to the Z:\ drive and lists its contents. This drive is empty. The second black box highlights where the attacker changes the directories to the C:\ drive and lists its contents. This is the victim’s system drive. It contains files and directories normally seen on a Windows host. This screenshot also shows the entire conversation size which is 796 bytes."
Figure 19. BackConnect traffic showing contents of the victim’s system drive and mapped drive.

Previous IcedID infections reveal this threat can use BackConnect traffic to load and run Cobalt Strike. We tweeted about one such case from March 24, 2023. However, this pcap does not contain any indicators of Cobalt Strike.

Previous IcedID infections also reveal this threat can generate VNC traffic over the same IP address used by BackConnect traffic. This happened during the same IcedID infection from March 24, 2023.

Pcap Analysis: Victim Details

The common internal IP address for the malicious traffic we have reviewed is 10.4.19[.]136. This is our victim’s IP address. To find the Windows user account name, filter on that IP address and kerberos.CNameString as shown in Figure 20.

Image 20 is a Wireshark screenshot highlighting the CNameString column, and the outcome of selecting “apply as column” from the menu. Highlighted in green is the command to filter to do this. Highlighted by arrows are the Windows account user name for the infected Windows host.
Figure 20. Finding the Windows user account name for our infected Windows host.

In some cases, lightweight directory access protocol (LDAP) might also provide the full name of the user. Use the following Wireshark filter:

ldap.AttributeDescription == "givenName"

This should provide four frames in our column display. Select any of them and expand the frame details until you find the user’s full name, Cornelius Silva, as shown below in Figure 21.

Image 21 is a Wireshark screenshot showing how to filter to find the victim’s full name from LDAP traffic. Highlighted by arrows are the names.
Figure 21. Finding the victim’s full name from LDAP traffic.

Perhaps the easiest way to find a victim’s hostname in Wireshark is to combine the victim’s IP address with a search for ip contains "DESKTOP-" as shown below, in Figure 22. Several results in the info column show Host Announcement DESKTOP-SFF9LJF sent by our infected Windows host at 10.4.19[.]136.

Image 22 is a Wireshark screenshot showing how to filter to find the Windows hostname in Wireshark. Highlighted in green is the filter to use.
Figure 22. Finding the Windows hostname in Wireshark.

To find the victim’s MAC address, just correlate the IP address to the host’s MAC address in any of the frame details windows, as shown below in Figure 23.

Image 23 is a screenshot where, highlighted, shows the victim’s MAC address with its associated IP address.
Figure 23. Correlating the victim’s MAC address with its associate IP address.

Conclusion

This blog provides answers and analysis for our Unit 42 Wireshark quiz featuring an IcedID infection from April 2023. IcedID is important to identify and stop, because it is a known vector for ransomware infections.

Many organizations lack access to full packet capture in their IT environment. As a result, security professionals might lack experience reviewing IcedID and other malware traffic. Training material like this Wireshark quiz can help. Pcap analysis is a useful skill that helps us better understand malicious activity.

You can also read the original post, without answers, from our standalone quiz post.

Palo Alto Networks customers are protected from IcedID and other malware through Cortex XDR and our Next-Generation Firewall with Cloud-Delivered Security Services that include WildFire, Advanced Threat Prevention and Advanced URL Filtering.

If you think you might have been compromised or have an urgent matter, get in touch with the Unit 42 Incident Response team or call:

  • North America Toll-Free: 866.486.4842 (866.4.UNIT42)
  • EMEA: +31.20.299.3130
  • APAC: +65.6983.8730
  • Japan: +81.50.1790.0200

Palo Alto Networks has shared these findings, including file samples and indicators of compromise, with our fellow Cyber Threat Alliance (CTA) members. CTA members use this intelligence to rapidly deploy protections to their customers and to systematically disrupt malicious cyber actors. Learn more about the Cyber Threat Alliance.

Indicators of Compromise

Traffic from the pcap related to the IcedID infection:

  • hxxp://80.77.24[.]175/main.php
  • hxxps://firebasestorage.googleapis[.]com/v0/b/serene-cathode-377701.appspot.com/o/XSjwp6O0pq%2FScan_Inv.zip?alt=media&token=a716bdce-1373-44ed-ae89-fdabafa31c61
  • 192.153.57[.]223:80 - hxxp://skigimeetroc[.]com/
  • 104.168.53[.]18:443 - askamoshopsi[.]com - HTTPS traffic
  • 217.199.121[.]56:443 - skansnekssky[.]com - HTTPS traffic
  • 193.149.176[.]100:443 - BackConnect traffic

Files associated with traffic from this IcedID infection:

  • SHA256 hash: fc96c893a462660e2342febab2ad125ce1ec9a90fdf7473040b3aeb814ba7901
  • File size: 262,343 bytes
  • Filename: Scan_Inv.zip
  • File description: Password-protected ZIP archive hosted on Firebase Storage URL
  • Password: 1235
  • MalwareBazaar Database sample
  • SHA256 hash: bd24b6344dcde0c84726e620818cb5795c472d9def04b259bf9bff1538e5a759
  • File size: 333,408 bytes
  • Filename: Scan_Inv.exe
  • File description: Windows executable file for IcedID installer
  • MalwareBazaar Database sample

Additional Resources

Tags

Table of Contents

Related Articles

Related Resources

Enlarged Image

Default Heading

Read the article Right Arrow