6 min read

Different Methods, Same Results

Different Methods, Same Results

Introduction

During my free time I enjoy doing some light malware analysis, utilising sites like MalwareBazaar, any.run, vx-underground, etc to obtain samples. Sometimes these samples are good where all the threat actor infrastructure is still active, which leads to some interesting analysis and other times these samples are rather underwhelming. One of the samples I analysed recently appeared to be interesting at first as it still had the infrastructure in place which allowed the secondary payloads to be downloaded, however, the malware itself was rather underwhelming and not good enough to write a proper article. Instead I decided to write about how different techniques can be used to obtain information about the malware and how Transport Layer Security (TLS) traffic can be decrypted using PolarProxy.

PolarProxy

If you have not heard about or used PolarProxy before but you like to dabble in malware analysis or incident response, then I highly recommend checking it out. PolarProxy is a transparent TLS inspection proxy which decrypts and re-encrypts TLS traffic, which can save the captured traffic into a PCAP file that can be loaded into Wireshark or an intrusion detection system for analysis. I won’t go into the setup of PolarProxy in this post as there are already several articles available online which outline the process of installing and configuring PolarProxy for use in a malware lab environment. However, for those that are interested in setting up PolarProxy, I have included some great links in the reference section.

Analysis

Sample Details

Type: Stealer (RustyStealer)
MD5: 0f9599d3ddf1e0c8f818d384ee8d0d19
SHA-1: 2ca17aef38df0c00efa49b4b448c5f8343725c2f
SHA-256: a98aec4a39f5f5ee41280cb17d9b4b5e9bc1eea2fb2ff0d7a962e2b74464d67c
File Type: Windows PE
Architecture: 64-bit

The malware to be analysed was meant to be a stealer called RustyStealer, but on further investigation it appeared to download a large archive as a payload which contained hundreds of exploits. This initially appeared to be interesting, but on further investigation it appeared to be some form of malware cobbled together by a script kiddy. Alas, this meant no proper malware analysis post but more of an informative post to show that sometimes similar results can be obtained using different methods. As the saying goes, there is more than one way to cook an egg.

Static Analysis

Conducting some basic static analysis it was possible to see that the malware most likely reached out to a domain called m.crep.vip and referenced something to do with packages.

Extract from Floss/Strings being run on executable

Network Analysis

Utilising the information obtained from the static analysis the executable was run with tools like Wireshark and Procmon running to capture any activity. Reviewing the results, it was surprising to see how much network traffic was being received from the IP 45.67.85.72.

High amount of traffic from 45.67.85.72

Reviewing the packet capture it was possible to correlate that m.crep.vip resolved to 45.67.85.72.

DNS query and response for m.crep.vip resolving to IP 45.67.85.72

Unfortunately, it was not possible to see what was being downloaded as the traffic was encrypted via TLS, but there is a solution.

TLS Encrypted traffic for host m.crep.vip

As mentioned earlier, it is possible to decrypt this traffic by sending it to PolarProxy, which will be running as a transparent proxy to decrypt the TLS traffic, making it possible to see this traffic in cleartext. All that is required is to set the default gateway as the PolarProxy server on the machine you are executing the malware and to install the self-signed certificate generated by PolarProxy as a Trusted CA.

After completing these basic steps, the malware was then launched again and it was possible to see the decrypted TLS traffic from the packet capture that was obtained from PolarProxy. Reviewing the unencrypted traffic, it was possible to see the URI along with the payload that was being downloaded. It was possible to see the initial GET request, requesting pkgs.txt, which was also evident in the static analysis conducted earlier.

Unencrypted network capture obtained from PolarProxy

Viewing the response from the GET request to pkgs.txt, it was possible to see that the file being downloaded was a zip archive called ransomware.zip.

Response from GET request to pkgs.txt

Due to the way the malware functioned, the archive was downloaded into the users %USERPROFILE$\AppData\Local\Temp\ directory where it was renamed as a random file and folder name before the contents of the zip file were extracted.

Extract of the file and folder creation from the malware

Basic Debugging

As mentioned earlier above, this sample was not worth conducting a full analysis and was more about using different methods to get similar results. Conducting a quick and basic analysis and debug of the malware it was possible to see that the malware reaches out to m.crep.vip, gets the package list to download from pkgs.txt and downloads the archive ransomware.zip.

Reference to m.crep.vip and pkgs.txt
Request to download ransomware.zip from m.crep.vip
Archive ransomware.zip being downloaded into %USERPROFILE$\AppData\Local\Temp\ directory

Analysis of ransomware.zip

MD5: bad869dd75ddf71ade1e036e7a888193
SHA-1: 9d271833b954de56dded68a15b61bd66f6e1b1c4
SHA-256: 45af632693dccb8a66ea18aa8f655df7fa28633d1ace591193ecc1d0f2b77bff

Due to all the analysis that had been conducted thus far, it was possible to obtain the full URL to download the ransomware.zip archive directly from the server by initiating a wget/curl request to https://m[.]crep[.]vip/packages/ransomware.zip.

Upon analysing the ransomware.zip archive it quickly became apparent that this malware just downloaded hundreds of exploits that were launched on the user’s machine. As a result of this discovery, analysis ceased as it became obvious that this malware was not a stealer but most likely a poorly put together piece of malware, created by a script kiddy that bombarded the infected host with hundreds of exploits. Many of these exploits were also extremely old and would be detected by all modern antivirus/EDR (Endpoint Detection and Response) solutions.

batch file that was run to launch all files with .exe extension
Extract showing 313 binaries that were inside the ransomware.zip archive

Conclusion

Sadly this post didn't turn out as I wanted it to as the malware sample I was analysing was not good enough to conduct proper malware analysis. However, I thought it would be a good example to demonstrate how different techniques can be utilised to obtain similar results. In this case it was possible to get as much information from a decrypted packet capture than debugging to obtain information about the connection and payload downloaded.

References