Trick HTB
Trick Attack Summary Performed initial enumeration with Nmap and discovered exposed services including DNS, HTTP, SSH, and SMTP. Abused a misconfigured DNS server to perform a successful zone transfer and discover hidden subdomains. Identified the preprod-payroll.trick.htb application and bypassed authentication using SQL Injection. Used sqlmap to enumerate databases, dump application credentials, and read sensitive files from the server. Extracted Nginx configuration files and discovered another hidden virtual host: preprod-marketing.trick.htb. Analyzed the vulnerable PHP source code and bypassed weak directory traversal protections to achieve Local File Inclusion (LFI). Read Michael’s SSH private key through the LFI vulnerability and gained an initial shell via SSH. Enumerated sudo permissions and discovered that the michael user could restart Fail2Ban as root. Leveraged writable Fail2Ban action configurations to inject a malicious reverse shell payload. Triggered Fail2Ban through failed SSH login attempts and obtained a root shell. Extracted the root SSH private key and logged in directly as the root user. --- Enumeration Nmap Scan As usual, the first step was to perform a full service and version scan against the target machine to identify exposed services and gather initial information about the environment. --- Nmap Scan Analysis From the Nmap scan, four interesting ports were identified: | Port | Service | Description | |---|---|---| | 22 | SSH | OpenSSH service running on Debian | | 25 | SMTP | Mail service | | 53 | DNS | ISC BIND DNS server | | 80 | HTTP | Nginx web server | A few important observations from the scan: The target appears to be running Debian Linux Port 53 exposed a DNS service, which is always interesting during enumeration because it may allow: zone transfers subdomain discovery internal hostname disclosure Port 25 exposed an SMTP service, which could potentially leak usernames or mail-related information Port 80 hosted a web application behind an Nginx server Among all the exposed services, the DNS service on port 53 looked especially interesting because misconfigured DNS servers can often reveal hidden subdomains or internal infrastructure. The next step was to start enumerating the web application and investigate the DNS service further. DNS Enumeration Since port 53 was exposed and running an ISC BIND DNS server, the next step was to perform DNS enumeration. Based on the machine name, the hostname trick.htb was guessed as the primary domain. One common misconfiguration in DNS servers is allowing anonymous zone transfers (AXFR), which can leak internal DNS records and subdomains. To test for this, a DNS zone transfer was attempted using dig: The zone transfer succeeded successfully, which confirmed that the DNS server was misconfigured. Most importantly, the output revealed a new subdomain: The name strongly suggested that this might be a pre-production payroll application, which could potentially contain vulnerabilities or development functionality not present in production systems. --- Adding the Domain to /etc/hosts To access the discovered virtual host correctly through the browser, the domain and subdomain were added to the local /etc/hosts file. After updating the hosts file, the newly discovered subdomain became accessible locally for further web enumeration. Exploring the Payroll Application After adding the discovered subdomain to the /etc/hosts file, the application was opened in the browser. The page returned a login portal: image The title of the page revealed the application name: image The application appeared to be an employee payroll management system running in a pre-production environment. Since login portals are common targets for authentication bypass vulnerabilities, the next step was to test the login functionality for SQL Injection. --- SQL Injection Authentication Bypass A basic SQL Injection payload was tested inside the username field: The password field was filled with random data because the injected SQL condition would bypass authentication regardless of the password value. image The login bypass succeeded successfully, confirming that the application was vulnerable to SQL Injection. At this point, authenticated access to the payroll management panel had been achieved. --- Capturing the Login Request with Burp Suite To investigate the SQL Injection vulnerability further, the login request was intercepted using Burp Suite. Capturing the raw request would allow automated testing and deeper database enumeration using tools such as sqlmap. image The intercepted request was then saved to a file for use with sqlmap during further exploitation. Database Enumeration with SQLMap After confirming the SQL Injection vulnerability manually, the next step was to automate database enumeration using sqlmap. The intercepted login request from Burp Suite was saved as login.txt and supplied to sqlmap using the -r option. To enumerate available databases: The application was confirmed to be vulnerable to: Boolean-based Blind SQL Injection Time-based Blind SQL Injection The backend database was identified as MariaDB/MySQL. Most importantly, a database named: was discovered, which likely stored application credentials and payroll-related information. --- Enumerating Tables The next step was to enumerate the tables inside the payroll_db database: The users table immediately looked interesting because it likely contained administrative credentials. --- Dumping the Users Table The contents of the users table were dumped using: Valid application credentials were successfully recovered: --- Attempting SSH Login Since SSH was exposed on port 22, the recovered credentials were tested against the SSH service: The credentials were valid for the web application but did not work for SSH authentication. At this point, additional attack vectors needed to be explored. --- Reading Files with SQLMap After further investigation, it was discovered that the SQL Injection vulnerability could also be abused for arbitrary file reading. Some MySQL/MariaDB configurations allow database users to read local files from the server using functions like LOAD_FILE(). sqlmap automates this capability through the --file-read option. Reading Files from the Target System Since the SQL Injection vulnerability allowed file reading through sqlmap, the next step was to start enumerating sensitive files from the server. A simple test was performed by reading /etc/hostname to confirm that arbitrary file access worked correctly. After the file was downloaded locally by sqlmap, the contents were inspected: The hostname confirmed that the file read attack was working successfully. --- Reading Nginx Configuration Files From the initial Nmap scan, port 80 was identified as an Nginx web server. Web server configuration files are often valuable because they may reveal: hidden virtual hosts internal applications alternate document roots sensitive paths The main Nginx configuration file was targeted next: Since file extraction through blind SQL Injection can take time, the download process may be slow. After inspecting the retrieved configuration file, the following lines were discovered: This revealed that the active virtual host configurations were stored inside: --- Discovering Additional Virtual Hosts The next step was to read the default virtual host configuration file from the sites-enabled directory. Inside the configuration, a new subdomain was discovered: This revealed another hidden virtual host: The subdomain name strongly suggested another pre-production application, likely related to marketing functionality. --- Adding the New Subdomain To access the newly discovered virtual host correctly, it was added to the local /etc/hosts file: Exploring the Marketing Application With the new virtual host added to the /etc/hosts file, the application became accessible in the browser. Opening: returned the following webpage: image The site appeared to be a basic marketing application containing several navigation pages such as: Services About Contact However, most of the visible content appeared to be placeholder or junk data. Even though the site itself looked uninteresting, the URL structure revealed something much more important. --- Interesting URL Parameter Clicking the Contact link redirected to: This immediately stood out because many PHP applications use a structure where: index.php acts as the main template/controller the page parameter determines which file gets included dynamically This pattern is commonly associated with: Local File Inclusion (LFI) Directory Traversal vulnerabilities Another interesting observation was that directly visiting: loaded the same page content successfully. This suggested that: the HTML files physically existed inside the web directory the page parameter was likely being passed directly into a PHP include() function At this point, the next step was to inspect the backend source code responsible for handling the page parameter. --- Reading the Application Source Code Earlier, the SQL Injection vulnerability already allowed arbitrary file reading through sqlmap. Since the Nginx configuration had revealed the web root: the main application source file was retrieved using: The extracted PHP source code revealed the following logic: --- Understanding the LFI Protection The source code explained why previous Local File Inclusion attempts had failed. The developer attempted to prevent directory traversal attacks using: However, the implementation was weak and incomplete. Blacklist-based filtering is generally insecure because attackers can often bypass it using crafted payloads. --- Why Previous LFI Attempts Failed Absolute Path Attempts Attempts like: failed because the application prepended the path with: resulting in: which does not exist. --- Standard Directory Traversal Attempts Attempts such as: also failed because: removed all ../ sequences. The final path became: which again does not exist. --- PHP Filter Attempts Attempts using PHP filters also failed: because the application prepended: resulting in: which PHP interpreted as an invalid local path rather than a stream wrapper. --- Special Case for index.php The source code also explained why: simply loaded the normal homepage. When index.php included itself recursively, the page parameter was no longer set during the second execution, causing the application to fall back to: This behavior confirmed that the vulnerability existed, but required bypassing the weak traversal filter. --- Directory Traversal Filter Bypass Even without access to the source code, this style of filtering is a very common mistake in vulnerable PHP applications. The developer attempted to sanitize traversal sequences using: The problem is that str_replace() only removes exact matches of ../. By carefully crafting the payload, it becomes possible to recreate valid traversal sequences after the replacement occurs. For example: When the replacement happens internally: This effectively bypasses the filter and recreates a valid directory traversal payload. --- Successful LFI Exploitation Using the traversal bypass payload: the application successfully disclosed the contents of /etc/passwd. image At this point, arbitrary local file read access had been successfully achieved through the vulnerable page parameter. Obtaining Initial Shell as Michael After successfully exploiting the Local File Inclusion vulnerability, the next step was to look for sensitive files that could provide access to the system. SSH private keys are commonly stored inside a user's .ssh directory, making them valuable targets during LFI exploitation. The following payload was used to read Michael's private SSH key: image The request successfully disclosed Michael’s private SSH key: --- Saving the SSH Private Key The retrieved private key was copied and saved locally: After saving the key, proper permissions were assigned because SSH refuses to use keys tha