Wireshark: Malware Analysis

RedLine Stealer is one of the most prolific and common info stealer logs. It is typically distributed through phishing emails, malicious websites, or in software. Once installed on the system, RedLine can harvest a wide range of sensitive information, including passwords, credit card information, crypto wallet seed phrases, cookies, app data, etc. It can also collect details about the system itself, such as the OS version, running processes, and installed antivirus software.

In this lab, courtesy of malware-traffic-analysis.net, traffic has been captured from an Active Directory environment. Using Wireshark, I can analyze the full packet capture to investigate the malware infection. The LAN details are as follows:

• LAN segment range: 10.7.10.0/24
• Domain: coolweathercoat.com
• Domain controller IP address: 10.7.10.9

Before digging into the packets, I can gather a high-level summary of the pcap by checking out the Protocol Hierarchy under the Statistics tab. This provides a summary of the various protocols in the traffic as well as their relative percentage. This can often quickly reveal anomalies such as if there was a significant amount of HTTP traffic.

Additionally, from the Statistics tab I can gather a summary of all the conversations that took place in the traffic. This is helpful to see all the endpoints and where traffic is flowing. This specific pcap summary shows all the traffic relates to 10.7.10.47.

Since there was HTTP traffic in the summary, I will begin by querying “http” to see those specific packets. There is a total of five packets, including three “GET” requests from source address 10.7.10.47. Unencrypted HTTP GET requests are usually a red flag, especially since the host names 623start[.]site and guiatelefonos[.]com look suspicious.

I further look into the TCP stream by right clicking on the first HTTP GET request packet and selecting “Follow” -> “TCP Stream”.

The GET requests to 623start[.]site reveal that it originated from Windows Powershell via the user-agent details. The first traffic request returned a HTTP response code 404 (not found) error from the Apache server. It appears that Windows Defender antivirus blocked the outgoing traffic to this site. The second request also returned a 404 error to a URL with an install status, likely to inject the malware on the victim.

The third HTTP GET request to hxxp://guiatelefonos[.]com/data/czx.jpg returned an HTTP 301 error code and redirected to HTTPS as indicated by port 443.

Since this traffic looks very suspicious, I will look up both URLs on VirusTotal to see if there any reports associated with each.

Both sites are flagged by multiple security vendors as malicious domains determined to be malware distribution. The “guiatelefonos” URL specifically is flagged as being used by REDLINE.

Returning to the pcap, I continue following this TCP stream to find incoming C2 traffic to the victim from 194.26.135.119 on port 12432. I can reduce the scope of the conversation by selecting just incoming traffic to the victim from the C2.

This data shows the user profile being searched on both the Desktop and Documents folder for keywords *.txt, *.doc, *key*, *wallet*, *seed* to probe for cryptocurrency private keys.

Scrolling down further is data showing that the malware searched for specific cryptocurrency wallets such as Metamask, BinanceChain and Phantom.

Additionally, the malware searched the victim’s AppData directory for various applications such as Brave Software, Google, Microsoft edge, NVIDIA, Steam and Mozilla to name a few.

Lastly, the malware also sought after private API keys and login data for Facebook, Amazon AWS, Azure, Docker, Okta, Slack, etc.

To view the outgoing traffic from the victim to the C2 server, I will then reverse the stream.

At the end of the packet are indicators of compromise. First, are a list of all the running processes on the victim Windows 10.

Further down I find login credentials to the domain coolweathercoat.com that were extracted from Microsoft Edge browser as well as a single Word document “Top_secret_ducment.docx”.

Lastly, for the report, the victim can further be identified by their MAC address, hostname and user account name. I already identified this is a Windows host, so I can try NBNS traffic to identify the hostname. NBNS (NetBios Name Service) is a Microsoft TCP/IP protocol for networking on a LAN segment for file/printer sharing. Applying nbns as the search filter returns the following NBNS packets from the victim 10.7.10.47 to the LAN broadcast 10.7.10.255 and the hostname DESKTOP-9PEA63H. The ethernet details include the user’s MAC address 80:86:5b:ab:1e:c4.

The Windows user account name can be found using Kerberos traffic. Kerberos is the protocol for authenticating service requests between hosts on an unsecure network, and is the default authorization in Microsoft Windows. I will apply “kerberos.CNameString” as a search filter along with the victim’s IP address.

In summary, my investigation of this pcap file determined that a malicious payload setup exfiltration to a C2 server which attempted to harvest a wide range of sensitive app data, login credentials, and crypto currency private keys on our victim’s Windows desktop.