TryHack3M: Bricks Heist
Crack the code, command the exploit! Dive into the heart of the system with just an RCE CVE as your key. - by umairalizafar, ujohn and l000g1c
Last updated
The following post by 0xb0b is licensed under CC BY 4.0
Recon
We run a Nmap scan and discover four open ports, on port 22 SHH, a web server behind 80 and 443 as well as a MySQL 3306 are open.
When calling up the page on port 80 we receive an error response, the method GET is not allowed, let's firstly move to 443 to check the same behavior.
On 443, we see on the index page only a picture of a wall with the caption brick by brick, mmh that sounds familiar after a WordPress plugin, let's investigate.
We run a Gobuster scan to enumerate all possible directories and find the directoreis wp-admin, wp-content and wp-includes, we are actually dealing with WordPresss, and maybe face that recent vulnerable plugin.
The robtos.txt also confirms these directories on the web server.
And we see with the WordPress scan that we are actually dealing with the vulnerable version: 1.9.5 of bricks, which allows us to use RCE.
Initial Access
We familiarize ourselves with the security gap:
After a short research, we find a poc to get us a shell.
After cloning the repository, installing the requirements and executing the exploit, we get a shell.
We are the user apache and in the directory directly located to us, we find the hidden.txt which contains the first flag for the first question. Next, we upgrade the shell by using busybox to spawn a new reverse shell.
We then upgrade the shell after getting a connection to our listener.
If one of the automated exploits you can find doesn't work, we can turn to manual poc as an alternative. This is also depicted in the repository above.
First, we get the nonce using cURL and grep. Then we insert host and nonce to execute arbitrary commands on the system.
Analyzing Services And Running Processes
The next two questions are: What is the name of the suspicious process? What is the service name affiliated with the suspicious process? We try to answer those by checking out suspicious services first, we find an ubunut.service with a description fitting to the room.
To confirm that it might be the suspicious on, we check the status of the service to get eventually the running suspicious process. We see it is running nm-inet-dialog. Kinda odd that this is running that binary. After having downloaded that to our machine and checked it via Ghidra / Strings, it does not look like what it is supposed to be. Confirming that by testing the binary on Virustotal. We are already anticipating that these are the suspected service and process. Next, we described how we brought the binary onto our machine and analyzed it.
Further Investigation With Virustotal
There is a neat little trick if we have netcat available on our machine to transfer files. A short overview can be found here:
Run the following first on the receiving machine:
Next, we transfer the file with the following command on the sending machine.
We pass the binary to Virustotal and see that it is indeed flagged as malicious, in the description of the room we can see that is has to be miner related.
To answer the question, what the log file name of the miner instance is, we can investigate the opened files by the binary shown in virustotal.
There are some, but one stands out, since it is in the same directory as the binary itself, inet.conf.
Inside this we find an ID, looks like a bunch of hex.
Let's pass it to CyberChef after decoding it from hex in CyberChef we see it resolve to a Base64 string and this again resolve also to Base64. After decoding it completely, we receive a bc1 wallet address.
A Bitcoin address starting with bc1, is a Bech32 address which is part of the SegWit (Segregated Witness) protocol enhancement for Bitcoin. This type of address is already a standard and is widely supported for use in Bitcoin transactions. It is preferred by many due to its benefits in efficiency and reduced transaction fees.
That's the one referring to the penultimate question.
But be careful, these are two concatenated bc1 addresses, if you look carefully, it starts with bc1 again from the middle. So for the answer, we only need the first half.
Using google we can find some address search pages for Bitcoin addresses.
We are able to spot the wallet, and see some transaction. We go through all the transactions and search for all the addresses we find here in the list. Further down, we find a transaction of about 11 bitcoins to <REDACTED>z07r
Searching the plain address via Google, it resolves to a sanctions page where we find a name and email of the attacker.
Scrolling the search results further down, we are able to identify the threat actor:
