Malware reverse engineering: Through the looking glass and what analysts found there – part 3

By Emilie Mavel Christensen

We have reached the third and final entry in our series about malware reverse engineering. Last week, we explored the techniques used to reverse engineer malware and the obstacles that may arise. This week, we apply this knowledge to a real-world situation that Trifork Security encountered back in October 2024.

Origin

The malicious software in question was first encountered in mid-October 2024, when a user tried to access a dubious streaming website. Details are unclear, but the user downloaded a file from the site and opened it. The file turned out to be a PowerShell script, which downloaded a .zip file from a known C2 server. This triggered one of Trifork Security’s alarms, and the threat was promptly eliminated. For further details, see the blog post “All that glitters isn’t 4K”.

Early assertions about the malware

Based on the discovery context, the malware can be identified as a trojan, presenting itself as an innocuous file to deceive the user. The PowerShell script’s behaviour suggests it functions as a downloader, aiming to fetch additional payloads upon infecting a system. This article presents a partial analysis of the additional payload.

Analysis tools

As per industry standards, the analysis utilised virtual machines running various OS. The primary tools used to perform the analysis included:

Ghidra
Wireshark
CyberChef[1]
Mockoon[2]

Investigating the malware’s metadata

The software metadata indicates that it was supposedly developed by Nenad Hrg, and references the website ‘SoftwareOK.com’. Despite its somewhat dated look, the  website is legitimate and hosts decade-old Windows tools (e.g. the original ‘GetWindowText’). When comparing the metadata of the malicious software with the original software, it is clear that they differ significantly, as evident below (malicious on the left, original on the right):

First, the size of the malicious software is 16 MB, a behemoth compared to the original’s 98 KB.

Second, the original has a valid certificate while the malicious version does not.

Several additional clues can be found when analysing the software headers and disassembling the code, but the two above discrepancies confirm that the malware uses piggybacking to appear genuine, meaning the additional payload is, just like the downloader that retrieved it, a trojan.

Analyzing stored strings

At first glance, there are close to 34.000 defined strings with a minimum of five characters, making it impossible to analyze them all in depth. However, one particular string immediately stands out with its length of 9,344 characters, as seen in the picture:

It is obfuscated and unreadable in its current state, though a quick browsing reveals words like “build” and addresses to GitHub repositories.

Deobfuscating the suspicious string

Deobfuscation is required to make the string readable. Frequent symbols like ‘\n’ (new line) and ‘\t’ (tab) were replaced with their function to tidy up the string and uncover its structure:

Now that the string is more readable, its content can be analyzed. 

The string contains several mentions of “Go”, an open-source programming language supported by Google. After looking through the documentation of this programming language and open-source code written with it, the string can be decrypted and understood line by line:

First line: the path of the main package used to build the executable
Second line: the module containing the main package. As it is the main module, it has the version “(devel)”.
Following lines starting with “dep” list the dependencies used by the compiled software. A line contains three columns: the dependency URL, version and checksum to verify the validity of the dependency.
Lines starting with “build” are the arguments that were used by the compiler when it built the malware[3].

Dependencies

The listed dependencies suggest the malware interacts with various technologies including:

Go development[4]
Containerization (“containerd”, “docker”)
Database management (“sq-lite-3”)
File manipulation (“copy”[5])
Cloud services such as Azure and Google Cloud (“azure-sdk-for-go”[6], “k8s-cloud-provider”[7]) 

Some other dependencies stand out from the rest. For example:

One of the libraries retrieved is for a NES emulator[8]
Another one is for a 2D game engine[9]
And a third one is for a Telegram[10] bot that automatically sends a Russian meme[11].

Based on these findings, it is safe to conclude the malware was developed in Go for Windows machines. The dependencies can be interpreted in different ways: the malware could be creating services running in the background, using the infected machine’s resources for malicious tasks, or attempting to access locally stored information on the infected machine (such as database credentials or cloud SSH keys).

Additional strings of interest

Other noteworthy stored strings include: 

Words that indicate networking/connection capabilities (“Proxy”, “tconn”, “pings”, conns”, “useTCP”)
Words that may indicate encryption schemes (“isRSA”, “SaltLength”, “crypto/rsa.init”)
And fifty strings containing the word “Mutex”, which could indicate the malware manipulates threads to do process injection. However, using mutexes is pretty standard in Go[12], [13], so one should be cautious before making any assumption. 

Network Analysis

As this malware was downloaded as an additional payload by a downloader, a logical step in the analysis is to examine the infected machine’s network, to see if the malware retrieves yet another payload.

To perform the analysis, a secured Windows-based virtual machine is set-up, and Wireshark is installed. The malware is then detonated on the virtual machine while Wireshark monitors the network.

When the malware is detonated, the process “GetWindowText.exe” appears in the task manager, but no window appears. After a while, the process exits, and suspicious HTTP- requests appear on Wireshark, as shown below:

The requests attempt to query several websites:

pittyshishre(.)site
famikyjdiag(.)site
possiwreeste(.)site
commandejorsk(.)site
underlinemdsj(.)site
bellykmrebk(.)site
agentyanlark(.)site
writekdmsnu(.)site
delaylacedmn(.)site
And finally, steamcommunity(.)com.

Looking up the URLs from this list on VirusTotal reveals that, except for steamcommunity(.)com, the websites have been flagged as malicious by several reliable vendors such as Fortinet[14] and BitDefender[15].

Since it is not possible to determine what the malware’s request to steamcommunity(.)com entails, one can only hypothesize why the malware queries this website. Fortunately, security researchers at Fortinet have encountered malware with similar behaviour and discovered that the malware creators concealed urls to Command and Control servers in plain sight, using encrypted strings as usernames on the gaming platform.

It is reasonable to assume that all the other websites the malware queries are also Command and Control servers used to remotely control the malware. To confirm this hypothesis, we can trick our malware into believing it has reached the websites using a mock API and log the request it sends.

After running the malware, we can look into the fake API’s logs to see the malware’s communication attempts with these domains:

The malware’s behaviour was very straightforward: once it connected successfully, it sent a POST request with the body “act=life”. This is clearly a form parameter key/value pair, its key likely standing for “action”. 

Based on the available information, we can confidently conclude that the malware requests to report the infection of a new device. Sending the same message to nine different C2 domains, plus any additional ones it may find via Steam user profiles, increases the likelihood that the malicious actors controlling the malware will receive the message and proceed with the attack manually.

We hope you found this series of articles informative.

If you wish to go deeper into this topic, you can read the full research and analysis this series was based on right here.

Sources:

[1] ‘CyberChef’. Accessed: Dec. 13, 2024. [Online]. Available: https://gchq.github.io/CyberChef/
[2] ‘Mockoon – Create mock APIs in seconds with Mockoon’. Accessed: Jan. 07, 2025. [Online]. Available: https://mockoon.com
[3] ‘go command – cmd/go – Go Packages’. Accessed: Jan. 02, 2025. [Online]. Available: https://pkg.go.dev/cmd/go
[4] ‘The Go Programming Language’. Accessed: Dec. 02, 2024. [Online]. Available: https://go.dev/
[5] H. OCHIAI, otiai10/copy. (Dec. 01, 2024). Go. Accessed: Dec. 02, 2024. [Online]. Available: https://github.com/otiai10/copy
[6] Azure/azure-sdk-for-go. (Dec. 31, 2024). Go. Microsoft Azure. Accessed: Jan. 02, 2025. [Online]. Available: https://github.com/Azure/azure-sdk-for-go
[7] GoogleCloudPlatform/k8s-cloud-provider. (Dec. 12, 2024). Go. Google Cloud Platform. Accessed: Jan. 02, 2025. [Online]. Available: https://github.com/GoogleCloudPlatform/k8s-cloud-provider
[8] M. Fogleman, fogleman/nes. (Nov. 29, 2024). Go. Accessed: Dec. 02, 2024. [Online]. Available: https://github.com/fogleman/nes
[9] H. Hoshi, hajimehoshi/ebiten. (Jan. 02, 2025). Go. Accessed: Jan. 02, 2025. [Online]. Available: https://github.com/hajimehoshi/ebiten
[10] ‘Telegram – a new era of messaging’, Telegram. Accessed: Dec. 16, 2024. [Online]. Available: https://telegram.org/
[11] pepeground/pososyamba_bot. (Oct. 16, 2021). Go. Pepeground. Accessed: Dec. 13, 2024. [Online]. Available: https://github.com/pepeground/pososyamba_bot
[12] ‘sync package – sync – Go Packages’. Accessed: Jan. 02, 2025. [Online]. Available: https://pkg.go.dev/sync
[13] ‘The Go Memory Model – The Go Programming Language’. Accessed: Jan. 02, 2025. [Online]. Available: https://go.dev/ref/mem
[14] ‘Global Leader of Cybersecurity Solutions and Services’, Fortinet. Accessed: Dec. 10, 2024. [Online]. Available: https://www.fortinet.com/?type=1652177826[15] ‘Bitdefender – Global Leader in Cybersecurity Software’, Bitdefender. Accessed: Dec. 10, 2024. [Online]. Available: https://www.bitdefender.com/en-us/