![Tools](
![Status](
**Objective:** Gain an initial foothold via an exposed web application and escalate privileges by abusing a security tool's configuration.
**Gain a shell, find the way, and escalate privileges to root.**
This room demonstrates a complete attack chain:
`Recon → Web Enumeration → RCE → Initial Shell → Enumeration → Fail2Ban Abuse → Root`
The first step was to perform network enumeration against the target.
I used Nmap with service/version detection and default scripts:
The scan identified multiple services running on the target. The HTTP service on port 80 was particularly interesting because Nmap identified the HTTP page title as:
This gave us our first strong indication of the web application running on the target.
The important discovery from the HTTP enumeration was:
This is how the application was initially identified.
The application was also accessible through the **/mbilling/** path.
Research vulnerabilities affecting MagnusBilling
In a real penetration test, I would not assume that an application is MagnusBilling simply because port 80 is open.
Instead, I would fingerprint the application using multiple sources of information.
The important lesson is: **An open port identifies a service, not necessarily the application. Further enumeration is required to fingerprint the application.**
After identifying MagnusBilling, I searched for known vulnerabilities affecting the application.
The vulnerability used in this room was: **CVE-2023-30258**
The vulnerability allows **unauthenticated remote command execution against vulnerable MagnusBilling installations.**
exploit/linux/http/magnusbilling_unauth_rce_cve_2023_30258
The module was located by searching Metasploit for MagnusBilling-related exploits.
use exploit/linux/http/magnusbilling_unauth_rce_cve_2023_30258
Before running the exploit, I examined the available targets.
> **Why Was the Unix Command Target Selected?**
The reason was based on the target environment and the objective.
- The target was identified as a Linux host, and the goal was to obtain operating-system command execution and ultimately a shell.
Therefore, the Unix Command target was appropriate.
- The important point is that the target number itself should not be memorized.
For a different exploit, target 1 could mean something completely different.
The local callback address was configured:
The exploit successfully established a command shell on the target.
After exploitation, an initial shell was obtained.
The result showed that this was a low-privileged account.
This is an important point in a penetration test:
**Obtaining a shell does not necessarily mean that the machine has been fully compromised.**
At this stage, the objective changed from initial access to local enumeration and privilege escalation.
After obtaining the initial shell, I began enumerating the local system.
One of the first areas to inspect was the **/ ** directory:
The system contained a directory associated with the magnus user.
The user's directory was then examined.
After obtaining the user flag, the objective was to escalate privileges.
A standard Linux privilege-enumeration step is checking the current user's sudo permissions.
User magnus may run the following commands:
This indicates that the command can be executed as another user, including root.
The user does not need to provide a password when executing the permitted command through sudo.
This is the specific program that the user is allowed to execute with elevated privileges.
This configuration was therefore worth investigating.
Before exploiting the configuration, it is useful to understand what Fail2Ban does.
Fail2Ban is a Linux security tool designed to detect suspicious activity by monitoring log files.
For example, an SSH service might generate repeated failed-login messages:
Failed password for admin from 10.10.10.20
Failed password for admin from 10.10.10.20
Failed password for admin from 10.10.10.20
Fail2Ban can detect these repeated failures and take an action against the source IP.
Fail2Ban therefore normally operates with elevated privileges because it may need to modify firewall rules or perform other system-level actions.
Because magnus had permission to execute fail2ban-client through sudo, I used it to enumerate the active Fail2Ban configuration.
The command showed several active jails, including:
One of the jails, ast-cli-attack, was investigated further.
I checked the actions associated with the jail:
sudo /usr/bin/fail2ban-client get ast-cli-attack actions
An existing action associated with the jail was returned.
The important discovery was that, because **fail2ban-client** was available through privileged **sudo**, the jail's action configuration could be manipulated.
This created a potential privilege-escalation path.
Determine whether an action can be modified
## 🚨 13. Creating a Malicious Fail2Ban Action
A new action called **evil** was added to the **ast-cli-attack jail**:
sudo /usr/bin/fail2ban-client set ast-cli-attack addaction evil
The action was then configured so that its **actionban** command would execute:
sudo /usr/bin/fail2ban-client set ast-cli-attack action evil actionban "chmod +s /bin/bash"
## 🧩 14. Why Does **chmod +s /bin/bash** Matter?
sets the **SUID (Set User ID)** permission on the Bash binary.
SUID is a special Linux permission that causes an executable to run with the privileges of the file owner.
If Bash is owned by root and has the SUID bit set, it can potentially be used to obtain a shell retaining root privileges.
The key issue is that Fail2Ban was operating with elevated privileges while we were able to manipulate an action through the privileged **fail2ban-client** interface.
The malicious action was triggered by banning an IP address:
sudo /usr/bin/fail2ban-client set ast-cli-attack banip 1.2.3.5
This caused Fail2Ban to execute the configured **actionban** command.
The SUID permission was therefore applied to Bash.
With the SUID permission applied to Bash, I launched Bash using:
The **-p** option is important because it tells Bash to preserve the privileged effective user ID instead of dropping it.
This confirmed successful privilege escalation.
With root access obtained, the root flag was retrieved: