TryHackMe Billing Room Walkthrough Uncovers Critical VoIP Vulnerabilities and Fail2Ban Privilege Escalation

The cybersecurity training landscape recently expanded with the introduction of "Billing," a medium-difficulty room hosted on the TryHackMe platform designed to test advanced penetration testing methodologies against telecommunications infrastructure. Centered around MagnusBilling—an open-source Voice over IP (VoIP) billing platform built on top of the Asterisk Private Branch Exchange (PBX) service—the challenge highlights the complex security considerations inherent in enterprise communication systems. Unlike standard content management system (CMS) environments, this specialized target exposes a domain-specific attack surface comprising payment gateway integrations, dedicated call manager ports, and telephony backend management panels. The exercise guides security practitioners through an end-to-end compromise, beginning with an unauthenticated remote code execution vulnerability in a third-party payment plugin and culminating in a sophisticated privilege escalation vector that leverages the fail2ban intrusion prevention daemon to achieve root access.

Reconnaissance and Service Enumeration

The investigative process commenced with comprehensive network reconnaissance to map the target’s exposed attack surface. Deploying port scanning utilities such as RustScan against the designated host revealed a distinct telecommunications-oriented service stack running on a Debian-based Linux environment. The enumeration phase identified four primary open ports: TCP port 22 running OpenSSH 9.2p1; TCP port 80 hosting an Apache 2.4.62 web server serving the MagnusBilling application; TCP port 3306 operating a MariaDB database instance; and TCP port 5038 running the Asterisk Call Manager version 2.10.6.

Further web content discovery using directory fuzzing tools mapped out the structural directory layout of the MagnusBilling installation. The scan successfully identified core directories including lib/, fpdf/, alongside a cluster of third-party payment gateway integration directories such as icepay/, mercadopago/, stripe/, anet/, and PlacetoPay/. Security analysts noted that the deployment utilized a stock, uncustomized version of the application. In penetration testing methodology, third-party payment gateway plugins represent high-value targets because they are frequently maintained by external developers rather than the core application team, often resulting in less rigorous code reviews and a higher incidence of security flaws.

Exploitation of the Unauthenticated Foothold

Focusing initial exploitation efforts on the discovered payment integration modules, analysts examined the IcePay integration file located at icepay.php. The script accepted an external input parameter designated as democ. Upon analysis, the application failed to implement proper input sanitization or validation, directly passing the parameter string into an underlying shell execution context. This programming oversight is characteristic of insecure application design where user-supplied data is concatenated into system commands, typically intended for verification routines or diagnostic demo-mode checks.

By appending shell metacharacters such as semicolons, attackers can successfully chain arbitrary system commands to the execution flow. Security researchers leveraged this vulnerability by crafting an HTTP request containing a malicious payload designed to fetch and execute a reverse shell script hosted on an external command-and-control server. The injection string utilized a plausible harmless value (/dev/null) followed by a command separator, successfully executing a curl and bash pipeline without requiring prior authentication.

Upon triggering the vulnerable parameter via an HTTP GET request, the external listener successfully caught an incoming connection. The resulting interactive shell dropped the session into the system context of the asterisk user account—the dedicated service account under which the Asterisk PBX and MagnusBilling background services operate. This initial foothold provided immediate access to local user enumeration files, successfully recovering the user-level flag (user.txt) located within the /home/magnus directory.

Privilege Escalation via Fail2Ban Client Misconfiguration

Following standard post-exploitation enumeration protocols, security analysts executed the sudo -l command to evaluate the current user’s permitted administrative privileges. The output revealed a critical system misconfiguration: the asterisk user was explicitly authorized to execute the /usr/bin/fail2ban-client binary with root privileges without requiring a password (NOPASSWD).

Fail2ban is a standard security daemon deployed across Linux environments to protect against brute-force attacks and unauthorized access attempts. It operates by continuously monitoring log files for predefined malicious behavioral patterns and subsequently invoking automated responses, known as "actions," to ban offending IP addresses—typically by modifying local firewall rules via iptables. The operational logic of fail2ban relies heavily on "jails" (which define monitored logs and filters) and "actions" (which specify the commands executed upon triggering a ban). Specifically, the actionban parameter dictates the exact shell command executed when a ban event occurs.

Initial hypotheses considered attempting to directly modify the global fail2ban action configuration files located in /etc/fail2ban/action.d/. However, standard file permissions restricted write access to the root user, rendering direct file tampering unviable. Further examination of the fail2ban-client utility revealed that administrative users possessing execution rights can dynamically redefine jail actions in real time entirely through command-line arguments, bypassing the need for persistent file modifications on disk.

To exploit this capability, analysts queried the active fail2ban status to list running jails, identifying several targets including sshd. Using the permitted sudo execution right, the fail2ban-client binary was instructed to update the actionban rule for the sshd jail. The original iptables-based ban action was substituted with a malicious command designed to execute a reverse shell payload upon triggering. Because fail2ban operates with root privileges to manage system firewall configurations, any command defined within the actionban directive executes automatically under the security context of the root user.

To force the newly redefined action to execute immediately without waiting for genuine authentication failures from external entities, analysts simulated a ban event by manually instructing fail2ban to ban the local loopback address (127.0.0.1) against the sshd jail. Satisfying the ban condition instantly triggered the modified action command. A secondary netcat listener configured on the attacker’s machine successfully captured the incoming connection, granting an interactive root shell and allowing analysts to retrieve the final administrative flag (root.txt) from /root/root.txt.

Technical Analysis of Implications and Vulnerability Mitigations

The successful compromise of the Billing target underscores two critical classes of security failures frequently observed in modern enterprise architectures: inadequate input validation in third-party software extensions and the dangers of over-permissive administrative access control lists.

Software Vulnerabilities and Application Security

The presence of an unauthenticated command injection vulnerability within the IcePay payment module demonstrates the systemic risks associated with modular web applications. Organizations deploying open-source platforms like MagnusBilling must establish rigorous patch management schedules and perform comprehensive code reviews on all integrated plugins, particularly those handling financial transactions or external API communications. Mitigation strategies for this vector require strict input validation, the implementation of parameterized system calls rather than raw shell execution, and the utilization of strict allowlisting for callback parameters.

Access Control and Principle of Least Privilege

The privilege escalation path identified in this exercise emphasizes the risks of misconfigured sudoers policies. Granting unrestricted execution rights to a client binary such as fail2ban-client—even if the underlying tool is intended for defensive security monitoring—equates to granting root access. Because client utilities often include subcommands or argument structures capable of altering application behavior, security administrators must strictly scope permitted commands to non-destructive, read-only operations where necessary, or eliminate unnecessary sudo permissions for low-privileged service accounts entirely. Service accounts running web-facing applications like Asterisk or MagnusBilling should operate under the strictest possible operational constraints to minimize the blast radius in the event of an initial application compromise.

Chronology of the Security Assessment

1. Initial Reconnaissance: Port scanning via RustScan identifies open ports 22 (SSH), 80 (HTTP/MagnusBilling), 3306 (MariaDB), and 5038 (Asterisk).
2. Directory Fuzzing: Feroxbuster maps the web application structure, highlighting third-party payment gateway directories including IcePay.
3. Foothold Acquisition: An unauthenticated command injection flaw in icepay.php (democ parameter) is exploited using shell metacharacters to execute a reverse shell via curl and bash.
4. User-Level Compromise: Successful execution drops an interactive shell as the asterisk user, enabling the retrieval of user.txt.
5. Privilege Escalation Enumeration: Executing sudo -l reveals NOPASSWD access to /usr/bin/fail2ban-client.
6. Live Action Redefinition: The fail2ban-client utility is leveraged to dynamically modify the actionban command for the sshd jail.
7. Triggering the Defense Mechanism: Manually banning 127.0.0.1 forces fail2ban to execute the injected payload with administrative privileges.
8. Root-Level Compromise: An incoming administrative reverse shell is established, allowing the retrieval of root.txt.