MalevolentModMaker Write-up

Introduction

In this write-up I’ll walk through the questions I answered about the Sherlock challenge, MalevolentModMaker, done on HTB, with some evidence captured by screenshots of the answers found.

Scenario

Bob, a senior software engineer at Acme Inc., was taking a break from correcting AI code to check in with his favorite gaming community. One of the newer members shared a new program that can make mods for a popular game. Eager to try new things, when he ran it as administrator (as instructed), all of his files were deleted and replaced! He immediately called the help desk, and they locked his machine and called in an incident response!

Tasks

Task 1

• Q: Right from the start, based on the incident details, the .TXT file’s contents, and the extension appended to the other .TXT file, what type of malware infection is this?
• A: ransomware, since it can be seen in the extracted .txt that it is clearly asking for a ransom to retrieve the stolen data

Task 2

• Q: What mechanism does MCModMaker-v.1.4.exe use to send information back to the C2 server?
• A: webhook, when inspecting the exe with disassembler.

Task 3

• Q: What command does MCModMaker-v.1.4.exe run suggesting that it is meant to execute other binaries or scripts?
• A: Using process monitor and running the exe, I could see it executes the powershell command powershell -ep bypass to enable it to run other bash/script files in the system

Task 4

• Q: What is the value of the API key contained within the URL which suggests it enumerates geolocation data?
• A: It can be seen in the memory while debugging the .exe, value is ZVBOKX3P8H7

Task 5

• Q: What domain is the C2 server that serves the ransomware payload?
• A: It can also be found in memory or the disassembler: goteem.htb

Task 6

• Q: While analyzing the MCModMaker-v.1.4.exe, what format is the data that is returned to the C2 server?
• A: Continuing to dig into the .exe binary with a disassembler, it’s possible to find the reference of application/json type right after the communication with the C2 server

Task 7

• Q: What specific filetype is enumerated by goteem.exe for encryption?
• A: Analyzing goteem.exe, I found an error explicitly showing the type of file that it expected to find: txt

Task 8

• Q: What is the full string that’s displayed when goteem.exe enumerates a restricted Windows folder?
• A: Inside the findTxtFiles function, using a disassembler, I found a string for the error: Skipping directory: %s (access denied)

Task 9

• Q: Within the encryptFile function, in case file was read successfully, what is the function name found at the call instruction?
• A: With a decompiler I could find it is named as crypto_aes_NewCipher

Task 10

• Q: What is the decryption key?
• A: While debugging goteem.exe and bruh.exe, I noticed a password string on the stack right before the encryption function, change this pass. In bruh.exe I also noticed a function that converts ASCII to hex, so decoding it gave me the real password: 6368616e676520746869732070617373

Task 11

• Q: What is the name of the project in the encrypted .TXT file?
• A: Now running the decryptor, bruh.exe, with the -key parameter and the password found in task 10, I could see the name of the project is AI Coding Chatbot

Conclusion

In this challenge we could see how ransomware hosted on a “legit” site trusted by users could be disguised to take control of the machines of people who trust the everyday sites they use (especially community-driven websites). The dropper staged its payload via PowerShell, then used AES to encrypt files and steal the project from the unsuspecting user.

As a leasson learned, always keeping an updated antimalware and running, or checking suspicious files against scanning websites like VirusTotal, can prove useful when something is asking for administrative privileges and you don’t know its source. This is difficult nowadays once we’re used to running stuff from the internet, even more so when it comes from the everyday sites you visit. In the age of AI, where code is easily produced at scale and bad actors can exploit that even more easily and faster, this challenge makes a point: always verify, never trust before confirming its clean.

---